4 Principles for Creating a New Blueprint for Secure Software Development

Professional and state-sponsored hacking groups are dedicating more time, money, and effort to cybercrime every year. Threat actors use novel techniques in new types of attacks that some of the world's best cybersecurity experts have never seen before. Emboldened and well-funded, bad actors now have the resources to target not only large corporations — a successful breach of which could be highly lucrative — but smaller organizations. A recent study from Duke University found a stunning 85% of surveyed midsize companies across sectors reported their systems had been successfully penetrated at some point, despite many of these organizations potentially following long-established best practices.

One industry that threat actors are fixated on is computer software development. Because we rely on software almost constantly in our personal and professional lives, it's critical for companies to have processes in place to help ensure their software is safe and to stay a step ahead of bad actors and unforeseeable threats.

At SolarWinds, we're helping create more secure software development with our Next-Generation Build System, which uses a parallel-build process to develop software in multiple secure, duplicate, and ephemeral environments. To help protect the entire industry against future threats, we're releasing components of this build system as open source, so other companies can benefit from what we've built.

Here are four guiding principles of the Next-Generation Build System companies might consider adopting. Combined with public-private cooperation and information sharing related to threats, these principles can help organizations improve security in the face of increased risks.

Build Systems That Self-Destruct and Are Built With Code

To secure the software development process, organizations need to implement systems leaving no long-lived environments. This is critical, as mature environments and build systems may contain more severe vulnerabilities and out-of-date components, inviting an easier opportunity for attackers to strike.

Organizations can mitigate these vulnerabilities by developing products in short-term software build environments, which means they self-destruct after each task is complete. Doing so removes the opportunity for attackers to establish a "home base" in systems, making it substantially more difficult for threat actors to attempt an attack.

Having the build system based on code enables the short-term self-destruct model and provides safeguards and versioning for the build components.

This method of development requires a tightly controlled process and organized leadership, as organizations must isolate, administratively separate, and closely monitor build systems.

Reproducibility Is Key

When it comes to software development, reproducibility is key to ensuring build security. The premise behind reproducibility is that a development team can build software in one place and rebuild it on another system or at a different time with the same outcome.

By relying on reproducible builds, developers can ensure their software behaves the same way, weeding out disparities in code, identifying anomalies, and preventing intrusions. With reproducible builds, software development companies can reproduce errors to better understand and remediate them and identify any unauthorized adjustments in the build pipeline.

A reproducible build is critical because it also enables software development to compare the final output of source code to ensure it's the same regardless of where or when the build was created. This is critical for the next step of the process: building in parallel.

Build in Parallel

Another way to strengthen the integrity of the software development process is through what's known as a "parallel build" process. For maximum security, this entails utilizing three logical build pipelines: developer, staging/validation, and production. All builds must meet the characteristics described above.

The developer pipeline performs normal engineering builds. Access to the build environment is necessary for most engineering. The staging/validation build has limited access. In addition to performing the build, it's also where quality, security, and performance tests take place.

The final pipeline is the production pipeline. Access to this pipeline is extremely limited. Only a couple of predefined people have access. Prior to shipping from the production pipeline, a comparison is completed to the staging pipeline. The build model takes an approach of assumed breach, meaning one compromised person can't independently compromise a production build.

These parallel environments each have a single entry point and are independent environments, decreasing vulnerabilities by focusing the potential threat on a single environment. If one is compromised, efforts of attack have a low probability of being replicated across the remaining two environments.

Retrace Your Steps

Traceability is the final principle critical for ensuring a secure build process. It's key to verify each build step through a tracking process you can verify prior to the software being released. This requires sign-off from engineers and management for each project running through the pipeline.

The idea is to watch each step carefully, verifying every code matches and is properly implemented, and that there's a clear, traceable history to understand any mistakes or abnormalities. Adding human validation prior to a production release helps guarantee all appropriate steps are taken to ensure quality and security.

The cybersecurity landscape is constantly shifting. New threats and motivated, well-funded bad actors emerge every day. Improving the security of the software development process is a key part of thwarting and mitigating these attackers. We encourage the industry to adopt these principles, to be more open about security, and to share information and best practices to improve the security of the industry overall.