A look at the Open Software Supply Chain Attack Reference (OSC&R)

A security framework for assessing and evaluating software supply chain security risks

By now, we’ve written and spoken about software supply chain attacks several times. From incidents such as SolarWinds, Log4j, CodeCov and the list goes on. Software supply chain attacks are near top of mind of most security and technology leaders and understandably so, as sources such as Sonatype show that software supply chain attacks have increased 742% annually over the last 36 months.

There has also been a tremendous increase in relevant guidance, best-practices and resources for the industry to leverage to try and mitigate this rapidly increasing threat. These include the NSA Software Supply Security Series, NIST Software Supply Chain Guidance and the Secure Software Development Framework (SSDF), the Supply Chain Levels for Software Artifacts (SLSA) framework, guidance from NTIA and CISA on Software Bill of Materials (SBOM) and Vulnerability Exploitability eXchange (VEX), OWASP’s coverage of VEX and Vulnerability Disclosure Reports (VDR)’s, OWASP’s Software Component Verification Standard (SCVS) and the list goes on.

That said, many of these sources of guidance can make it difficult to think about the entire software supply chain concisely and the various attacker techniques and behaviors that can introduce risk to organizations and be key considerations for their software supply chain security efforts.

Right on queue, the Open Software Supply Chain Attack Reference (OSC&R) comes on the scene. OSC&R is a resource that was created through collaboration of Google, Microsoft, GitLab, and OX Security. Much like the famous and widely used MITRE ATT&CK framework, OSC&R aims to help establish a common lexicon to discuss and analyze the various tactics, techniques and procedures used by malicious actors to target the software supply chain.

The framework boasts broad coverage of the various attack vectors for the software supply chain, which is a complex challenge due to how diverse and interdependent it can be and is for many organizations.

In this article we will take a look at OSC&R and its respective areas and TTP’s for those areas.

OSC&R

Based on the OSC&R FAQ, it states:

OSC&R is a framework that provides a comprehensive, systematic and actionable way to understand attacker behaviors and techniques used to compromise the software supply chain.

This is valuable given how detailed, lengthy and opaque much of the software supply chain security guidance can be. Being able to visualize and digest attack vectors and TTP’s in a matrix is something that has resonated with the security community for some time and is why we have seen similar efforts such as MITRE ATT&CK be so successful in their adoption and use.

One key concept and term the OSC&R framework introduces is the term of “PBOM” or a Pipeline Bill of Materials. It distinguishes it from the popular concept of an SBOM as defining it as:

A pipeline bill of materials (PBOM) goes beyond that list of ingredients and tells you whether other products made using the same machinery or produced in the same factory contain nuts. It does not just look at the software, it looks at the full pipeline from design to production.  PBOMs do a better job of helping people avoid using harmful software because it looks at all the stages where an attack might happen.

In a corresponding blog post, OX Security, who was involved in the release of OSC&R further describe it as:

A PBOM is a dynamically-updated list of everything ever done to a given piece of software. This includes the first line of code all the way through to release.

Some in the community in organizations such as CNCF have pointed out similarities of the PBOM concept being strikingly similar to the intent of the well established in-toto specification. in-toto’s own website describes it as:

in-toto is designed to ensure the integrity of a software product from initiation to end-user installation. It does so by making it transparent to the user what steps were performed, by whom and in what order

in-toto also provides comprehensive GitHub repositories with corresponding resources on using in-toto.

I’ll say there are certainly similarities and I hope the two disparate efforts can converge and collaborate to maximize the potential of each effort and the value they provide to the community.

This article is not intended to be an endorsement of any of the organizations involved in the OSC&R framework and instead is just a piece discussing its structure and how it can provide utility when thinking about securing your software supply chain and addressing associated risks from malicious actors.

So let’s take a look at the OSC&R domains and various TTP’s at a high-level. It is worth noting that upon its initial release the matrix’s TTP’s only provide names and no additional hyperlinks for detailed discussion but I suspect that will change as the OSC&R matrix continues to mature and is embraced by the community.

The matrix is laid out with various aspects of the software supply chain on the left under the heading of the PBOM concept discussed above and then correlating TTP’s on the right.

Container Security

First up in the list as laid out by OSC&R is Container Security. Containers of course are a compute abstraction that has seen tremendous adoption in cloud-native environments, due to their immutability, portability, efficiency and more. Containers are most often managed by a Container Orchestrator, with Kubernetes easily being the most widely used Container Orchestrator.

That said, despite the tremendous benefits of containers, they come with their own potential risks and concerns such as vulnerabilities, secrets, complicated layers each which can introduce vulnerabilities and more. There has been great resources published by groups such as Palo Alto’s Unit 42 Threat Research group which discuss the pervasiveness of vulnerabilities among public container repositories and also a lot of innovative work being done by organizations such as software supply chain security leader Chainguard with their approach to secure base images.

For Container Security OSC&R lists the following TTP’s

Best-practices in the area of Container Security include activities such as using secure base images, container vulnerability scanning, establishing an internal repository of hardened base images, producing SBOM’s for containers and container signing/using signed and trusted container images. Organizations can check out guidance such as NIST’s SP 800-190 Application Container Security Guide for a deeper dive on the topic.

Open Source Security

Next up is Open Source Software (OSS) Security. As we have discussed in previous articles and has been covered by groups such as Synopsys and Sonatype, OSS now exists in nearly all modern applications and often can compose up to 70% of an applications code base. Organizations such as Endor Labs and Sonatype have also documented how 6 out 7 vulnerabilities come from transitive dependencies, or dependencies of your direct dependencies, rather than being vulnerabilities of the direct dependencies themselves. OSS is now pervasive across everything from mundane leisure applications for personal use to every critical infrastructure sector.

OSC&R lists TTP’s in the OSS section as follows.

Activities here include initial discovering of OSS dependencies to advertising malicious artifacts, introducing backdoors and malicious dependencies and more. Guidance has now come from sources such as NIST in their OSS controls which lays out their recommendations across a maturity model of Foundational, Sustaining and Enhancing Capabilities.

These capabilities include things such as performing Software Composition Analysis (SCA) to identify known vulnerabilities in OSS components, such as CVE’s, as well as acquiring from trustworthy repositories over secure channels, establishing internal repositories of vetted OSS components and performing additional scanning prior to introducing OSS components into production.

In addition to looking for known vulnerabilities, which are lagging indicators of risk, organizations should look at other metrics such as national origin of maintainers/contributors, # of maintainers, meantime-to-remediation (MTTR) of vulnerabilities and more, which serve as leading indicators of risk and can help inform OSS consumption prior to finding yourself with many known vulnerable components.

Source Code Management (SCM) Posture.

The OSC&R model also covers SCM posture. Leading SCM tools include include Git, GitHub, GitLab and others and are used to track file changes, allow collaboration across users/teams on files/code and resolve conflicts if the same line of code is changed by multiple team members concurrently.

The OSC&R lays out TTP’s for SCM as follows:

Activities here include things such as determining the accounts used in the public registry, compromising access tokens and user accounts, introducing malicious code and dependencies and abusing privileged user accounts among others.

SCM platforms such as GitHub provide extensive documentation on how to secure accounts and data on their platforms such as managing accounts, credentials, preventing unauthorized access and more.

Another key consideration is whether you’re self-hosting the SCM platform or consuming it as-a-Service (e.g. SaaS), each of which have their own unique security considerations and the path taken here should be weighed against the business and financial tradeoffs as well as internal security capabilities and competencies, especially compared to some of the larger providers that are used by millions worldwide.

Secrets Hygiene

Can you keep a secret? As it turns out, most can’t, as we have seen many high-profile security incidents in recent years due to exposed and compromised secrets that get abused by malicious actors. One great resource is GitGuardian’s “State of Secrets Sprawl 2023” report, which had some concerning findings such as 3,400 occurrences of secrets detected per AppSec engineer, and over 6 million secrets detected in publicly exposed repositories.

For a deep dive of the Secrets Management challenge and issues, I published an article on CSO Online titled “Keeping Secrets in a DevSecOps Cloud-Native World”, which can be found here.

OSC&R breaks the TTP’s for Secrets Hygiene down as follows:

Malicious actors are regularly performing activities such as scanning public repositories for mistakenly exposed secrets, looking to compromise tokens and also harvesting secrets from sources such as environment variables and logs.

There are of course popular tools to help mitigate the risk of exposed secrets such as Gitleaks and TruffleHog which can perform activities such as detecting and preventing hardcoded secrets such as passwords, API keys and tokens from being exposed in Git repositories such as the popular ones we discussed above, as well as internal repositories.

Code Security

Moving on from the area of Secrets Hygiene we have Code Security. This is dealing with application code and of course has long established best-practices such as Fuzzing, SAST and more to identify vulnerabilities and security flaws that can make applications vulnerable to malicious actors.

There is also tremendous momentum underway in areas such as DevSecOps to bring security into the software development lifecycle (SDLC) earlier and drive down the cost of addressing vulnerabilities and flaws and also mitigate the scale of them that make it to runtime production environments.

OSC&R lays out the TTP’s in this area as follows:

Malicious actors are performing activities such as looking to discover coding flaws, weak authentication mechanisms, vulnerable developer endpoints, introduce backdoors into code and push malicious software across repositories.

These activities are exactly why organizations should follow secure coding practices, guidance such as NIST’s Secure Software Development Framework (SSDF) and also expose their developers to courses such as OpenSSF’s “Secure Software Development Fundamentals”.

This of course is easier to do with internal software development than the massive and complex OSS ecosystem, where organizations have little control over the software development practices and rigor that produces OSS components.

Many argue that OSS contributors also have little interest in security, with a 2020 study from Harvard’s Laboratory for Innovation Science and the Linux Foundation finding that FOSS developers only spend 2.3% of their time on improving the security of their code and describe security activities as “insufferably boring and soul-withering”. This of course doesn’t present a warm and fuzzy feeling when we consider that 70% of modern code bases are composed of OSS and its use is pervasive in even our most critical systems.

This isn’t to say OSS is any less secure than vendor software either, as both have ample examples of insecure code and exploitation. Internal security teams have no challenge laying out examples of where it has been difficult to get security prioritized among development against competing priorities such as time-to-market and a lack of incentives.

As with everything in security, it varies massively when it comes to OSS projects and vendor software and a multitude of factors are in play such as resources, culture, industry and more.

Cloud Security

Next up on the OSC&R Matrix is Cloud Security. There can be, and is, entire books written on the topic of cloud security. Whether you’re discussing cloud security in the context of Infrastructure-as-a-Service (IaaS) providers such as AWS, Azure and Google Cloud, who have entire courses, learning paths and certifications dedicated to cloud security or other areas of cloud security such as Software-as-a-Service (SaaS) and SaaS Security Posture Management (SSPM).

Organizations have rushed head first into using cloud platforms for their most critical business operations and have moved tremendous amounts of organizational workloads into cloud environments with no signs of slowing down.

That said, cloud adoption has also been riddled with many examples of cloud data breaches and security incidents, almost always traced back to customer misconfigurations and a lack of understanding of the shared responsibility model (SRM), which I have an article on, and recommend for anyone not familiar with SRM or looking for a refresher.

As I say in that article, “many business leaders still ask, is the cloud secure? This is the wrong question. A more appropriate question would be, are we, as a security team and organization, securing our share of the cloud?”

The OSC&R lays out the Cloud Security TTP’s below:

As you can see, this one is fairly robust compared to some of the other areas we have discussed and that is because cloud environments can be incredibly complex with hundreds of services, thousands of API’s, countless variations of configurations, many of which can put customer/consumer data at-risk.

Activities for malicious actors include things such as scanning the configuration of public resources, compromising user and service accounts, running malicious code on cloud workloads and accessing unencrypted data-at-rest and in-transit.

Organizations have realized for quite a while that cloud security is a challenge that must be accounted for as part of cloud adoption but currently adoption has outpaced investment, competence, focus and implementation of cloud security, as evident from the never ending examples of cloud security incidents, almost always due to customer misconfigurations and missteps.

CI/CD Posture

For those unfamiliar with the term CI/CD, it stands for Continuous Integration/Continuous Delivery/Deployment (CI/CD). CI is the process of automation for developers of having new code changes regularly built, tested and merged to a shared repository. CD, which can stand for Continuous Delivery or Continuous Deployment depending on the context, is taking CI further and using automation in pipeline stages to either automatically test and upload code changes to something such as GitHub to be deployed to live production environments, or in the example of Continuous Deployment, means automatically releasing developers changes from a repository to production to be used by customers. For those looking for a detailed write up on CI/CD, Red Hat has an excellent article here.

The OSC&R matrix lays out CI/CD Posture as follows:

Activities malicious actors take throughout the attack lifecycle include scanning public CI/CD configurations and infrastructure for vulnerabilities, compromising plugins and CI/CD systems directly, abusing runners/agents and performing resource hijacking.

Malicious actors have also realized that by compromising CI/CD systems they can then “poison the well”, by passing malicious software downstream to any and all consumers using software produced by the CI/CD pipeline and infrastructure. This is exactly what happened in situations such as SolarWinds, impacting thousands of downstream consumers.

Notable resources for organizations to use here include the OWASP Top 10 CI/CD Security Risks, which was originally created by the folks at Cider Security (acquired by Palo Alto).

The project lists the 10 top risks impacting CI/CD environments

Cider also created the CI/CD Goat project, which is an intentionally vulnerable CI/CD environment that engineers, security practitioners and others can use to learn and experience the major CI/CD security risks and then take that knowledge to harden their own CI/CD environments.

Artifact Security

Second from last on the list is Artifact Security. I will admit this seems to be the most opaque on the list, since “artifact” is a broad term that can have different interpretations depending on who you ask.

That said, OSC&R lists the TTP’s for Artifact Security as follows:

You can see the lifecycle of the attacker from initial access, execution, persistence, credential access and lateral movement. Activities here include compromising tokens, user accounts, service accounts and trying to steal credentials embedded in container artifacts (which some can argue should fall under Secrets Hygiene). That said, this is an aspect of the PBOM list, so it made sense to cover it here.

Infrastructure-as-Code (IaC) Security

Last on the OSC&R list is IaC Security. For those unfamiliar with IaC, it is a method of configuring and deploying infrastructure declaratively rather than click-ops in a GUI or the traditional on-premise activities of running cable, servers, racks and so on. It does this through machine-readable definition files and can be correlated with the growth of cloud computing which has a self-service elastic consumption model.

Popular IaC examples include CSP-specific options such as AWS Cloudformation but there are also CSP-agnostic options, such as the very popular Terraform by HashiCorp.

For all the promise of IaC, it isn’t without its own concerns and risks as well. While it is incredible to be able to write and deploy infrastructure declaratively, if the IaC includes vulnerable configurations or misconfigurations (remember most cloud security incidents are tied to this), all you’ve done is sped up the ability to declare vulnerable configurations and deploy them at scale.

This is why we have seen an increased attention on IaC security with popular options such as Checkov and Terrascan which as OSS options, as well as Snyk IaC which is a vendor version of IaC security tooling. These tools help scan your cloud IaC vulnerabilities and catch misconfigurations prior to deployment as well as help enforce organizational/industry compliance requirements around things such as networking and encryption.

Palo Alto’s Unit 42 Threat Research group also found concerning findings associated with IaC security, which often uses methods of borrowing and reusing multiple layers of third-party resources which can lead to a snowball of vulnerabilities. This exists in examples such as IaC packages, Kubernetes Helm Charts and Container Images.

OSC&R covers the following TTP’s for IaC Security:

Activities here include compromising various credential types, exposed API’s, permissive network controls and also dumping credentials and secrets or access unencrypted data.

While IaC offers tremendous benefits, such as shifting to a GitOps deployment model of bringing DevOps methodologies and practices to managing IaC in a declarative format and mitigate the risks of configuration and architecture drift, organizations must take IaC security measures as well to mitigate relevant risks.

Conclusion

As you can see, it is safe to say the modern software supply chain is complex to put it lightly. Organizations have to be concerns with everything from containers, OSS, secrets, code, cloud, CI/CD, IaC and more. Couple this massive and complex attack surface with the reality that defenders must be right all the time and attackers only need to be right once and it is easy to see why we have so many security incidents and data breaches. It is very hard to get all of these things right, especially in large complex environments with multiple different toolsets, resource constraints, competing priorities and more.

That said, the OSC&R helps serve as a useful mental model to understand the various aspects of the software supply chain as well as potential TTP’s to consider to protect against and be aware of.

I’ll also say that of course the OSC&R isn’t exhaustive, there are more TTP’s that can be added, and it doesn’t go deep on the software supply chain in the context of upstream providers, managed service providers, third-parties and so on.

Lastly, my coverage of OSC&R is not to be confused as an endorsement of any of the specific organizations involved or concepts against other industry standards that we have touched on throughout the article. This article is merely an attempt to cover OSC&R and PBOM and the concepts therein and be a useful and informative read for the security community.