7 Best Practices for Modern AppSec Programs
Mend.io CEO Rami Sass, Jeff Martin, VP of product management, and CMO Arabella Hallawell recently sat down for a panel discussion on AppSec today. In this second of a two-part series, they get tactical, as they discuss seven best practices for building modern AppSec programs.
1. Make AppSec dynamic
Jeff Martin: A lot of the development methodologies that are actually in practice for major application vendors are still old. The wall between development and security has to come down in the same way that the wall between development and QA came down many years ago. Because your software’s a living, breathing thing. It’s not static. It’s connected to everything else and it’s constantly changing. So, you can’t use those same processes, and AppSec is better enabled by modern tooling than the tooling we had five years ago.
2. Address the lack of processes
Arabella Hallawell: Many organizations don’t have either the tools or the processes to scan either custom code or open source, and they haven’t connected their dev teams and the security teams to implement some of these things.
I recently spoke with a large technology research organization and they said that open source functions and things like a full dependency health program just aren’t there. Yes, there are tools that can automate dependency updates and provide the information you need, but if you don’t have processes, they’re difficult to implement.
JM: Tools to automatically update dependencies certainly exist. We’ve got a great one, Mend Renovate. But the first thing you need to ensure you’re not introducing functional risk is automated testing. Sure, you can mitigate issues. Tools can tell you that a particular version of software has been used by others, it’s safe, and they aren’t having problems. But other processes don’t enable this. You need a capability like automated testing to check whether you have introduced functional risk when remediating security risk.
3. Overcome existing security debt
Rami Sass: Some of the organizations that are most successful at handling application security risk segregate their preexisting situation. They have some backlog or existing security debt. So, they start by making sure they’re not making matters worse with any updates. First, implement a process that ensures you don’t introduce any new application security risks, preemptively keep your dependencies updated, and apply a high level of hygiene to your software. Then, gradually you’ll start reducing your security debt. You can prioritize it, to get good ROI when you make incremental investments that will decrease your exposure to risk.
I think this is the most effective way to approach implementing AppSec. First, ensure you’re not doing any additional harm. Then go back and prioritize your biggest exposure, and tackle that. What you’ll find is with a relatively small investment in resources, you can start fixing 50, 60, and 70% of your risk before you hit the more complicated problems.
4. Prioritize prioritization
AH: It’s also worth highlighting that close to 85 percent of updates have already got a fix available before they’re published. So, if you get up to date on dependency health, you genuinely narrow your attack surface. Some basic technologies should be adopted, including reachability analysis. This looks at all the issues that are found, identifies how many will actually reach your application, and what you can do to fix it. It’s still not as widely deployed as it should be, yet without it, security is so much more difficult than it has to be. If you map dependency health with reachability, you can become way more effective.
JM: Measurable prioritization is really important. How are you going to prioritize, and pick what matters to you as a business? Is a vulnerability really exposed to attack? Prioritize and fix what’s most necessary, not just what’s in front of you.
Then measure the success of what you’re using and what you’re doing. CEOs may see all those resources focused on security and they want to know what they’re getting for it. Without measurement in place, then it’s very hard to justify the spending, ask for more, or prove the value of your work. It all boils down to metrics.
5. Measure AppSec success
AH: There’s the amount of time it takes to remediate a critical issue. We did some research recently and 271 days is the average. If you implement some best practices, you can get that down to less than a month.
Then there’s what I call developer adoption. What percentage of all the code that you develop is scanned and fixed? This is a fundamental consideration because it means you’ve got visibility around all the code you create, so you know how much risk you’re exposed to and how much is remediated. It’s a huge factor for AppSec owners because you can’t manage risk if you don’t know what your risk is or what code is being created.
Just these two metrics seem to drive many quite sophisticated AppSec programs in organizations. I think you can probably fine-tune your AppSec program around them.
Some other organizations look at their apps that pose the most business risk. Sometimes it can be as basic as those apps that have a lot of customer information and are the most customer-facing. Once you improve those, you can make a step-level change to reduce risk.
6. Deploy a risk score
RS: Risk isn’t easy to measure. It changes between organizations and depends on what they do, what they need to protect, how many different applications they have, where they are located, and more. But you can create some form of risk scoring that takes into account not just the technical aspects of vulnerabilities, but also the business risk.
Risk scoring answers some salient questions: Is it a heavily used application or is it something that is only used by employees? You can also go beyond this to see if there have been publicly reported exploits in the wild, gauge the level of harm there, and consider secondary protection measures if.
A risk score of this kind is the best metric any company can have to gain visibility into its security posture. The next thing you need to track is trends. Is your risk escalating or decreasing, and how quickly? These are the two main things that I’ve heard at companies’ board level.
JM: Most of us need a solution and a manageable metric for the size and risk profile of our applications. And it starts with some basic things to measure:
- How many new vulnerabilities?
- Have you stopped installing anything risky or malicious?
- Do you know what’s in your software?
- Do you have an accurate SBOM?
If you’re a federal government customer, you better remediate everything in the known exploit vulnerability database within two weeks because that’s the rule.
7. Raise the bar on communication
AH: I think that narrowing the attack surface with some basic kind of dependency hygiene could benefit many organizations. I don’t think it’s currently as widespread as it should be.
Have a “report card” for your organization. This gives you awareness about how you want to improve. Those are the two basic ways I recommend helping raise the bar for your organization.
JM: I think education is a big way to improve security, particularly among more senior stakeholders. Invite them to webinars, direct them to white papers, and to relevant news and blogs about security issues. These are great ways to educate them and involve them in considerations about AppSec.
RS: I’d advise people not to confuse effort with results. I see people who have bought tools and implemented policies to handle security, but they don’t know whether they’ve reduced their risk. That’s because they’re not tracking their efforts and responding accordingly. You have to make sure that you’re genuinely getting value and reducing your risk, so you’re not just spending all that time and effort for nothing.
And remember: It isn’t just about technology. It’s about a combination of people, processes, and technology, working together to help you progress in your AppSec journey.
