OWASP DSOMM

Level 2: Adoption of basic security practices: Security unit tests for important components
Risk:
Vulnerabilities are rising due to code changes.
Measure:
Usage of unit tests to test important security related features like authentication and authorization.
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time: Very High
Resources: Medium
Usefulness:
High
Implementation:

Level 3: High adoption of security practices: Security integration tests for important components
Risk:
Vulnerabilities are rising due to code changes in a complex microservice environment.
Measure:
Implementation of essential security related integration tests. For example for authentication and authorization.
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time: Very High
Resources: Medium
Usefulness:
Medium

Level 4: Very high adoption of security practices: Smoke Test
Risk:
During a deployment an error might happen which leads to non-availability of the system, a part of the system or a feature.
Measure:
Integration tests are performed against the production environment after each deployment.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Medium
Usefulness:
Medium

Level 5: Advanced deployment of security practices at scale: High coverage of security related module and integration tests
Risk:
Vulnerabilities are rising due to code changes in a complex microservice environment in not important components.
Measure:
Implementation of security related tests via unit tests and integration tests. Including the test of libraries, in case the are not tested already.
Difficulty of Implementation:
Knowledge:
Time:
Resources: High
Usefulness:
High

Level 1: Basic understanding of security practices: Fix based on severity
Risk:
Overwhelming volume of security findings from automated testing tools. This might lead to ignorance of findings.
Measure:
Implement a very simple risk-based prioritization framework for vulnerability remediation based on the severity of the findings.
On level one, fix only critical findings.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Low
Usefulness:
High

Level 1: Basic understanding of security practices: Simple false positive treatment
Risk:
As false positive occur during each test, all vulnerabilities might be ignored.
Measure:
False positives are suppressed so they will not show up on the next tests again. Most security tools have the possibility to suppress false positives. A Vulnerability Management System might be used.
Difficulty of Implementation:
Knowledge: Low (one discipline)
Time: Low
Resources: Low
Usefulness:
Very High
Implementation:

Level 1: Basic understanding of security practices: Treatment of defects with severity high or higher
Risk:
Vulnerabilities with severity high or higher are not visible.
Measure:
Vulnerabilities with severity high or higher are added to the quality gate.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Low
Usefulness:
Very High

Level 2: Adoption of basic security practices: Simple visualization of defects
Risk:
The security level of a component is not visible. Therefore, the motivation to enhance the security is not give.
Measure:
Vulnerabilities are simple visualized.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Low
Usefulness:
High
Implementation:

Level 3: High adoption of security practices: Fix based on accessibility
Risk:
Overwhelming volume of security findings from automated testing tools. This might lead to ignorance of findings.
Measure:
Implement a simple risk-based prioritization framework for vulnerability remediation based on accessibility of the applications.
Implementation Guide:
Develop a scoring system for asset accessibility, considering factors like:

Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Low
Usefulness:
Very High

Level 3: High adoption of security practices: Integration in development process
Description:
Validating Findings by Security Engineers Pros:

Validating Findings by Security Engineers Cons:

Pushing Findings Directly to Product Teams Pros:

Risk:
Not integrating vulnerability handling into the development process may result in product teams ignoring findings.
Security joke: We will gain 100% false negatives.
Measure:
Integration of findings into the development process. E.g. adding findings to the backlog of products teams
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Medium
Usefulness:
High
Implementation:

Level 3: High adoption of security practices: Integration of vulnerability issues into the development process
Risk:
To read console output of the build server to search for vulnerabilities might be difficult. Also, to check a vulnerability management system might not be a daily task for a developer.
Measure:
Vulnerabilities are tracked in the teams issue system (e.g. jira).
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Low
Usefulness:
Medium
Implementation:

Level 3: High adoption of security practices: Treatment of defects per protection requirement
Description:
Validating Findings by Security Engineers Pros:

Validating Findings by Security Engineers Cons:

Pushing Findings Directly to Product Teams Pros:

Risk:
Not integrating vulnerability handling into the development process may result in product teams ignoring findings.
Security joke: We will gain 100% false negatives.
Measure:
Integration of findings into the development process. E.g. adding findings to the backlog of products teams
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Medium
Usefulness:
High
Implementation:

Level 3: High adoption of security practices: Treatment of defects with severity middle
Risk:
Vulnerabilities with severity middle are not visible.
Measure:
Vulnerabilities with severity middle are added to the quality gate.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Low
Usefulness:

High

Level 3: High adoption of security practices: Usage of a vulnerability management system
Description:
For known vulnerabilities a processes to estimate the exploit ability of a vulnerability is recommended.
To implement a security culture including training, office hours and security champions can help integrating
security scanning at scale. Such activities help to understand why a vulnerability is potentially critical and needs handling.
Risk:
Maintenance of false positives in each tool enforces a high workload. In addition a correlation of the same finding from different tools is not possible.
Measure:
Aggregation of vulnerabilities in one tool reduce the workload to handle them, e.g. mark as false positives.
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time: High
Resources: Medium
Usefulness:
Medium
Implementation:

Level 4: Very high adoption of security practices: Advanced visualization of defects
Risk:
Correlation of the vulnerabilities of different tools to have an overview of the the overall security level per component/project/team is not given.
Measure:
Findings are visualized per component/project/team.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Very High
Resources: Low
Usefulness:
Medium
Implementation:

Level 4: Very high adoption of security practices: Reproducible defect tickets
Risk:
Vulnerability descriptions are hard to understand by staff from operations and development.
Measure:
Vulnerabilities include the test procedure to give the staff from operations and development the ability to reproduce vulnerabilities. This enhances the understanding of vulnerabilities and therefore the fix have a higher quality.
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time: Medium
Resources: Medium
Usefulness:
Medium

Level 5: Advanced deployment of security practices at scale: Treatment of all defects
Risk:
Vulnerabilities with severity low are not visible.
Measure:
All vulnerabilities are added to the quality gate.
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time: Very High
Resources: Low
Usefulness:
Medium

Level 2: Adoption of basic security practices: Coverage of client side dynamic components
Risk:
Parts of the service are not covered during the scan, because JavaScript is not getting executed. Therefore, the co
Measure:
Usage of a spider which executes dynamic content like JavaScript, e.g. via Selenium.
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time: High
Resources: Low
Usefulness:
Very High
Implementation:

Level 2: Adoption of basic security practices: Simple Scan
Risk:
Deficient security tests are performed. Simple vulnerabilities are not detected and missing security configurations (e.g. headers) are not set. Fast feedback is not given.
Measure:
A simple scan is performed to get a security baseline. In case the test is done in under 10 minutes, it should be part of the build and deployment process.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Low
Usefulness:
Low
Implementation:

Level 2: Adoption of basic security practices: Usage of different roles
Risk:
Parts of the service are not covered during the scan, because a login is not performed.
Measure:
Integration of authentication with all roles used in the service.
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time: High
Resources: Low
Usefulness:
Medium
Assessment:
For REST APIs, multiple OAuth2 scopes are used.
Implementation:

Level 3: High adoption of security practices: Coverage of hidden endpoints
Risk:
Hidden endpoints of the service are not getting tracked.
Measure:
Hidden endpoints are getting detected and included in the vulnerability scan.
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time: Medium
Resources: Low
Implementation:

Level 3: High adoption of security practices: Coverage of more input vectors
Risk:
Parts of the service are not covered. For example specially formatted or coded parameters are not getting detected as parameter (e.g. parameters in REST-like URLs, parameters in JSON-Format or base64-coded parameters).
Measure:
Special parameter and special encodings are defined, so that they get fuzzed by the used vulnerability scanners.
Difficulty of Implementation:
Knowledge:
Time:
Resources: Low
Usefulness:
Very High
Implementation:

Level 3: High adoption of security practices: Coverage of sequential operations
Risk:
Sequential operations like workflows (e.g. login -> put products in the basket
Measure:
Sequential operations are defined and checked by the vulnerability scanner in the defined order.
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time: High
Resources: Low
Implementation:

Level 4: Very high adoption of security practices: Usage of multiple scanners
Risk:
Each vulnerability scanner has different opportunities. By using just one scanner, some vulnerabilities might not be found.
Measure:
Usage of multiple spiders and scanner enhance the coverage and the vulnerabilities.
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time: High
Resources:
Usefulness:
Low
Implementation:

Level 5: Advanced deployment of security practices at scale: Coverage analysis
Risk:
Parts of the service are not still covered by tests.
Measure:
Check that there are no missing paths in the application with coverage-tools.
Difficulty of Implementation:
Knowledge: Very High (three or more disciplines)
Time:
Resources: High
Usefulness:
Very High
Implementation:

Level 5: Advanced deployment of security practices at scale: Coverage of service to service communication
Risk:
Service to service communication is not covered.
Measure:
Service to service communication is dumped and checked.
Difficulty of Implementation:
Knowledge: Very High (three or more disciplines)
Time:
Resources: Medium
Usefulness:
High

Level 2: Adoption of basic security practices: Test for exposed services
Risk:
Standard network segmentation and firewalling has not been performed, leading to world open cluster management ports.
Measure:
With the help of tools the network configuration of unintentional exposed cluster(s) are tested. To identify clusters, all subdomains might need to be identified with a tool like OWASP Amass to perform port scans based o the result.
Difficulty of Implementation:
Knowledge: Low (one discipline)
Time: Low
Resources: Medium
Usefulness:
Medium
Implementation:

Level 2: Adoption of basic security practices: Test network segmentation
Risk:
Wrong or no network segmentation of pods makes it easier for an attacker to access a database and extract or modify data.
Measure:
Cluster internal test needs to be performed. Integration of fine granulated network segmentation (also between pods in the same namespace).
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Low
Usefulness:
High
Implementation:

Level 2: Adoption of basic security practices: Test of the configuration of cloud environments
Risk:
Standard hardening practices for cloud environments are not performed leading to vulnerabilities.
Measure:
With the help of tools the configuration of virtual environments are tested.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Low
Usefulness:
Very High
Implementation:

Level 3: High adoption of security practices: Test for unauthorized installation
Risk:
Unapproved components are used.
Measure:
Components must be whitelisted. Regular scans on the docker infrastructure (e.g. cluster) need to be performed, to verify that only standardized base images are used.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Low
Resources: Low
Usefulness:
High
Implementation:

Level 3: High adoption of security practices: Weak password test
Risk:
Weak passwords in components like applications or systems, specially for privileged accounts, lead to take over of that account.
Measure:
Automatic brute force attacks are performed. Specially the usage of standard accounts like 'admin' and employee user-ids is recommended.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Low
Resources: Low
Usefulness:
Low
Implementation:

Level 4: Very high adoption of security practices: Load tests
Risk:
As it is unknown how many requests the systems and applications can serve, due to an unexpected load the availability is disturbed.
Measure:
Load test against the production system or a production near system is performed.
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time: Medium
Resources:
Usefulness:
High

Level 5: Advanced deployment of security practices at scale: Test for unused Resources
Risk:
Unused resources, specially secrets, might be still valid, but are exposing information. As an attacker, I compromise a system, gather credentials and try to use them.
Measure:
Test for unused resources helps to identify unused resources.
Difficulty of Implementation:
Knowledge: Low (one discipline)
Time: Low
Resources: Low
Usefulness:
Medium
Implementation:

Level 2: Adoption of basic security practices: Software Composition Analysis (server side)
Description:
Use a tool like trivy and concentrate on application related vulnerabilities. At this stage, ignore vulnerabilities in container base images used in the service.
Risk:
Server side components might have vulnerabilities.
Measure:
Tests for known vulnerabilities in server side components (e.g. backend/middleware) are performed.
Difficulty of Implementation:
Knowledge: Low (one discipline)
Time: High
Resources: Low
Implementation:

Level 2: Adoption of basic security practices: Test for Time to Patch
Risk:
Automatic PRs for dependencies are overlooked resulting in known vulnerabilities in production artifacts.
Measure:
Test of the Time to Patch (e.g. based on Mean Time to Close automatic PRs) This activity is not repeated in the Sub-Dimension "Static depth for infrastructure", but it applies to infrastructure as well.
Implementation Guide:
Usage of a version control platform API (e.g. github API) can be used to fetch the information. Consider that Measure libyears might be an alternative to this activity.
Difficulty of Implementation:
Knowledge: Low (one discipline)
Time: Low
Resources: Low
Usefulness:
High
Implementation:

Level 2: Adoption of basic security practices: Test libyear
Risk:
Vulnerabilities in running artifacts stay for long and might get exploited.
Measure:
Test libyear, which provides a good insight how good patch management is.
Implementation Guide:
libyear can be integrated into the build process and flag or even better break the build in case the defined threshold (e.g. 30 years) is reached. An alternative approach is to determine libyear based on deployed artifacts (which requires more effort in implementation).
Difficulty of Implementation:
Knowledge: Low (one discipline)
Time: Low
Resources: Low
Usefulness:
High
Implementation:

Level 3: High adoption of security practices: API design validation
Risk:
Creation of insecure or non-compliant API.
Measure:
Design contract-first APIs using an interface description language such as OpenAPI, AsyncAPI or SOAP and validate the specification using specific tools. Checks should be integrated in IDEs and CI/CD pipelines.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Medium
Usefulness:
High
Implementation:

Level 3: High adoption of security practices: Exploit likelihood estimation
Risk:
Without proper prioritization, organizations may waste time and effort on low-risk vulnerabilities while neglecting critical ones.
Measure:
Estimate the likelihood of exploitation by using data (CISA KEV) from the past or prediction models (EPSS).
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Medium
Usefulness:
Very High
Implementation:

Level 3: High adoption of security practices: Local development security checks performed
Risk
Creating and developing code contains code smells and quality issues.
Measure
Integration of quality and linting plugins with interactive development environment (IDEs). Implement pre-commit checks to prevent secrets & other security issues being commit to source code.
Difficulty of Implementation
Knowledge: Medium (two disciplines)
Time: Low
Resources: Low
Usefulness
Very High
Implementation

Level 3: High adoption of security practices: Software Composition Analysis (client side)
Risk:
Client side components might have vulnerabilities.
Measure:
Tests for known vulnerabilities in components via Software Composition Analysis of the frontend are performed.
Difficulty of Implementation:
Knowledge: Low (one discipline)
Time: Medium
Resources: Low
Usefulness:
Medium
Implementation:

Level 3: High adoption of security practices: Static analysis for important client side components
Risk:
Important parts in the source code of the frontend have vulnerabilities.
Measure:
Usage of static analysis tools for important parts of the frontend are used. Static analysis uses for example string matching algorithms and/or dataflow analysis.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Low
Usefulness:
High
Implementation:

Level 3: High adoption of security practices: Static analysis for important server side components
Risk:
Important parts in the source code of the middleware have vulnerabilities.
Measure:
Usage of static analysis tools for important parts of the middleware are used. Static analysis uses for example string matching algorithms and/or dataflow analysis.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Low
Usefulness:
Very High
Implementation:

Level 3: High adoption of security practices: Test for Patch Deployment Time
Risk:
Automatic PRs for dependencies are overlooked resulting in known vulnerabilities in production artifacts.
Measure:
Test of the Patch Deployment Time. This activity is not repeated in the Sub-Dimension "Static depth for infrastructure", but it applies to infrastructure as well.

Implementation Guide:
Self implementation. This activity is not repeated in the Sub-Dimension "Static depth for infrastructure", but it applies to infrastructure as well.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Low
Usefulness:

High

Level 4: Very high adoption of security practices: Static analysis for all self written components
Risk:
Parts in the source code of the frontend or middleware have vulnerabilities.
Measure:
Usage of static analysis tools for all parts of the middleware and frontend. Static analysis uses for example string matching algorithms and/or dataflow analysis.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Low
Usefulness:
Very High
Implementation:

Level 4: Very high adoption of security practices: Usage of multiple analyzers
Risk:
Each vulnerability analyzer has different opportunities. By using just one analyzer, some vulnerabilities might not be found.
Measure:
Usage of multiple static tools to find more vulnerabilities.
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time: High
Resources:
Usefulness:
Low

Level 5: Advanced deployment of security practices at scale: Dead code elimination
Risk:
Dead code increases the attack surface (use of hard coded credentials and variables, sensitive information)
Measure:
Collection of unused code and then manual removal of unused code.
Difficulty of Implementation:
Knowledge: Low (one discipline)
Time: Low
Resources: Low
Usefulness:
Low
Implementation:

Level 5: Advanced deployment of security practices at scale: Exclusion of source code duplicates
Risk:
Duplicates in source code might influence the stability of the application.
Measure:
Automatic Detection and manual removal of duplicates in source code.
Difficulty of Implementation:
Knowledge: Low (one discipline)
Time: Low
Resources: Low
Usefulness:
Low
Implementation:

Level 5: Advanced deployment of security practices at scale: Static analysis for all components/libraries
Risk:
Used components like libraries and legacy applications might have vulnerabilities
Measure:
Usage of a static analysis for all used components.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Very High
Resources: Medium
Usefulness:
High

Level 5: Advanced deployment of security practices at scale: Stylistic analysis
Risk:
Unclear or obfuscated code might have unexpected behavior.
Measure:
Analysis of compliance to style guides of the source code ensures that source code formatting rules are met (e.g. indentation, loops, ...).
Difficulty of Implementation:
Knowledge: Low (one discipline)
Time: Low
Resources: Low
Usefulness:
Low
Implementation:

Level 1: Basic understanding of security practices: Test for stored secrets
Risk:
Stored secrets in git history, in container images or directly in code shouldn't exists because they might be exposed to unauthorized parties.
Measure:
Test for secrets in code, container images and history
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Low
Resources: Medium
Usefulness:
Medium
Implementation:

Level 2: Adoption of basic security practices: Test cluster deployment resources
Risk:
The deployment configuration (e.g. kubernetes deployment resources) might contain unsecured configurations.
Measure:
Test the deployment configuration for virtualized environments for unsecured configurations.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Low
Resources: Medium
Usefulness:
High
Implementation:

Level 2: Adoption of basic security practices: Test for image lifetime
Risk:
Old container images in production indicate that patch management is not performed and therefore vulnerabilities might exists.
Measure:
Check the image age of containers in production.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Low
Resources: Low
Usefulness:
Medium
Implementation:

Level 2: Adoption of basic security practices: Test of virtualized environments
Risk:
Virtualized environments (e.g. via <i>Container Images</i>) might contains unsecure configurations.
Measure:
Test virtualized environments for unsecured configurations.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Low
Resources: Medium
Usefulness:
High
Implementation:

Level 2: Adoption of basic security practices: Test the cloud configuration
Risk:
Standard hardening practices for cloud environments are not performed leading to vulnerabilities.
Measure:
With the help of tools, the configuration of virtual environments are tested.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Low
Usefulness:
Very High
Implementation:

Level 2: Adoption of basic security practices: Test the definition of virtualized environments
Risk:
The definition of virtualized environments (e.g. via <i>Dockerfile</i>) might contain unsecure configurations.
Measure:
Test the definition of virtualized environments for unsecured configurations.
Implementation Guide:
For containier (images), test that the images are following best practices like distroless or non-root.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Low
Resources: Medium
Usefulness:
High
Implementation:

Level 3: High adoption of security practices: Analyze logs
Risk:
Not aware of attacks happening.
Measure:
Check logs for keywords.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Medium
Usefulness:
High
Implementation:

Level 3: High adoption of security practices: Test for malware
Risk:
Third party might include malware. Ether due to the maintainer (e.g. typo squatting of an image name and using the wrong image) or by an attacker on behalf of the maintainer with stolen credentials.
Measure:
Check for malware in components (e.g. container images, VM baseline images, libraries).
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Medium
Usefulness:
High
Implementation:

Level 3: High adoption of security practices: Test for new image version
Risk:
When a new version of an image is available, it might fix security vulnerabilities.
Measure:
Check for new images of containers in production.
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time: High
Resources: Low
Usefulness:
Medium

Level 4: Very high adoption of security practices: Correlate known vulnerabilities in infrastructure with new image versions
Risk:
TODO.
Measure:
TODO
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time:
Resources: Very High
Usefulness:
Low
Implementation:

Level 4: Very high adoption of security practices: Software Composition Analysis
Description:
Subscribing to Github projects and reading release notes might help. Software Composition Analysis for infrastructure might help, but is often too fine-granular.
Risk:
Known vulnerabilities in infrastructure components like container images might get exploited.
Measure:
Check for known vulnerabilities
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Low
Resources: Low
Usefulness:
Very High
Implementation:

Level 4: Very high adoption of security practices: Test of infrastructure components for known vulnerabilities
Risk:
Infrastructure components might have vulnerabilities.
Measure:
Test for known vulnerabilities in infrastructure components. Often, the only way to respond to known vulnerabilities in operating system packages is to accept the risk and wait for a patch. As the patch needs to be applied fast when it is available, this activity depends on 'Usage of a maximum life for images'.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time:
Resources: Medium
Usefulness:
Low
Implementation:

Level 1: Basic understanding of security practices: Default settings for intensity
Risk:
Time pressure and ignorance might lead to false predictions for the test intensity.
Measure:
The intensity of the used tools are not modified to safe time.
Difficulty of Implementation:
Knowledge: Low (one discipline)
Time: Low
Resources: Low
Usefulness:
Low

Level 1: Basic understanding of security practices: High test intensity
Risk:
A too small intensity or a too high confidence might lead to not visible vulnerabilities.
Measure:
A deep scan with high test intensity and a low confidence threshold is performed.
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time: High
Resources:
Usefulness:
High

Level 2: Adoption of basic security practices: Regular automated tests
Risk:
After pushing source code to the version control system, any delay in receiving feedback on defects makes them harder for the developer to remediate.
Measure:
On each push and/or at given intervals automatic security tests are performed.
Difficulty of Implementation:
Knowledge: Low (one discipline)
Time: Low
Resources: Low
Usefulness:
Medium

Level 3: High adoption of security practices: Deactivating of unneeded tests
Risk:
As tools cover a wide range of different vulnerability tests, they might not match the used components. Therefore, they need more time and resources as they need and the feedback loops takes too much time.
Measure:
Unneeded tests are deactivated. For example in case the service is using a Mongo database and no mysql database, the dynamic scan doesn't need to test for sql injections.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: High
Resources: Low
Usefulness:
Low

Level 4: Very high adoption of security practices: Creation and application of a testing concept
Risk:
Scans might use a too small or too high test intensity.
Measure:
A testing concept considering the amount of time per scan/intensity is created and applied. A dynamic analysis needs more time than a static analysis. The dynamic scan, depending on the test intensity might be performed on every commit, every night, every week or once in a month.
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time: High
Resources: High
Usefulness:
Medium