October 16, 2023
October 11th has come and gone, and we have more information about the HIGH severity CVE that affects the common cURL package that is used throughout the software ecosystem. We now have much more information regarding the actual exploitable vulnerability and the versions that were affected (libcurl 7.69.0 to and including 8.3.0). But almost a week before this information was released, the maintainers had already advised the community of the upcoming HIGH severity vulnerability but did not disclose information about which versions were affected, just mentioning the “last several years” of versions.
Getting ahead of the problem and being prepared is half the battle and this statement is also very true when it comes to software supply chain security. The problem is that the vulnerability is so new and with little information about the versions that are affected, the vulnerability and SCA scanners will not be able to help you find the issue. What do you do now?
You’ve been doing your part in response to EO 14028 and you have collected a bunch of accurately built SBOMs (securely during the build process), which should magically give you the answer! Using our favorite tool, grep, over our corpus of SBOMs, we find many occurrences of “curl”. When we look at the results, there is much to digest!
We see many things, license annotations, metadata files, binaries, CPEs, dynamically linked libraries, etc. However, finding the right signal in the sea of information becomes a tedious exercise!
This is the perfect use-case for GUAC (Graph for Understanding Artifact Composition) to provide insight into where other tools lack behind. GUAC aggregates all the software security metadata (SBOMS, SLSA attestations, Vulnerability reports, VEX, Scorecard, and others) into a high-fidelity graph database that can be easily and quickly queried to find the blast radius and determine a patch plan to remediate issues quickly. Let's see how GUAC could have been used in the case of the cURL vulnerability to be proactively ready when the updated version gets released.
First setup your GUAC environment by following our guide here: https://docs.guac.sh/setup/. Once GUAC is up and running, we will ingest the SBOMs above that we generated using Syft which makes up our software environment.
Now with GUAC, once we’ve ingested the SBOMs, we can do a search to find things related to curl. This can be done easily with a `findSoftware` GraphQL query:
This yields succinct results of just 27 relevant curl software - both packages and libraries, from debian, alpine, pycurl, rpm/amzn, etc.
Piping this out to a more readable form:
From here, we can then pick out one that we know would be of interest, for example, pkg:deb/debian/curl, and let’s dive deep!
There are multiple approaches we can take:
Our ingested data contains curl Debian packages that we can query quickly. By running:
We see the output:
By clicking on the guac-visualizer link, we can view the graph in real-time:
If you noticed, we did not specify a version on the cURL purl we used to run the patch planning CLI. This was done such that, we do not know the vulnerable versions of cURL and we need to be prepared to update when the time comes. FRONTIER LEVEL 0, shows all the current versions of cURL we are using in our environment. Going down to FRONTIER LEVEL 1, we see the various images that need to be updated as they rely on a version of cURL. No longer do you need to re-scan or pour through large amounts of data to determine if/where cURL is used.
GUAC reduces the time it takes to remediate by quickly helping you determine your blast radius and the proper patch planning to quickly get ahead of the problem. Going a level further, GUAC can also keep track of the “Point of Contact” or organization that is responsible for a specific package. This greatly reduces the churn that enterprises with multiple organizations or teams have to determine who to contact to get the remediation process started. Moving the MTTR (Mean Time to Remediate) needle back significantly!
Depending on the package and vulnerability, you may need to mark it as “bad”. This can be useful in a variety of situations where you want to ensure that a package that depends on a vulnerable version does not run in a production environment. It can also be marked by the security team to allow for developers to quickly locate if and where they are affected.
A quick example of how this can be done in GUAC (for our debian example):
From here that package (along with all its versions) is marked as “bad” such that policy engines and other integrations can act autonomously.
SBOMs are a starting point. They help us collect the data but to get the full value out of them, we have to turn to GUAC! SBOM alone is not the answer, but combined with the synthesis capabilities of GUAC, we can be proactive about vulnerabilities before they are released. We can quickly determine the various packages that match and run patch planning queries to get to the root source that needs to be remediated. We can even mark them “bad” to trigger alerts for other teams and kick-off automated policy actions!
This was just a small example of how GUAC can help enterprises get ahead of software supply chain incidents. Be sure to check out https://guac.sh for more information and other demos. We are always building out new use cases and queries to match.
The latest industry news, interviews, technologies, and resources.