Technology Sharing

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

source:https://thehackernews.com/2024/06/practical-guidance-for-securing-your.html

It’s no surprise that software producing organizations are facing increasing regulatory and legal pressure to protect their supply chains and ensure the integrity of their software. Over the past few years, software supply chains have become an increasingly attractive target for attackers, who see an opportunity to increase their attacks by orders of magnitude. For example, look at the 2021 Log4j vulnerability, where Log4j (an open source logging framework maintained by Apache and used in countless different applications) was the source of a vulnerability that put thousands of systems at risk.

Log4j's communication capabilities are vulnerable, thus providing an opportunity for attackers to inject malicious code into the logs, which can then be executed on the system. After the discovery, security researchers saw millions of attempted exploits, many of which turned into successful denial of service (DoS) attacks. According to some recent research from Gartner, by 2025, nearly half of enterprise organizations will be the target of software supply chain attacks.

But what is the software supply chain? First, it is defined as the sum of all code, people, systems, and processes within and outside an organization that contribute to the development and delivery of software artifacts. What makes securing the software supply chain so challenging is the complexity and highly distributed nature of developing modern applications. Organizations employ global teams of developers who rely on an unprecedented number of open source dependencies, as well as extensive code repositories and artifact registries, CI/CD pipelines, and infrastructure resources to build and deploy applications.

While security and compliance have always been top concerns for enterprise organizations, the challenge of protecting an organization's software supply chain is growing. However, many organizations have made substantial progress in implementing DevSecOps practices, many of them still find themselves in the early stages of figuring out what to do.

That’s exactly why we put this article together. While the following is by no means an exhaustive list, here are four guiding principles to get your software supply chain security efforts moving in the right direction.

Consider every aspect of the software supply chain when applying security

Given that more than 80% of code bases have at least one open source vulnerability, OSS dependencies are rightfully a core focus for software supply chain security. However, the modern software supply chain includes other entities whose security posture is either overlooked or not widely enough understood within the organization to be properly managed. These entities are code repositories, CI and CD pipelines, infrastructure, and artifact registries, each of which requires security controls and regular compliance assessments.

Frameworks such as OWASP Top-10 for CI/CD and CIS Software Supply Chain Security Benchmark. Compliance with these frameworks will require fine-grained RBAC, applying the principle of least privilege, scanning containers and infrastructure-as-code for vulnerabilities and misconfigurations, isolating builds, integrating application security testing, and properly managing secrets — to name a few.

SBOM is critical for fixing zero-day and other component issues

Part of Executive Order 14028, issued by the White House in mid-2021 to strengthen the nation's cybersecurity posture, requires software producers to provide their federal customers with a Software Bill of Materials (SBOM). SBOMs are essentially formal records designed to provide visibility into all the components that make up a piece of software. They provide a detailed, machine-readable list of all open source and third-party libraries, dependencies, and components used to build the software.

Generating and managing SBOMs for software artifacts is a valuable practice regardless of whether an organization is mandated by EO 14028. SBOMs are an indispensable tool for remediating component issues or zero-day vulnerabilities. When stored in a searchable repository, SBOMs provide a map of where specific dependencies exist and enable security teams to quickly trace vulnerabilities back to the affected component.

Managing the software development lifecycle with policy as code

In the world of modern application development, rock-solid guardrails are an essential tool to eliminate errors and intentional behavior that compromise security and compliance. Proper governance throughout the software supply chain means that the organization has made it easy to do the right thing and extremely difficult to do the wrong thing.

While many platforms and tools provide out-of-the-box policies that can be quickly executed, policy-as-code based on the Open Policy Agent industry standard enables the authoring and execution of fully customizable policies. Manage policies from access permissions to allowing or denying the use of OSS dependencies based on criteria such as vendor, version, package URL, and license.

Ability to verify and ensure trust in your software artifacts using SLSA

How do users and consumers know that a piece of software is trustworthy? When determining the trustworthiness of a software artifact, you want to know who wrote the code, who built it, and what development platform it was built on. Knowing what components are inside it is also something you should know.

Once provenance (the record of the software's origin and chain of custody) can be verified, a decision can be made whether to trust the software. To this end, the Supply Chain Level for Software Artifacts (SLSA) framework was created. It enables software production organizations to capture information about any aspect of the software supply chain, verify the properties of artifacts and their builds, and reduce the risk of security issues. In practice, software production organizations must adopt and adhere to the SLSA framework requirements and implement a method for verifying and generating software attestations, which are authenticated statements (metadata) about software artifacts throughout the software supply chain.