7 Tips for Securing the Software Development Environment
Recent attacks have highlighted the need for organizations to pay closer attention to the hardware, software, and networks used in software development.
August 24, 2021
![Laptop floating in space Laptop floating in space](https://eu-images.contentstack.com/v3/assets/blt6d90778a997de1cd/blt450b15f7b6c44ac7/64f150ccdf86f78488579463/mainimage.jpg?width=700&auto=webp&quality=80&disable=upscale)
ZinetroN via Shutterstock
The attack disclosed by SolarWinds last December and others like the one on Codecov earlier this year focused a lot of attention on how organizations can mitigate risks via the software supply chain. Considerably less attention has been paid, however, to how organizations can protect their own software development and testing environments against similar breaches.
As the attacks demonstrated, software development environments are an attractive target for threat actors. Protecting these environments is critical to reducing the risk of an attacker carrying out a variety of potentially different actions. This can include stealing encryption and access keys, passwords, and intellectual property, according to the UK National Cyber Security Centre (NCSC).
Other risks include attackers embedding malicious code into a development project, using a development system to attack the build and software deployment pipeline, and harvesting information on how sensitive applications work for use in future attacks, the NCSC has noted.
Following are seven tips for protecting your development environment and continuous integration/continuous development (CI/CD) pipeline against attacks and compromises.
Any attempt to secure your development environment needs to begin with the systems and devices used for coding, storing, and accessing the environment. A good way to approach this is to consider implementing Group 1 of the Center for Internet Security's (CIS) Critical Security Controls, says John Pescatore, director of emerging security trends at the SANS Institute.
The CIS has broken down the various controls that organizations need to protect critical systems and data into 18 separate categories. They range from controls for protecting hardware and software to access management, log management, email security, application security, and incident response.
Group 1 controls pertain to the inventory and control of any asset, including PCs and mobile systems, servers, IoT devices, and other devices connected to a particular environment, whether physically, remotely, virtually, or within cloud environments. As part of these controls, CIS recommends the use of active and passive asset discovery tools using Dynamic Host Configuration Protocol (DHCP) logging to update inventory, implementing port-level access controls, hardware authentication via client certificates, and identifying and removing unauthorized assets.
"Security hygiene [via] implementation of Group 1 of the Critical Security Controls has to be the starting point for any attempt to secure systems" in the development environment, Pescatore says.
Strong authentication controls are fundamental to security in any environment, but especially so for software development. A threat actor using stolen but legitimate access to a build system can sneak malicious code into software that's being built without being detected.
Multifactor authentication (MFA) is one way to make these kind of unauthorized code changes much harder.
"Treat code like the crown jewels," says Richard Stiennon, chief researcher analyst at IT-Harvest. "This means strong authentication to pull and push code to repositories. Revoke access when a developer leaves or moves on to a different project."
In addition, make privilege management a part of the strong authentication process for all development, test, and quality assurance environments and repositories.
"Require peer reviews for pull requests and require developers to authenticate with cryptographic keys to authenticate themselves," says Jack Mannino, CEO at nVisium.
The UK's National Cybersecurity Centre advocates that organizations take an assumed-breach approach and deploy controls as if an attacker has already compromised a developer's credentials. Using MFA, for example, can make it harder for an attacker to leverage stolen credentials, access tokens, and keys. Similarly, a multiperson review can make it harder for an attacker to sneak in unwanted changes
In the same manner, have strong controls for tracking and managing changes to code. Ensure all changes are properly authorized, reviewed, and vetted before they're accepted, SANS Institute's Pescatore says.
"On internal development, test and QA systems and all software distribution systems," he says. "Change management, privilege management, and auditing need to be implemented."
Run all submitted code through a process to discover changes, IT-Harvest's Stiennon adds. Have more than one individual looking at the changes before the code is committed to product.
Russia's GRU didn't create an exploit in Solarwinds' code, he says: "They installed backdoors, which would stick out to anyone who is looking."
Organizations are increasingly deploying code in public and private cloud repositories. That's one reason why GitHub has been a relatively popular target for threat actors in recent years. The protections that organizations might have deployed to secure their on-premises development environment, such as firewalls, VPNs, and network segmentation, are typically not sufficient to protect access to code repositories in the cloud. This is especially the case at a time when developers, like others, are working remotely more so than ever before.
Adopt a zero-trust approach to address these issues, IT-Harvest's Stiennon says. In a zero-trust model, every request to enterprise systems and data, whether from inside or outside the perimeter, is fully authenticated and vetted before access is granted. Enterprise interest in the approach has grown significantly since the pandemic forced a change to a more distributed and hybrid work environment.
"Use zero-trust access controls to the code repositories," Stiennon says. "This will hide them from attackers."
Organizations should focus on hardening organizational and repository-level security controls, nVisium's Mannino says.
"Ensuring that main branches in repositories are protected is a good first step toward reducing the likelihood of malicious code being pushed into production," he says.
Ideally, the product "gold image" should be backed up to a physically separate storage system, SANS Institute's Pescatore says. Use file integrity management tools on any applications, executables, containers, and images that will be pushed out to production, he says.
Change management processes should include checking the image to be pushed out against the physically secured image before initiating software distribution. Doing so is one way of spotting changes that an attacker might have stealthily incorporated into the code just before it's committed to production.
"There are several change-management controls you could implement in development environments to ensure code integrity," nVisium's Mannino notes. "You could implement code signing and attestation across your build and deployment systems, as well as artifact servers and container registries."
The UK's NCSC recommends that organizations develop a baseline for legitimate activity in the development environment and then proactively monitor it for potential changes. Combining knowledge about the baseline state of the environment with continuous logging can help detect compromises and potentially malicious behavior.
"For example, are strange websites being accessed and are privileged actions being carried out during unusual hours of the day?" the NCSC states.
The data organizations use for software-testing purposes can often contain sensitive information taken straight out of production environments. Though best practices call for such data to be properly sanitized from a security standpoint, it's not unusual for it to contain personally identifiable information, account data, and transaction data that could be of high value to attackers.
"The data that is pulled from production doesn't always get modified before it is used in development," says Pete Lindstrom, an analyst at IDC.
Security teams need to ensure such data is encrypted or anonymized and obfuscated in such a way as to protect sensitive information.
"Not only should you be managing the security of the network and hosting environment, but you should also be managing the test data," Lindstrom adds.
The data organizations use for software-testing purposes can often contain sensitive information taken straight out of production environments. Though best practices call for such data to be properly sanitized from a security standpoint, it's not unusual for it to contain personally identifiable information, account data, and transaction data that could be of high value to attackers.
"The data that is pulled from production doesn't always get modified before it is used in development," says Pete Lindstrom, an analyst at IDC.
Security teams need to ensure such data is encrypted or anonymized and obfuscated in such a way as to protect sensitive information.
"Not only should you be managing the security of the network and hosting environment, but you should also be managing the test data," Lindstrom adds.
The attack disclosed by SolarWinds last December and others like the one on Codecov earlier this year focused a lot of attention on how organizations can mitigate risks via the software supply chain. Considerably less attention has been paid, however, to how organizations can protect their own software development and testing environments against similar breaches.
As the attacks demonstrated, software development environments are an attractive target for threat actors. Protecting these environments is critical to reducing the risk of an attacker carrying out a variety of potentially different actions. This can include stealing encryption and access keys, passwords, and intellectual property, according to the UK National Cyber Security Centre (NCSC).
Other risks include attackers embedding malicious code into a development project, using a development system to attack the build and software deployment pipeline, and harvesting information on how sensitive applications work for use in future attacks, the NCSC has noted.
Following are seven tips for protecting your development environment and continuous integration/continuous development (CI/CD) pipeline against attacks and compromises.
About the Author(s)
You May Also Like
CISO Perspectives: How to make AI an Accelerator, Not a Blocker
August 20, 2024Securing Your Cloud Assets
August 27, 2024