In my previous post, I began to list the ways you can strengthen your security posture, with some holistic approaches to application security and the software supply chain. In this second part of the series, let’s look at six more important considerations.
Education strengthens knowledge, but you also need to apply good judgment ― wisdom, if you will ― that arises from experience. This is particularly significant when using new AI and LLM technologies. Many of these tools give you a convincing — but not necessarily the best ― answer, so you must evaluate the results. Blindly following the answer, no matter what tool, will cause problems.
There are generalist LLMs like ChatGPT, and then there are more specific add-ons such as GitHub Copilot, which works in your development environment and has been trained on code. These more domain-specific LLMs are likely to provide more useful answers, especially when building on any of the data that you have. That’s where we’re going to see big value from LLMs.
All of this requires the buy-in of the C-suite and stakeholders. The success of your AppSec and software supply chain security program depends partly on whether decision-makers understand the risks they face at any given time. At this level, a lot of folks don’t understand the technology, so they don’t fully understand the risks, and how to manage them. Those in the application security space need to help them improve their understanding of risk. What is inherent risk? What are controls? How do controls give you residual risk? What are the control options? How does time fit into this?
For instance, you sometimes might need to accept some risk in the short term to build an effective solution that is more supportable in the long term. Investing the time, effort, and budget in an automated, scalable solution will be more efficient over time, but perhaps more challenging in the short term.
You need a modicum of both knowledge and wisdom to manage risk and exceptions, particularly at scale, because you need to base decisions on what risks you will tolerate based on an understanding of the way your software and its dependencies work, and judgment as to what risks and exceptions are acceptable. It could mean the difference between operating a targeted and effective detection and remediation strategy, and an inefficient process weighed down with false positives. You need to apply know-how and experience to decide how best to modulate your risk threshold using techniques and tools such as SCA, SAST, container scanning, and more. Otherwise, you risk blocking developers when it isn’t necessary. That’ll make a real mess, and your developers will be discouraged from actively supporting security efforts, which will detrimentally affect your AppSec program.
Perhaps the main challenge for security is to deliver without impeding developers’ pipelines and hindering their productivity. Think of it like motor racing. A pit stop is a big deal. There needs to be a serious reason why performance must be interrupted to address a problem. Better to avoid this situation, where possible, by monitoring and tweaking performance while driving. While things are happening on the track, there are all kinds of telemetry decisions, communication analyses, and more, and that’s how we have to think about security. Wherever possible, it should take place during the workflow, whatever it might be. SBOMs are being produced, static analysis, software composition analysis, all those things create telemetry for us. We just have to figure out the right way to harness this information, so we know what’s going on, and we know when to take action.
Then we have to think about who is authorized to make the right calls when it comes to security decisions. It’s often unclear who is accountable for the process and it’s inconsistent in industry right now. The modern complexity of relationships between the manifold components and dependencies within modern software lends itself to security teams having oversight, with developers implementing security as it shifts left.
The challenge is how to set up a framework so that developers understand and manage their risk as opposed to managing their risk for them. It involves helping people easily identify, understand, and assess their risk, and providing them with information, so they can make wise, educated judgments.
Recently, we’ve seen attacks become more sophisticated as well as more numerous. For example, many more malicious packages are now being published into npm than before. Nevertheless, the challenge remains to ensure that your security processes are accurate, or they’ll get overlooked. We don’t want to become the boy who cried “Wolf!” Most companies that are trying to develop at scale need to maintain their speed of output while reinforcing their security, so the balance is to practice responsible open source usage by applying pre-emptive and preventive AppSec tactics and tools earlier in the software development lifecycle (SDLC) by shifting left and iterating those procedures during the SDLC ― shifting smart.
Most importantly, make sure you have a plan. Keep your dependencies up to date. It’s like fixing up your house. You don’t wait until things start falling apart. Do preventative maintenance. Understand where you are in the value chain. Ensure that you develop solutions that are highly scalable and that fit the capabilities of your team. And don’t break development. Don’t break the build.