1. Apply common controls for security and compliance

Achieving regulatory compliance and ensuring proper security relies on managing control points throughout your software supply chain, along with the visibility necessary to audit the results. For example, you must set controls for who can make changes to code and configurations, approve merge requests (that may have policy exceptions), and scan applications for vulnerabilities. Some of the common controls you’ll want to think about include:

When it comes time for an audit, you’ll need to have a way to see who changed what, where, and when — as well as who reviewed, approved, and merged it — along the entire software development lifecycle. Auditors should be able to check the compliance of every audit event in your logs or you should be able to prove that you have an automated process in place that satisfies the requirements.

2. Automate common controls and CI/CD

Automating policies for common controls helps you ensure more consistent compliance, reduce your audit surface, and more easily prove compliance to auditors. One popular way to do this is by automating CI/CD to apply common controls.

For example, security scanning for vulnerabilities is a common control you can automate. First, determine which projects or applications you want to require scans on and what the policies for those scans will be. Hopefully, your policies will require using more than one type of scan. CI templates can be used to ensure automated scans are consistently applied. Without automation in place, it’s all too easy to end up doing scans less frequently than you planned and let a vulnerability go too long and too far into the software supply chain without being remediated. (See page 9 for more on the types of security scans available.)

3. Apply zero-trust principles

Zero trust is an approach that assumes that hackers are going to get inside your network and focuses on protection from the inside rather than just the perimeter. Embracing this perspective can protect you from lateral attacks where hackers find an easy way in via a low-value asset, but then use privilege escalation and advanced techniques to reach mission-critical apps and data.

The modern software era relies upon so much more than application code and the network, which makes zero-trust principles a necessity. Today’s complexities include APIs, secrets, containers, orchestrators, cloud services, templates, and other tools that your development team uses. All of these provide additional attack surfaces. If an attacker exploits misconfigurations of one of these elements of your software supply chain, they may move laterally across applications, clusters, and environments.

Here are some key ways zero-trust principles help you secure your software supply chain:

• Lateral movement becomes more difficult because each service has to be authenticated
• Protection is consistently applied for both human access and machine access (such as APIs)
• Stolen credentials are less valuable.
• Non-targeted attacks are less successful
• Role-based access prevents threats from malicious or simply careless insiders

4. Inventory all tools and access, including IAC

First, you’ll want to inventory anything your development team is using that could be a point of entry or new attack surface — from code repositories to APIs, containers, orchestrators, artifacts, templates, and all your build tools. In many organizations, the security team isn’t aware of a lot of the tools that are being used, and you can’t make something more secure if you don’t know it’s there.

Once development and security teams are on the same page, it’s time to re-examine all your access controls. Certainly, take a look at typical things like your network and endpoints, but keep going until you’ve covered all points of entry along your software supply chain. For instance, consider who can change IaC templates. Containers are used to stand up new projects quickly. If they are not scanned, security flaws can be quickly replicated across projects. Be sure to scan containers and monitor the behavior of APIs and orchestrators. For some ideas, check out the National Institute of Standards (NIST) Secure Software Development Framework (SSDF).

5. Consider unconvetional scans to find unconventional vulnerarabilities

Conventional scans, like static analysis, dynamic analysis, secret detection, dependency scanning, and container scanning, will help you find Common Vulnerabilities and Exposures (CVEs), or vulnerabilities with a known signature. But vulnerabilities that don’t have known signatures or are unique to your environment could also expose the organization to a breach or attack.

The line between what is a security flaw and what is a logic flaw can be thin — and won’t matter if the flaw is exploited.

For unknown vulnerabilities, fuzz testing can be especially helpful. There’s coverage-guided fuzz testing, API fuzz testing, and protocol fuzz testing, and they allow you to find insecure logic flaws that do not have a signature of a known CVE. To help shift this security check earlier in the software development lifecycle, it’s a good idea to add fuzz testing within your CI pipeline right alongside other security scan types. (See page 9 for more on fuzz testing.)

Other ways to find unknown vulnerabilities in your applications include:

• Monitoring for stability and reliability issues, which can lead to exploitable vulnerabilities
• Confirming reproducibility to minimize false positives and identify root cause analysis

The goal is to test wider and deeper so you can maximize your testing coverage and reduce your overall risk.

6. Secure containers and orchestrators

Protecting your software’s infrastructure in production — like Docker containers and Kubernetes — is an important piece of securing your software supply chain. To keep things secure and compliant, you’ll want to apply many of the same common controls in code creation, testing, and deployment to your container infrastructure as well.

Make sure you include container scanning to find any known vulnerabilities in your container images. If you’re using Kubernetes, you’ll also want to scan your Helm charts, and you can do that with static application security testing (SAST).

Apply zero-trust principles and work to limit lateral movement among your containers. You can create a policy that blocks east-west traffic, so pods will only be allowed to communicate with certain other pods.

Also, think about more obscure things like the container registry and who has write access in your organization. A compromise of one person could potentially lead to a compromise of the container registry, which could lead (via pipelines) to compromises of numerous projects.

7. Automate SBOM generation

A software bill of materials (SBOM) is a list of all the components in a codebase — essentially a list of the ingredients that make up your software.

By automating SBOM generation, you can avoid lengthy manual processes to confirm that malicious software is not packaged within your software. Automating SBOM generation will provide insights into dependencies across transient structures from package managers and containers. Developers will be able to expedite remediation activities when SBOM vulnerabilities are displayed in the UI.

To further increase usability and adoption, reduce the number of tools used for reviewing and processing SBOMs. Utilizing SBOM in an end-to-end secure platform helps to protect from multiple attacks, including protection for internal code, external sources, and even the build process.

Security dashboard

A security dashboard lets you know the number of vulnerabilities that were introduced over time. For instance, after you run a security scan, the detected vulnerabilities should automatically be displayed in the dashboard. Dashboards should be able to be customized so that departments, teams, and individuals can easily see the vulnerabilities in their projects. Vulnerabilities also should be labeled according to their severity levels.

Vulnerability management

Vulnerability management lets you dive deeper into the information that appears on the security dashboard. With so many moving parts, it’s critical to have a comprehensive plan to deal with vulnerabilities. Teams need to be able to see the problem areas, triage them for severity/threat status, be able to note trends, and then track the status and remediate or resolve the vulnerabilities. A solid plan and the correct tools will give teams full visibility into an organization’s risk and can unite developers and security around a common view. You should be able to sort and filter vulnerabilities by characteristics such as severity, status, and the type of scan performed. Without moving to another tool, the reporting should show if there has been activity on the vulnerability — for instance, whether an issue has been created to resolve ita, developer has been assigned, or it has a targeted completion date. Also, if it’s been dismissed, why and by whom.

Audit logs and audit events

Audit logs and events offer detailed information about what types of changes were made on the system, when, and by whom. For example, audit events should show if a vulnerability check or license check was added, or if a group was added or removed. If a policy stops the build and an exception is approved, audit logs will show who approved the exception. This comprehensive audit trail can greatly simplify an audit, while also expediting root cause analysis following a breach.

Dependency lists

A dependency list shows all the code dependencies throughout the software so that if a vulnerability is detected, you know the extent of its reach and impact. You should be able to drill down and see what file or files the dependency is in as well as what licenses it is associated with.