Skip to main content
search

An Inside Look at the Innovation happening in OSS Spinnaker’s CVE Process

By July 7, 2020November 1st, 2023Blog, Community

Contributed by Rin Oliver & Beth Fuller

CDF Newsletter – July 2020 Article
Subscribe to the Newsletter

“I once went to a security talk, and it was such a mind shift for me when they explained that the only way to guarantee a system is 100% secure, is to unplug everything. You take all the wires, you take all the, you know, your bare metal, you take all of it, you dig a ditch, you throw everything in there, and you cover it with concrete,” Beth Fuller, Sr. Product Manager at Armory

As our community continues to grow and evolve, so too do the needs of enterprises using Spinnaker to fuel business via software. With security and compliance top of mind, Armory.io Senior Product Manager Beth Fuller is one of many people helping to trailblaze the new CVE process for OSS Spinnaker. The Spinnaker Security Special Interest Group (SIG) has taken on this project, motivated to maintain a safe product that can easily adapt to security and compliance requirements across industries. 

Spinnaker excels at abstracting complex software lifecycles. In these, DevSecOps requires the daunting, yet essential, exercise of managing multiplying, distributed exploit vulnerabilities across a complex SDLC. To make this easier, the Spinnaker Security SIG is developing a protocol to create a CVSS score for each CVE found in the Spinnaker project. This will help security professionals and businesses alike understand the severity of the Common Vulnerabilities (CVEs), and define best practices to mitigate a particular CVE. “Having this threat model available for OSS Spinnaker is a critical factor in ensuring that the CVSS is defensible,” said Fuller. 

First, we’ll define the Vulnerability Management policy. Read on for a brief walkthrough of how the Spinnaker Security SIG plans to implement CVSS scores, what they are, and how this information will be used to improve and define OSS Spinnaker security best practices moving forward.

Demystifying CVEs and CVSS Scores

Let’s start with the basics. The Common Vulnerabilities and Exposures (CVE) list is a resource that catalogues publicly disclosed cybersecurity vulnerabilities and exploits. It provides a standardized identifier for each known vulnerability or exposure, defined with an ID number, a description, and at least one public reference. This common identifier allows security practitioners to quickly and accurately correlate data about a problem across multiple CVE-compatible information sources. With CVE, vulnerability scanners, intrusion detection systems, and commercial software can use that same identifier to link fixes, exploit attempts, and other relevant information to particular vulnerabilities. 

The Common Vulnerability Scoring System (CVSS) is an open framework that communicates the severity and characteristics of software vulnerabilities. CVSS scores range from 0.0-10.0. This numerical scoring framework helps organizations assess and prioritize their vulnerability management processes. Spinnaker’s Security SIG has begun that process by assigning qualitative severity ratings to score ranges:

  • A low CVSS score of 0.0-5.9 means that a CVE can be mitigated with reasonable effort, is currently mitigated through other established control methods, or is unable to be mitigated due to normal operations. 
  • A medium CVSS score from 6.0-10.0 is not actively exploitable and no known exploit has been made available to the public. 
  • A high CVSS score of 8.0-10.0 may be readily compromised by using malware or publicly available exploits. 

CVE Scoring for Spinnaker 

The process designed by the Security SIG has several steps for scoring CVEs in the Spinnaker project.

  • Front Door
    • The Security SIG will accept new vulnerability reports via security@spinnaker.io and will aim to respond to new reports within 1 week of receipt.
    • A SECURITY.md disclosure policy will be added via a template in the GitHub org to all Spinnaker GitHub repositories, explaining our requirements for responsibly disclosing security issues.
  • Evaluation
    • Members of the Security SIG with knowledge of affected Spinnaker services will review new reports to determine:
      • Whether the report contains a new issue and/or new information
      • Whether the vulnerability applies in the context of a deployed Spinnaker instance
      • What the CVSS c3.0 score of the vulnerability in the Spinnaker context
      • What exploits or proof-of-concept code exist to take advantage of the vulnerability
      • What services and release versions are affected by the vulnerability
  • Tracking
    • Vulnerability tracking will take place in a private issue-only GitHub repository under the Spinnaker organization, and issues will be visible to members of the Spinnaker Security SIG for review. 
    • Each issue will track the following attributes:
      • The CVE ID of the vulnerability in question
      • Its CVSS 3.0 score
      • The severity of the vulnerability against current taxonomy
      • An explanation of the vulnerability and any components that are impacted by it
      • The current state of the vulnerability against the most recent release
      • The security SIG’s response to the vulnerability, and an anticipated timeline by which the Security SIG aims to address the vulnerability
  • Mitigation 
    • The Security SIG will identify individuals to develop patches or other workarounds for vulnerabilities that are deemed security risks 
    • All updates will be tracked in the relevant GitHub issue
    • Once a vulnerability is ready to publicly announce, the CVE record will be updated and the private GitHub issue will be copied to the affected service’s public repository
    • Mitigated vulnerabilities will be included in application release notes

We’ve Got Standards. Now What?

By setting these standards, the Spinnaker Security SIG aims to fulfill the needs and requirements of enterprises using Spinnaker in production environments. The reporting, scoring, and tracking process is key to the success of the Security SIG’s Spinnaker Vulnerability Management pipeline. Fuller stresses that no matter what market your organization is in, seeing all of your CVEs listed can be intimidating, even scary. For example, if a codebase has an XML piece somewhere in its infrastructure with a CVE rating of 8 or 9, that poses a significant risk. If no-one can to exploit that piece of code based on where it’s located, to the point that its difficulty is nearly impossible, after that CVE goes through the CVSS scoring process, its severity may then be brought down to a 1.9. This would mean that it was no longer a significant and worrisome threat.

While organizations may have their own policies around CVSS scores, the Security SIG hopes that raising visibility into CVEs and determining scores based on threat models built by experts in the community will encourage public trust in Spinnaker CVSS scoring. It will allow for organizations to document their CVEs, determine their actions based on CVSS Scoring, and make better decisions as to how to document patches, and address security exploits. This will also be documented in the upcoming Spinnaker 1.1.21 release, Fuller noted. “You’re creating that level of visibility, so as security-minded people come in, they don’t have to guess if it’s a scary thing. We’re giving them the information so they don’t have to guess. They can just have a better understanding of why it is that we’re not fixing this thing that looks scary on the face of it. So, I think for the community, that’s going to be a big win.”

Help Build Modern Security Solutions for Safe Software Delivery Collaboration

Alongside other subject matter experts such as eCISCO CEO Jeff Kohrman, and companies such as Salesforce and OpsMX, Fuller hopes that anyone interested in documentation, security, DevSecOps, and improving the security of OSS Spinnaker will get involved in the Security SIG. “You don’t have to be a security person to join, we are anyone interested in security. If you want to come from a documentation perspective and help us—Oh my gosh—We need that,” Fuller said, adding that sometimes it’s even better if participants don’t have a security background because everyone starts to then consider what it means to truly create a secure environment.

No two software delivery life cycles are alike, so exchanging ideas, fresh perspectives, and best practices raises the security bar for everyone. Fuller points out the value of sharing expertise that may not have been considered if everyone involved in a discussion had the same background and experience.

The Spinnaker Security SIG welcomes all who wish to contribute to join the Spinnaker Slack SIG-Security Channel, and to attend community meetings which take place every other Thursday at 11:00 AM PST/2:00 PM EST. The next meeting takes place on July 16, which happens to be the first day of Spinnaker Gardening Days week, an open source virtual hackathon. The Security SIG will form a team to tackle threat model development for common deployment endpoints. Register now to join SIG members in solving real-world issues facing the OSS Spinnaker and DevSecOps communities today.

Close Menu