Skip to content

Instantly share code, notes, and snippets.

@pastcompute

pastcompute/export.py

Created April 6, 2023 04:42
Show Gist options
  • Save pastcompute/b7fd9b1e7d95cda8b805ea3c5be39e2b to your computer and use it in GitHub Desktop.
Save pastcompute/b7fd9b1e7d95cda8b805ea3c5be39e2b to your computer and use it in GitHub Desktop.
Download ZIP
YAML converter
Raw
export.py
from ruamel.yaml import YAML
import json
import os
import csv
import re
yaml = YAML()
root = os.path.normpath('src/assets/YAML/default')
fields = ['Dimension', 'Subdimension', 'Activity', 'Maturity Level', 'Measure']
csvfile = open('table.csv', 'w', newline='')
csvwriter = csv.writer(csvfile)
csvwriter.writerow(fields)
for topDir in os.scandir(root):
if not topDir.is_dir(): continue
for yamlEntry in os.scandir(topDir):
if yamlEntry.is_file() and yamlEntry.name.endswith('.yaml') and yamlEntry.name != '_meta.yaml':
print(f'Processing: {yamlEntry.path}')
with open(yamlEntry) as f:
yamlObj = yaml.load(f)
jsonStr = json.dumps(yamlObj)
f = open(os.path.splitext(yamlEntry.path)[0] + ".json","w+")
f.write(jsonStr)
f.close()
jsonDict = json.loads(jsonStr)
# We expect first key is only yey, being the title
dimension = next(iter(yamlObj))
subdimension = next(iter(yamlObj[dimension]))
for activity in iter(yamlObj[dimension][subdimension].items()):
level = activity[1]['level']
measure = activity[1]['measure']
# fixup stray line ends and duped spaces
measure = re.sub(r'\s+', ' ', str(measure))
print(f'{subdimension}, {level}, {activity[0]}')
csvwriter.writerow([dimension, subdimension, activity[0], level, measure])
csvfile.close()
Raw
table.csv
Dimension Subdimension Activity Maturity Level Measure
Build and Deployment Build Building and testing of artifacts in virtual environments 2 Each step during within the build and testing phase is performed in a separate virtual environments, which is destroyed afterward.
Build and Deployment Build Defined build process 1 A well defined build process lowers the possibility of errors during the build process.
Build and Deployment Build Pinning of artifacts 2 Pinning of artifacts ensure that changes are performed only when intended.
Build and Deployment Build SBOM of components 2 Creation of an SBOM of components (e.g. application and container image content) during build.
Build and Deployment Build Signing of artifacts 3 Digitally signing artifacts for all steps during the build and especially docker images, helps to ensure their integrity.
Build and Deployment Build Signing of code 3 Digitally signing commits helps to prevent unauthorized manipulation of source code.
Build and Deployment Deployment Blue/Green Deployment 4 By having multiple production environments, a deployment can be performant on the first environment to spot possible defects before it is deployment in the production environment(s)
Build and Deployment Deployment Defined decommissioning process 2 By having a clear decommissioning process, applicaitons not used are not running anymore and can therefore not be explointed.
Build and Deployment Deployment Defined deployment process 1 A defined deployment process significantly lowers the likelihood of errors during the deployment phase.
Build and Deployment Deployment Environment depending configuration parameters (secrets) 2 Configuration parameters are set for each environment not in the source code. By using encryption, it is harder to read credentials , e.g. from the file system. Also, the usage of a credential management system can help protect credentials.
Build and Deployment Deployment Handover of confidential parameters 3 By using encryption, it is harder to read credentials , e.g. from the file system. Also, the usage of a credential management system can help protect credentials.
Build and Deployment Deployment Inventory of dependencies 3 A documented inventory of dependencies used in images and containers exists.
Build and Deployment Deployment Inventory of running artifacts 3 A documented inventory or a possibility to gather the needed information.
Build and Deployment Deployment Rolling update on deployment 3 A deployment without downtime is performed*.
Build and Deployment Deployment Same artifact for environments 3 Building an artifact once and deploying it to different environments means that only tested artifacts are allowed to reach the production environment
Build and Deployment Deployment Usage of feature toggles 3 Usage of environment independent configuration parameter, called feature toggles, helps to enhance the test coverage. Only what has been tested, goes to production.
Build and Deployment Deployment Usage of trusted images 2 Create image assessment criteria, perform an evaluation of images and create a whitelist of artifacts/container images/virtual machine images.
Build and Deployment Patch Management A patch policy is defined 1 A patch policy for all artifacts (e.g. in images) is defined. How often is an image rebuilt?
Build and Deployment Patch Management Automated PRs for patches 1 Fast patching of third party component is needed. The DevOps way is to have an automated pull request for new components. This includes <ul> <li>Applications</li><li>Virtualized operating system components (e.g. container images)</li> <li>Operating Systems</li><li>Infrastructure as Code/GitOps (e.g. argocd)</li> </ul>
Build and Deployment Patch Management Nightly build of images (base images) 2 Custom base images are getting build at least nightly. In case the packages in the base image e.g. <i>centos</i> has changed, the build server triggers the build of depending images.
Build and Deployment Patch Management Reduction of the attack surface 2 Removal of unneeded components, dependencies, files or file access rights. For container images the usage of distroless images is recommended.
Build and Deployment Patch Management Usage of a maximum lifetime for images 2 A short maximum lifetime for images is defined, e.g. 30 days. The project images, based on the nightly builded images, are deployed at leased once within the defined lifetime. Third Party images are deployed at leased once within the defined lifetime.
Build and Deployment Patch Management Usage of a short maximum lifetime for images 4 A good practice is to perform the build and deployment daily or even just-in-time, when a new component (e.g. package) for the image is available.
Culture and Organization Design Conduction of advanced threat modeling 3 Threat modeling is performed by using reviewing user stories and producing security driven data flow diagrams.
Culture and Organization Design Conduction of simple threat modeling on business level 3 Threat modeling of business functionality is performed during the product backlog creation to facilitate early detection of security defects.
Culture and Organization Design Conduction of simple threat modeling on technical level 1 Threat modeling of technical features is performed during the product sprint planning.
Culture and Organization Design Creation of advanced abuse stories 4 Advanced abuse stories are created as part of threat modeling activities.
Culture and Organization Design Creation of simple abuse stories 3 Abuse stories are created during the creation of user stories.
Culture and Organization Design Creation of threat modeling processes and standards 3 Creation of threat modeling processes and standards through the organization helps to enhance the security culture and provide more structure to the threat model exercises.
Culture and Organization Design Information security targets are communicated 1 Transparent and timely communication of the security targets by senior management is essential to ensure teams' buy-in and support.
Culture and Organization Education and Guidance Ad-Hoc Security trainings for software developers 1 Provide security awareness training for all personnel involved in software development Ad-Hoc.
Culture and Organization Education and Guidance Aligning security in teams 4 By aligning security SME with project teams, a higher security standard can be achieved.
Culture and Organization Education and Guidance Conduction of build-it, break-it, fix-it contests 3 The build-it, break-it, fix-it contest allows to train people with security related roles like security champions the build, break and fix part of a secure application. This increases the learning of building secure components.
Culture and Organization Education and Guidance Conduction of collaborative security checks with developers and system administrators 3 Periodically security reviews of source code (SCA), in which security SME, developers and operations are involved, are effective at increasing the robustness of software and the security knowledge of the teams involved.
Culture and Organization Education and Guidance Conduction of collaborative team security checks 4 Mutual security testing the security of other teams project enhances security awareness and knowledge.
Culture and Organization Education and Guidance Conduction of war games 4 War Games like activities help train for incidents. Security SMEs create attack scenarios in a testing environment enabling the trainees to learn how to react in case of an incident.
Culture and Organization Education and Guidance Each team has a security champion 2 Each team defines an individual to be responsible for security. These individuals are often referred to as 'security champions'
Culture and Organization Education and Guidance Regular security training for all 2 Provide security awareness training for all internal personnel involved in software development on a regular basis like twice in a year for 1-3 days.
Culture and Organization Education and Guidance Regular security training for externals 4 Provide security awareness training for all personnel including externals involved in software development on a regular basis.
Culture and Organization Education and Guidance Regular security training of security champions 2 Regular security training of security champions.
Culture and Organization Education and Guidance Reward of good communication 2 Good communication and transparency encourages cross-organizational support. Gamification of security is also known to help, examples include T-Shirts, mugs, cups, giftcards and 'High-Fives'.
Culture and Organization Education and Guidance Security code review 1 The following areas of code tend to have a high-risk of containing security vulnerabilities: - Crypto implementations / usage - Parser, unparser - System configuration - Authentication, authorization - Session management - Request throttling - :unicorn: (self-developed code, only used in that one software)
Culture and Organization Education and Guidance Security consulting on request 1 Security consulting to teams is given on request. The security consultants can be internal or external.
Culture and Organization Education and Guidance Security-Lessoned-Learned 3 Running a 'lessons learned' session after an incident helps drive continuous improvement. Regular meetings with security champions are a good place to share and discuss lessons learned.
Culture and Organization Education and Guidance Simple mob hacking 2 Participate with your whole team in a simple mob hacking session organized by the Security Champion Guild. In the session the guild presents a vulnerable application and together you look at possible exploits. Just like in mob programming there is one driver and several navigators.
Culture and Organization Process Approval by reviewing any new version 3 On each new version (e.g. Pull Request) of source code or infrastructure components a security peer review of the changes is performed (two eyes principle) and approval given by the reviewer.
Culture and Organization Process Definition of a change management process 3 Each change of a system is automatically recorded and adequately logged.
Culture and Organization Process Definition of simple BCDR practices for critical components 1 By understanding and documenting a business continuity and disaster recovery (BCDR) plan, the overall availability of systems and applications is increased. Success factors like responsibilities, Service Level Agreements, Recovery Point Objectives, Recovery Time Objectives or Failover must be fully documented and understood.
Culture and Organization Process Prevention of unauthorized installation 3 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.
Implementation Application Hardening App. Hardening Level 2 2 Following frameworks like the <ul> <li>OWASP Application Security Verification Standard Level 2</li> <li>OWASP Mobile Application Security Verification Standard Level 2</li> </ul>
Implementation Application Hardening App. Hardening Level 3 3 Following frameworks like the <ul> <li>OWASP Application Security Verification Standard Level 3</li> <li>OWASP Mobile Application Security Verification Standard Maturity Requirements</li> </ul> and gain around 75% coverage of both.
Implementation Application Hardening Application Hardening Level 1 1 Following frameworks like the <ul> <li>OWASP Application Security Verification Standard Level 1</li> <li>OWASP Mobile Application Security Verification Standard Level 1</li> </ul> in all applications provides a good baseline.
Implementation Application Hardening Full Coverage of App. Hardening Level 3 4 Following frameworks like the <ul> <li>OWASP Application Security Verification Standard Level 3</li> <li>OWASP Mobile Application Security Verification Standard Maturity Requirements</li> </ul> and gain around 95% coverage of both.
Implementation Development and Source Control Local development linting & style checks performed 4 Integration of quality and linting plugins with interactive development environment (IDEs).
Implementation Development and Source Control Pre-Commit checks and validations 2 Implement pre-commit validations to prevent secrets & other security issues being commit to source code.
Implementation Development and Source Control Source Control Protection 1 Enabled protections on the source code management system preventing committed directly to an important branch.
Implementation Development and Source Control Versioning 1 versioning of artifacts related to production environments. For example Jenkins configuration, docker images, (system provisioning) code.
Implementation Infrastructure Hardening 2FA 2 Two factor authentication for all privileged accounts on systems and applications
Implementation Infrastructure Hardening Applications are running in virtualized environments 2 Applications are running in a dedicated and isolated virtualized environments.
Implementation Infrastructure Hardening Backup 2 Performing automated periodical backups are used. Backup before deployment can help facilitate deployments whilst testing the backup restore processes.
Implementation Infrastructure Hardening Checking the sources of used libraries 2 Each libraries source is checked to have a trusted source.
Implementation Infrastructure Hardening Filter outgoing traffic 2 Having a whitelist and explicitly allowing egress traffic provides the ability to stop unauthorized data leakage.
Implementation Infrastructure Hardening Immutable Infrastructure 3 Redundancies in the IT systems
Implementation Infrastructure Hardening Infrastructure as Code 3 Systems are setup by code. A full environment can be provisioned. In addition, software like Jenkins 2 can be setup and configured in in code too. The code should be stored in a version control system.
Implementation Infrastructure Hardening Isolated networks for virtual environments 1 The communication between virtual environments is controlled and regulated.
Implementation Infrastructure Hardening Limitation of system calls in virtual environments 4 System calls in virtual environments like docker are audited and limited.
Implementation Infrastructure Hardening Microservice-Architecture 4 A microservice-architecture helps to have small components, which are more easy to test.
Implementation Infrastructure Hardening Production near environments are used by developers 4 Usage of infrastructure as code helps to create a production near environment. The developer needs to be trained in order to setup a local development environment. In addition, it should be possible to create production like test data. Often personal identifiable information is anonymized in order to comply with data protection laws.
Implementation Infrastructure Hardening Role based authentication and authorization 3 The usage of a (role based) access control helps to restrict system access to authorized users.
Implementation Infrastructure Hardening Simple access control for systems 1 All internal systems are using simple authentication
Implementation Infrastructure Hardening The environment is hardened 2 Harden cluster environments according to best practices. Level 1 and partially level 2 from hardening practices like 'CIS Kubernetes Bench for Security' should considered.
Implementation Infrastructure Hardening Usage of a chaos monkey 4 A randomized periodically shutdown of systems makes sure, that nobody will perform manual changes to a system.
Implementation Infrastructure Hardening Usage of an security account 2 Usage of a seperate account dedicated for security activities.
Implementation Infrastructure Hardening Usage of edge encryption at transit 1 By using encryption at the edge of traffic in transit, it is impossible or at least harder to sniff credentials beeing outside of the organization.
Implementation Infrastructure Hardening Usage of encryption at rest 1 By using encryption at trdt, it is impossible or at least harder to to read information.
Implementation Infrastructure Hardening Usage of internal encryption at tansit 2 By using encryption internally, e.g. inside of a cluster, it is impossible or at least harder to sniff credentials.
Implementation Infrastructure Hardening Usage of security by default for components 2 Hardening of components is important, specially for image on which other teams base on. Hardening should be performed on the operation system and on the services inside (e.g. Nginx or a Java-Application).
Implementation Infrastructure Hardening Usage of test and production environments 1 A production and a production like environment is used
Implementation Infrastructure Hardening Virtual environments are limited 2 All virtual environments are using resource limits on hard disks, memory and CPU
Information Gathering Logging Centralized application logging 3 A centralized logging system is used and applications logs (including application exceptions) are shipped to it.
Information Gathering Logging Centralized system logging 1 By using centralized logging logs are protected against unauthorized modification.
Information Gathering Logging Correlation of security events 4 Events are correlated on one system. For example the correlation and visualization of failed login attempts combined with successful login attempts.
Information Gathering Logging Logging of security events 1 Security-relevant events like login/logout or creation, change, deletion of users should be logged.
Information Gathering Logging PII logging concept 1 A concept how to log PII is documented and applied.
Information Gathering Logging Visualized logging 2 Protocols are visualized in a simple to use real time monitoring system. The GUI gives the ability to search for special attributes in the protocol.
Information Gathering Monitoring Advanced availability and stability metrics 3 Advanced metrics are gathered in relation to availability and stability. For example unplanned downtime's per year.
Information Gathering Monitoring Advanced webapplication metrics 3 All defects from the dimension Test- and Verification are instrumented.
Information Gathering Monitoring Alerting 2 Thresholds for metrics are set. In case the thresholds are reached, alarms are send out. Which should get attention due to the critically.
Information Gathering Monitoring Coverage and control metrics 4 Usage of Coverage- and control-metrics to show the effectiveness of the security program. Coverage is the degree in which a specific security control for a specific target group is applied with all resources. The control degree shows the actual application of security standards and security-guidelines. Examples are gathering information on anti-virus, anti-rootkits, patch management, server configuration and vulnerability management.
Information Gathering Monitoring Deactivation of unused metrics 3 Deactivation of unused metrics helps to free resources.
Information Gathering Monitoring Defense metrics 4 Gathering of defense metrics like TCP/UDP sources enables to assume the geographic location of the request. Assuming a Kubernetes cluster with an egress-traffic filter (e.g. IP/domain based), an alert might be send out in case of every violation. For ingress-traffic, alerting might not even be considered.
Information Gathering Monitoring Grouping of metrics 3 Meaningful grouping of metrics helps to speed up analysis.
Information Gathering Monitoring Metrics are combined with tests 4 Metrics during tests helps to identify programming errors.
Information Gathering Monitoring Monitoring of costs 2 Implement cost budgets
Information Gathering Monitoring Screens with metric visualization 4 By having an internal accessible screen with a security related dashboards helps to visualize incidents.
Information Gathering Monitoring Simple application metrics 1 Gathering of application metrics helps to identify incidents like brute force attacks, login/logout.
Information Gathering Monitoring Simple budget metrics 1 Cloud providers often provide insight into budgets. A threshold and alarming for the budget is set.
Information Gathering Monitoring Simple system metrics 1 Gathering of system metrics helps to identify incidents and specially bottlenecks like in CPU usage, memory usage and hard disk usage.
Information Gathering Monitoring Targeted alerting 3 By the definition of target groups for incidents people are only getting alarms for incidents they are in charge for.
Information Gathering Monitoring Visualized metrics 2 Metrics are visualized in real time in a user friendly way.
Test and Verification Application tests High coverage of security related module and integration tests 4 Implementation of security related tests via unit tests and integration tests. Including the test of libraries, in case the are not tested already.
Test and Verification Application tests Security integration tests for important components 3 Implementation of essential security related integration tests. For example for authentication and authorization.
Test and Verification Application tests Security unit tests for important components 2 Usage of unit tests to test important security related features like authentication and authorization.
Test and Verification Application tests Smoke Test 4 Integration tests are performed against the production environment after each deployment.
Test and Verification Consolidation Advanced visualization of defects 4 Findings are visualized per component/project/team.
Test and Verification Consolidation Definition of quality gates 1 Quality gates for found vulnerabilities are defined. In the beginning it is important to not overload the security analyst, therefore the recommendation is to start with alerting of high critical vulnerabilities.
Test and Verification Consolidation Integration of vulnerability issues into the development process 3 Vulnerabilities are tracked in the teams issue system (e.g. jira).
Test and Verification Consolidation Reproducible defect tickets 4 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.
Test and Verification Consolidation Simple false positive treatment 1 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.
Test and Verification Consolidation Simple visualization of defects 2 Vulnerabilities are simple visualized.
Test and Verification Consolidation Treatment of all defects 4 All vulnerabilities are added to the quality gate.
Test and Verification Consolidation Treatment of defects with severity high or higher 1 Vulnerabilities with severity high or higher are added to the quality gate.
Test and Verification Consolidation Treatment of defects with severity middle 3 Vulnerabilities with severity middle are added to the quality gate.
Test and Verification Consolidation Usage of a vulnerability management system 3 Aggregation of vulnerabilities in one tool reduce the workload to mark false positives.
Test and Verification Dynamic depth for applications Coverage analysis 4 Check that there are no missing paths in the application with coverage-tools.
Test and Verification Dynamic depth for applications Coverage of client side dynamic components 2 Usage of a spider which executes dynamic content like JavaScript, e.g. via Selenium.
Test and Verification Dynamic depth for applications Coverage of hidden endpoints 3 Hidden endpoints are getting detected and included in the vulnerability scan.
Test and Verification Dynamic depth for applications Coverage of more input vectors 3 Special parameter and special encodings are defined, so that they get fuzzed by the used vulnerability scanners.
Test and Verification Dynamic depth for applications Coverage of sequential operations 3 Sequential operations are defined and checked by the vulnerability scanner in the defined order.
Test and Verification Dynamic depth for applications Coverage of service to service communication 4 Service to service communication is dumped and checked.
Test and Verification Dynamic depth for applications Simple Scan 1 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.
Test and Verification Dynamic depth for applications Usage of different roles 2 Integration of authentication with all roles used in the service.
Test and Verification Dynamic depth for applications Usage of multiple scanners 3 Usage of multiple spiders and scanner enhance the coverage and the vulnerabilities.
Test and Verification Dynamic depth for infrastructure Load tests 4 Load test against the production system or a production near system is performed.
Test and Verification Dynamic depth for infrastructure Test for exposed services 1 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 portscans based o the result.
Test and Verification Dynamic depth for infrastructure Test for unused Resources 4 Test for unused resources helps to identify unused resources.
Test and Verification Dynamic depth for infrastructure Test network segmentation 2 Cluster internal test needs to be performed. Integration of fine granulated network segmentation (also between pods in the same namespace).
Test and Verification Dynamic depth for infrastructure Test of the configuration of cloud environments 2 With the help of tools the configuration of virtual environments are tested.
Test and Verification Dynamic depth for infrastructure Weak password test 3 Automatic brute force attacks are performed. Specially the usage of standard accounts like 'admin' and employee user-ids is recommended.
Test and Verification Static depth for applications Exclusion of source code duplicates 4 Automatic Detection and manual removal of duplicates in source code.
Test and Verification Static depth for applications Local development security checks performed 2 Integration of quality and linting plugins with interactive development environment (IDEs).
Test and Verification Static depth for applications Static analysis for all components/libraries 4 Usage of a static analysis for all used components.
Test and Verification Static depth for applications Static analysis for all self written components 4 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.
Test and Verification Static depth for applications Static analysis for important client side components 3 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.
Test and Verification Static depth for applications Static analysis for important server side components 2 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.
Test and Verification Static depth for applications Stylistic analysis 4 Analysis of compliance to style guides of the source code ensures that source code indenting rules are met.
Test and Verification Static depth for applications Test of client side components with known vulnerabilities 3 Tests for known vulnerabilities in components of the frontend are performed.
Test and Verification Static depth for applications Test of server side components with known vulnerabilities 1 Tests for known vulnerabilities in server side components (e.g. backend/middleware) are performed.
Test and Verification Static depth for applications Usage of multiple analyzers 4 Usage of multiple static tools to find more vulnerabilities.
Test and Verification Static depth for infrastructure Analyze logs 3 Check logs for keywords.
Test and Verification Static depth for infrastructure Check for image lifetime 2 Check the image age of containers in production.
Test and Verification Static depth for infrastructure Check for known vulnerabilities 4 Check for known vulnerabilities
Test and Verification Static depth for infrastructure Check for malware 3 Check for malware in components (e.g. container images, VM baseline images, libraries).
Test and Verification Static depth for infrastructure Check for new image version 3 Check for new images of containers in production.
Test and Verification Static depth for infrastructure Correlate known vulnerabilities in infrastructure with new image versions 4 TODO
Test and Verification Static depth for infrastructure Stored Secrets 1 Test for secrets in code, container images and history
Test and Verification Static depth for infrastructure Test cluster deployment resources 2 Test the deployment configuration for virtualized environments for unsecured configurations.
Test and Verification Static depth for infrastructure Test of infrastructure components for known vulnerabilities 4 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'.
Test and Verification Static depth for infrastructure Test of virtualized environments 2 Test virtualized environments for unsecured configurations.
Test and Verification Static depth for infrastructure Test the cloud configuration 2 With the help of tools, the configuration of virtual environments are tested.
Test and Verification Static depth for infrastructure Test the definition of virtualized environments 2 Test the definition of virtualized environments for unsecured configurations.
Test and Verification Test-Intensity Creation and application of a testing concept 3 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.
Test and Verification Test-Intensity Deactivating of unneeded tests 2 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.
Test and Verification Test-Intensity Default settings for intensity 1 The intensity of the used tools are not modified to safe time.
Test and Verification Test-Intensity High test intensity 1 A deep scan with high test intensity and a low confidence threshold is performed.
Test and Verification Test-Intensity Regular tests 2 On each push and/or at given intervals automatic security tests are performed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment