Some software supply chain vulnerability events make mainstream news. At the beginning of the Ukraine-Russia conflict, the developer of node-ipc decided to impose a blanket ban on using their code by any IP address inside Russia, unknowingly impacting many humanitarian and charitable organizations operating in the country. In other incidents, developers disgruntled by the ubiquity of their code in profitable products have poisoned their own GitHub to draw attention to their lack of financial support from users and the larger community.

It’s undeniable that common developer resources and libraries are being compromised by bad actors who are fully aware that a simple typo-squat can distribute their corrupted code to thousands of projects across the globe. But most malicious supply chain malware instances go unreported – more than likely because they are numerous. An active scan by OSS supply chain cybersecurity vendor Sonatype found 102,930 malicious or potentially malicious instances of code across the npm eco-system. Once integrated into development pipelines, corrupted applications enter QA, testing, or even production stages. Then they can compromise cloud credentials, hijack processor cycles for cryptocurrency mining, exfiltrate companies’ IP, and the usual unpleasant smorgasbord of malware activities.

The developer community has posted its resources and code for the good of all since the final throes of proprietary UNIX were triggered by the deployment of the early versions of the Linux kernel. And while the ideology of OSS (open source software) will endure because of its overwhelming advantages for all developers and software, the means of delivering such benefits are being compromised by criminal elements. It’s an unfortunate side of human behavior and one that’s unavoidable unless every project is written from scratch without reference to common libraries, frameworks, and code.

Organizations have remedied many security and quality control issues by creating their own repositories containing only “approved” elements for internal use – or at least ensuring the veracity of all packages coming into their CI/CD pipeline. Control brings advantages to software production in general, including version control and compatibility, dependency resolution, CI/CD automation, and the (relatively) simple production of entire BOMs (bills of materials) for any application, to name a few examples. Local repositories quickly become integral to any delivery pipeline for change management, new development, and everything in between. But of course, the security maintenance of such a resource is a complex undertaking that consumes (highly paid) resources.

Source: Shutterstock

DevOps teams under pressure to hit targets not only make mistakes but will be tempted to park security concerns for the sake of lower overheads. First to be forgotten is likely the proper vetting of every library or function. That’s a story that has traditionally put developers and their security-focused colleagues at loggerheads. There are many methods and solutions that attempt to bake in cybersecurity best practices to all parts of the software supply chain and the CI/CD lifecycle.

The core elements of any application throughout its development and subsequent updates must be checked for safety and license compliance. That means free of malware or incompatible Ts & Cs at the point they’re downloaded and constant re-examining as CVEs or other susceptibilities become apparent (or license terms change). In a complex application, that can mean observing and managing many thousands of components, an undertaking clearly beyond most organizations.

It’s a situation that won’t change and, indeed, will likely worsen as the dependence on software grows. Every company and organization in the world, large and small, is continuing to digitize and deploy more technology. Therefore, it’s safe to assume that bad actors’ activities will likewise increase in step. In short, the problem is growing at the same time that open source software development needs to accelerate innovation, produce new solutions and update services & apps everywhere.

Sonatype

The figure quoted above (192,000+ malicious packages in the wild) was collated by behavioral analysis and automated security scans run by the Nexus Firewall from Sonatype. It’s a way by which organizations’ development functions can help protect themselves from the type of vulnerabilities epitomized by the Log4J incident – the effects of which continue. SCA (software composition analysis) is the process by which organizations can assess the security of their software components, manage versioning, ensure fewer dependency issues and keep on the right side of the many license types.

Nexus Firewall quarantines (and releases, after vetting) any downloaded component, giving companies full control over what is permitted into their SDLC (software development lifecycle). Policy can be attenuated according to needs and can include degrees of control based on package or library popularity, age, source, version, and license. (The latter has the additional advantage of ensuring no violations that might raise legal concerns somewhere down the line.)

Source: Shutterstock

Developers can only use secure components inside a set version range, lowering version choices and reducing breaking dependencies. New versions are blocked by default until they can be examined and released into the local repo, be that Nexus Repository or JFrog Artifactory Enterprise.

With multi-language support (Java, JS, Ruby, .NET, Python, Go), the Nexus Firewall is the best way to enhance progress towards the oft-quoted goal of security, operations, and development integration: DevSecOps. To find out more, discover pricing and community-focused resources, book a demo from Sonatype.

Qualys

Qualys is renowned as a provider of information security and compliance in development solutions. It interfaces neatly with common CI/CD platforms like Jenkins and Puppet, plus it will also plug into popular SIEM platforms like Splunk.

It was one of the first developer-focused software platforms to take the emergence of microservices built around Podman and Docker and ensure that development using containers (even in experimental, pre-production environments) was safe and secure. Multiple instances of corrupted Docker images proved the company’s conservatism in this regard. For its grateful users, it was able to cross-check expected container behaviors with real-world deployments to flag anomalies that might suggest the presence of bad actors.

The Qualys platform can scan all available assets, from cloud repositories (where there are built-in connections to popular hyperscalers’ services) to individual endpoints operated by single developers.

Read here for more information on Qualys DevOps security solutions.

Micro Focus

The great majority of apps using some sort of third-party open-source software will have been built with an existing chain of tooling that may be long-bedded into business processes.

Micro Focus Fortify offers companies the ability to backport through the extant CI/CD stack to backwards engineer better security at each stage of the SDLC.

Its software removes the need for application development to be paused at key points to be security scanned – the process is continuous, bringing value in terms of time-to-production and therefore ROI on investment in a new application.

The company’s focus is on three pillars of security, perhaps best described as the three elements that need attention to ensure a clean BOM: people, process and technology.

With departments under increased pressure to push updates and add features, as well as to bring new applications and services to market, Fortify can ensure speedy workflows that remain safe.

Click here to learn more about how Micro Focus Fortify can help organizations secure their software supply chain.