3 ways to strengthen security with software supply-chain automation

Federal agencies are striving to become more innovative and iterative, leading to growing adoption of open source within the government. The issuance earlier this year of the Federal Source Code Policy illustrates how this technology, once anathema to government agencies, has become the de facto standard for the creation and deployment of many applications.

With the explosive adoption of open-source components being used to assemble applications, agency personnel are now tasked with ensuring the quality of the components that are being used. Developers must have confidence in components’ security, licensing and quality attributes and know for certain that they are using the latest versions.

However, recent analysis from my company’s 2016 State of the Software Supply Chain report found that one in 16 software components used by development organizations to assemble applications contained at least one known security vulnerability. Just one vulnerable component propagated across thousands of applications can lead to Heartbleed-scale breaches, and a single agency might use as many as 500,000 components per year.  

Combatting such risk is at the root of the National Institute of Standards and Technology’s Risk Management Framework. The RMF requires federal agencies to continually understand, assess, monitor, and document their cybersecurity risks over the lifecycle of the IT assets they procure. It consists of a process that includes system categorization; selection, implementation, and assessment of security controls; and system authorization and monitoring.

Unfortunately, many agencies that are adopting the RMF are also relying on outdated and inefficient practices and tools that are not designed for today’s open and agile world. In addition to relying on potentially vulnerable components to build applications, some agencies have continued to depend too heavily on common application security tools, such as static application security testing and dynamic application security testing.

These tools work well for custom code but are ineffective at screening open-source components, which now make up 80 to 90 percent of an application. Even worse, many agencies are also still dependent on manual screening, which can be error-prone, time-consuming and cannot scale to match the pace of component consumption.

Agencies using open-source components can combat these problems by embracing software supply-chain automation, which can help them ensure the software components they are using are secure and remain so throughout every step of the RMF life cycle.

Here are three steps that federal IT professionals can take to monitor their software supply chains and ensure that only the best open-source components make their way into their organizations.

1. Implement an automated firewall. The best protection starts with the creation of a firewall that automatically and continuously blocks substandard components from entering into the software supply chain. This first line of defense should be configured with automated policies that meet NIST security standards for the RMF.

Taking this one step further, federal IT professionals should imbue their firewalls with automated monitoring that allows them to retroactively review the components that may have triggered policy violations. Looking back on historical data can help refine and further strengthen security controls to better prevent similar vulnerabilities.

2. Apply user-defined policies and security controls. The RMF gives agencies leeway to set up myriad security controls and components to help support risk management, vulnerability scanning, flaw remediation and more. Agency IT personnel should enhance these efforts by applying user-defined policies and controls that govern which open-source and third-party components can be used in application development. In the event that a software component that does not conform to security policies gets through the firewall, alerts will be triggered and remediation scenarios presented, allowing users to respond quickly and effectively.

Also, a software bill of materials should be created for each application to ensure the application complies with RMF security protocols. A BOM can also make it easy to track and replace vulnerable components that are identified after applications are shipped out of development and into production.

3. Continually audit and assess. After components have been procured and applications are in production, it’s important to continually audit and assess those applications to ensure they remain secure. This activity can help proactively identify vulnerabilities and alert managers to potential hazards even after an application is up and running.

In fact, this process is particularly important as software components age. The previously mentioned software supply-chain report also revealed that open-source component versions between seven and 10 years of age have three times higher vulnerability rates than those between one to three years old. Therefore, it’s critical to track components throughout the entire life of an application, especially after they are released into production environments.

Automation is the common thread that binds all of these processes. There are simply too many components, coming from too many different developers, to trust in manual monitoring processes that can miss -- or even, through the result of human error, create -- security holes. Application security is far too complex and important to take that risk, making automated software supply-chain management essential to agencies’ RMF initiatives.