Why would you want to know the current state of application security in your organization? There may be several reasons:
You want to introduce security into the SDLC and don't know where to start.
You are doing it as part of your company's risk assessment.
You have had a security incident and want to assess other vulnerabilities in your applications and infrastructure.
Although there are various cybersecurity frameworks dedicated to this purpose: OWASP SAMM [1][3], BSIMM [2][3], NIST SSDF [2], they are difficult to start with and often too general to follow. For example, NIST SSDF [5] states:
The SSDF does not prescribe how to implement each practice. The focus is on the outcomes of the practices rather than on the tools, techniques, and mechanisms to do so. This means that the SSDF can be used by organizations in any sector or community, regardless of size or cybersecurity sophistication.
This leaves companies to define their own approach to these frameworks, which is where many organizations struggle.
Step 1: Know Your Applications and Infrastructure
The first step is to understand the full scope of your applications and infrastructure. If you don’t know what you’re protecting, it’s impossible to create a solid security plan.
Start by creating an asset inventory that describes all the applications and infrastructure assets your organization uses. While you can purchase automated asset discovery tools, it’s also possible to do this manually with a template like this:
Key Considerations:
Resource Identification: What assets are deployed (servers, databases, APIs)?
Criticality: How essential is this asset to business operations?
Compliance: What regulations (GDPR, PCI DSS) apply to this asset?
Data Sensitivity: What type of data does this asset process or store?
💡 Tip: Work with your DevOps team and application product owners to fill out this asset inventory. Start small—don’t worry if some information is missing initially; you can always return to it later.
Step 2: Application and SDLC Review
Many application security programs are created by someone new to the organization or security, often without full knowledge of the software development process. Especially in larger organizations, understanding the SDLC across different teams can be a challenge.
SDLC review
If your organization has a consistent SDLC across all teams, great! You can review security practices by meeting with a product owner or DevOps lead. Otherwise, you’ll need to hold additional meetings to understand the different processes in play.
Here is an example of a template to use during interviews.
Prepare a list of questions to ask during the meeting, and assess how security is integrated throughout the development process.
Focus Areas:
How is security integrated at each phase (requirements, design, development, testing, deployment)?
Are security tools (SAST, DAST) integrated into CI/CD pipelines?
Is there an incident response or patch management process?
Application functionality review
To evaluate the business risks associated with your applications, conduct demo sessions with team members who understand the application context—usually product owners or QAs.
Prioritize public-facing apps or those handling sensitive data. Aim for 1-2 hour sessions per app and review the following:
Critical features.
Data handling (e.g., sensitive personal data, financial data).
Potential threats.
This will help you understand which apps carry the most risk and should be prioritized for security reviews.
💡 Tip: Don't forget to record meetings with team members and save audit documents in the project folder. Chances are you will need to review them later.
Step 3: Infrastructure Testing
Now that you’ve inventoried your applications and infrastructure, it’s time to assess their security posture.
Infrastructure Vulnerability Assessment
Perform vulnerability assessments (VA) [6] on all assets in your inventory, focusing first on public-facing resources (external infrastructure) and later on internal assets.
Use tools like Nessus [6] (for infrastructure), Acunetix [7] (for web-based scanning) or OpenVAS [8] (open source scanner).
💡 Tip: Always validate scanner findings to filter out false positives and focus on the high-risk vulnerabilities. Categorize them by severity and impact.
Prioritization
Use this prioritized approach to set clear security objectives and decide what needs to be addressed first:
High-Risk Assets: Focus first on resources that are critical to business operations, process sensitive data, or are publicly accessible.
Compliance-Driven Prioritization: Ensure any assets related to regulatory compliance (GDPR, PCI DSS) are secured and meet all requirements.
Step 4: Application Security Testing
Once your infrastructure is assessed, turn your attention to the applications.
Full-Scale Security Audit
For critical applications, conduct a full-scale security audit following the OWASP ASVS [9] or Mobile Application Security Verification Standard (MASVS) [10] checklists.
These audits will require access to source code, documentation, and test environments. Typically, an audit for a critical application takes about two weeks, depending on its complexity.
Ad-Hoc Manual and Automated Testing
For less critical applications, a timeboxed approach to security testing can be more efficient:
Select the most important applications.
Decide on a fixed timeframe for testing.
Use both manual tests and automated tools (SAST, SCA, DAST).
For instance:
Application | # of Repositories | Testing (Days) | Scanners (Days) | Notes |
Web dashboard | 2 | 2 | 1 | Includes API |
Customer portal | 2 | 2 | 1 | Includes API |
Admin panel | 1 | 2 | 1 | |
Client mobile app | 1 | 1 | 1 | |
Total: | 6 | 7 | 4 | ~2 weeks testing |
💡 Tip: Document findings and update the asset inventory with the results to keep everything centralized and easy to review.
Now that you know what's going on with your applications and infrastructure, we could start putting together our first set of security goals and get to work implementing the right security practices and controls.
Summary
It's really important to understand where your organisation is with application security right now. This is true whether you're introducing security into your SDLC or doing a risk assessment. While frameworks like OWASP SAMM, BSIMM, and NIST SSDF give some helpful guidance, their general nature often leaves companies struggling with implementation.
The first thing you need to do is create a complete list of all your assets, which is the basis of your security strategy. The best way to make sure you know what you're protecting is to work with your DevOps and product owners to document all your assets.
Then, you want to review your SDLC for security integration and evaluate your application functionality. This helps you identify security gaps early in development. Finally, test your infrastructure and applications via vulnerability assessments and security audits. This will give you a clearer picture of your security posture.
