Modern Application Development (MAD) is an approach to developing software applications using cloud-native technologies. The main idea is to leverage newer emerging tools like K8s to bootstrap adaptive and fine-grained applications that are easy to scale, easy to monitor, and easy to manage.
But what about security? Should we try to secure MAD applications using only the OWASP Top 10 list as a guide, or should we explore additional options? And if we adopt a comprehensive security solution, how can we be sure that developers stick with it in the long term?
Keep reading for a comprehensive discussion of Modern Application Development from a secure software development and deployment perspective.
What Are the Best Practices for Modern Secure Application Development?
In an ideal world, security and compliance solutions would be included at every stage of the application development lifecycle. This means that every software component would be secured by default and implemented using industry best practices. You need your applications to work safely as intended with bulletproof security controls in place.
MAD applications (and especially microservices) help us create a clear division of responsibilities along with components that can be individually secured and protected. This, however, also increases the chance of misconfigurations. It is up to developers and security professionals to follow the right path, boost their essential security skills, and continuously monitor for new vulnerabilities.
With the increased complexity of MAD applications in mind, let’s explore the current landscape of best practices for secure development, starting with the OWASP Top 10.
The OWASP Top 10 and Why It’s Important
Today, the most recognized list of top security threats is the OWASP Top 10. OWASP is a non-profit organization that is dedicated to promoting secure software methodologies and improving awareness. Over the years, they’ve published a list of the top 10 most critical web application security risks based on information gathered from open community contributors and real threat data. The latest one was updated in 2011.
Because it’s based on evidence, fairly documented, and easy to reproduce, the OWASP Top 10 can be an invaluable resource for learning and practicing software application development. MAD applications can be particularly susceptible to these security risks because the use of microservices and container orchestration systems can increase the complexity of the system’s architecture (by adding more moving pieces and infrastructure to manage) and introduce many more opportunities for misconfigurations, authentication failures, and broken access controls.
There is also another reason why the OWASP Top 10 is important. Mitigation controls can be automated, scripted, and integrated into Web Application Firewalls, security automation tools, and CI/CD pipelines. This makes it easier to identify and prevent many common security issues by integrating OWASP security controls into the code pipeline. There are many conventional tools that help, including configuration drift detectors, IaC checks, dependency scanners, policy checkers, and integrity checkers.
Are There Other Methodologies or Models That Should Be Considered?
The practice of secure application development is not dominated solely by OWASP. In fact, there are competing guides and standards that promote the use of best practices for Modern Secure Application Development. The real question is: why are they not as widely used?
To answer that question, let’s take a look at two such models: BSIMM and SAMM.
Building Security in Maturity Model (BSIMM)
BSIMM (Building Security In Maturity Model) is a security framework that gives organizations practical insight into how their security posture compares to that of other organizations. BSIMM doesn’t really tell you what you should do; instead, it tells you what other organizations are doing. You want to use BSIMM if you intend to take an established security model and fit it into your own business domain.
BSIMM collects information from around 128 firms spanning several business categories. The core of the BSIMM framework consists of 122 tasks divided into 12 practices that are organized into four domains:
- Governance (which includes strategy & metrics, compliance & policy, and training),
- Intelligence (which includes attack models, security features & design, and standards & requirements),
- SSDL Touchpoints (which includes architecture analysis, code review, and security testing),
- Deployment (which includes penetration testing, software environment, and configuration management & vulnerability management).
In practice, the SecOps team evaluates the organization’s security posture and assigns scores to the activities. From this, they build a scorecard which helps them determine if they want to include additional security controls based on the scores. They normally refine the scorecard according to specific areas of interest, and there’s no need to try to include all of the activities in each practice. Some practices will be more important than others; for example, PII obligations, security standards, and good network security are always important considerations.
BSIMM is free and can serve as a good reference point when implementing security audits in an organization. It is not standardized, however, which makes it a little less appealing than other options.
Software Assurance Maturity Model (SAMM)
SAMM (Software Assurance Maturity Model) is an OWASP security framework project that has much in common with BSIMM. Like BSIMM, organizations can use it to measure and score their security posture. The core pillars of SAMM consist of:
Figure 1 – The Structure of SAMM (source: https://owaspsamm.org/about/)
OWASP offers some valuable tools (like this one) to help you manage the maturity models that you are using (SAMM or BSIMM). However, you still need expertise to properly evaluate them in practice. Below, we will explain why these methodologies are not as popular as the OWASP Top 10.
The primary reason why these methodologies are not universally adopted comes down to convenience and practicality. From our perspective, they’re too comprehensive, and it simply requires too much effort to repeat the assessments. For example, imagine that your organization wanted to adopt BSIMM as your software maturity framework. You would have to evaluate which of the 122 tasks would be relevant to your organization and then try to monitor your security score based on those tasks. Your organization would also have to invest heavily in training, hiring the right security experts, choosing the right tools, and making sure that the task list is being followed. Inevitably, you would experience many growing pains just in trying to understand and adopt a framework that essentially only tells you what everyone else is doing (and implicitly that you should be doing it, too).
It is therefore more convenient to adopt the OWASP Top 10 as a single standard that is based on real incidents, has better tooling, and takes a vast range of attacks into account to help you plan for your specific organization. So, does this mean that your organization should not consider BSIMM or SAMM? The answer primarily depends on your software assurance model and the specific outcomes you’re trying to achieve (such as audit readiness, critical systems support, or holistic security goals).
The problem with these security frameworks is that they tend to be overly complex, with almost unmanageable expectations in terms of balancing security and usability. To put it mildly, it’s more reasonable to expect human operators to flawlessly obey the Ten Commandments than to adopt 122 tasks that may have unclear expectations and outcomes.
It can make sense to use these security frameworks in certain scenarios when you’re trying to achieve certification status. For example, Checkmarx KICS has achieved CIS level 2 certification. Organizations that want to acquire similar certifications would have to follow a set of rules and audit criteria to gain the relevant stamp of approval.
Still, both security frameworks discussed above have merit in that they are free to use and can save time that you would spend researching to find out what everyone else is doing.
Next Steps with Modern Secure Application Development
In this article, we briefly explained the OWASP Top 10 as well as BSIMM and SAMM, two alternative open source security frameworks for Modern Secure Application Development (and any type of software). The next step for your organization is to set everything in motion. If you haven’t initiated that process already, start by adopting the OWASP Top 10 security best practices. Checkmarx SAST is the industry-leading tool that helps you utilize this list by integrating checks into your CI/CD pipeline.
Developers also need to be educated about the latest Modern Secure Application Development best practices in order to write secure, standard-compliant software. Checkmarx Codebashing is a training platform dedicated to upskilling developers in secure coding fundamentals through their participation in practical and fun activities. OWASP Top 10 protections and developer training should both be indispensable parts of your modern application development workflows.