Characteristics of a World-Class AppSec Program
A great AppSec program requires more than just scanning. It takes seamless processes and services designed to help developers fix flaws and write more secure code.
The following is a list of the characteristics that we have found among our customers with world-class AppSec programs.
Consider security early
In early planning phases, ensure secure architecture and design and conduct threat modeling of applications. The easiest security flaw to fix is the one that is never introduced.
Create a centralized AppSec inventory
One of the first challenges when kicking off an AppSec program is understanding where the applications are hosted, where the codebases are, who is responsible for building and maintaining them, what development languages are used, how critical are they to the organization, and so on.
In addition, organizations may not know about all of their web applications, either due to M&A activities or because they are created faster than they can track them, leaving them vulnerable to attack. Veracode Discovery quickly scans your entire web application attack surface to identify and inventory all of your web applications, giving you the best visibility into (1) where to target Dynamic Application Security Testing (DAST) scanning with Veracode Dynamic Analysis, and (2) into apps that can be decommissioned.
Learn more about prioritizing applications in this blog post.
Move beyond “business-critical” apps
A focus on business-critical apps is a good place to start, not to stop. While business-critical applications do pose a high risk because of the nature of the information they touch, cyberattackers are unconcerned with the business criticality of the applications they attack. Instead, they look for the path of least resistance into an organization, and oftentimes this can be an application whose security was overlooked because it was not deemed business critical. In the end, an effective application security program assesses the entire application landscape – including all applications internally developed, vendor-supplied, and downloaded – and considers both criticality and exploitability.
Defend in depth
There is no application security silver bullet. Effective application security combines the strengths of different testing types – both manual and automated – throughout the application lifecycle. For instance, our research showed that there are significant differences in the types of vulnerabilities you discover dynamically at runtime compared to those you’ll find when doing static testing in a non-runtime environment. In fact, two of the top five vulnerability categories we found during dynamic testing weren’t even among the top five found by static, with one not found by static at all. Cumulatively, these data points reveal that security testing, with multiple methods, remains a necessary step in securing your application layer and avoiding a damaging breach.
For more details on the different types of application security testing, see Your Guide to Application Security Solutions.
Create risk-based policies
Application security policies should always prioritize and emphasize vulnerabilities and applications that create the most risk.
For instance, rank vulnerabilities so that you are focused first and foremost on those that are actually increasing your risk. It’s important to distinguish between flaws that represent a remote risk and those that represent more substantial, real-world risks. In some cases, the likelihood of a vulnerability being exploited may be low, but the potential damage might be great. In other instances, the chance of exploit might be high, but the damage may not be substantial.
In addition, not all apps are created equal, so create different requirements for different apps. For instance, an application that has IP, is public facing, and has third-party components may require all medium to very critical flaws to be fixed. A one-page temporary marketing site may only require high/very high flaws to be fixed.
Learn more in Everything You Need to Know about Application Security Policies.
Employ developer coaching
Developer training has an essential role in reducing flaws. Effective application security requires both locating security-related defects, and fixing them. But developers simply aren’t equipped with the knowledge or skills they need to fix these flaws. Veracode recently sponsored the
Learn more about developer training.
Allow for developer self-service
Contrary to many security professionals’ innate tendencies, it’s ideal to give your security testing tools “away for free.” Give developers a self-service portal where they can access AppSec tools, help them integrate AppSec tools into their IDEs, and make security reports visible to all.
However, governance should still sit with security. The security team should own setting policies, tracking KPIs, and providing security coaching to developers.
Learn more in The Security Professional’s Role in a DevSecOps World.
Focus on remediation and mitigation
Ultimately, your AppSec program is not effective if you’re not fixing what you find. You can scan every piece of code you write, but without adequate training and guidance, you will not create more secure code. In fact, you will delay developer timelines and still produce vulnerable code. Enabling developers with both a scanning tool and remediation and mitigation guidance is key. At Veracode, we conduct over 5,000 consultation calls a year with development teams, guiding them through fixing flaws they have never had to address before. And we’ve found that after only one to two of these calls, developers’ secure coding know-how improves dramatically.
In addition, your AppSec program also needs to be set up to enable remediation guidance.
For instance, every scan completed should be assessed against a policy — not a policy that changes how you scan or what is discovered, but rather a filter of the results to see if you passed or failed based on the parameters you set for risk tolerance. This policy should also include: how often does a team need to scan, how long do they have to fix certain flaws based on severity/criticality, and what scanning techniques must be used. In addition, you need remediation time built in between scans. Just scanning multiple times a day and pulling results into a tracking system is not useful if no one has the bandwidth to fix anything. You are better off setting a realistic scanning schedule (once a day) so developers have time to fix what they find. You can increase scan frequency as you become more secure and are passing policy on a regular basis.
Learn more in Application Security Beyond Scanning.
Integrate into the SDLC
Integrate security into the CI/CD process as early in the development lifecycle as possible. Your goal should be to minimize the gap between the discovery of a problem and the time it takes to bring the developer back in to fix it. First, because it’s much faster, cheaper and easier to ask a developer to fix something they just coded compared to something they wrote six months ago. The longer you wait, the longer it will take for the developer to get back up to speed with that particular code, assuming the developer is even still on the project. Second, because the time it takes for attackers to come up with exploits for newly discovered vulnerabilities is measured in days, and sometimes hours. Yet our most recent State of Software Security report found that one in four high and very high severity flaws are not addressed within 290 days of discovery.
Aim to conduct security testing during continuous integration. Better yet, use automation to conduct testing while the developer is writing the code, giving them instant feedback so they can make a fix before it ever becomes a problem.
Get more details on integrating AppSec on our website.
Learn more
Learn from our decade-plus of helping customers build out their AppSec programs; start with our Application Security Best Practices Handbook.
Related Posts
