Building a Modern AppSec Strategy: How to Secure Applications
Table of Contents
Second of a two-part series:
Threat actors today are increasingly targeting the application layer, driving significant challenges for companies using traditional application security strategies. To defend themselves against the rapidly evolving threat landscape, organizations need to build a modern AppSec strategy that addresses these fast-changing conditions. But how?
In a recent webinar, Jeff Martin, Mend’s vice president of outbound product management, and Janet Worthington, senior analyst at Forrester, discussed top tactics for securing modern applications.
Shift left becomes shift everywhere
Perhaps the most significant trend concerns where security processes are implemented within the software development lifecycle (SDLC). Over the past couple of years, Forrester reported in its annual state of application security survey that the shift left concept is now gaining traction. We have seen many organizations saying that they have implemented static analysis during the development phase. It is becoming a given that security testing shouldn’t wait until you go into production. Instead, it should be done early in the SDLC, where things are cheaper and easier to fix.
Worthington noted that people have been doing more in the development, testing, and even design phases as well as in production. They’re thinking about both shifting left and right, what she calls a “shift everywhere movement,” because it applies the principle that if you want to secure your application and the application layer, it goes beyond just assessing security at one point in time. You can no longer rely on that. You must think about continuous security throughout the lifecycle of that application and dive into the pre-release side of the development with testing. “More teams are actually integrating and automating security throughout the pipeline, making it easier,” she says. “So, you don’t have to remember to kick it off. It just gets kicked off for you. It’s integrated into your pipeline. We’re seeing more people who are planning to adopt technologies in both the development and the testing phases. Software composition analysis (SCA) leads the way here, and it is cited the most out of all of the testing tools.”
But other types of testing are also being adopted. 42 percent of respondents in the Forrester survey are planning to adopt dynamic analysis in development and 44 percent in tests. Previously, this had been implemented towards the end of the SDLC, but the report shows that this process is shifting left, spreading the testing more evenly throughout the SDLC.
“I like the shift everywhere language,” said Martin, “because realistically, everybody realizes you can’t test in one spot, or at least they’re beginning to realize that you have to test throughout. And one kind of application security is not sufficient. SAST (static application security testing) checks a specific kind of weakness. SCA gets you your inventories and your known vulnerabilities, especially from reusable components like open source. Dynamic analysis helps you filter things down and find actual risk factors. The fact is, none of these by themselves are sufficient for a modern application security program. Maybe you don’t need all of them, but you certainly need one and you need to have them influencing each other, helping you take all these findings and filter them. This is now understood, and the survey backs up the fact that you have to test in multiple places and with multiple kinds of testing.”
The role of government and the rise of SBOMs
No discussion of security can ignore the U.S. Presidential Executive Order on Improving the Nation’s Cybersecurity that was published in May 2021. Worthington described it as “probably the most exciting thing that happened to the security industry in the last couple of years.” She focused on the executive order’s call to improve software supply chain security, and particularly its request to the U.S. National Telecommunications and Information Administration (NTIA) to come up with minimum requirements for software bills of materials (SBOMs). In her view, SBOMs are critical to knowing what ingredients are in the software you’re selling, and whether they pose any risks. Equally, they’re vital for knowing what components are in any open source you’re purchasing or downloading so that when a Log4j-type vulnerability is present, you’re alert to it, and can take the necessary steps to avoid or mitigate it. It’s a signal that companies and government agencies must make sure that they’re following guidelines when they are purchasing or accepting software. “We’re really seeing the government go through with this idea that we need to have more transparency in the software supply chain,” Worthington said.
The implications of this are wide-ranging, as companies don’t have to sell to the government to be required to secure your software supply chain and provide an SBOM. “We are moving towards requiring software bills of materials when you buy software,” Martin said. “When you sell your software to another big, large enterprise, one of the things that is going to be in the contract is the requirement to provide a software bill of materials. I think that’s the first step in creating what I would call a more transparent and formal trust process between software vendors.”
There’s an effective precedent for this. Medical devices have been made this way for 70 years. You need to know where every component and every screw came from before you implant a device in somebody.
“Fundamentally, these trust relationships have to be documented,” Martin said. “They have to have artifacts like a software bill of materials. And I think, once that stage gets accomplished in general, three to five years from now, you’ll see it go further. And people will start asking for things like a list of known vulnerabilities.
We hear a lot of talk about VEX right now (vulnerability, exchange information). People won’t just want lists of everything you use. They will want to be told what you know. What’s wrong with these components and how have you mitigated those problems? So, I think this will spread beyond the federal government very quickly.”
How do you deliver good SBOMs?
At Forrester, clients want to know how to ask vendors and suppliers for SBOMs and what to do when their customers ask for them. The SBOM guidance from the NTIA focuses on the following main areas as the minimum elements of good SBOMs:
- Data fields. What information should be included to ensure an SBOM is comprehensive and authoritative
- Automation. The process is most effective when it isn’t a one-time thing. It should be updated continuously as you build your applications
- Formats. The two most commonly used formats are SPDX (Software Package Data Exchange) and CycloneDX (Learn more about SBOM formats)
- Practices and processes. How frequently you’ll generate SBOMs, how they’ll be distributed, and who has access to them
However, Worthington urged organizations to go beyond these bare bones, to gain clear visibility and understanding of all components, dependencies, and their relationships so that they really know what they’re purchasing. Preparing your organization to do this involves the following steps:
- Inventory your software supply chain
- Document any supply chain and third-party risk issues, and propose mitigations
- Talk to suppliers about providing SBOMs and vulnerability reports
- Automate SBOM generation for software you sell and the open source you package
- Collaborate across departments to implement software supply chain security: legal, licensing, security, developers, and other stakeholders
Suppliers are strongly recommended to be proactive and transparent about this, as you don’t want customers to receive an SBOM, report further vulnerabilities, and ask you how you’re addressing them. This would cast doubt in customers’ minds and erode trust.
Furthermore, SBOMs are all inherently machine-readable and machine generative, so their production and consumption should be automated. Manual versions simply can’t be thorough enough or generated fast enough. SBOMs need to cover multiple layers of dependencies, quickly. It requires automation to be ready to share that information when needed. And be aware that, in the interests of “shift everywhere”, items that are introduced later in your build cycles, like your deployments, your infrastructure, and the containers that are running, also have bills of materials.
The role of software composition analysis (SCA)
Most software composition analysis (SCA) tools will generate SBOMs if you plug them into your application lifecycle. That allows software producers to analyze SBOMs to find components and their vulnerabilities, as well as to pass on the SBOMs to customers in one of the forms mentioned previously.
Additionally, a good SCA tool helps you to identify malicious components and remove them from your SDLC. “SCA should be a part of every program, even if you don’t care about security, because it generates your inventory for you,” Martin said. “Then it goes further and actually tells you about those risks and vulnerabilities and the good solutions also help you prioritize all of the findings.”
These capabilities also help with licensing compliance. No wonder, then, that the Executive Order highlighted the SBOM and made it into a rock star, although it was well on its way to becoming very popular anyway. It is being adopted quite equally across the board in design, development, testing, and production, according to the Forrester report, and many respondents plan to adopt exceed current usage rates. That’s because if you can ensure that before you even get into the SBOM, you’re pulling down open source and third-party libraries that meet your standards, then you’ll make life a lot easier for yourself in the future.
According to Forrester research, a larger proportion of those respondents who reported a breach over the last year are planning on adopting SCA than those who haven’t experienced a breach. They appreciate the need for it to be a goal for the coming year. “You don’t need to wait until there’s a burglar inside your house to lock your doors,” Martin said. “The numbers show that 85 percent of people are either already implementing this technology or planning on doing so. I don’t know what the other 14 percent are thinking, but I guarantee you that after their first breach, they will be part of that 86th percent.”
API security and best practices
Worthington and Martin also delved into API security. Forrester asked respondents when they plan to implement API security in the SDLC.
Planning is very uniform across development, testing and production with a lot of API security tools starting in production. But Worthington emphasized that the shift left mentality remains important in this context. She advised that you should start early in the life cycle while building APIs to make sure that you’re catching things before they’re going into production when it is easier to change things to mitigate vulnerabilities.
With that in mind, her recommendation for API best practices revolves around knowing what you’re using, which versions of APIs you’re employing, and ensuring that your security and development team are thinking about these issues early in the SDLC. The key best practices are:
- Conduct secure design, development, and testing practices. Engage your security and development teams
- Authenticate everywhere, and do this constantly
- Discover and catalog your APIs in an inventory
- Block malicious API traffic when you’re in production
Conclusion
Martin advocated for a design development approach that integrates application security into the design phase rather than layering it on top. And while that’s very hard to do for legacy applications, it’s a must-have for new application development.
Wothington added that successful programs also need a culture in which development, security, and the rest of the team all work together. With that culture in place, it’ll be easier to integrate security tools and methods because you will already have established an understanding between teams of why they’re important. Then, you can work together on the small incremental changes that will make your security better as you progress through your SDLC.
