More recently, supply chain attacks have taken a more sinister turn because bad actors are no longer waiting for public vulnerability disclosures. Instead, they’re injecting malicious code into open-source projects, or building malicious components that feed the global supply chain.

No one in the enterprise knows all of the components that an application comprises, nor do they understand all the dependencies associated with those components. It’s a potential liability issue that, combined with a demand for greater transparency, has fueled the adoption of software composition analysis (SCA) and software bill-of-materials (SBOM) tools.

According to Sonatype’s 2020 State of the Software Supply Chain Report, the number of next-generation cyberattacks actively targeting open-source projects increased 430% year over year. From February 2015 to June 2019, 216 such attacks were recorded. Then, from July 2019 to May 2020, an additional 929 attacks occurred. These next-generation supply chain attacks are increasing for three reasons.

First, open-source projects rely on contributions from thousands of volunteer developers and it’s difficult or impossible to discern between members with good or malicious intent.

Second, when malicious code is secretly injected “upstream” to the developer via open-source, it’s highly likely that no one realizes the malware exists, except for the person who planted it. This approach allows adversaries to surreptitiously set traps upstream and carry out attacks downstream once the vulnerability has moved through the supply chain into the wild.

Finally, open-source projects typically incorporate hundreds or thousands of dependencies from other open-source projects, many of which contain known vulnerabilities. While some open-source projects demonstrate exemplary hygiene as measured by mean time to remediate (MTTR) and mean time to update (MTTU), many others do not. The sheer volume of open source and the massive number of dependencies makes it difficult to quickly evaluate the quality and security of every new version of a dependency.

Why Approved Component Lists Don’t Help

The dynamic nature of software development is at odds with approved component lists because the lists are not to be updated as often as they should be. The task is too complex and time-consuming for humans.

Modern enterprises need the ability to define policies that can be applied to individual components whether the rule is based on licensing, the age of the component, the popularity of the component or other criteria. Once the policy has been defined, it can be executed automatically. While static and dynamic analysis tools help identify problems in code, their capabilities may not extend to third-party code because there are too many code paths to evaluate. So, the vast majority of code may not be scanned, giving developers a false sense of security.

In addition, when a developer downloads and runs a malicious component, that component could install a backdoor on their system. Similarly, with continuous integrations, the poisonous code can seep even further into the pipeline.

OpenShift GitOps provides IT teams with GitOps workflows to use for cluster configuration and application delivery. It is based on the idea of GitOps, which enables developers and operations teams to use a Git repository as a single source of trust.

Red Hat noted that one of the key benefits of GitOps is the automation of infrastructure and deployment requirements, which leads to faster, more secure, and scalable development. The senior vice president of Cloud Platforms at Red Hat, Ashesh Badani commented:

“With OpenShift GitOps and OpenShift Pipelines, we are working to remove the false wall between developers and IT operations, enabling the teams to work together earlier in the application development process. This not only helps to find and prevent defects more quickly in the software delivery process but also streamlines the process as a whole by providing increased visibility and security across the lifecycle.”

OpenShift Pipelines runs in each step of the CI/CD pipeline in its own container. It allows each step to scale independently, which helps reduce the cost and overhead for running the pipeline.

Red Hat hopes that OpenShift Pipelines will provide teams with full control over their delivery pipeline, plugins, and access control without needing to manage a central CI/CD server.