Building an Application Security Program from scratch can be a challenging but necessary effort for any company that develops own applications and services.
An Application Security Program is a comprehensive set of processes, practices, tools, and strategies implemented throughout the software development lifecycle to identify, assess, mitigate, and prevent security vulnerabilities in applications, ensuring their integrity, confidentiality, and availability
Imagine a situation where a small start-up rapidly deployed its services in an efficient and productive manner. The company has experienced rapid growth and hired more people, but in the process, it has overlooked the creation of a sensible and sustainable AppSec program.
Fictional Background Story
You’ve been employed in-house, and you strongly believe that the company need an application security program. The discussion between you as a security engineer (SE) and management (BOSS) might go like this.
SE: “Thank you for meeting with me. I wanted to discuss the urgent need for implementing an Application Security Program in our company.”
BOSS: “I appreciate your concern, but we already have firewalls, antivirus software, and give gazillion of dollars to Microsoft for E5 licenses. Why do we need another security program?”
SE: “While those are important, they don’t address the specific vulnerabilities in our in-house applications. An Application Security Program would help us identify and mitigate risks throughout the entire software development lifecycle.”
BOSS: “That sounds time-consuming and really expensive. How do you propose we start such a program without disrupting our current operations?”
SE: “I understand your concerns. Let me outline the basic principles of the approach.
Cornerstones
Asset Management
If you don’t know your environment, components, owners and dependencies that your application is built on, it’s really hard to secure them. One of the most crucial things from many angles is to have one central place where you can find the information you need, and this is called CMDB (Configuration Management Database). It does not only contain the ip addresses of the servers or the version numbers of the installed software libraries. It should also contain information about dependencies between systems. It should be able to answer the questions “What other systems will be at risk if this system is compromised? Who all should I contact if I make changes to the APIs.”
Building an compherensive CMDB system is really challenging, but you can start building this in pieces. Start using tagging in cloud environments, so you can find all the related components with couple of queries on AWS or Azure. Easier said than done.
The most common issue with these systems is that they are built on manually updated static data which ages and becomes unreliable over time. You should eventually reach a point where, for instance, data is pulled straight from the AWS to the CMDB.
SBOM’s (Software Bill of Materials) are also critical part of the Asset Management. Companies must understand what 3rd-party libraries and dependencies their applications use. One centralized place to gather dependencies is OWASP Dependency-Track. You can push SBOM’s directly from CI/CD pipeline to DT, and when disaster strikes, you only need to go in one place to find products with that vulnerable dependency (refer to case log4j). Also not totally true, but in dreamland is should work like this.
Gap analysis
It might be that teams are doing really good things and they have good processess in place, but they just don’t tell or share the outcomes. There are frameworks which can be used to check “how we are doing”. One of these frameworks is OWASP SAMM. SAMM stand for Software Assurance Maturity Model, and it aims to analyze and improve companies software security posture. It will also provides roadmap what we need to do so that we can get better scores. It can be done interview based or self assessment. There is total of 90 different questions from multiple domains. When gaps are identified, it becomes much easier to focus on areas where the company has biggets gaps.
OWASP SAMM is by no means the only way to do gap analysis, but it is a one way to start measuring the state of AppSec program. Of course company can hire a consultant to do a gap analysis.
Metrics - Measure What Matters
If you don’t know what’s broken it’s really hard to fix. From day one you probably already have some kind of statistics how the company is doing. It can be Microsoft Defender for cloud scores or Github’s dependabot metrics. It’s not much but it’s something.
The long-term outcome should be meaningful metrics, hard numbers to show the direction and state of the company’s application security. Eventually if you have raports (even dynamic dashboards) that can be shown to the management you have evidence that you need more resources (money, workforce) and time.
DefectDojo is one example of an open source ASPM (Application Security Posture Management) tool. It can aggregate e.g., scan results from over 140 different SCA/SAST/DAST tools, and build dashboards for development teams and top management.
Secure by Design
Secure by Design is a proactive approach to AppSec which integrates security at the early phase of application development. To properly deploy a secure by design approach, companies should focus on creating blueprints, providing clear examples, and defining best practices. By doing so, development teams do not have to reinvent the wheel for the 97th time.
This also includes Forrester’s concept of “Shift Everywhere” from “The State of Application Security 2022”. Meaning that “Shift Left” is no longer enough, we need to shift security to the left, right, up and down.
But if you shift your application security testing left, doesn’t that imply you’re shifting your focus away from some other area?
Automation
Automation is key to success. By now every company should test, build and deploy automatically. Automated security scanners which are triggered from CI/CD pipeline will significantly reduce the burden on developers. Automate infrastucture building with Infrastructure as Code (IaC). This works really well with the conjuctions of secure by design blueprints and templates.
Happy path would go something like this: vulnerable dependencies are detected in developers IDE (Integrated Development Environment, e.g., Visual Studio Code or IntelliJ), static code analysis (SAST) is executed after developers pushes some code to the version control system. CI/CD pipeline run tests, builds the application and deploys it to the test environment. After the deployment dynamic test (DAST) tools are automatically executed agaist the test environment. All the results from all the stages are pushed to the centralized ASPM product which automatically generates relevant alerts and dashboards.
Tooling
Here is a short list of tools which can be easily integrate to CI/CD pipeline (and they work conjuctions with the DefectDojo).
SCA (Software Composition Analysis / Dependencies)
SAST (Static Code Analysis)
DAST (Dynamic Code Analysis)
- Nuclei
- Zap Proxy
- Burp Dastardly
- Nikto
- MobSF - For Mobile Applications
Observability
Observability in AppSec refers to gaining comprehensive visibility into an application’s security posture through the collection and analysis of logs, metrics, and traces. By deploying security focused instrumentation and advanced analytics, observability enables security teams to continuously assess and improve security controls and identify vulnerabilities before they can be exploited.
We need a comprehensive picture of how our application is behaving. We should be able to answer the question “What’s Happening in Our System?” Again, easier said than done.
Processess
Everybody love processess, not. But they are playing crucial part in AppSec. How the organizations is going to respond if vulnerability is found by DAST scanners in production environmenent? How we will update and upgrade dependencies in our code base? How can you ensure that third-party products and services meet your our security requirements? So, at the very least, incident and vulnerability management processes should be created, and their functionality tested.
Training
AppSec program should provide meaningful trainings to developers and product owners. Meaningful I mean something that resonates. It’s good if organization can provide trainings in multiple level. Something that explains Application Security principles and foundational knowledge, and top of those there should be hands-on training and case examples. Developers usually want the trainings to be hands-on, SecureFlag and Secure Code Warrior provides a learning platforms with hands-on excersices.
Hack the Box and TryHackMe provides comprehensive cybersecurity excercies, but they are more focused to penetration testing than solely to AppSec.
For instance, teaching threat modelling to developers is very beneficial. One easy way for teaching is to use Elevation of Privilege - Card Game.
Culture
Last but definitely not the least. Fostering a strong security culture is crucial for companies. Top management plays critical role of shaping the AppSec culture, if AppSec program doesn’t get management buy-in then it is doomed to fail. Building culture is always time consuming and time equals money. AppSec should get the same visibility as traditional security awareness (which is of course in good shape in every company, right).
Organize sessions that demonstrates how new and existing vulnerabilities can be exploited and how fixing them makes a difference.
Dialoque continues
BOSS: “This still sounds comprehensive and expensive. How do we justify the cost to the board?”
SE: “Consider the potential costs of a data breach or compromised application. According to recent studies, the average cost of a data breach is 4,6M€. Our investment in an Application Security Program would be a fraction of that and could prevent such incidents.”
BOSS: Could prevent or prevent? We are not investing things that cost money, but does not guarantee 100% security!
SE: It could prevent, but there is always residual risk in risk management, and we need to accept that fact. But at least we we will not face massive government sanctions if something bad happens because we have tired to do our best.
BOSS: “You make a compelling point. I see the value in what you’re proposing. Let’s start with a small pilot project to demonstrate the benefits. Can you prepare a detailed proposal for the board meeting next month?”
SE: “Absolutely, sir. I’ll have that ready for you. Thank you for your support in making our applications more secure.”
Conclusion
Keep in mind that the goal is not to achieve perfect AppSec program overnight, but to continuously improve and adapt to evolving threats. Starting with a small pilot project can show concrete advantages and pave the way for broader implementation. Ultimately, investing in an AppSec Program is not just about preventing potential breaches; it’s about building trust with customers, meeting regulatory requirements, and ensuring the long-term sustainability of business in an increasingly digital world.