HOW IS SOFTWARE BUILT?

If you’re a software development organization, an attacker wants to insert malware into your system build. There are several avenues to accomplish this goal. Keep in mind that many projects have millions of lines of code and hundreds, if not thousands, of files. The size and complexity make it easy for someone to insert unpleasant surprises into the system without notice.

Let’s start with a simple explanation of how a developer builds a software system. First, programmers write code. Code is a set of instructions that tells a computer what to do. Code combines into modules, and modules merge into libraries. These combine with other files, resources, and artifacts to form a system. The developer writes code with an integrated development environment or IDE. Code and related resources are stored in a repository known as the source code management system.

More than just the written code is vulnerable. Code combines with more code already built into modules and libraries. Often this is code written by other people, who may not know anything about how the code will be used. This code forms more modules adding to the libraries acquired from external sources and software vendors. These components might be database connectors or business logic provided by companies with special expertise in their field.

Often the systems include free and open source code and libraries that have become popular because they address needs others have encountered. Today a large percentage of a typical system consists of blocks built and maintained by others who have no relationship to those building the system. This code is typically stored in repositories and extracted when the build process requires it.

A build environment gathers and assembles all the pieces into a form that deploys to an environment where it all runs. We call these processes of writing the code and combining it with more code, modules, and libraries from various sources then creating a deployable component the development pipeline. From here, the attack is simple. All the bad guys need to do is add their code to any of the systems involved in the pipeline and boom – you’re sending malware out to users.

HOW TO PROTECT THE BUILD ENVIRONMENT

The bad guys want to get to the development and build environments. This includes the developer PC,
any of the repositories, and the build system itself. This creates the need for strong security measures to protect:

• Development environments and systems
• Developers’ computers and networks
• The source code management system
• Any other environment developers need to access.
• Repositories for the third party and open-source code.
• The built environment and the communications between build and the environments storing the code must be secure as well.

While you’re at it, you don’t want to store passwords, private keys, or other secrets in the source code repositories. Think about adding a secrets management system as well.

SIGN YOUR CODE

Developers should sign their code electronically. Code signing is a way of making sure the source code isn’t modified once it’s submitted to the repository.

Using languages like Java can prevent code from running if it isn’t signed. Other languages can benefit by signing the code and maintaining a signed list of the filenames and their signatures and a utility to compare the signatures and assure they’re all correct before running the system.

MANIFEST AND BOMS

The software industry is working on standards to help protect against supply chain attacks. New tools help to generate a manifest, or software bill of materials (SBOM).

The idea is that each deployment package should include a signed list of everything that’s part of the system. The list includes information like filenames, file sizes, file version, and license information for each file, and a signature for each file. While this can’t totally prevent an attack, it can help identify the files that are involved. For example, a manifest would have helped many companies deal with the log4j vulnerabilities.

THIRD PARTY AND OPEN SOURCE CODE

When using third-party modules, start by asking if source code is available. If so, ask for a copy, because many companies use open source and enhance it. Even if they aren’t currently providing manifests, ask if they could calculate and/or provide one for you.

I always prefer to examine open source code and build it myself. The development team should do this. I also sign the code with my own signature, so no one can drop in another copy of the code to replace my copy.

Always scan the source code and binary code for malware. There are a number of tools available for developers to do this. Check the common vulnerabilities and exposures (CVE) list to see if any components have already known issues and if the vendor has applied a fix.

THE SOFTWARE COMPONENT VERIFICATION STANDARD

The Open Web Application Security Project (OWASP) has created a software component verification standard (SCVS) to help companies verify components acquired from third parties and the open source world. This process should help reduce the likelihood of supply chain attacks if widely adopted and practiced.

The SCVS provides six sets of requirements at up to three verification levels:

1. Inventory. Makes certain the organization can provide an inventory of all the components of a package.
2. Software Bill of Materials. Confirms whether or not the organization has the ability to automatically generate a Software Bill of Materials.
3. Build Environment. Ensures the build environment is secure and works consistently.
4. Package Management. Controls the security and functionality of external package managers that are typically used to distribute open source code.
5. Component Analysis. Identifies potential areas of risk with the components. Focuses on static code analysis and elements of the SBOM.
6. Pedigree and Provenance. Checks for changes by possible separate parties after the original version release.