In this talk (embedded below), brothers Glenn ten Cate and Riccardo ten Cate identify issues in current secure coding practices. They show how to use the Open Web Application Security Project’s security knowledge framework to build apps that are secure by design.
Secure Software Development Life Cycle (SSDLC)
DevOps is more achievable than ever, with plenty of available materials on what it is and how to get started with it. But how should you incorporate security into it? This is the challenge of DevSecOps and the subject of a talk by Glenn and Riccardo.
The secure software development life cycle is a method to help web and app developers establish best practices at each stage of product development. What are the parts of this method, and why does it make sense to use it?
Components
An SSDLC relies on four parts:
- Security requirements
- Test automation and code quality checks
- Security test automation
- Manual verification
Let’s talk about each of these in turn.
Security Requirements
It’s critical that you gather security requirements before starting work. Otherwise, you’ll miss requirements and struggle to secure your application at the end.
Test Automation and Code Quality Checks
Dead end code, overly complex code, and repudiated code each present potential vulnerabilities. Automation makes finding these easier than doing so by hand.
Security Test Automation
Security test automation is common in DevOps processes and comes in two flavors: static analyzers (SAST) look at source code, and dynamic analyzers (DAST) inspect a running application. That said, they detect only about 20% of the 280 controls in the OWASP application security verification system.
In addition, these analyzers present two more challenges beyond struggling to find vulnerabilities. First, you must verify all findings manually. Second, running the analyzers requires architecture considerations such as containers to run the applications, plus tests and tools to track and manage the findings.
Manual Verification
Because all analyzer findings need manual verification, false positives are a nightmare for security engineers. You’ll want to track false positives across builds, and that requires additional tools.
Better Automated Security Tooling
Automated security tooling has a place in the SSDLC, but we need something more effective: developers. Developers are the most effective tool for building apps that are secure by design. Developers make a lot of the same coding mistakes over and over, and as a result, some developers are barely hanging on. Instead, developers should be in control and confidently build secure apps.
Fortunately, there’s a way to do this: the Security Knowledge Framework, developed five years ago by Glenn, Riccardo, and several other contributors.
Security Knowledge Framework
The security knowledge framework (SKF), part of OWASP, helps you write more secure apps by:
- Guiding you to a secure application design instead of thinking about security after the fact
- Informing you about threats before a single line of source code is written
- Providing information that applies to your needs on the spot
- Setting up the right security requirements for your project
The SKF relies heavily on OWASP’s application security verification standard (ASVS) and its security controls. The ASVS has 4 levels: Cursory (level 0); Opportunistic (level 1); Standard (level 2); and Advanced (level 3). With this in mind, start at level 1 unless your industry or situation dictates starting elsewhere. For example, banks should be at level 3 and use all the controls.
Code analyzers find injection and configuration vulnerabilities pretty well, but they miss issues in application logic. In contrast, the SKF gives developers both the right security requirements and the right mindset for success.
SKF In Depth
The security knowledge framework website has a live demo you can check out. From there, you can install and host the SKF app internally for your own use. The SKF website has a chatbot that will link you to OWASP resources based on questions you enter. The SKF has four main sections:
- Labs
- Checklists
- Knowledge base
- Projects
Labs
Labs in the SKF provide a live example of each issue through containerized code.
Checklists
Checklists break the ASVS into categories for easier consumption. To start, use a checklist to help assess your project against the ASVS, as all the controls are linked to knowledge base articles.
Knowledge Base
Every ASVS control has a knowledge base article describing the attack vector and solution with accompanying code samples.
Projects
A project in SKF links work on your team to your security requirements through checklists and ASVS controls. Also, you can lay out your security requirements in sprints to break them down for tracking purposes.
Conclusion
The goal of this talk was to move developers from barely hanging on, security-wise, to confidently building apps that are secure by design. As shown above, the SKF fuels that transition.
Use the SKF to gather security requirements, schedule them for implementation, and track their assessment. When you do, you’ll unlock the power of developers as security champions through OWASP and SKF.
You can check out Glenn and Riccardo ten Cate’s talk “OWASP Security Knowledge Framework” here.
