How to Prevent Risk From Unknown Build Assets

Find out why unknown build assets is a growing problem and how Legit can help.

Do you know: 

• Where all your development assets are? 

• How to map out your pipelines from start to finish? 

• When developers spin up a new asset like a Jenkins environment? 

• Where you have appropriate security controls within your pipeline? 

 If you struggle to answer any of these questions, know that you are not alone. We commonly uncover build assets in organizations’ development environments that they are not currently using and are not aware of. For example, working with a major manufacturing enterprise, we helped discover a rogue Jenkins server in their environment; they were not aware it was there, and it was not only exposed to the Internet, but also had risky misconfigurations. 

Why are there so many unknown assets in build environments today?  

Developers “bringing their own devices” plays a significant role.  

 In the not-so-distant past, there was a sharp divide between dev and ops — developers 
created applications, and operations ran them. Now development teams are creating their own build and deployment pipelines, which includes assets such as source code managers (SCMs), continuous integration/continuous delivery (CI/CD) pipelines, and cloud deployments. This helps development teams move substantially faster, though at the cost of security’s visibility into those systems. We often come across scenarios where development teams are spinning up Jenkins servers, Azure DevOps pipelines, or JFrog artifact repositories, and the security team has no visibility into where those exist, when they were instantiated, or why they have been provisioned in the first place.   

And this isn’t just a hypothetical risk … 

Unknown build asset leads to SolarWinds attack 

The SolarWinds attack, where attackers deployed malicious code into its Orion IT monitoring and management software used by thousands of enterprises and government agencies worldwide, originated with an unknown asset.   

The attacker's entry point was through an unknown and unmonitored build server. Misconfigurations played a role as well, though the lack of visibility into build assets was the first flaw in a series of vulnerabilities that led to a successful hack. 

How to prevent unknown build assets  

Trust but verify. Most development teams are happy to share what’s in use and where; however, sometimes there are assets development and IT operations teams do not know exist. This can be due to rapidly changing teams with poor change management practices or mergers and acquisitions (M&As) introducing a flood of new assets into environments.  

Here is what we recommend: 

Implement a robust configuration management database (CMDB) and tagging structure. It is important to keep an inventory of what is being built, what is generating revenue, who owns what, and the risk analysis associated with assets. This inventory is fundamental to contextualizing risks detected and determining which business impact factors should be considered when triaging and prioritizing security vulnerabilities or misconfigurations. 

Implement paved pathways with control checkpoints. A paved pathway helps developers meet security requirements without having to figure out what the requirements are. By enabling developers, they do not have to think about questions such as, “Do I have the right scanners? Are they configured to my mobile tech stack when I go to production? Do I have the right checks in place to be able to deploy?” Reducing their cognitive loads will allow them to focus on delivering business value without inundating them with security controls that must be built into the software development lifecycle (SDLC). 

Create templates for build and deployment pipelines. Rather than require developers to reinvent the wheel to build and deploy software, pre-configured and hardened resources reduce the likelihood of failing to implement security controls. When the technical stack for pipelines is secured from the start within developer tool chains, the blast radius for vulnerabilities discovered within applications is more easily contained and managed.  

Harden container images. Given how prolific microservices have been within the last decade, container images remain a targetable entry point because they are easy to spin up and build on top of with minimal configurations.  

For example, if you deploy a container image pulled off Docker Hub, by default it is set to a root user with default passwords and has access to the underlying host it is deployed on. To prevent exploitation of containers, you can harden the image by creating a specified user with credentials pulled from a password manager to limit permissions. This practice of least privilege can be built into container images without requiring developers to fully understand container security.  

Consider SDLC inventory platforms that can auto-discover and alert to deviations in environments. Auto-discovery of assets with built-in automated workflows and notifications are vital as businesses can and will grow over time. 

If your organization is part of an M&A, or your product scope expands, you need to have some sort of system that will prevent shadow IT from accruing. 

I have had so many conversations with people who say they are 100% a Jenkins shop. Then they plug into the Legit platform, and they see that they actually have some rogue or orphan Azure DevOps pipelines that no one had any idea about. 

In another example, at one organization, we found over 20,000 homeless repositories that were not being managed or scanned by the security team. Discovering these types of assets is important so that you can apply the right controls and assign ownership to deal with any potential risks discovered. 

Facilitate culture shift. While last on this list, this is the most important action to take. Regardless of what your role is, everyone needs to buy into the mission to not become the next SolarWinds. A shared responsibility for cybersecurity and resiliency requires a proactive mindset to discover assets and apply the appropriate levels of security controls so that when something happens, everyone is prepared to respond accordingly.

Understanding common SDLC risks 

As development environments grow increasingly more complex, they introduce more risk, such as misconfigurations of build tools, proliferation of secrets, or unknown build assets.  

Get our new guide on the top unknown SDLC risks we uncover to get a sense of the risks that might be lurking in your development environment, and how to address them.