Ayman Patel

Posted on Jan 16 • Originally published at aymanace2049.hashnode.dev on Dec 31, 2023

The quest to improve Supply Chain Security

Introduction with a sour taste

Writing software is hard. Maintaining is harder. Securing it is the hardest. The attack vectors keep on increasing, year on year, as and when new features introduced. For instance, Log4j vulnerability that was seen a couple of years ago in December 2021, was because of a JNDI interface that was introduced in 2014. (Blackhat attack talk on the exploitability in 2016!) Another example would be that of Panama Papers leak , where the open-source CMS Drupal was the root cause of the hack.

Third example which nails down is the Equifax hack; whose root cause of not updating their Apache Struts vulnerability for 6 months after a 0-day exploit was found.

Recent high-profile hacks which happened after the pandemic on Colonial pipelines, Microsoft Exchange server, Log4j, SolarWinds Hack; has made the people and governments weary of the security of software systems. Government has come up with legislation in order to curb these hacks.

Application Testing Tools

SAST

Static Application Security Testing

The security of application is determined by scanning static code. It does not have any information on the running application which can lead to some false-positives.

DAST

Dynamic Application Security Testing

The security of application is determined by running test on the running application. This can be achieved by sending malicious code/input fields . As it does not look into the code, it has not context on root cause of a security vulnerability. Hence, it will be difficult for developer to understand and guage what architectural/code issues are the root cause of the security vulnerability.

IAST

Interactive Application Security Testing

The security of application is determined by running an agent inside the application similar to agents deployed for monitoring such as Dynatace, eBPF etc It has advantages of both DAST and SAST. It can run against deployed application as well as see the source code.

Following illustration is on what DAST, SAST, IAST tests:

SCA

Software Component Analysis

This provides information on dependencies or libraries. Information include

Downstream vulnerabilities
License risks
Library health (how well maintained is the library)

SCA's provide an interface with dashboards on number of issues (license, vulnerability and package health); and also provide links to CVEs which can aid developers and security engineers to get all information of the software dependencies at a single place.

The following caability matrix by veracode provides the capabilities f each tool:

SBOM, VEX and CSAF

According to US ruling, it is mandated for companies to include a software-bill-of-materials. Generally, bill of materials is traditionally a list of items that was used to build a particular product. For example, you might have heard of card recalls due to some fault at brake discs. BOM allows for auto-manufacturers to pinpoint the raw material to the cars where it was used, so that they can trace from raw materials to the cars where the materials were used. In software also, there are standards to define the components of software, which are mainly libraries.

SCA might sound similar to SBOM; but goal of SBOM is to collaborate with other systems. SCA is vendor-specific, but SBOMs are driven by foundations such as OWASP and Linux Foundation, which provides interoperability for further things such as advisory framework, exploitability of vulnerability as well as signing of software packages to maintain authenticity of the packages.

SBOM

There are 2 standards for SBOM

SPDX (by Linux foundation)
CylconeDX (by OWASP)

SPDX

This was created by Linux foundation in 2011 to track software licenses. After some years, information regarding the materials/components of software was added.

CycloneDX

Cyclone DX was created by OWASP for combating vulnerability identification, outdate softwares and license compliance. It not only included SBOM but also HBOM (Hardware), OBOM (Operations), SaaSBOM (Software as a Service), VDR (Vulnerability Disclosure Report), VEX (Vulnerability Explotability eXchange). VDR and VEX is more important and useful when used with SBOM for software engineers in order to find vulnerabilities, create a report on impact through advisory and finally making a decision if vulnerability is explitable in the current software stack.

SBOM Tools

Anchore/Syft

Generate SBOM for your container images, libraries, filesystems

a. Generating CyclineDX and SPDX using Syft

b. JSON output from SPDX and Cyclone DX

Anchore/Grype Works with Syft and does vulnerability scanning for containers as well as filesystems.

Synk provides all tools under 1 hood. It provides tools such as

Synk OpenSource: Identify vulnerable open source libraries
Synk Container Image: Securing container images
Snyk IaC: Misconfiguration of IaC secrets and policies
Snyk Code: SAST offering form Snyk

Aqua

Aqua vSheild: Mitigation strategy for vulnerability
Aqua Trivy: OSS Vulnerability scanner, IaC protection

VEX (Vulnerability eXploit)

Goal of VEX is to provide information on the **to communicate the exploitability of components with known vulnerabilities in the context of the product in which they are used."

Having a lot of libraries can lead to a lot of noise if there is a vulnerability. The vulnerability can be an obscure function which is hardly used. So in order to combat such scenarios, where we need clarity on the risk of the vulnerability so that appropriate action can be taken on fixing it or keeping it on hold for some time as it is not. arisk at this point of time.

Goals of VEX:

VEX can be inserted into a BOM (CycloneDX); or have an dedicated VEX BOM.
Provide clear details on vulnerability, exploitability.
Bridge the communication gap between software consumer and software producer. It can communicate to software consumer on the actions taken by the software producer and actions to be taken by consumer to minimize security impact.

CSAF

Common Security Advisory Framework (CSAF) is a language to communicate security advisories. It is the final step of understanding the software components, and providing enough information in order to make the decision of remediating software vulnerabilities.

It is maintained by OASIS Open and a CSAF v2.0 standard can be found here

Example CSAF JSON

{ "document": { "category": "csaf_vex", "csaf_version": "2.0", "notes": [{ "category": "summary", "text": "Example Company VEX document. Unofficial content for demonstration purposes only.", "title": "Author comment" }], "publisher": { "category": "vendor", "name": "Example Company ProductCERT", "namespace": "https://psirt.example.com" }, "title": "Example VEX Document Use Case 1 - Fixed", "tracking": { "current_release_date": "2022-03-03T11:00:00.000Z", "generator": { "date": "2022-03-03T11:00:00.000Z", "engine": { "name": "Secvisogram", "version": "1.11.0" } }, "id": "2022-EVD-UC-01-F-001", "initial_release_date": "2022-03-03T11:00:00.000Z", "revision_history": [{ "date": "2022-03-03T11:00:00.000Z", "number": "1", "summary": "Initial version." }], "status": "final", "version": "1" } }, "product_tree": { "branches": [{ "branches": [ { "branches": [ { "category": "product_version", "name": "1.1", "product": { "name": "Example Company DEF 1.1", "product_id": "CSAFPID-0001" } }], "category": "product_name", "name": "DEF" } ], "category": "vendor", "name": "Example Company" } ] }, "vulnerabilities": [{ "cve": "CVE-2021-44228", "notes": [ { "category": "description", "text": "Apache Log4j2 2.0-beta9 through 2.15.0 (excluding security releases 2.12.2, 2.12.3, and 2.3.1) JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. From version 2.16.0 (along with 2.12.2, 2.12.3, and 2.3.1), this functionality has been completely removed. Note that this vulnerability is specific to log4j-core and does not affect log4net, log4cxx, or other Apache Logging Services projects.", "title": "CVE description" }], "product_status": { "fixed": ["CSAFPID-0001"] } } ]}

Signing your software libraries

There are a couple of attack vectors that are based on how software is installed. A couple of years ago, security researcher wrote this article which went viral "Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies". He was able to download private repos from companies. Another example is series of attacks on npm where a misnomer(spelling mistake) of packages led to installation of malware. These sort of attacks could have been mitigated by using digital signatures.

We have encryption which follows the practice of integrity, authenticity and non-repudiation. Software libraries signing can allow us to keep malicious packages out of our systems. There are a number of technologies which are using the signing principles of cryptography but for software binaries/libraries/containers signing.