This blog post has been archived and replaced by the supporting pillar page that can be found here:
https://anchore.com/wp-admin/post.php?post=987473370&action=editThe blog post is meant to remain “public” so that it will continue to show on the /blog feed. This will help discoverability for people browsing the blog and potentially help SEO. If it is clicked on it will automatically redirect to the pillar page.
Hello friends. My name is Josh and I’ve just started at Anchore as the Vice President of Security. I’ll talk more about what the role means in future posts, but for the moment I want to answer a few questions that are top of mind right now. Namely, what do I think the future of software supply chain security looks like and why did I choose to work with Anchore to help organizations better protect their software supply chains.
Back in 2004 I started working on the Red Hat Product Security Team. My focus has always been on securing the open source we all use every day. Back then we were securing the open source supply chain, but there wasn’t really a name for this practice yet. I have always felt very strongly about the integrity and security of software products as well as the security of open source. It’s a happy coincidence that these two topics have merged in the last few years!
Today open source software makes up a majority of the code in almost every software application we use. Combining open source with cloud platforms and modern development technologies has completely changed the way we build and deliver software applications. These changes have helped us to fundamentally transform how we interact with technology in our jobs and our lives. But now, this dependence on software, and the supply chain that produces it, has created a new set of attack points for bad actors. I believe this industry-wide and economy-wide realization will change the foundations of how we build, deliver, and use technology.
There was once a time the security team would end every conversation with “if you don’t listen to us someday you’ll be sorry.” Nobody was ever sorry. But the world has changed a lot and that “someday” may be now. There are many new threats and attacks that create significant and measurable losses. Breaches are expensive, ransomware is expensive, personal data has monetary value now. Anchore’s 2021 Software Supply Chain Security Report found that 64% of organizations had been impacted by a software supply chain attack in the past year. We exist at a nexus point that has made the risk very real. Every company has gone digital with almost everything online now, DevOps has made the number of services uncountable and the pace of change almost unmeasurable. Meanwhile, the adversaries are organized and highly motivated. Separately any one of these factors might be manageable, but when you put it all together we need to completely rethink the approach to software supply chain security. Big problems need bold new ideas.
We are also in a period of disruptive change that allows for new ideas and real change to happen much faster than normal. The explosion of ransomware and increasing supply chain attacks against the backdrop of a global pandemic that have changed the very foundations of society, are creating the imperative to act. As we witness the growing attention software supply chain security is getting, it’s important to notice that we are no longer just talking about software supply chain security, we’re actually taking concrete steps to solve the problems.
Now we are starting to understand what the future will look like as we move toward solutions that will help better protect the software supply chain against these growing risks. In the past it was very common to conduct a security review once a product was “done”. This often resulted in a lot of missed security vulnerabilities being run in production or delivered to customers. Modern day development has changed such that security is expected to be tightly integrated into every step of the development process. This is where the term “shift left” originated.
We are already seeing the beginning of this change with the growing attention paid to the software bill of materials (SBOM) and vulnerability scanning as critical components of software supply chain security. Neither of these ideas are new, but we are seeing convergence around SBOM standards. There are groups like The Linux Foundation’s OpenSSF and the Cloud Native Computing Foundation (CNCF) that are working in the open source ecosystem to create a common understanding of the problems and define potential solutions. The United States Cybersecurity and Infrastructure Agency (CISA) has a supply chain task force. Conferences have entire supply chain tracks to share emerging best practices. The time to address software supply chain security is here.
There are new practices, processes, and tools that will need to be put into place to protect the software supply chain. While the importance of SBOM and vulnerability scanning is well understood, the critical challenge is in using the data to improve security. I think what we do with this data is the biggest area for improvement. Having an SBOM by itself isn’t useful. You need the ability to store it, track it over time, to aggregate the data, search the data, and get back actionable answers to questions. The same holds true for vulnerability scanning. Just scanning software after it has been built isn’t enough. What happens after the scan runs? How do you use the data to identify and remediate problems to reduce risk?
I want to use the Heartbleed vulnerability as a great example of where we started, where we are today, and where I want to see us go next. If you were around for Heartbleed, it was an eye opening experience. Just determining which systems you had running a vulnerable version of OpenSSL was a herculean task. Most of us had to manually go looking for files on a disk. Today with our ability to generate and distribute SBOMs, it’s not hard to figure out what systems are using OpenSSL. We can even construct policies now that could prevent a new build or deployment that contains an old version of OpenSSL.
The future I want to see is having insight into your end-to-end software supply chain and the security of the software you create and use. Being able to craft policies that can be enforced about what your software should look like. Not just having the ability to ask what a vulnerability or bug means for your application, but having tools that tell you before you even ask the question.
This all brings us to Anchore. I’ve known about Anchore for quite some time. In my previous role in Product Security, I worked with a large number of organizations focused on software supply chain issues. This included open source projects, software vendors, consultants, and even supply chain working groups. It became very obvious that while there was increasing focus on software supply chain security, there wasn’t always a consensus on the best practices or tooling needed.
The current state of tools is very uneven. Few tools provide comprehensive SBOMs with all of the relevant metadata needed to make accurate security assessments and decisions. Some scanning tools want to report zero false positives, resulting in lots of false negatives. Other tools simplistically report every possible vulnerability which results in lots of irrelevant false positives. I’m not looking to point any fingers here, this is all very new and everyone is continuing to learn. In my experience the sweet spot is somewhere in the middle—some false positives should be expected, but too many or too few are both bad. The purpose of tooling is to help provide data to make decisions. Bad data results in bad decisions.
Every time I interacted with any organization in the software supply chain space, I kept seeing Anchore as occupying the sweet spot in the middle over and over again. Anchore starts from a foundation of open source tools that are easy for developers to integrate and use. Syft, an open source SBOM generator, is incredibly useful and accurate. Grype, an open source vulnerability scanner, is one of the best vulnerability scanners I’ve ever used. Anchore’s commercial product, Anchore Enterprise, builds on that open source foundation and adds some powerful features for cataloging SBOMs, remediating vulnerabilities, and enforcing policies. Everywhere I looked it seemed that Anchore was the one company that “got it.” Anchore was doing all the things that were important to me in a way that made sense. Relevant scanning results, easy SBOM creation and use, and the ability to leverage existing policies (like CIS) instead of trying to build new ones.
And lastly, open source. Open source isn’t something I think is a good idea, it’s part of who I am. My entire life has been shaped and built within the open source community. I know anywhere I work has to be extremely open, very open source friendly, and have a culture that mirrors the ways open source thinks and works. Anchore has the open source culture and open source focus that I know is so very important. They have a whole blog dedicated to their culture, give it a read, it’s fantastic!
The easiest way to see what’s next is to give the Anchore open source tools a spin. Generate an SBOM with Syft. Then scan the SBOM file for vulnerabilities with Grype. It’s all open, try them out, file some bugs, submit pull requests. Open source works best when everyone works together.
If you want to pull it all together for an end-to-end solution for securing your software supply chain, check out Anchore Enterprise. It’s a nice way to tie the tools together in one place to meet the needs of a larger organization or multiple teams.
I love to talk about these topics. If you’re interested in having a chat or even just saying hi feel free to reach out. Watch this space, there’s a lot to talk about, and even more work to do. It’s going to be a truly epic adventure!
Last week the United States Cybersecurity and Infrastructure Security Agency (CISA) published a binding operational directive describing a list of security vulnerabilities that all federal agencies are required to fix. Read the directive here: https://cyber.dhs.gov/bod/22-01/
The directive establishes a CISA-managed catalog of known exploited vulnerabilities that carry significant risk to federal agencies. The list can be found here: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
While CISA’s directive is binding only on U.S. federal agencies, companies can also leverage this catalog to prioritize vulnerabilities that may put their organization at risk.
There has been a lot of discussion about this directive and what it will mean. Rather than add commentary about the directive itself, let’s discuss what’s actually inside this list of vulnerabilities and what actions you can take to check if you are using any of the software in question.
It’s important to understand that the list of vulnerabilities in this catalog will not be static. CISA has stated in their directive that the list will be modified in the future, meaning that we can expect more vulnerabilities to be added. Even if a federal agency is not currently running any of the vulnerable software versions, as the list grows and evolves and the software that is running evolves, it will be important to have a plan for the future. Think about handling vulnerabilities like delivering the mail. Even if you finish all your work by the end of the day, there will be more tomorrow.
If you work with lists of vulnerabilities you will be used to vulnerabilities having a severity assigned by the National Vulnerability Database (NVD). The NVD is a U.S. government repository of vulnerability data that is managed by the National Institute of Standards and Technology (NIST). The data in NVD enriches the CVE data set with additional product information as well as a severity rating for the vulnerability based on the CVSS scoring system.
It is very common for policy decisions to be made based on the NVD CVSS severity rating. Any vulnerability with a CVSS score of critical or important is expected to be fixed very quickly, while more time is allowed to fix medium and low severity vulnerabilities. The idea is that these severity ratings can help us decide which vulnerabilities are the most dangerous, and those should be fixed right away.
However, this new list of must-fix vulnerabilities from CISA goes beyond just considering the CVSS score. At the time of writing this the CISA list contains 291 vulnerabilities that require special attention. But why these 291 when there are an almost immeasurable number of vulnerabilities in the wild? The directive indicates that these vulnerabilities are being actively exploited, which means there are attackers using these vulnerabilities to break into systems right now.
Examining the catalog of vulnerabilities from CISA, many of the IDs have received a rating of critical or important from NVD, but not all. For example CVE-2019-9978 is a WordPress plugin with a severity of medium. Why would a medium severity rating make this list? Attackers don’t pay attention to severity.
Remember this list isn’t based on the NVD CVSS severity rating, it’s based on which vulnerabilities are being actively exploited. CISA has information that organizations do not and is aware of attackers using these particular vulnerabilities to attack systems. The CVSS rating does not indicate if a vulnerability is being actively attacked, it only scores on potential risk. Just because a vulnerability is rated as medium doesn’t mean it can’t be attacked. The severity only describes the potential risk; low risk does not mean zero risk.
There are a few options Anchore provides that can help you handle this list. Anchore has an open source tool called Grype which is capable of scanning containers, archives, and directories for security vulnerabilities. For example, you can use Grype to scan the latest Ubuntu image by running
docker run anchore/grype ubuntu:latest
You will have to manually compare the output of Grype to the list from CISA to determine if you are vulnerable to any of the issues, luckily CISA has provided a CSV of all the CVE IDs here:
https://www.cisa.gov/sites/defaultkn/files/csv/known_exploited_vulnerabilities.csv
Here’s a simplified example you can use right now to check if a container is vulnerable to any of the items on the CISA list.
First, use Grype to scan a container image. You can also scan a directory or archive; this example just uses containers because it’s simple. Extract just the CVE IDs, sort them, then store the sorted list in a file called scan_ids.txt in /tmp.
docker run anchore/grype | sed -r 's/.*(CVE-[0-9]{4}-[0-9]{4,}).*/\1/g' | sort > /tmp/scan_ids.txt
Next download the CISA csv file, extract the CVE IDs, sort it, and store the results in a file called “cisa_ids.txt” in /tmp/
curl https://www.cisa.gov/sites/default/files/csv/known_exploited_vulnerabilities.csv | sed -r 's/.*(CVE-[0-9]{4}-[0-9]{4,}).*/\1/g' | sort > /tmp/cisa_ids.txt
Then compare the two lists, looking for any IDs that are on both lists
comm -1 -2 /tmp/cisa_ids.txt /tmp/scan_ids.txt
The “comm” utility when run with the “-1 -2” flags only returns things it finds in both lists. This command will return the overlap between the vulnerabilities found by Grype and those on the CISA list. If the container doesn’t contain any CVE IDs on the CISA list, then nothing is returned.
Users of Anchore Enterprise can take advantage of a pre-built, curated CISA policy pack that will scan container images and identify any vulnerabilities found that are on the CISA list.
Download the CISA policy pack for Anchore Enterprise here.
Once downloaded, Anchore customers can upload the policy pack to Anchore Enterprise by selecting the Policy Bundles tab as seen below:
Next, upload the policy pack by selecting the Paste Bundle button.
If done correctly, you should see something very similar to what is depicted below, where you can see the raw json file loaded into the policy editor:
Lastly, activate by clicking the radio button for the bundle, so that it can be used in your CI/CD pipelines and/or runtime scans to detect the relevant CVEs from the CISA catalog that are specified within the policy.
You can now see the results generated by the CISA policy pack against any of your images, as demonstrated below against an image that contains Apache Struts vulnerabilities that are included within the CISA vulnerability list.
From here, you can easily generate automated reports listing which CVEs from the CISA policy exist within your environments.
Organizations should expect new vulnerabilities to be added to the CISA catalog in the future. Attackers are always changing tactics, finding new ways to exploit existing vulnerabilities, and finding new vulnerabilities. Security is a moving target and security teams must remain vigilant. Anchore will continue to follow the guidance coming out of organizations such as CISA and enable customers and users to take action to secure their environments based on that guidance.