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.