Shipping your software – and doing it on time – may be your first priority as a developer. However, as your company shifts security left, you need to build it into your processes while still meeting estimated timelines. Now you need to manage cross-functional communications and respond to seemingly competing priorities. You’re trying to debug the software and remediate the vulnerabilities that the security team found. 

With the OWASP Testing Framework, you can build security into your application development workflows, making it easier to meet deadlines. 

What is the OWASP Testing Framework?

Developed by the Open Web Application Security Project (OWASP), the OWASP Testing Framework suggests activities that development and AppSec teams can implement at various stages of the software development lifecycle (SDLC) to improve security and reduce costs. Intended to fit into any development methodology, the Testing Framework acts as a generic development model by proposing across five SDLC states:

• Before development
• Definition and design
• Development
• Deployment
• Maintenance

Phase 1: Before Development

Waiting to do security testing until right before you push the application to production ultimately increases all your costs. Before outlining software requirements, you should consider where testing fits into your workflows. 

As part of defining where security sits in your SDLC, you should also:

• Review policies and standards: Know the documentation you need, and document how people should respond to common issues.
• Develop measurement and metrics: Define criteria to measure to ensure that you capture the data during the development process

Phase 2: Definition and Design

When building the requirements list, you’re used to thinking about who uses an application and how they use it. Today, the who and how overlap with the application’s security. For example, a non-technical user may not think to use multi-factor authentication. OWASP suggests identifying the following security mechanisms:

• User management
• Authentication
• Authorization
• Data confidentiality
• Integrity
• Accountability
• Session management
• Transport security
• Tiered system segregation
• Legislative and standards compliance (including privacy, government, and industry standards)

Additionally, you should incorporate security testing into the following:

• Review design and architecture: Test models, textual documents, or other artifacts to save time and money by identifying security issues so you can make changes before development starts. 
• Create and review Unified Modeling Language (UML) models: Review how the application should work to determine whether the system architect needs to address weaknesses or look for alternative approaches. 
• Create and review threat models: Develop realistic threat scenarios so the organizations can analyze whether to mitigate, accept, or transfer responsibility. 

Phase 3: Development

In the definition and design phase, you’re building the map for how to develop the application. Just like taking a trip, you input the expected start and endpoints. However, as you code the application, you’ll likely need to make smaller decisions, much like taking a detour when you get stuck in unexpected traffic. 

During the development phase, OWASP suggests:

• Performing code walkthroughs: Take a high-level look at the code with the security team so that you can explain the decisions made around logic and data flow.
• Doing code reviews: Testing code for actual security defects

At a minimum, you should engage in a static code review that validates the code against checklists for issues with:

• Availability, confidentiality, and integrity
• Technical exposures aligned to OWASP Guide or Top Ten Checklists
• Programming language or framework 
• Industry-specific compliance requirements

To gain a comprehensive picture of your application’s security during the development process, you can automate secure code reviews for real-time review with the following:

• Software composition analysis: identifying open-source software components to track potential vulnerabilities
• Static application software testing (SAST): reviewing source code to identify vulnerabilities
• Dynamic application software testing (DAST): testing against the business logic to identify ways attackers can exploit vulnerabilities

By building these tools into your development processes, you reduce the amount of time it takes to build secure code. For example, when you combine SCA, SAST, and DAST for a comprehensive, real-time code review, you gain visibility and insights into:

• Risky components
• Vulnerabilities in code
• Whether attackers can use either the components or vulnerabilities during an attack

When you focus on remediating the vulnerabilities that attackers can actually use, you reduce the amount of time and work that securing your application takes. 

Phase 4: Deployment

Before the deployment phase, you should try to eliminate as many security issues as possible to reduce both costs and potential customer impact. 

OWASP explains that during this phase, your security testing should include the following:

• Penetration testing: Actively looking for new vulnerabilities and ways to compromise the application. 
• Configuration management testing: Examining the infrastructure’s security, including changing default settings

If you engage in comprehensive secure code testing during the development phase, then the penetration testing and issue remediation costs will be lower during the deployment phase. Further, when you get a clean bill of technical health from the penetration testers, your customers have greater confidence in your product. 

Phase 5: Maintenance and Operations

After deployment, you should have plans for monitoring the application’s security so that you can push updates before attackers exploit previously unknown vulnerabilities. 

At this point, you should consider:

• Operational management reviews: Process for managing application and infrastructure
• Periodic health checks: Regular reviews to ensure security level remains intact
• Change verification: Reviewing changes made in the testing environment and deployed to production to ensure they don’t impact security 

Qwiet AI: Noise reduction for securing code during development

Qwiet AI’s platform enables developers to get the security insights they need without undermining their delivery times. Our Code Property Graph (CPG) gives you the combined visibility that you normally need separate SCA, Container Scanning, and SAST tools to achieve. With Qwiet AI’s Blacklight, you can use the first threat intelligence feed designed for application development to reduce the number of remediation activities by incorporating attacker behaviors into your analysis. 

Try Qwiet AI’s preZero platform for free to see how it enables you to implement the OWASP Testing Framework.