Don't Let 'Perfect' Be the Enemy of a Good AppSec Program

Some security programs need to have the absolute highest possible level of security assurance for the systems and the data they protect. They need to be as close to perfect as they can be. Examples of this would be managing evidence for top secret counterterrorism activities, invaluable intellectual property such as the first COVID-19 vaccine, or systems that require uptimes of five 9s (99.999%) or higher, for which downtime of a single minute can cost millions of dollars.

That said, for most companies, a "good" application security (AppSec) program will suffice. A good program is one where your applications are safe against the most common types of attacks but could still fall to a determined, well-funded, and advanced attacker. Let's discuss the differences, and how to create something that meets your company's needs.

Elections Require Perfection

For a "perfect" AppSec program, every single potential vulnerability reported by any test must be investigated by a security expert. This means running static application security testing (SAST), dynamic application security testing (DAST), and other automated tools with the confidence level for findings set to report "any and all" possibilities. That requires hiring one or more security experts who are trained to run down each item and given weeks to check each application. It also means hiring several security professionals to do manual security testing and code review, for multiple viewpoints, and to re-test that the bugs are truly fixed and have not created new bugs in the process. It is both time-consuming and quite expensive.

A few years ago, I worked on an application that had to run on a 32-kilobit modem in the Arctic. It makes our elections in Canada happen, which meant it had to be absolutely perfect. We hired several different security professionals, who used a multitude of tools and manual techniques to find both security and non-security issues within our application. We did stress testing, performance testing, integration testing, and so much more. We set up a functional returning office (the place that you vote), with every system fully functional, and ran an entire 36-day mock election, with fake security incidents thrown into the mix, 6 months before the big day. We spent the following 6 months finalizing every detail. It's unlikely you would have noticed, as when the 52nd General Election happened on Oct. 19, 2015, it went off without a hitch.

They don't write news articles when everything goes right. We also put in quite a bit more work than what I shared above, which I am not at liberty to share. The point is that being perfect is not cheap, and it is not quick.

5 Ways to Make Good 'Good Enough'

With that story in mind, does your organization need to be truly perfect? Or is "good" good enough? Let's look at some ways your organization could create a scalable and affordable application security program that is good.

1. Automate. First off, leverage automation whenever possible. There are many free and paid security tools that can provide good results. When I say good, I mean most of the results they report are true positives, and the false negatives (missed bugs) are at a level your organization can be comfortable with. Some automated tools will allow you to set a confidence level for your results; starting with a confidence level of "high" in the first year of your program, and then shifting to "medium" in the second year, is a good way to get software developers to have faith in what you are reporting while not overwhelming them.

2. Use anti-pattern matching SAST. For SAST tools, when you're aiming for "good" results, select a next-generation SAST that performs anti-pattern matching (regex looking for known-bad patterns) rather than an original SAST type that performs symbolic execution (running down every possible code outcome, searching for potential flaws and bugs). While the original types of SAST are ideal for creating a perfect application, next-generation SASTs are faster, provide more true positives, and are sometimes quite a bit cheaper as well.

3. Spell out technical requirements. When starting new projects, give your project team a list of expectations, both for technical security requirements and for activities you expect them to participate in as part of the project life cycle. You could create a list once for each type of technology (Web apps, APIs, serverless, infrastructure as code, containers, etc.), then reuse that list for every new project it applies to. This also allows a project manager to schedule time for the security activities to happen so that project teams don't face unexpected overtime.

4. Run a threat model. During the design phase, reserve one hour with the product owner, the technical leader of the project, and a member of the AppSec team. Perform a simple threat model on your application and implement some of the recommendations from that session.

5. Train people on secure coding. Give your software developers secure coding training. There's several free or almost-free courses on the Internet for this now, and every bug they help your people avoid creating saves you more time and money than you may realize.

Although this is just a short list of ways to build a scalable and affordable program for creating secure apps, these five suggestions provide a great place to start from or to add to an already existing program to make "good" software.