Enhancing software supply chain security

The Secretary of Commerce must solicit input from the federal government, private sector, academia, and other appropriate actors to identify existing or develop new standards, tools, and best practices for complying with secure software development standards and procedures identified in President Biden’s Executive Order (EO) on cybersecurity. The scope of the EO’s Section 4 on software supply chain focuses on the ability of software manufacturers and software developers, in particular, to validate all components of the sub-systems which support their offerings. It also focuses on best practices for assessing the risk of included components in their offerings, either in pure form, object, or executable, which cannot be verified or validated to their true origins. Furthermore, the EO solicits guidance from industry including best practices for identifying breaches in the management of the software supply chain, and allows for multiple agencies to receive such alerts and ingest threats into their systems, enabling analysis at a much greater velocity than has been achieved before.

EO RESOURCE CENTER: Learn how to accelerate your ability to meet the requirements

Whether it is an entire platform or a single library, the software lifecycle starts with one or more use case(s). First, a design contains features and functions which address the use case as well as meet the financial goals of the organization. Next, the solution is vetted and management accepts the cost for the development of the software. Engineers then come together and combine reusable objects (development libraries, OS libraries, compilers, web services, databases, etc.) with code and develop a solution, which becomes a release candidate. Along the way, documentation around the successful, as well as not-so-successful, development efforts are compiled. Once it is deemed viable, testing occurs with the candidate, and depending upon the outcome of the testing, the candidate is officially released. The release can then be sold, distributed, and delivered in many forms to consumers.

With so many moving components to the software lifecycle, threats can enter the solution at multiple phases. An approach to addressing security vulnerabilities within a software supply chain will need to:

  • Utilize a cybersecurity posture regarding the policy of identifying security vulnerability indicators and warnings promptly
  • Alert about the elevation of access during the composition and execution of an offering, eliminating any unforeseen introduction of vulnerabilities
  • Provide both positive and negative artifacts during the software supply chain process (events captured can be shared and readily imported to any consumer data lake for risk analysis)

Looking at the software supply chain from an obtuse to an acute way, a security solution should start with creating policy around a proper build cycle that produces artifacts concerning the success and failure of build, test, and deployment. These artifacts are the cornerstone to which a risk assessment can be made. Additional components necessary to help mitigate supply chain risk include a vulnerability assessment of the target solution and target platform. Looking more closely at what glues the solution together, a static/dynamic code analysis tool should also be leveraged during the overall build/test process to mitigate the risk of introducing unforeseen vulnerabilities downstream to the consumer. Examining what comprises a solution shouldn’t stop at the application itself but should extend to secondary and tertiary dependencies upon which solutions depend.

Vulnerabilities can present themselves in many ways and a vulnerability scan tool utilized during the testing process will assist in mitigating risk. The scope of the vulnerability scan needs to consider all components north and south with regards to the solution to consider the full potential scope of the vulnerability risk assessment. As these lower-level components are leveraged, additional policy regarding software supply chain validation needs to be enforced. Sub-systems and repository sources will need appropriate attestation to their validity and can be achieved using cryptographic mechanisms to verify component integrity. With sub-systems also relying heavily on platform as a service (PaaS) technology, there should be consideration given to vetting the location of platform components to include OS/Container image validation.

Merlin Labs builds Proof of Concept integrations with several best-in-class cybersecurity partners which demonstrate market-leading solutions to difficult real-world problems, including supply chain security. Some of these tools address CI/CD DevSecOps, application security, and application access management. For example, the combination of CyberArk and Contrast Security can help federal agencies meet the EO’s Section 4 requirements.

CyberArk’s Platform Access Security/Application Access Manager is a critical piece of the puzzle. By managing least privilege to the application layer, it can manage access control and work to leverage threat analysis based upon behavior from within applications. The addition of Contrast gives software providers real-time remediation guidance and attack protection through inline use, cutting valuable time to market due to inherent risks via code practices or dependent modules. With these and other partner solutions, Merlin offers comprehensive solutions for securing the software supply chain.

How PAM Can Protect Feds From Third Party/Service Account Cyber Attacks

How PAM Can Protect Feds From Third Party/Service Account Cyber Attacks

Share This