This post was originally published on this site
This blog is co-authored by Nur Hayat and is part two of a four-part series about DevSecOps.
Earlier in this series we covered how Continuous Security Buddy (CSB) for continuous integration/continuous delivery (CI/CD)—CSB for CI/CD —provides an automation framework for holistic, continuous security based on DevSecOps principles. In this blog, let’s take a closer look at software composition analysis, with a focus on security scanning of third-party software components in Cisco software.
As the use of third-party software has become ubiquitous across product development and industry, there has been growing interest in more accurate visibility and accounting of the use of open source and commercial components. High-profile vulnerability events have yielded critical security exploits, especially in commonly used open source software such as OpenSSL (Heartbleed vulnerability), Apache Struts, glibc (GHOST vulnerability), and bash (Shellshock vulnerability). This has increased awareness and concern among customers and security practitioners, accelerating the need for the proper management and hygiene of third-party software.
At Cisco, we are addressing this need by offering an internal service called Corona that uses proprietary and commercially available scanning tools to identify third-party software components. It also provides validation of applicable security posture characteristics within released Cisco software. Corona was named after the CORONA Program of American reconnaissance and discovery satellites launched between 1959-1972. The Cisco Corona service is similarly tasked with providing surveillance of software, to view its components more clearly and to provide a platform to perform a holistic analysis of the software and associated risks.
Key Components of the Corona Service
1. Discovery of Third-party Software
Corona is a tool-agnostic harness for various types of third-party and internal software decomposition tools, including file unbundling capabilities and binary and source scanners. Corona coalesces input from individual discovery tools to produce a consolidated software Bill of Materials (BOM) of the product or offer.
A few important observations to share about third-party software security scanning:
Software is Complex
There is a plethora of file formats, ranging from well-known Linux to proprietary formats. Commercially available proprietary scan tools may not be able to decompose on their own. To address this, Corona runs a pre-processing unbundling step based on the file encapsulation prior to running traditional scan tools. Another complexity is that software can vary from static, dynamic, and script-based languages. Also, software is not flat but can be nested. In some case this may require additional discovery considerations, such as reconciling hierarchical relationships between components.
One Sized (tool) May Not Fit All
Individual use cases may require the combination of complimentary tools across different software technologies (like containers) and languages. Corona includes support for multiple scan technologies, ranging from binary to source scan, and detection leveraging hash to YARA rules. To promote extensibility, users can also send results from their own tools and provide their own disclosure based on triage insights.
The Naming Issue
One of the fundamental hurdles of correlating third-party software is naming because component names are currently not completely standardized between scan tools and systems. At Cisco, we attempted to address this by creating an internal database that aliases instances of component name variations to a master name to enable comparison across tools and ecosystems.
2. Value to Clients – Corona Reports
The key outputs from the analytical tools available with Corona include the following reports:
This report provides the list of third-party components detected in the software and associated metadata. Components are typically atomic pieces of software that have license and vulnerability implications and are uniquely identified via a tuple or set of characteristics, (e.g., component name, version, release details, and supplier).
This report also provides insight into the level of software decay or the presence of stale components, which significantly increase the vulnerability exposure and can impact market access certification compliance (e.g., FIPS) if deprecated libraries are present. Along with the detected version, the tools also provide the latest known version from the supplier to promote basic software hygiene like frequent upgrades or patching.
Security Awareness Reporting and Compliance
This report provides statistics, verification evidence, and the compliance state of key software security characteristics mandated by secure development lifecycle processes and industry-based Security Control Framework (SCF) requirements. These include establishing:
- Whether approved cryptographic libraries are used in the software
- If the software is appropriately digitally signed
- If run-time defense capabilities are present to prevent code write and execute exploits, buffer overflows, and memory attacks
3. Scaling and Adoption
Corona is interconnected with broader Cisco software processes and workflows to provide holistic third-party software visibility, traceability, and risk mitigation. These include the following:
Along with integration into the development lifecycle, Corona is also inserted into Cisco’s software publication systems, specifically those that distribute on-premises software. This allows one final scan and checkpoint assessment before the software is available for customer consumption.
Cisco’s Third-Party Software Compliance and Risk Management (TPSCRM) Integration for Legal and Vulnerability Compliance
Corona is the ingress tool into the TPSCRM ecosystem. It provides the scanning and third-party software discovery functionality. The software BOM and component metadata are then sent downstream and registered with Cisco supply chain tools that validate whether open source and commercial legal and license requirements have been met prior to release. The software BOM is also sent to Cisco vulnerability management tools that correlate the third-party software components with vulnerability data feeds to provide a list of Common Vulnerabilities and Exposures (CVEs) and the associated severity impact.
In today’s application and deployment paradigm, it is not uncommon to find products that contain 70 to 80% of third-party software. With the rising tide of cyberattacks and the vulnerabilities potentially enabled by those third-party components, it is imperative that administrators determine if and where they are impacted by potential exploits. This is a call to action for the industry at large to secure and mitigate risk from third-party software.
Cisco continues to engage with customers and policy advisors, like the National Telecommunications and Information Administration (NTIA), to help define best-practices and guidance related to software transparency. We have pledged to introduce these principles into our product and solution processes.
We would love to hear from fellow practitioners about how you are managing third-party software risk. Please post your comments below and come back to read the next blog in the series!
Visit our Trust Center
To hear about Cisco’s security and trust journey