Dive into the key insights from our recent DevOps Downloads webinar, featuring Stephen Magill, Vice President of Product Innovation at Sonatype.
This frequently asked questions (FAQ) resource distills Stephen’s expertise on safeguarding development environments against intentionally malicious and vulnerable components. We’ve refined the responses for clarity and brevity.Frequently Asked Questions
What is the standard process for officially identifying vulnerabilities, and how do organizations contribute to this process?
What is the standard process for officially identifying vulnerabilities, and how do organizations contribute to this process?
The official source for identified vulnerabilities is the CNAs — the CVE numbering authorities, where CVE is the Common Vulnerabilities and Exposures list managed and published via MITRE services.
Sonatype contributes to industry knowledge of vulnerabilities by identifying them before they have an official CVE number. In that case, we would assign our own identifiers, and then if a CVE gets assigned later on, we’ll add that as additional information on that vulnerability. To identify emerging vulnerabilities we pull from a number of public sources, various vulnerability feeds, disclosure forums, and so forth. In addition to the information that we add to identify vulnerabilities, as our security researchers take a deeper dive into the cause of these issues they can identify additional insight into the vulnerability and this contributes to providing a clearer picture.
Should I implement something like a risk score to assess and prioritize the security risks associated with multiple vulnerabilities in a single application?
Should I implement something like a risk score to assess and prioritize the security risks associated with multiple vulnerabilities in a single application?
A risk score system can provide concise insight into the security risk for an application. There’s this question “When you have an application that has several components that have vulnerabilities — five low-profile, two high-profile, and one critical — how do you aggregate that? What’s the right way to view that risk? Do the loads really combine to be something you should worry about, or should you mostly focus on the critical? So, we do have algorithms we’ve developed to fold all of that vulnerability information into a single risk score that you can focus on.
How can developers evaluate the trustworthiness and quality of open-source components and projects?
How can developers evaluate the trustworthiness and quality of open-source components and projects?
Evaluating the quality and trustworthiness of open-source components and projects is essential for ensuring the security and reliability of software. Researchers have identified several key factors that can help you understand a project's quality and security posture. These include the presence of a code review process, which has been shown to be highly correlated with positive security outcomes.
OSS Index and Maven Central are free resources where developers can find information about vulnerabilities in open-source software packages. There are attributes of projects that are important from a security standpoint and that vary from project to project. As part of that work, we found, not surprisingly, that having a code review process in place was super important, very highly correlated with security outcomes. Similarly, not checking in binary data to the repository.
All of these things that we looked at are tracked by the OpenSSF Scorecard project. If you’re looking for good raw data on project quality, I would go look at OpenSSF and their scorecard information. That binary component bit was also very predictive, which I think is interesting. We did this work a couple of years ago before the XZ attack. And then a big part of the XZ attack was that the malicious payload was hidden in a binary file that was part of that repository. So it’s an example of why that’s important.
Sonatype also releases our State of the Software Supply Chain report, where we take a look at the various quality measures, comparing them and developing additional ways to gauge project quality.
Managing vulnerabilities with Sonatype
A proactive approach with Sonatype’s tools ensures that vulnerabilities are caught early — often before they receive official CVE numbers — allowing your teams to mitigate risks promptly.
For a deeper understanding of our vulnerability management processes and to gain more insights from industry experts like Stephen Magill, we invite you to access the full webinar and explore further resources on our DevOps Downloads homepage.
Trust Sonatype to empower your organization with the knowledge and tools needed to navigate the complex landscape of security vulnerabilities.