First steps to increase confidence in your build environment's integrity
Security operations monitoring in the traditional sense is often a beaten path for most large organizations. What’s new for many however, is applying the concepts of automated, real-time alerting and streamlined responses to the fast-paced, rapidly changing landscape of DevOps.
In the winter of 2020, the SUNSPOT malware demonstrated how sophisticated attackers may target software vendors. After achieving a foothold inside of an organization, attackers can compromise a build pipeline so that customers of an affected company’s software may be subject to compromise as well. So how can an organization monitor the integrity of their software build process to increase detection of malicious activity?
What knowledge would make you feel better about your software development infrastructure itself, in addition to contributors and processes? Can you develop a list of questions that you’d like answered for each of the major steps in the build process?
Here are a few examples of security monitoring questions that may help identify potentially malicious behavior in software development:
Build Process Stage | Example Security Monitoring Questions |
Source Code Repository |
|
Dependency Management |
|
Build |
|
Artifact Repository |
|
In this approach, which some may refer to as automated governance, it goes without saying that not all use cases are equally attractive. What makes a use case better? Analyzing use case attributes like “ability to reduce risk” and “level of effort to implement” will help identify a first set of more valuable use cases. Another round of prioritization could come from answers to questions about the monitoring use cases such as:
The goal of putting your first few build pipeline security monitoring use cases in production should be to learn the process of their implementation, not inspire complete assurance of build pipeline. You may even include the buildout of such monitoring use cases as part of your organization’s regular security champion dialog or hackathons. If you crowdsourced the buildout of some such use cases to engaged security champion developers, is one new use case per month realistic? And of course, consider sending alerts from such monitoring beyond the classical security operations team to the developer teams’ real time instant messaging collaboration tools. When done well, this can increase security awareness among broader development teams who may not yet consciously prioritize security and minimizes unnecessary “hand offs” – a core tenet of the “First Way” of DevOps and key to increasing process flow.
The suggestions above should provide a framework for what to monitor in your developers’ build activity, how to implement them, and who gets alerted when something potentially malicious is identified. As more build pipeline monitoring use cases are implemented, confidence that your build pipeline and software development is trustworthy increases, the likelihood of serious security events decreases, and you can focus on innovation and delivering value to your customers.