Producing Secure Software

Knowing the current types of attacks targeting the software supply chain can inform security improvements for the development and deployment of software, but security needs to be well integrated into the process to avoid creating bottlenecks in the creation of applications and new features. Some simple process changes can have outsized security impacts while maintaining developer momentum.

Provide Developers the Information They Need

The shift-left movement has placed more responsibility for software security on developers, but the focus on security should be implemented in a way as to minimize any disruption to development. Security information and guidance, for example, should be presented as early as possible to both alert the developer to poor security patterns and defects that create vulnerabilities, but also as a way to train developers to recognize such coding patterns in the future.

This extends to the supply chain as well. Security metrics should be presented whenever developers import libraries or include components, so they have information about the security and stability of open-source components and don’t import vulnerable components into their software, essentially propagating exploitable code. In addition, the company’s overall policy on component characteristics should be available through a dashboard to provide opinionated conclusions on the projects behind the code.

Remediation: Helping Enterprises Get the Control Back

1

Upgrade Component(s): In most cases, reducing the risk will involve deploying an upgrade recommended by the tool itself. However, Upgradation can be tricky sometimes since it requires the business-critical system to be halted for a given time window. So think of removing the Vulnerable component that is not actually being used.

2

Patch Component(s): In some cases, Developers will go ahead and fix the vulnerability by forking the Open-Source component master branch and creating a new release path for the revised and secured component which can be moved to white-list and approved software, the best practice is to perform SAST on the code now owned by the development team.

3

Disable the vulnerable process or function: this might be the easiest way to reduce the risk but if the vulnerable component does not impact the business functionality, it can also be disabled.

Block Known Malicious Attacks, White List Approved Software

The shift-left movement has placed more responsibility for software security on developers, but the focus on security should be implemented in a way as to minimize any disruption to development.

Security information and guidance, for example, should be presented as early as possible to both alert the developer to poor security patterns and defects that create vulnerabilities, but also as a way to train developers to recognize such coding patterns in the future.

Knowing the current types of attacks targeting the software supply chain can inform security improvements for the development and deployment of software, but security needs to be well integrated into the process to avoid creating bottlenecks in the creation of applications and new features.

Up next: