SnykSecProprietary severity scoring often burdens AppSec teams. With every new vendor, you must evaluate their custom severity framework and work to translate assessed risk between tools.To eliminate this burden and provide our customers with a clear security assessment for configurations across the SDLC, Snyk will be moving towards standardizing our code to cloud security rules set on the Common Configuration Scoring System (CCSS)!
With this update from the Snyk Security Research team, we continue our mission to empower developers and security teams alike with a better way to assess, prioritize, and triage security issues, fostering a more secure and efficient development lifecycle.
The rules and rule severity used by our newest version of Snyk Infrastructure as Code (IaC), IaC+, will be evaluated according to CCSS. As a result, Snyk will be able to provide customers with more accurate risk scoring for their infrastructure as code and cloud configurations based on technical severity (CCSS), threat intelligence, and application and business context.
What’s in a severity?
Industry standard frameworks such as Common Vulnerability Scoring System (CVSS) and Common Configuration Scoring System (CCSS) provide us with a valuable methodology for scoring vulnerabilities and provide a common language for everyone. It means providers don’t have to invent their own framework, and consumers can directly compare vendors without the burden of translation.
In a nutshell, these frameworks define a number of metrics plus a set of formulas that convert those metric values to a score from 0 to 10 and a severity corresponding to low, medium, high, or critical.
What is the Common Configuration Scoring System?
The Common Configuration Scoring System (CCSS) was created by the National Institute of Standards and Technology (NIST). Derivedt from CVSS, it modified to address software security configuration issues. Since IaC misconfigurations are essentially security configurations, we can apply CCSS to them.
Standardizing with CCSS addresses a number of previously mentioned issues. It uses familiar, CVSS-based terminology, metrics, and formulas to assign vectors to IaC misconfigurations from which we can determine an issue’s score and severity.
Thus, it allows us at Snyk to replace our previous process for assigning severity to IaC misconfigurations. Moving to the CCSS standard also allows Snyk to be more transparent by displaying the vector, score, and severity without a large learning curve, much like we currently do with CVSS vulnerabilities.
The CCSS vector for the above issue is AV:L/AC:H/Au:M/C:P/I:C/A:N/PL:U/EM:A. This gives us a base score of 8.3 and severity of High. The first six metrics are shown in the graphic above, but the last two, PL and EM, or Privilege Level and Exploitation Method, respectively, are not. The main reason is that these two metrics do not affect the base score even though they play important roles.
Privilege Level can be either User, Application, Root, or Not Defined and indicates the level of unauthorized access an attacker could gain. For the purposes of the base vector and base score PL acts to supply additional information to consumers and is used when calculating certain environmental metrics.
Exploitation Method is a bit more interesting as many of the base metrics’ values depend on the value of the EM metric. The EM metric’s value can be either Active or Passive. Active misconfigurations expose a vulnerability that can be exploited by an attacker, such as allowing AWS S3 buckets to be publicly readable or exposing a database with a default root user password. Passive misconfigurations are categorized as preventing authorized actions from occurring or something that makes a defender’s life more difficult. Some examples include disabled API logging or database backups that are not retained for a sufficient amount of time. Passive misconfigurations are typically an error or policy violation that is quickly mitigated, whereas Active misconfigurations can be more involved and require more planning and analysis.
How did we implement CCSS at Snyk?
Snyk has a large set of security rules to check the security of IaC and cloud configurations with severities assigned using the previous process. Manually adding CCSS vectors, calculating scores, and deriving new severties would be a tedious task to perform manually. Scripting would help, but it lacks decision-making capabilities. Fortunately, there’s a better way!
By integrating AI into the implementation process, we have streamlined the adaptation of our existing rule set to align with CCSS standards. Our use of AI guided by prompts, enriched with our unique expertise, ensures that the severity of each misconfiguration is determined with consistency and precision. This advancement not only enhances the transparency and reliability of our security assessments for our users but also reinforces Snyk's commitment to leading the industry in developer-centric security practices.
Armed with our prior experience of leveraging AI, we set to work condensing the CCSS specification into a prompt along with additional guidelines based on our investigation. After analyzing the outcome, our severity breakdown goes from:
To the following:
The graphs above illustrate that our previous Snyk severity ratings were often far more conservative than CCSS.
Standardizing our severity system on CCSS not only gives us a repeatable process for determining rule severity but also preserves valuable contextual data for in-depth analysis, such as Snyk’s risk score. Moreover, an analysis of the distribution of base scores across our dataset reveals a bell curve pattern. This is consistent with the expected statistical distribution for scores ranging from 0 to 10, reaffirming the reliability of the CCSS method in producing balanced and predictable severity assessments powered by AI.
What’s next for Snyk IaC?
Keep an eye out for security research updates and our rollout of CCSS severity on updates.snyk.io!
If you’d like to learn more about the Common Vulnerability Scoring System (CVSS) that has been around for almost two decades, we’ve covered it many, many times.
If you’d like to learn more about the use of AI as a development tool to augment our security research process, we’ve written about it here — including some best practices.
