Making Security in a Software Factory

DRAFT: I will update based on your feedback. Thanks in advance for help!        

Application security is at a crossroads:

• Option 1 -- keep trying a waterfall based, expert-driven, siloed approach to security that's slow and expensive and has never delivered much real value.
• Option 2 -- re-imagine the work of application security so that it can be delivered by a normal software organization as part of delivering great software.

If you like Option 1, or think it will work if we would just try a little harder.... this isn't the article for you. Or if you like Option 2, but think all you need to do is shove traditional appsec activities onto already overworked development teams, there's a special "false positive" room in hell waiting for you.

Actually, it's pretty easy to rule out Option 1 by simply adding up the cost and expert resources required, not to mention the awful results. So, if you're ready to abandon security exceptionalism and focus on creating a software factory that can produce both great software and security at high speed... read on!

Software factories and siloed security

Somewhere in your organization, you're designing, coding, building, integrating, testing, delivering, deploying, operating, and monitoring software. I've worked with hundreds of organizations building software, and they all do this differently. But let's call this whole thing your "software factory."

Interestingly, the term "software factory" hails from the late 1960's and there are pros and cons to the concept. Here I'm using the term very generally so we stay focused on the big picture and don't revert to "SDLC thinking" about a single project at a time. By the way, I'm including both development and operations, because devops is really one thing and security must be part of that thing. So if you've ever considered whether the right approach is to secure code in development or to protect apps in operations, the answer is clearly both.

Most organizations today have a small application security team that operates largely separate from the software factory. There's way too much work for these teams, so they often become disruptive bottlenecks. In the past few years, it's become quite trendy to attempt to force the software factory to do that work. But while saying "shift left" or "build security in" is simple, in reality it's like asking your dishwasher to fix a margarita. And the solution isn't to just swizzle in some "champions" and hope they fix it. Instead, we have to repackage your security work and get creative about how we use the existing software factory machinery to deliver it.

The good news is that development organizations are great at building things, so if we can frame up security work so that it looks like something to build, it could work! But we have to be careful not to mess up the factory. Businesses simply won't tolerate delays, bottlenecks, terrible working conditions, etc...

Traditional application security problems

We need to acknowledge that traditional application security activities like writing security requirements, creating threat models, security architecture, security scanning, penetration testing, security training, etc... don't work very well. We've been trying for decades and nothing has changed. I'm disappointed these activities haven't worked better. But frankly, we shouldn't be too concerned about blowing them up.

It's not that these activities are necessarily "wrong." They might even work if we were building a single app and had unlimited time and security expertise available. But despite almost cult-like belief in these activities, there's scant evidence these activities have actually enabled organizations to reliably deliver secure software, particularly on modern software projects and at realistic scale. In fact, overwhelming statistics show that this approach does not work.

Whether they work or not, it's certain that the traditional activities will be very disruptive to your software factory. First of all, they're slow. When teams are releasing code daily and pipelines must complete in minutes, you can't insert security scanning or testing that takes hours, much less days, weeks, or months to complete. Second, they're inaccurate. Almost every traditional security activity misses critical risks and generates false alarms about risks that aren't real. Third, they're wasteful. These activities spend far too much time on non-existent or trivial risks. And finally, they all require experts, which creates bottlenecks and backlogs into your factory.

Remember, the traditional approach has been delivering code riddled with vulnerabilities for decades. Therefore, relying on these practices is itself very risky. It's deeply ironic that the experts we rely on to make smart choices about risk unquestioningly trust these provably risky practices.

Yes, security is something concrete that you build.

Let's start with some basics. Today, our software factory only delivers software, not security. In a sense, of course, security is a property of that software, so it must be in there somewhere. But in the siloed approach, it takes experts armed with sophisticated tools weeks to verify even basic security attributes of software. Security is so hidden that it's effectively impossible to measure, share, or communicate. It's useless. We need security to be something concrete that we can build and actually use.

Traditional approaches to application security provide a disorganized hodgepodge of claims, documents, reports, etc... that mostly adds up to nothing. Ask yourself if you are sure your app is protected against SSRF... Can you prove it to me? I thought so. Seriously, what does a scan or pentest really tell you or your auditor? Often, even for critical applications, the requirements don't match the threat, the defenses don't actually implement the requirements, the security tests are whatever some tool or pentester decides to test, and no there's essentially no monitoring of attacks in production. So, even though we did a bunch of security work, we have essentially nothing to show for it.

Instead, we're going to use our software factory to produce a clear and compelling security story explaining the security of our software. This isn't the fairytale kind of story -- it's the kind you support with hard evidence -- an argument that connects our threats, defenses, and testing so that anyone can clearly understand whether the software is secure enough for them or not.

If you can imagine combining your security threat model, requirements, architecture, test plan, and test results all into a single structure... with as much as possible automatically generated...you'd be pretty close. It's pretty silly to maintain all these things separately -- it creates massive traceability and maintenance problems. So almost nobody does this well. Instead of tackling all of security at once, we're going to build this argument one piece at a time. And we'll end up with secure software and a real tangible form of "security" that we can reason about, share, measure, compare, and improve. Oh, and satisfy your auditor as well.

And building this story is much more cost-effective. Software factories are allergic to wasted effort and inefficiency. I wouldn't expect much tolerance for doing "check the box" activities that don't produce value. If you're one of the security folks that complains that compliance is a terrible way to get security, then this should be a welcome change.

APPLICATION SECURITY STORY

- Identify the right threats and attack vectors

- For each threat, detail a robust defense strategy

- For each strategy, detail the implementation of defenses

- For each defense, evidence of correctness, effectiveness, and usage        

This is freedom! You can immediately stop doing anything that doesn't directly contribute to this story. If you're scanning or pentesting for SQL injection in an application that doesn't use a database -- stop it. If you've already built a great case that your authentication is strong, you don't need more effort. If a tool is producing very weak evidence because it doesn't really verify what you want it to -- dump it. It doesn't matter that much how you add to your story -- only the outcome matters. When you're very clear about the outcome, it's very likely that development teams will invent novel and efficient ways to generate security. There are massive opportunities to save time, money, and frustration.

Adapting a software factory to make security

So, how do we use the machinery in our software factory to make security?

You can start today. Take one thread of your security story for one application and build it from what you already have lying around. The first few should be pretty easy -- they're your biggest risks and you probably already have strong defenses. Pick a threat - say SQL injection. Write down your strategy -- your intended defenses. Then write down how you've implemented those defenses -- parameterization, escaping, etc... Then support those claims with test results demonstrating that your defenses are correct, effective, and used properly in all the right places. When you look at that argument, are you convinced? Now you have a clear line of sight from threat to assurance.

If you can create a security story that makes a convincing argument for your top ten threats, I guarantee your application or API will be far more secure than most. And you can probably get there with far less effort than you're currently expending. As you set up processes to automatically create, expand, and support these arguments, be careful not to do anything that will disrupt the delivery of value in your software factory. That means paying careful attention to...

Velocity. Delivering value to customer is the whole point of the software factory, and velocity is a primary concern. Security has to work without slowing things down. If it doesn't, teams will interpret security as damage and route around it.

Flow. By doing security work in small pieces, we can better manage security work in progress. To the maximum extent possible, avoid creating that span multiple risks, like requirements documents, security architectures, and test plans. Keep tasks small and focused.

Observability. Security is often buried in processes, in products, in teams, etc... Instrumenting your factory's different functions and the software being built exposes their inner workings and enables your teams to see, measure, and improve security.

Scalability. Remember, most security activities are conceived with a single application in mind. It may not be obvious, but software factories can have tens of thousands of applications, all changing, building, testing, deploying, and monitoring in parallel. As soon as you establish centralized security anything, it will get overrun, become a bottleneck, and force teams to lower the bar.

Communication. Short feedback loops are the key to getting both value and security flowing to customers. So we are going to need to leverage existing communications infrastructure and prioritize realtime notifications focused on a single piece of security work.

Culture. We're going to keep a close eye on the culture of security in our factory. We can't have friction, much less outright aggression, between development and security. We're going to attempt to eliminate blame, fear, hiding, and conflict by making everything about security visible.

The ability to adapt a software factory for security isn't limited to DevOps, Agile, Waterfall, or any other approach to building software. This article leans towards more modern styles, but there's no reason that waterfall development organizations can't build security too. The rest of this article shares some experience with patterns that work, but don't be afraid to experiment... the how doesn't matter as long as you're producing security.

Yes, your software factory CAN...

SOFTWARE FACTORY SECURITY CAPABILITIES

C1: Establish a set of effective application security defenses

C2: Use defenses in all the right places

C3: Verify the security of code it produces

C4: Secure its supply chain

C5: Model application threats and create defense strategy

C6: Set useful application security policy

C7: Communicate effectively about application security

C8: Detect application attacks, respond, and recover        

Note that managing your security program isn't in this list. That's because it doesn't really require any changes to things you're already doing. You already have the capability to create plans, set budgets, hire staff, manage initiatives, track progress, make improvements, etc...

The only thing that really matters is that you're producing security in your factory. That is, as long as you can easily demonstrate that you've got strong defenses in all the right places when software pops out, it doesn't really matter how you do it.

C1: Your software factory can establish a set of effective application security defenses

Let's start with something obvious. You're going to need a set of strong security defenses. Security defenses are just software and configuration, so we should be able to build and test them just like any other software we build.

Defenses are anything that detects, deters, or denies threat agents from achieving their goal -- an encryption library, a coding pattern for input validation, training developers, setting an HTTP header, enabling a CSRF token in a framework configuration, etc... Some of these are 'primary' defenses that directly address the problem. Others are 'secondary' defenses that help or support other defenses.

Your software factory should discourage creating custom security defenses. Coding security defenses requires specialized knowledge about design and implementation weaknesses that we've discovered over the last fifty years. One simple example of things you'd need to know are the 1000 different classes of weaknesses that MITRE has catalogued, most of which are non-intuitive and highly technical.

Generally, you don't want to centralize security. But rather than having every project create custom security defenses, you should create a product team with both developers and security experts to build, package, test, configure, enhance, document, and train your standard defenses. In modern applications, the best choice of security defense is often the one that's built into your application or API framework -- not a separate library or service. But the team can still study, test, and standardize your framework defense choices.

Since your overall security relies heavily on these defenses, this is where you want a bulletproof security story. The team should build and maintain a complete automated test suite to continuously verify that all of your defenses are correct and effective. Note that testing security defenses is not the same as testing whether applications use them properly, and is harder to automate. But it's worth it, as all your projects will benefit by inheriting the strength of these arguments. Development teams that attempt to build custom defenses without security expertise are very likely to underestimate the amount of work required and create a very weak security story.

METRICS: STANDARD DEFENSES

- Do standard defenses exist for most common threats?

- Are defenses secure by default?

- Are defenses documented and easy to use correctly?

- Are defenses thoroughly tested for correctness and effectiveness?        

C2: Your software factory can use defenses in all the right places

Just having a great set of defenses doesn't do anything. You still need to configure and use them in all the right places. This approach makes it far easier for development teams, allowing them to focus on delivering value to customers. Verifying the use of standard defenses is far easier to automate than creating tests for custom security defenses.

To the maximum extent possible, you should make it impossible to not use the defenses right. That is, build them into your application framework, filters, stack, templates, anything to make it difficult to screw up. This reduces the testing requirement to making sure that the environment, including built-in defenses, is set up correctly.

Whenever it's not possible to make things inherently secure, you're going to have to rely on the skill, foresight, and industry of software developers to use your standard defenses correctly and in all the right places. So rather than creating security "toolbox" APIs that can be used in a million different ways (most of them insecure), this is where you should be opinionated. Focus on optimizing your APIs, documentation, configuration, and training to encourage the correct use of your standard defenses, rather than vainly attempting teach them to be application security experts who can build their own security controls.

METRICS: USING DEFENSES

- What percentage of portfolio uses standard vs. custom defenses?

- Are there test patterns for verifying correct defense use in apps/APIs?

- Are employees trained in how to use defenses effectively?        

C3: Your software factory can verify the security of code it produces

Your defenses are meaningless without verification. You'll have no idea whether they're missing, giving you a false sense of security, or working fine. So how do we get our software factory to do great security testing? We can leverage our existing quality testing machinery. Try to set up your tests as positive claims, like "all PCI data is encrypted before storage." There's minimal value in negative claims, such as "the scan didn't find any cross-site scripting vulnerabilities."

Security testing isn't something you do, it's something you build. When you build security tests, it makes your pipeline stronger and will run continuously, forever. First, you should capture how you plan to verify a defense in your security story, along with a rationale for the approach. Don't forget tests for security configurations, secondary defenses, etc... Ensure that your factory has the following security testing capabilities:

Automated Security Testing. Running a bunch of security tools and praying they covered what you want is a terrible strategy. Instead, go through your defenses and decide if there's an automated way to test it. Your test approach needs to find the defense, verify that it works correctly, check effectiveness against expected attacks, and ensure that it is used in all the right places. Add your security tests to your normal QA pipeline. Beware inaccuracy, both false positives and false negatives. Both types of error create work for human experts which obviates the benefit of automating in the first place. And, of course, your automated security tests can't mess up your software factory by being slow or impossible to scale.

Security Testing via Observability. Many defenses, such as authentication, authorization, and encryption may be difficult to automatically test. However, as a step in the right direction, you may be able to make security defenses "observable." So, for example, you can instrument your application and expose a matrix of all the access control checks by route and role. Then it should be very easy for a project member to verify that the right checks are in all the right places. This is a middle ground between manual and automated security tests.

Manual Security Testing. Some security tests are hard to automate, such as the internal workings of the defenses themselves, business logic, etc... For these areas, you'll have to rely on manual code review and manual penetration testing. As discussed above, standardizing your security defenses can make this much easier. When you must do manual security testing, try to raise the bar forever by capturing the results as automated test cases, not written reports, even if you use outside consultants or a bug bounty program.

Testing for Novel Threats. To ensure that you stay ahead of the threat, you want to have an expert team that keeps abreast of the latest vulnerabilities, attacks, tools, etc.... and adds new tests to make your software factory stronger. See C4 below.

Malicious Code Testing. There's a final category that's way beyond the state of the art. Detecting malicious code, whether from an insider or outsider is important, but we have to walk before we run. There's not much point to working on this problem before you're pretty sure your software doesn't have inadvertent vulnerabilities. Still, you could show a little restraint in what software you bring in, and maybe train your people to be on the lookout for anything suspicious.

One more thing. Consider how you want to communicate vulnerabilities to the folks that need them, track them over time, create analytics, etc... And beware building your security testing around a vulnerability repository. It's far better to use realtime notifications so that teams can find and fix vulnerabilities "in stride." Otherwise you're likely to end up with expensive vulnerability backlogs. See C6 below.

METRICS: SECURITY TESTING

- Percentage of application portfolio being tested for security

- Percent of applications properly using standard defenses

- Percent of attack surface properly protected

- Time elapsed before vulnerability detection (MTTD)

- Time and effort required to detect vulnerabilities

- Time to remediate vulnerabilities (MTTR)

- Rate of new vulnerabilities (Vin)

- Rate of remediated vulnerabilities (Vout)

- Vulnerability flow (Vin - Vout)        

C4: Your software factory can secure its software supply chain

You're trusting your entire business to both your software factory and the code that moves through it. Literally all of this code could compromise your entire enterprise and your customers if it is trojaned or exploited. So you want to be sure that everything you bring in is safe. This is a lot harder than you might think. Most organizations implicitly trust third party code. That's insane but it's where we are.

The obvious part of your supply chain is the software you bring in and make part of your software, including libraries, frameworks, outsourced code, services (SaaS), platform, stack, cloud, containers, and other third party code. Less obvious is that your supply chain also includes all the software that you use as part of the software factory itself, including operating systems, IDEs, test frameworks, CI/CD, tools, and everything else.

Continuous Inventory. It starts with inventory, because you can't secure what you don't know you have. But it will take time to get a complete and continuous inventory infrastructure put together. You're shooting for an always up-to-date database of every piece of software, including the exact version number, build, and branch across all your environments, include dev, test, and prod. Scanning is a lot of work, so consider instrumenting your environments so they can self-inventory and report all the software running there continuously.

Prevent Known Vulnerabilities. Using software with known vulnerabilities is like driving a car with a defective gas tank that might explode at any time. Fortunately, once you have a continuous inventory, looking up which versions have known vulnerabilities is relatively easy. Your software factory can do the work of updating software. Make it an integral part of your software factory that you keep up with software and library updates, even when there aren't vulnerabilities. This will minimize the "version distance" you have to close when a new vulnerability comes out. If you're using non-public third party software, ask questions of your vendors and demand their security story to make sure it's compatible with yours.

Protect against Exploit. Even with the best preparation, new vulnerabilities will come out that surprise everyone. You'll need to respond within a few hours when a new vulnerability is made public, because the exploits will start soon after that. Most likely, you won't be able to update a library, rework your code to adapt to any changes, retest, resecure, and redeploy in time. This can take months in many organizations. So you should also establish an infrastructure that enables you to quickly deploy new targeted defenses when new supply chain issues arise. That will allow you to stay operational while you update apps in a sane manner.

For the record, you don't have to bring in every new library, framework, platform, tool, and component into your factory. You could show a bit of restraint.

METRICS: INVENTORY

- Percent of apps and APIs tracked in inventory

- Percent of software factory infrastructure tracked in inventory

- Percent of apps with infrastructure for deploying new defenses        

C5: Your software factory can model application threats and create defense strategy

Software factories are great at planning work, breaking it down into small pieces, scheduling, and delivering. There's no reason that security can't be a part of this process. Use the same system to capture and maintain your security work that you use to plan your regular work. The best way to plan security work is to do some threat modeling and research and build it into your security story A great way to start is to capture your existing defenses and work backwards to the threat. Add in security testing results and, for better or worse, that's your initial security story. Now you can look for gaps and prioritize them.

Remember, you don't have to build your entire model in one shot. You want to do this one piece at a time. You're very unlikely to get security right in advance. There is simply too much that evolves during the development of a complex system. So you want to hone your ability to continuously evaluate and strengthen your security story. Here are the activities to think about during each iteration:

Research. You build your security story incrementally, strengthening with every iteration. Your threat modeling and research should focus on identifying the next most important threat. If you want to stay ahead of the attackers, it's not enough to focus on the vulnerabilities from a few years ago that you'll see in industry documents like the OWASP T10. You need to consider current threats based on real world data, internal and external security research, data shared with peer companies, new environments, emerging technologies, etc... Using data from attacks on your applications and APIs in your environments really helps to make compelling arguments. Try to avoid relying on other people's ideas about what's important for your security story.

Strengthen. When you add to your story, focus on a specific enhancement. Often it will be a threat or weakness that has not been addressed. However, it might be a simplification, standardization of a defense, a process enhancement, etc. Anything that makes the story stronger and easier to manage. Each thread of your story connects a threat with a defense strategy, primary and secondary approaches to implement that strategy, and a security verification approach. As you implement these arguments, you'll build an increasingly robust security story. If you're not susceptible to a particular threat, capture your rationale. There can be a lot of sharing here. Most threats and defenses are common to a class of applications, and probably have very similar threat models.

Capture. From the software factory point of view, threat modeling should look as much as possible like normal epics and stories. Capture who the threat agent is and their motivation to attack you. What specific attack vector are you thinking about? Why does it matter? What are the technical and business impacts? Detail the defense strategy and specific defenses that need to be implemented. And don't forget to explain the rationale for your design choices here. Each piece of security work should be clear about how it supports your security story... otherwise just don't do it. Finally, be sure to include exactly how you're going to test to be sure the work is correct and effective. I recommend using the same system you use to track epics and stories to manage your threat model. Done right, you can probably share your model across many projects and businesses.

When your threat modeling efforts can't easily identify a novel risk that's likely to substantially harm the business, you're in good shape. Use a periodic review (or penetration test) by experts to seek weaknesses in your security story.

METRICS: THREAT MODELING

- Strength of security story compared to enterprise risk tolerance

- Percentage of common threats captured in security story

- Frequency of security story updates

- Percentage of portfolio with up-to-date security story        

C6: Your software factory can set useful application security policy

Traditional security policies are mostly ineffective because they're punitive and discouraging. Without context or rationale they can feel arbitrary and capricious. They're also captured in massive documents that nobody reads. When they are read, policies are almost impossible to use because they require extensive interpretation for the technology of a specific project. Not surprisingly, development teams often sidestep these rules in order to create beautiful software.

But policy isn't evil. It's is just a way to communicate saved decisions about security and minimize complexity. Software factories can be far better at saving these decisions in a useful format and communicating them to the people that need them. When you capture "security as code" in your enterprise architecture, standard defenses, security stories, test cases, and executive dashboards it's not a boring document, but a way to make your security decision come to life. Make it impossible to do things that don't comply with your policies. And remember, policy isn't immutable. If it's not helping you build great software and strong security, you can and should change the policy.

Executive security decisions. Policies at this level should emphasize the importance of security and a rough sense of priorities. Bill Gates' Trustworthy Computing Memo clearly communicated why security matters and trajectory of his company. Are you willing to set a courageous policy like this for your software factory?

Defense strategy decisions. These are key decisions about how your organization will defend against certain threats. In many organizations, these are never captured and every project makes different choices. Capture these decisions in your security stories and your application frameworks so that most developers never have to make these choices. Using standard defenses reduces the decisions you need to make dramatically.

Implementation decisions. These are detailed decisions about how specific security defenses are to be implemented and used. You can capture these policies in tools and tests, not dusty secure coding guidelines or security requirements documents that nobody ever reads. Try to make these policies positive and specific, like "Invoke SecurityContext.isAuthorized() in every API" as opposed to a generic "Implement least privilege" or "avoid cross-site scripting vulnerabilities."

Remember, policy doesn't control you... you control policy. Done right, policy should accelerate your factory and the delivery of value to customers.

METRICS: SECURITY POLICY

- Clear executive support for security that articulates risk tolerance

- Well defined rules governing promoting code to production

- Percentage of policy defined "as code" in frameworks or defenses        

C7: Your software factory can communicate effectively about application security

Traditional security communications are notoriously bad -- late, confusing, and far too often arrogant. Despite time-honored wisdom about the cost-effectiveness of fixing vulnerabilities early, a lot of security work is communicated in PDF reports, doesn't have the context and details that the recipient needs, and uses language designed to shame and blame. All this bad communication leads to delay, mistakes, and extra cost.

Great security communication can change everything about your program. Just as shortening feedback loops has proven to be extremely effective in devops, it can make a tremendous difference to security. For decades we've known that identifying and fixing security problems early is dramatically more cost-effective than waiting until just before production. Security communication designed for the recipient that arrives at exactly the right time facilitates this fast response. Encouraging fast remediation helps to prevent the backlogs (aka "security debt") that plague most enterprises.

Blame-free culture. Repeat after me, there is no shame in making security mistakes. Blame inevitably leads to a self-destructive culture of hiding, grandstanding, and conflict. Aim for a culture of "security in sunshine," where you publish everything about vulnerabilities and attacks.

Real time notifications. Because the cost of security issues increases dramatically as time passes, you should address security problems early when they are cheapest. Avoid slow reporting and repositories, and favor real time notifications through tools already being used by development and operations teams.

Value stream. Consider all the different stakeholders in application security, including audit, legal, executives, etc... Make sure that the output from each function has the right context, detail, and tone for the consumers. Too often, security information is generic boilerplate, without the details about the exact data, code-level information, protocol information, backend connections, etc...

Integrations. Focus on communicating security using tools that are already part of your software factory. Some of the best vehicles are IDE warnings, failed test cases, business dashboards, Slack messages, SIEM, etc... Using bug trackers and build failures is okay too, but probably indicates a missed opportunity earlier.

METRICS: SECURITY COMMUNICATION

- Mean time between vulnerability discovery and communication to developer

- Size of security backlog

- Integrations in existing tools versus separate security dashboards        

C8: Your software factory can detect application attacks, respond, and recover

Your applications will each be attacked thousands of times a month by skilled, motivated adversaries, even if you don't know they're doing it. Only one or two percent of these attacks will connect with the right vulnerability and exploit your code, but it only takes one. You're probably already monitoring your production environments for a variety of issues, so I recommend leveraging that infrastructure to detect and thwart these attacks. You must focus on speed, accuracy, and scalability, which are even more critical in the operational environment than in development.

Detect. For a variety of reasons, software factories must have instrumentation to detect who is attacking, what attack vectors they're using, and which systems they're targeting. Your security story should include attack detection as part of every defense strategy. Complex protocols and data structures used in modern applications and APIs like JSON, XML, and serialized objects make application attacks difficult or impossible to detect at the perimeter. Detecting attacks using instrumentation from inside applications is much more accurate. The threat intelligence you gather here should be a major part of driving your security story and priorities.

Respond. Of course, detection isn't enough. Your factory needs the capability to prevent real attacks from exploiting vulnerabilities in my applications and libraries. Complex data formats and protocols have undermined the effectiveness of boundary protection, which wasn't great in the first place. Look to defenses that work closer to the code and data, like zero trust and runtime protection (RASP). These defenses become part of your application and have the code-level context necessary to accurately prevent exploits. Accuracy is critical here, because a false negative means an attack goes undetected, and a false positive means an application or API that no longer works properly.

Recover. Sooner or later, there will be a novel vulnerability or attack for which your existing defenses are no match. Updating, recoding, rebuilding, retesting, and resecuring will likely take far longer than the few hours it takes for attacks to start. It's important to prepare your software factory in advance by establishing an infrastructure that can quickly deploy new defenses into applications and APIs to counter new attacks.

METRICS: ATTACKS

- Percent of apps and APIs with runtime detection and protection

- Attacks detected per month

- Percent of portfolio targeted

- Percent of viable attacks that targets a real vulnerability        

Conclusions

I'm convinced that a software factory can do the work of security. I've seen many pieces of what's described in this article being done in companies large and small, as part of every software development process imaginable (and some that are frankly unimaginable). DevOps has shown security that path, but we must completely rethink traditional security practices in order to truly achieve DevSecOps. Done right, there's no question that DevSecOps will revolutionize application security.

We must focus our limited supply of security experts where their skills are most needed: threat modeling, implementing standard security defenses, and the most difficult security testing. When we frame up the work properly, all the rest is easily done by existing processes, tools, and developers. And we can massively improve the day-to-day work of application security workers.

Why should you do this? Well, it's pretty obvious that the trend for more complex, connected, and critical software is going to continue for quite a while. The already very high rate of application vulnerabilities is likely to increase. Likewise, the attackers will almost certainly continue to increase both volume and sophistication of their attacks. So there's a lot of foreseeable and preventable risk.

But possibly more importantly, you're probably not getting much value for all the time, effort, and money you're spending on security. There are significant opportunities here to reduce security spending while improving results. It's time to stop the busywork and focus on actually producing application security. You and your customers will be glad you did.