Six Top Tips For Holistic AppSec and Software Supply Chain Security

Developing applications and working within the software supply chain requires hard skills such as coding and proficiency in programming languages. However, protecting the software supply chain also requires some softer skills and an openness to strategies and tools that will strengthen your security posture. In this two-part series, we will discuss these considerations and how they support a holistic approach to application security and software supply chain security. 

1. Walk a mile in developers’ shoes.

We’re increasingly applying security earlier in the software development lifecycle (SDLC), a shift-left approach that requires the buy-in and involvement of developers. However, developers are very sensitive to additional work, so approach this situation with empathy. You have to understand and anticipate the issues involved, and provide solutions.

Consider how you are going to integrate with development teams. What are their needs and concerns? Then frame your strategy around that and provide them with ways that make security easy for them to adopt. And seek solutions that have scalable outcomes. If you implement something that creates a huge mess for developers, it’s going to be difficult to develop and maintain momentum.

2. Where possible, automate.

Automating security measures is important because when processes are manual, you simply can’t scale to handle the volume of components and dependencies, as well as the speed of change and software development. For example, static application security testing (SAST) can be integrated into the development environment so that you can help developers learn from any errors as they work. Don’t develop a program that requires them to submit the application for scanning, get the results back, and then learn. Integrate those lessons into the development loop as quickly as possible. They reduce the friction for the developers and this leads to a better application security program.

3. Build a good inventory.

It might sound obvious, but you can’t fix things if you don’t know you’ve got them. So, having a good software inventory is critical. Employ tools such as a software bill of materials (SBOM) and integrate it into the development environment. The detailed inventory of the libraries you get from an SBOM gives you the visibility needed to align responsibility and have traceability for the repos. There are always incremental improvements, but it’s an exciting place to be because we can know very quickly who’s responsible for repos or any other zero day going back to the likes of Spring4Shell.

4. Take responsibility.

You need inventory to have accountability, and you have to provide your teams with tools to take responsibility for effective management. SBOMs aren’t just gestures. They address a market inefficiency that governments are trying to correct. This inefficiency is that sometimes software vendors or service providers have inadvertently transferred the risk of ineffective maintenance over to their customers, and the customers are not sufficiently aware of that risk. SBOM and other standards, like configuration management database (CMDB), are attempts to fix this, and they address calls from governments such as the Biden administration to apply such standards via agencies such as the National Telecommunications and Information Administration (NTIA).

We know from experience that when customers seek proposals and RFIs, they request SBOMs. So, I anticipate that over time, more sophisticated consumers at the corporate level will ask for SBOMs, and I think that the intent of the public policies that are being introduced is to correct the market inefficiency.

5. Don’t rest on your laurels. Keep updated.

Once a tool like this is in place, stay alert and keep it updated. Teams that struggle to patch new vulnerabilities and threats also struggle with maintenance. That’s where a tool like Mend Renovate helps enormously, scanning your software, discovering dependencies, automatically checking to see if an updated version exists, and submitting automated pull requests.

And be mindful that security can’t be a one-time thing. Whether it’s an SBOM, a code scan, or an architectural review, it’s got to be built into a flow because software’s changing very quickly. You can create an SBOM in the morning and quite quickly, it can become out of date because someone has checked something in, pushed it into test, and it might have even gone to production. That’s why automation is so important. It makes security seamless and eases the process for those who are tasked with it, like developers, so they can readily adopt and embrace the process. That circles back to my first point: be developer-focused, because they’re the folks you’re relying on to apply your security strategy.

6. Integrate education.

Developers need to know what they’re looking for and what to do when they find it. They therefore need to be educated and remain cognizant of changes and updates. It’s a process that should be ongoing, and as integrated as possible into their normal workflow. So, make sure you have processes that are integrated with IDEs and build pipelines that show teams flaws and errors. This is important because you can take the lessons learned from finding vulnerabilities and feed them back into the training program. Most important is helping people understand when errors occurred and why, so that security can constantly improve.

Equally, focus on your people. Set them up for long-term success by keeping them trained and educated. Give them a strong foundation in networking. Offer even non-technical folk with a stake in security some introduction to Linux and some Python. Then they will expand their skills, become more valuable to your processes, and grow with you. With increased knowledge comes increased understanding and more visibility into security issues. Establish a minimum standard and ensure that everybody is trained to that standard in both the security and DevOps spaces, and you’ll benefit from a lot of efficiencies in the long run.

Learn how SBOMs can go beyond compliance

Read the report