{ "standard": "OWASP DevSecOps Verification Standard", "abbreviation": "DSOVS", "version": "1.2.0", "source": "data/controls/*.yaml", "generator": "scripts/generate_json.py", "phases": [ "Organisation", "Requirements", "Design", "Code/Build", "Test", "Release/Deploy", "Operate/Monitor" ], "control_count": 39, "controls": [ { "id": "DSOVS-ORG-001", "code": "ORG-001", "title": "Risk Assessment", "phase": "Organisation", "slug": "ORG-001-Risk-Assessment", "status": "complete", "type": "process", "summary": "Risk assessment is a process of analyzing the risks associated with an organization, project, system or business process that could have an impact on its success.\n\nIt is an important part of DevSecOps because it helps identify any potential vulnerabilities or threats that may affect the security and performance of the system or process.\n\nRisk assessment enables organizations to develop better security practices, prioritize remediation efforts, and proactively address potential risks before they become problems.", "doc_url": "https://github.com/OWASP/www-project-devsecops-verification-standard/blob/main/document/ORG-001-Risk-Assessment.md", "levels": [ { "level": 0, "title": "No risk assessment activities performed", "description": "There is no evidence that the organisation performs any form of risk assessment across its projects, systems, or business processes. Potential vulnerabilities and threats are neither identified nor analysed, so decisions about features and architecture are made without any structured understanding of the security risks they introduce. As a result, the organisation cannot prioritise remediation effort or anticipate problems before they materialise.", "evidence": [] }, { "level": 1, "title": "Verify that risk assessment exercise is performed on request", "description": "Risk assessment is carried out only on an ad-hoc basis, typically in response to a specific request, a notable incident, or a particular concern raised by a stakeholder. While these exercises can surface useful insights, they are reactive and inconsistent, and there is no guarantee that every feature or change receives the same scrutiny. Because the activity depends on someone asking for it, significant risks can go unexamined whenever a request is not made.", "evidence": [ "At least one completed risk assessment report exists with an associated request or ticket that triggered it.", "The report documents identified threats, their likelihood and impact, and resulting prioritisation.", "Interview with stakeholders confirms how a risk assessment is requested and who performs it." ], "diagram": "graph LR; Stakeholder-- on request -->Risk-Assessment-- findings -->Prioritised-Backlog;" }, { "level": 2, "title": "Verify that security subject matter expert within software development team performs risk assessment on each feature", "description": "A security subject matter expert embedded within the software development team assesses the risk of each feature as it is designed and built. This brings security analysis directly into the development workflow, allowing threats and vulnerabilities to be considered consistently for every change rather than only when prompted. The expert's involvement helps the team weigh design decisions against their security implications early, so that remediation can be prioritised before features are released.", "evidence": [ "A named security SME is identified within the development team and their role is documented.", "Feature tickets or design records show a completed risk assessment attached to each feature.", "A repeatable risk assessment template or methodology is defined and applied per feature.", "Interview with the team confirms the SME reviews every feature before release." ], "diagram": "graph LR; Each-Feature-- assessed by -->Security-SME-- risk profile -->Prioritised-Backlog;" }, { "level": 3, "title": "Verify that periodic review schedule is defined for the development team to review the risk profile.", "description": "In addition to assessing individual features, the development team follows a defined, periodic schedule to review the overall risk profile and keep it current as the system, its dependencies, and the threat landscape evolve. Each review revisits previously accepted risks and confirms whether earlier decisions remain valid. Risk decisions are recorded and tracked over time, giving the organisation a clear, auditable view of how its risk posture is changing and where attention is needed next.", "evidence": [ "A documented review schedule (e.g. calendar invites or policy) defines how often the risk profile is reviewed.", "A maintained risk register shows risk decisions recorded and tracked over time, including revisited accepted risks.", "Minutes or records from at least one periodic review demonstrate the schedule is followed.", "Audit trail links changes in the risk posture to specific review cycles." ], "diagram": "graph LR; Each-Feature-- assessed by -->Security-SME-- risk profile -->Prioritised-Backlog; Periodic-Review-- revisits -->Risk-Profile-- keeps current -->Prioritised-Backlog;" } ], "further_reading": [ { "url": "https://evaluator.tidyrisk.org/", "note": "Risk assessment tool." }, { "url": "https://csrc.nist.gov/Projects/ssdf", "note": "NIST Secure Software Development Framework (SSDF), a set of fundamental, sound, and secure software development practices based on established secure software development practice documents from organizations such as BSA, OWASP, and SAFECode." }, { "url": "https://www.synopsys.com/blogs/software-security/software-risk-analysis/", "note": "Synopsys - A practitioner-oriented overview of software risk analysis that explains how to identify, assess, and prioritise security risks throughout the software development life cycle." }, { "url": "https://owasp.org/www-community/OWASP_Risk_Rating_Methodology", "note": "OWASP Risk Rating Methodology - A structured approach for estimating the severity of security risks by scoring the likelihood and impact of each issue, helping teams rank and prioritise remediation consistently." } ], "mappings": { "owasp_samm": [ "Governance > Risk Profile", "Design > Threat Assessment" ], "owasp_asvs": [ "V1 Architecture, Design and Threat Modeling" ], "nist_ssdf": [ "PO.1 Define Security Requirements for Software Development", "PW.1 Design Software to Meet Security Requirements and Mitigate Security Risks" ], "iso_27001": [ "Clause 6.1.2 Information security risk assessment", "A.8.8 Management of technical vulnerabilities" ] } }, { "id": "DSOVS-ORG-002", "code": "ORG-002", "title": "Security Training", "phase": "Organisation", "slug": "ORG-002-Security-Training", "status": "complete", "type": "process", "summary": "The security training capability is focused on establishing a plan that can be measured and scale as the software project teams grow. The main objective is to foster continuous learning culture in which organisation will require invest personnel time to attend the training. The effectiveness of the training must be measurable and tailored to specific role of the personnel involved in the software lifecycle.", "doc_url": "https://github.com/OWASP/www-project-devsecops-verification-standard/blob/main/document/ORG-002-Security-Training.md", "levels": [ { "level": 0, "title": "No security training plan", "description": "There is no evident of formal training plan in the organisation for application security. The organisation does not provide sufficient investment in both personnel's time and training materials, either through instructor-led sessions or computer-based modules.", "evidence": [] }, { "level": 1, "title": "Verify at ad-hoc security training is conducted for all roles associated to development team members, operational support and end-users", "description": "There are some irregular application security training run within the organisation for the software project team. Although the training delivery can be instructor-led sessions or computer-based modules, there is no evident that training modules is tailored to personnel's role nor measured as individual KPI.", "evidence": [ "Records or attendance logs exist for at least one delivered security training session.", "Training materials (slides, recordings, or module links) are available and cover application security topics.", "Interview with staff confirms training has been offered to development, operations, and end-user roles." ] }, { "level": 2, "title": "Verify that scheduled repeatable role specific security training is conducted for development team members, operational support, and end-users", "description": "There is planned time schedule for personnel training that tailored to personnel specific roles. Although the training is run in regular set time basis there is no evident that the application security training is measured towards KPI or individual training goals.", "evidence": [ "A documented, recurring training schedule exists that maps modules to specific roles.", "Role-specific curricula or training paths are defined for developers, operational support, and end-users.", "Attendance records across multiple cycles show the schedule is repeatedly followed.", "Interview confirms training content differs by role." ] }, { "level": 3, "title": "Verify that security training is scheduled and measured as part of individual training plan or KPI", "description": "The application security training is tailored to personnel's role and measured towards individual KPI within the organisation. The training effectiveness is continuously measured and improved by organisation to align with organisation's risk appetite, application vulnerabilities and personnel career goals.", "evidence": [ "Individual training plans or KPIs include security training objectives and completion targets.", "Assessment or test results are captured to measure training effectiveness per individual.", "Metrics show training outcomes being reviewed and the programme adjusted over time (e.g. linked to vulnerability trends).", "Performance review records reference security training completion and outcomes." ] } ], "further_reading": [ { "url": "https://owaspsamm.org/model/governance/education-and-guidance/", "note": "OWASP SAMM - Education & Guidance governance practice." } ], "mappings": { "owasp_samm": [ "Governance > Education & Guidance" ], "nist_ssdf": [ "PO.2 Implement Roles and Responsibilities", "PO.3 Implement Supporting Toolchains" ], "iso_27001": [ "A.6.3 Information security awareness, education and training" ] } }, { "id": "DSOVS-ORG-003", "code": "ORG-003", "title": "Security Champion", "phase": "Organisation", "slug": "ORG-003-Security-Champion", "status": "complete", "type": "process", "summary": "A security champion is a person or team whose role within an organization is to promote and implement security practices.\n\nThey are responsible for ensuring that security is considered throughout the development and deployment process of products, services and applications.\n\nSecurity champions play an important role in DevSecOps as they work to ensure that security is integrated into DevOps processes and tools, helping organizations achieve their security goals.\n\nThey also serve as a bridge between security and DevOps teams, communicating the importance of security and advocating for its inclusion.\n\nSecurity champions help ensure that an organization's DevSecOps initiatives are effective, driving real results.", "doc_url": "https://github.com/OWASP/www-project-devsecops-verification-standard/blob/main/document/ORG-003-Security-Champion.md", "levels": [ { "level": 0, "title": "No application security capability in the organisation", "description": "The organisation has no recognised application security capability and no individuals tasked with advocating for secure development practices. Security knowledge is not consciously cultivated within the engineering teams, and there is no point of contact who can answer security questions or guide design and implementation decisions. As a result, security considerations depend entirely on the incidental experience of individual developers rather than any deliberate organisational function.", "evidence": [] }, { "level": 1, "title": "Verify that the centralised application security function or capability exists to provide subject matter expertise", "description": "A central application security function or team has been established to provide subject matter expertise to the wider organisation. Development teams can reach out to this group for guidance on threats, secure design, and remediation, which gives the organisation a consistent and authoritative source of security knowledge. While this represents a meaningful improvement over having no capability at all, the expertise remains concentrated in a single team and is delivered on request, so coverage across individual development teams is uneven and reactive rather than embedded in day-to-day delivery.", "evidence": [ "An organisation chart or charter documents a central application security team and its remit.", "A defined intake channel (e.g. ticket queue, mailbox, or chat channel) exists for teams to request security guidance.", "Records show at least several guidance requests handled by the central team." ], "diagram": "graph LR; Development-Team-- requests guidance -->Central-AppSec-Team;" }, { "level": 2, "title": "Verify that a dedicated security champion appointed to work within each development team", "description": "The organisation has moved security expertise closer to where software is built by appointing a dedicated security champion within each development team. These champions are embedded developers who advocate for security inside their own teams, act as the first point of contact for security questions, and create a direct link back to the central application security function. Because every team now has a named individual responsible for promoting secure practices, security guidance is applied more consistently and earlier in the lifecycle, and issues are increasingly identified by the teams themselves rather than only during centralised review.", "evidence": [ "A register names a security champion for each development team.", "The champion role has a documented job description or responsibilities.", "Records show champions liaising with the central AppSec team (e.g. meeting notes, shared channels).", "Interview with a champion confirms they act as the first point of contact for security in their team." ], "diagram": "graph LR; Development-Team-- includes -->Security-Champion-- liaises with -->Central-AppSec-Team;" }, { "level": 3, "title": "Verify that the multiple security subject matter experts can be the champion within the development team", "description": "Security expertise has matured to the point where multiple subject matter experts within a team are capable of acting as the security champion, removing reliance on any single person. The champion role is supported, rotated, and measured, with the organisation actively developing the depth of its security talent and tracking the effectiveness of the programme. This redundancy and ongoing investment make the security champion capability resilient and continuously improving, allowing the organisation to scale secure development practices as teams grow and to refine the programme in line with its evolving risk profile.", "evidence": [ "The champion register shows multiple qualified champions per team and a documented rotation schedule.", "Programme metrics (e.g. issues raised by champions, training completed) are tracked and reviewed.", "A documented support or enablement plan exists for developing champion capability.", "Evidence shows the programme being refined over time in line with the organisation's risk profile." ], "diagram": "graph LR; Development-Team-- includes -->Champion-A & Champion-B-- rotated and measured -->Central-AppSec-Team;" } ], "further_reading": [ { "url": "https://owasp.org/www-project-security-culture/", "note": "OWASP Security Culture Project - Guidance on building a security culture, including how to establish and run a security champions programme." }, { "url": "https://github.com/c0rdis/security-champions-playbook", "note": "OWASP Security Champions Playbook - A practical, step-by-step playbook for identifying, nominating, and supporting security champions within development teams." }, { "url": "https://owaspsamm.org/model/governance/education-and-guidance/", "note": "OWASP SAMM - Education & Guidance - The SAMM governance practice covering how organisations grow security knowledge and embedded expertise such as champions." } ], "mappings": { "owasp_samm": [ "Governance > Education & Guidance" ], "nist_ssdf": [ "PO.2 Implement Roles and Responsibilities" ], "iso_27001": [ "A.5.2 Information security roles and responsibilities", "A.6.3 Information security awareness, education and training" ] } }, { "id": "DSOVS-ORG-004", "code": "ORG-004", "title": "Security Reporting", "phase": "Organisation", "slug": "ORG-004-Security-Reporting", "status": "complete", "type": "process", "summary": "Security reporting is the ongoing process of collecting and analyzing data regarding security-related activities within an organization.\n\nIt's an important part of DevSecOps because it provides organizations with key insights into their security posture, enables decision makers to more accurately identify and assess existing and potential threats, and helps organizations respond to cybersecurity incidents quickly and appropriately.\n\nSecurity reporting also helps organizations develop better security policies, practices and procedures, as well as ensure compliance with data protection and other legal and regulatory requirements.", "doc_url": "https://github.com/OWASP/www-project-devsecops-verification-standard/blob/main/document/ORG-004-Security-Reporting.md", "levels": [ { "level": 0, "title": "Security findings is segregated in many systems and tools", "description": "Security findings are scattered across numerous disconnected systems and tools, with each scanner, tracker, or assessment maintaining its own isolated view. There is no consolidated reporting, so leadership has no coherent picture of the organisation's security posture and cannot reliably understand where risk concentrates. Because the data is fragmented and never brought together, trends go unnoticed, duplicate issues are common, and decisions about prioritisation and investment are made without an accurate evidence base.", "evidence": [] }, { "level": 1, "title": "Verify that security findings from multiple sources are manually collated to a single report", "description": "Findings from the various sources are manually gathered and combined into a single report, giving the organisation its first unified view of security issues. This collation is typically performed periodically by individuals who export, deduplicate, and summarise results by hand, which makes it possible to communicate an overall position to stakeholders. The process is labour-intensive and prone to inconsistency and delay, so while it is a clear improvement over completely siloed data, the report quickly becomes stale and its accuracy depends heavily on the diligence of whoever assembles it.", "evidence": [ "A consolidated security report exists that combines findings from multiple sources into a single document.", "The report identifies its source systems and the date it was assembled.", "Interview confirms who produces the report, on what cadence, and how findings are deduplicated." ], "diagram": "graph LR; Source-A & Source-B-- manually collated -->Single-Report-- reported to -->Leadership;" }, { "level": 2, "title": "Verify that security findings from multiple sources are periodically populated to a centralised dashboard", "description": "Findings from multiple sources are now fed into a centralised dashboard on a regular, repeatable basis, replacing manual report assembly with a defined and consistent process. Leadership and delivery teams can view a common, up-to-date representation of findings, severities, and ownership, which supports more reliable prioritisation and clearer accountability. Because the dashboard is populated on a schedule rather than continuously, the information still lags behind reality between refresh cycles, but the consistency and shared visibility represent a substantial step beyond hand-built reports.", "evidence": [ "A centralised dashboard exists that aggregates findings from multiple sources with severity and ownership.", "Configuration or job definitions show the dashboard is populated on a defined schedule.", "Refresh logs or timestamps demonstrate the dashboard is updated at the documented frequency." ], "diagram": "graph LR; Source-A & Source-B-- periodically populated -->Centralised-Dashboard-- reported to -->Leadership;" }, { "level": 3, "title": "Verify that the centralised dashboard represents real-time data capture and representation", "description": "The centralised dashboard captures and represents data in real time, so the organisation's security posture is reflected as findings are discovered, triaged, and resolved. Leadership has continuous visibility into key metrics, KPIs, trends, and emerging risk, enabling timely, data-driven decisions and meaningful tracking of improvement over time. With reporting measured and continuously refined, the organisation can detect changes in its risk profile quickly, validate the effectiveness of its security efforts, and align investment with the areas of greatest exposure.", "evidence": [ "Source systems integrate with the dashboard via APIs or streaming so findings appear without a scheduled batch.", "The dashboard displays live KPIs, trends, and metrics that update as findings change state.", "Metrics history shows posture trends being tracked over time and used in leadership decision making." ], "diagram": "graph LR; Source-A & Source-B-- real-time capture -->Centralised-Dashboard-- live metrics and KPIs -->Leadership;" } ], "further_reading": [ { "url": "https://owaspsamm.org/", "note": "The Software Assurance Maturity Model, including the metrics and measurement practices that underpin meaningful security reporting." }, { "url": "https://owasp.org/www-project-devsecops-maturity-model/", "note": "A maturity model that describes how to measure and improve security activities across the DevSecOps lifecycle." }, { "url": "https://csrc.nist.gov/projects/ssdf", "note": "Guidance on the practices and outcomes that security reporting and metrics should help organisations demonstrate." } ], "mappings": { "owasp_samm": [ "Governance > Metrics & Reporting" ], "nist_ssdf": [ "RV.3 Analyze Vulnerabilities to Identify Their Root Causes", "PO.4 Implement and Maintain Secure Development Practices" ], "iso_27001": [ "A.5.36 Compliance with policies, rules and standards for information security", "A.8.16 Monitoring activities" ] } }, { "id": "DSOVS-REQ-001", "code": "REQ-001", "title": "Security Policy and Regulatory Compliance", "phase": "Requirements", "slug": "REQ-001-Security-Policy-and-Regulatory-Compliance", "status": "complete", "type": "process", "summary": "Security Policy and Regulatory Compliance is concerned with identifying the laws, regulations, and contractual obligations that apply to a software project and translating them into security policy the project must meet. Obligations such as GDPR, PCI DSS, and HIPAA impose specific requirements depending on the data an application handles and the markets it operates in.\n\nThe objective is to establish a clear baseline of what the organisation is required to do, verify that those obligations are being met, and keep that view current as regulations and business commitments change.\n\nDevSecOps is an approach to software development that incorporates security into design and delivery while enabling automation and efficient maintenance. This makes security policy and regulatory compliance an integral part of DevSecOps, as it helps organisations meet their obligations continuously rather than treating compliance as a periodic, after-the-fact exercise.", "doc_url": "https://github.com/OWASP/www-project-devsecops-verification-standard/blob/main/document/REQ-001-Security-Policy-and-Regulatory-Compliance.md", "levels": [ { "level": 0, "title": "No periodic compliance verification activities performed", "description": "The organisation has not identified which laws, regulations, or contractual obligations apply to the project, and there is no process to verify that these obligations are being met. Requirements such as GDPR, PCI DSS, or HIPAA may be relevant to the data the application handles, but no one has formally mapped them to the work being delivered. Any awareness of compliance tends to be incidental, residing in the knowledge of individual team members rather than in a repeatable activity.\n\nAs a result, the project cannot demonstrate whether it satisfies its regulatory or contractual duties. Gaps surface only reactively, typically during an external audit, a customer security review, or after an incident has already occurred.", "evidence": [] }, { "level": 1, "title": "Verify that periodic compliance audit is performed and documented", "description": "The organisation has identified the applicable laws, regulations, and contractual obligations and has documented them, and a compliance audit is carried out on a periodic basis with its results recorded. This establishes a known baseline: the project can point to a written set of obligations and to evidence that it has been checked against them at least once in recent memory.\n\nAt this level the activity is still largely manual and informal. Audits may be triggered by a calendar reminder or an upcoming deadline rather than embedded in the way the project is run, and the translation of obligations into concrete security policy may be inconsistent. Nevertheless, the documentation provides a foundation that later levels build upon.", "evidence": [ "A documented register of applicable laws, regulations, and contractual obligations (e.g. GDPR, PCI DSS, HIPAA) exists for the project.", "A dated compliance audit report records the results of checking the project against those obligations.", "Interview confirms the cadence on which the audit is performed and who is responsible for it." ], "diagram": "graph LR; Regulations-- documented in -->Security-Policy-- periodic audit -->Compliance-Baseline;" }, { "level": 2, "title": "Verify implementation of real-time compliance verification and the findings are automatically recorded to a centralised issue tracker system", "description": "Compliance verification is integrated into the software development lifecycle rather than performed as a stand-alone exercise. Applicable obligations have been translated into explicit security policy that the project is expected to meet, and adherence is checked continuously as changes are made, so that deviations are surfaced close to the point at which they are introduced.\n\nFindings are routed into a centralised issue tracker so that compliance gaps are managed alongside other engineering work, with clear ownership and traceability. This consistent, integrated approach means that compliance is treated as a routine property of delivery rather than an event, and the project can show an ongoing record of how it has met its obligations.", "evidence": [ "Obligations are translated into explicit security policy or policy-as-code checked within the SDLC.", "Pipeline or tooling configuration shows compliance verification runs automatically on changes.", "Compliance findings are automatically raised as tickets in a centralised issue tracker with ownership and traceability." ], "diagram": "graph LR; Regulations-- mapped to -->Security-Policy-- verified in -->SDLC-- findings -->Centralised-Issue-Tracker;" }, { "level": 3, "title": "Verify that compliance status is enforced and periodic review schedule is defined", "description": "Compliance status is actively enforced and is governed by a defined periodic review schedule. The organisation does not merely detect deviations but maintains controls that keep the project within its policy boundaries, and the set of applicable obligations is revisited on a regular cadence so that new regulations, contractual changes, or shifts in the threat landscape are reflected in policy promptly.\n\nAt this level the effectiveness of the compliance programme itself is measured and improved. Metrics such as the time taken to remediate findings, recurrence rates, and audit outcomes are tracked over time and used to refine the controls and the policy. Compliance thereby becomes a continuously improving capability that is aligned with the organisation's risk appetite rather than a static checklist.", "evidence": [ "Enforcement controls (e.g. blocking gates or guardrails) prevent non-compliant changes from progressing.", "A documented periodic review schedule exists for revisiting applicable obligations and updating policy.", "Metrics such as remediation time, recurrence rate, and audit outcomes are tracked and used to refine controls." ], "diagram": "graph LR; Regulations-- enforced via -->Security-Policy-- measured by -->Metrics-- scheduled review -->Security-Policy;" } ], "further_reading": [ { "url": "https://csrc.nist.gov/projects/ssdf", "note": "Practices such as PO (Prepare the Organization) cover defining security requirements and meeting regulatory expectations across the lifecycle." }, { "url": "https://owaspsamm.org/model/governance/policy-and-compliance/", "note": "The Governance practice that this control aligns to, describing maturity in identifying obligations and verifying compliance." }, { "url": "https://www.nist.gov/privacy-framework", "note": "A structure for mapping data protection obligations (such as those arising from GDPR) into organisational policy and controls." }, { "url": "https://www.pcisecuritystandards.org/document_library/", "note": "Authoritative source for the PCI DSS requirements that apply to systems handling cardholder data." }, { "url": "https://www.hhs.gov/hipaa/for-professionals/security/index.html", "note": "Reference for the safeguards required when handling protected health information." } ], "mappings": { "owasp_samm": [ "Governance > Policy & Compliance" ], "owasp_asvs": [ "V1 Encoding and Sanitization" ], "nist_ssdf": [ "PO.1 Define Security Requirements for Software Development", "PO.5 Implement and Maintain Secure Environments for Software Development" ], "iso_27001": [ "A.5.31 Legal, statutory, regulatory and contractual requirements", "A.5.36 Compliance with policies, rules and standards for information security" ] } }, { "id": "DSOVS-REQ-002", "code": "REQ-002", "title": "Security Requirements and Standards", "phase": "Requirements", "slug": "REQ-002-Security-Requirements-and-Standards", "status": "complete", "type": "process", "summary": "Application Security Requirements and Standards is concerned with defining concrete, testable security requirements for an application early in its lifecycle and aligning them with recognised industry standards and technology best practices. Frameworks such as the OWASP Application Security Verification Standard (ASVS) and the OWASP Mobile Application Security Verification Standard (MASVS) provide structured, verifiable requirements covering areas such as authentication, access control, data protection, and secure communication.\n\nCapturing these requirements up front, rather than retrofitting controls after the fact, ensures that security expectations are explicit, agreed, and able to be verified during design, development, and testing.\n\nIn a DevSecOps environment, well-defined security requirements and standards play an important role by ensuring that applications are developed securely, deployed safely, and remain aligned with current best practices over time.", "doc_url": "https://github.com/OWASP/www-project-devsecops-verification-standard/blob/main/document/REQ-002-Security-Requirements-and-Standards.md", "levels": [ { "level": 0, "title": "No periodic audit to ensure alignment to industry security standards and technology best-practices", "description": "The project has no defined set of security requirements and makes no reference to recognised industry standards or technology best practices. Security expectations, where they exist at all, are implicit and depend on the individual judgement of whoever happens to be building a given feature. There is no audit or review to confirm that the application aligns with frameworks such as OWASP ASVS or MASVS.\n\nBecause requirements are neither written down nor verified, the team cannot demonstrate which security properties the application is meant to uphold. Weaknesses are typically discovered late, during penetration testing or after an incident, rather than being prevented by clear requirements stated up front.", "evidence": [] }, { "level": 1, "title": "Verify that periodic audit to ensure alignment to industry security standards and technology best-practices is performed", "description": "A set of security requirements has been documented with reference to industry standards, and a periodic audit is performed to check the application's alignment with them. The team can point to an agreed baseline, drawn from sources such as OWASP ASVS, OWASP MASVS, or the OWASP Proactive Controls, and to evidence that this baseline has been reviewed.\n\nAt this level the requirements and the audit remain largely informal and detached from day-to-day delivery. Reviews tend to occur on a schedule or ahead of a release rather than being woven into design and development, so the requirements may lag behind the code and best practices may be applied unevenly across teams.", "evidence": [ "A documented set of security requirements referencing standards such as OWASP ASVS, MASVS, or Proactive Controls exists.", "The documentation records the targeted ASVS or MASVS verification level for the application.", "A dated audit report records the application's alignment against the agreed requirements baseline." ], "diagram": "graph LR; OWASP-ASVS-- documents -->Security-Requirements-- periodic audit -->Alignment-Check;" }, { "level": 2, "title": "Verify that real-time verification to industry security standards and technology best-practices is performed", "description": "Security requirements are consistently applied and verification against industry standards is integrated into the software development lifecycle. Requirements derived from standards such as ASVS and MASVS are treated as first-class acceptance criteria, considered during design and checked continuously as the application evolves rather than only at periodic checkpoints.\n\nThis integration means deviations from the agreed standards are surfaced close to the point at which they are introduced and can be addressed before they reach production. Security requirements thereby become a routine, expected part of how features are built and reviewed, providing an ongoing view of how well the application aligns with best practice.", "evidence": [ "Security requirements appear as acceptance criteria or definition-of-done items in user stories or design artefacts.", "Pipeline configuration shows automated checks that verify requirements against the chosen standard on each change.", "Test or scan results map back to specific ASVS/MASVS requirements, demonstrating continuous verification." ], "diagram": "graph LR; OWASP-ASVS-- defines -->Security-Requirements-- acceptance criteria -->SDLC-- verified by -->Tests;" }, { "level": 3, "title": "Verify that applicable standards and best practices are enforced and periodic review schedule is defined", "description": "The applicable standards and best practices are actively enforced, and a defined periodic review schedule keeps the chosen requirements current. The organisation maintains controls that hold the project to its agreed requirements, and revisits the selected standards and the targeted ASVS or MASVS levels on a regular cadence so that emerging threats, new technologies, and updated guidance are reflected promptly.\n\nAt this level the requirements programme is itself measured and improved. The organisation tracks indicators such as coverage of requirements, the rate at which deviations are found and fixed, and how requirements perform against real findings, and uses these to refine both the requirements and the way they are verified. Security requirements thus become a continuously improving capability aligned with the organisation's risk appetite.", "evidence": [ "Enforcement controls (e.g. blocking gates) prevent changes that violate agreed requirements from progressing.", "A documented periodic review schedule exists for revisiting selected standards and targeted ASVS/MASVS levels.", "Metrics such as requirements coverage, deviation find-and-fix rate, and performance against real findings are tracked and used to refine the requirements." ], "diagram": "graph LR; OWASP-ASVS-- enforced as -->Security-Requirements-- measured by -->Coverage-Metrics-- scheduled review -->OWASP-ASVS;" } ], "further_reading": [ { "url": "https://owasp.org/www-project-application-security-verification-standard/", "note": "A catalogue of testable web application security requirements organised into verification levels, ideal for defining requirements early." }, { "url": "https://mas.owasp.org/MASVS/", "note": "The equivalent standard for mobile applications, providing verifiable security requirements for mobile platforms." }, { "url": "https://owasp.org/www-project-proactive-controls/", "note": "A developer-focused set of the most important security techniques to build into software from the outset." }, { "url": "https://csrc.nist.gov/projects/ssdf", "note": "Includes practices for defining and communicating security requirements throughout the development lifecycle." }, { "url": "https://owaspsamm.org/model/design/security-requirements/", "note": "The SAMM Design practice describing maturity in eliciting and standardising security requirements." } ], "mappings": { "owasp_samm": [ "Design > Security Requirements" ], "owasp_asvs": [ "V1 Encoding and Sanitization" ], "nist_ssdf": [ "PO.1 Define Security Requirements for Software Development", "PW.1 Design Software to Meet Security Requirements and Mitigate Security Risks" ], "iso_27001": [ "A.8.25 Secure development life cycle", "A.8.27 Secure system architecture and engineering principles" ] } }, { "id": "DSOVS-REQ-003", "code": "REQ-003", "title": "Security User Stories and Acceptance Criterias", "phase": "Requirements", "slug": "REQ-003-Security-User-Stories-and-Acceptance-Criteria", "status": "complete", "type": "process", "summary": "Security user stories and acceptance criteria are a way of making sure that security is built into the software development process rather than bolted on afterwards. They translate security requirements into the same language the team already uses to plan and deliver features.\n\nSecurity user stories help developers understand what protective behaviour an application must exhibit, while abuse or misuse cases describe how an attacker might subvert a feature. Acceptance criteria then give both developers and testers a concrete, testable definition of \"done\" for those security needs.\n\nBy capturing security expectations as stories and acceptance criteria, teams can be confident that an application meets a minimum security baseline and that flaws are surfaced and fixed during development rather than after release.\n\nThis is an important part of DevSecOps because it keeps security visible in the backlog, makes it a shared responsibility of the whole team, and helps demonstrate that regulatory and compliance obligations are being met.", "doc_url": "https://github.com/OWASP/www-project-devsecops-verification-standard/blob/main/document/REQ-003-Security-User-Stories-and-Acceptance-Criteria.md", "levels": [ { "level": 0, "title": "No security user stories or abuse stories template defined", "description": "At this level there is no consistent way to capture security requirements as part of feature work. The backlog describes functional behaviour only, and any security considerations depend entirely on the knowledge and initiative of individual developers at the moment they happen to write code.\n\nBecause there is no template for security user stories or abuse cases, the team has no shared starting point for thinking about how a feature could be attacked or misused. Security requirements are therefore frequently overlooked, discovered late, or addressed inconsistently from one feature to the next.", "evidence": [] }, { "level": 1, "title": "Verify that security user stories and abuse stories template are defined and used", "description": "The organisation has created a reusable template for security user stories and abuse or misuse cases, and teams have begun applying it to their work. This gives people a common structure and vocabulary for describing the protections a feature requires and the ways an adversary might attempt to defeat them.\n\nCompared with Level 0, security is now expressed in artefacts that live alongside functional stories instead of relying purely on individual memory. Adoption may still be uneven and the depth of each story can vary, but the team has a deliberate, repeatable mechanism for surfacing security needs early in the requirements stage.", "evidence": [ "A documented security user story and abuse/misuse case template exists and is accessible to the team.", "Sample backlog items show security user stories authored from the template.", "Interview confirms which teams use the template and how it is introduced into requirements work." ], "diagram": "graph LR; Template-- shapes -->Security-User-Story-- captured in -->Backlog;" }, { "level": 2, "title": "Verify that security use or misuse cases are defined as feature's acceptance criteria", "description": "Security expectations are no longer captured only as standalone stories; they are written directly into the acceptance criteria that define when a feature is complete. Each relevant feature carries explicit, testable security conditions describing both the desired protective behaviour and the misuse scenarios that must be prevented.\n\nThis is a meaningful step up from Level 1 because security becomes a non-negotiable part of the definition of done rather than an optional supporting artefact. Developers know what they must build to pass, testers have unambiguous criteria to validate against, and a feature cannot be considered finished until its security acceptance criteria are demonstrably satisfied.", "evidence": [ "Feature tickets contain explicit, testable security acceptance criteria covering protective behaviour and misuse cases.", "The definition of done references security acceptance criteria as a completion gate.", "Test cases or pipeline checks are traceable to the security acceptance criteria of a feature." ], "diagram": "graph LR; Security-User-Story-- defines -->Acceptance-Criteria-- validated by -->Tests-- gate -->Definition-of-Done;" }, { "level": 3, "title": "Verify that periodic review schedule is defined for the development team to review the security user stories template and scope of the acceptance criteria", "description": "The practice is now actively maintained through a defined, recurring review cycle. On a regular cadence the development team revisits the security user story template and the scope of the acceptance criteria to confirm they still reflect current threats, lessons learned from incidents, and changes to the application and its regulatory context.\n\nThis level builds on Level 2 by treating the security requirements process itself as something to be measured and continuously improved rather than left static. Feedback from testing results, vulnerabilities found in production, and evolving attack techniques is fed back into the templates, so the criteria stay relevant and the overall quality of security requirements steadily increases over time.", "evidence": [ "A documented schedule and owner exist for reviewing the security user story template and acceptance criteria scope.", "Review records or changelogs show the template being updated in response to incidents and testing feedback.", "Metrics or retrospectives demonstrate improving coverage and quality of security requirements over time." ], "diagram": "graph LR; Acceptance-Criteria-- validated by -->Tests-- feedback -->Scheduled-Review-- refines -->Template;" } ], "further_reading": [ { "url": "https://owasp.org/www-project-application-security-verification-standard/", "note": "OWASP ASVS provides a catalogue of verifiable security requirements that can be turned directly into security user stories and acceptance criteria." }, { "url": "https://owaspsamm.org/model/design/security-requirements/", "note": "OWASP SAMM Security Requirements practice describes how to build and improve security requirements (including misuse cases) within an agile lifecycle." }, { "url": "https://owasp.org/www-community/Threat_Modeling", "note": "OWASP threat modeling guidance helps teams derive abuse and misuse cases that inform security stories." }, { "url": "https://owasp.org/www-project-proactive-controls/", "note": "OWASP Proactive Controls offers developer-focused security techniques that map well onto concrete acceptance criteria." }, { "url": "https://owasp.org/www-pdf-archive/OWASP_Testing_Guide_v4.pdf", "note": "OWASP Testing Guide describes test approaches that acceptance criteria can reference to verify security behaviour." } ], "mappings": { "owasp_samm": [ "Design > Security Requirements", "Design > Threat Assessment" ], "owasp_asvs": [ "V1 Architecture, Design and Threat Modeling" ], "nist_ssdf": [ "PW.1 Design Software to Meet Security Requirements and Mitigate Security Risks", "PO.1 Define Security Requirements for Software Development" ], "iso_27001": [ "A.8.25 Secure development life cycle", "A.8.26 Application security requirements" ] } }, { "id": "DSOVS-REQ-004", "code": "REQ-004", "title": "Security Issues Tracking", "phase": "Requirements", "slug": "REQ-004-Security-Issues-Tracking", "status": "complete", "type": "process", "summary": "Security issues tracking is focused on making sure that security defects and improvement work are managed with the same rigour and visibility as ordinary functional work. The objective is to ensure that vulnerabilities, weaknesses and remediation tasks are recorded, prioritised and resolved rather than lost or quietly deprioritised.\n\nWhen security issues live in the same backlog and tooling the team already uses, they compete for attention alongside features and bugs, get scheduled in planning sessions, and remain visible to delivery and management. As the capability matures, the organisation moves from simply recording issues to dedicating time to fixing them and, ultimately, to measuring how quickly and how well security work is being completed.", "doc_url": "https://github.com/OWASP/www-project-devsecops-verification-standard/blob/main/document/REQ-004-Security-Issues-Tracking.md", "levels": [ { "level": 0, "title": "Security issues are reported separately from functional backlog", "description": "At this level security issues are captured in a different place from the team's normal functional backlog, for example in spreadsheets, email threads, or standalone reports produced after an assessment. They are disconnected from the day-to-day planning the team actually uses to decide what to work on next.\n\nBecause these issues sit outside the main workflow, they are easily forgotten, rarely prioritised against feature work, and often go unaddressed. There is no single, reliable view of which security problems exist or who is responsible for resolving them.", "evidence": [] }, { "level": 1, "title": "Verify that security issues are tracked in a centralised location and prioritised in the planning session", "description": "Security issues are now recorded in a single, centralised tracking system, ideally the same issue tracker the team uses for functional work, so that nothing is scattered across disconnected reports. This gives the organisation one authoritative place to see what security problems are outstanding.\n\nCrucially, these issues are brought into regular planning sessions and prioritised alongside other work. Compared with Level 0, security defects are no longer invisible to delivery; they are triaged, ranked by risk, and scheduled, which dramatically reduces the chance that important issues are simply lost.", "evidence": [ "Security issues are recorded in a single centralised issue tracker with severity and ownership.", "Planning session notes or board views show security issues being triaged and prioritised alongside functional work.", "Interview confirms there is one authoritative view of outstanding security issues rather than scattered reports." ], "diagram": "graph LR; Security-Issue-- logged in -->Central-Backlog-- prioritised in -->Planning-Session;" }, { "level": 2, "title": "Verify that the pre-allocated time is dedicated to development team work on security remediation or improvements", "description": "Beyond simply tracking and prioritising issues, the team now reserves capacity specifically for security remediation and improvement. A defined portion of each iteration or release cycle is set aside so that fixing vulnerabilities and hardening the application is a planned, expected activity rather than something squeezed in only when time allows.\n\nThis is an advance on Level 1 because prioritisation alone does not guarantee that security work actually gets done when feature pressure is high. By pre-allocating time, the organisation makes a deliberate, sustained commitment to working through the security backlog and prevents remediation from being perpetually deferred.", "evidence": [ "A documented policy or capacity allocation reserves a defined portion of each iteration for security remediation.", "Sprint/iteration plans show security remediation items consistently scheduled within the reserved capacity.", "Interview confirms security work is treated as a planned, expected activity rather than ad-hoc." ], "diagram": "graph LR; Central-Backlog-- prioritised -->Dedicated-Time-- delivers -->Remediation;" }, { "level": 3, "title": "Verify that the security remediation or improvement efforts and speed are continuously monitored and measured", "description": "At the highest level the organisation continuously measures how its security remediation is performing. Metrics such as time to remediate, the age and volume of open issues, and trends in recurring vulnerability types are tracked over time and reviewed to understand whether the process is keeping pace with incoming risk.\n\nBuilding on the dedicated time established at Level 2, these measurements turn remediation into a managed, data-driven activity. The insights feed back into planning and process improvements, allowing the team to set and tune service-level targets, identify bottlenecks, and steadily improve both the speed and the quality of security fixes.", "evidence": [ "Dashboards or reports track remediation metrics such as time-to-remediate, open issue age, and volume over time.", "Documented service-level targets (SLAs/SLOs) for remediation exist and are reviewed against actuals.", "Review records show metrics feeding back into planning and process improvements." ], "diagram": "graph LR; Remediation-- measured by -->Metrics-- feedback -->Planning-Session-- tunes -->Remediation;" } ], "further_reading": [ { "url": "https://github.com/DefectDojo/django-DefectDojo", "note": "OWASP DefectDojo is an open-source vulnerability management platform for centralising, deduplicating and tracking security findings." }, { "url": "https://owaspsamm.org/model/implementation/defect-management/", "note": "OWASP SAMM Defect Management practice describes how to track, prioritise and measure security defects across the lifecycle." }, { "url": "https://csrc.nist.gov/Projects/ssdf", "note": "NIST Secure Software Development Framework (SSDF) sets out practices for identifying, tracking and remediating vulnerabilities throughout development." }, { "url": "https://owasp.org/www-project-vulnerability-management-guide/", "note": "OWASP Vulnerability Management Guide offers practical guidance on running an effective issue tracking and remediation process." } ], "mappings": { "owasp_samm": [ "Implementation > Defect Management", "Operations > Incident Management" ], "owasp_asvs": [ "V1 Architecture, Design and Threat Modeling" ], "nist_ssdf": [ "RV.2 Assess, Prioritize, and Remediate Vulnerabilities", "RV.3 Analyze Vulnerabilities to Identify Their Root Causes", "PO.4 Implement and Maintain Secure Environments for Software Development" ], "iso_27001": [ "A.8.8 Management of technical vulnerabilities", "A.5.24 Information security incident management planning and preparation" ] } }, { "id": "DSOVS-DES-001", "code": "DES-001", "title": "Security Architecture Design Reviews", "phase": "Design", "slug": "DES-001-Secure-Architecture-Design-Reviews", "status": "complete", "type": "process", "summary": "Secure Architecture Design Reviews are a type of security review that focuses on the development of secure architectures.\n\nThey involve analyzing the architecture and design of a software system to ensure that it meets the security goals and objectives of the organization.\n\nThese reviews are important in DevSecOps because they help to identify any weaknesses or potential vulnerabilities in the system, allowing the team to take corrective measures to improve the security posture of the system.\n\nSecure Architecture Design Reviews can also help to ensure that the system adheres to best practices and industry standards for security.", "doc_url": "https://github.com/OWASP/www-project-devsecops-verification-standard/blob/main/document/DES-001-Secure-Architecture-Design-Reviews.md", "levels": [ { "level": 0, "title": "No security architecture design review performed", "description": "At this level there is no practice of reviewing architecture or design from a security perspective. Systems are built and changed without anyone deliberately examining how their structure, trust boundaries, data flows, or integration points might introduce risk.\n\nBecause security is never considered at the design stage, weaknesses tend to surface much later, during testing, audits, or after an incident, where they are far more expensive and disruptive to fix. The organisation has no shared understanding of the security assumptions underpinning its systems.", "evidence": [] }, { "level": 1, "title": "Verify that ad-hoc security architecture design review is performed and action items are created in the development team's backlog", "description": "At level one, security architecture design reviews begin to happen, but on an informal and reactive basis. Typically a security analyst is pulled in to look over a particular design when someone remembers to ask, or when a change feels high risk. The review examines the proposed architecture, identifies areas of concern, and records the resulting recommendations as action items in the development team's backlog so they are not lost.\n\nThis is a meaningful improvement over having no reviews at all, because at least some designs now receive security scrutiny and the findings are captured in a place the team already works from. However, coverage depends entirely on individuals choosing to initiate a review, so it remains inconsistent and many changes still ship without ever being examined.", "evidence": [ "At least one documented security architecture design review exists for a recent design or change.", "Review findings are captured as action items in the development team's backlog.", "Interview confirms who initiates reviews and on what trigger." ], "diagram": "graph LR; Design-- ad-hoc review -->Security-Analyst-- findings -->Backlog;" }, { "level": 2, "title": "Verify that security architecture design review is performed prior to development activity is finalised and action items are created in the development team's backlog", "description": "At level two, design review is no longer an occasional favour from a security analyst but a standard, expected activity that development teams perform themselves as part of building a feature. Reviews take place before the design is finalised and development is committed, so that security concerns can shape the architecture while changing it is still cheap. As with the previous level, the resulting action items are recorded in the team's backlog and tracked through to resolution.\n\nThe key advance is that responsibility shifts onto the teams who own the work and is built into the normal flow of delivery, rather than relying on a central specialist being available. This makes coverage far more consistent and timely, catches issues earlier in the lifecycle, and helps developers internalise secure design thinking as a routine part of their craft.", "evidence": [ "A documented process requires security design review before a design is finalised and development is committed.", "Reviews are performed by the owning development team rather than only a central specialist.", "Resulting action items are recorded in the backlog and tracked through to resolution." ], "diagram": "graph LR; Feature-Design-- review before finalised -->Development-Team-- findings -->Backlog-- shapes -->Feature-Design;" }, { "level": 3, "title": "Verify that all security features have been addressed in the design", "description": "At level three, design review is governed by a periodic review schedule that keeps architecture and design artifacts current as systems evolve. Rather than reviewing only at the point a feature is first designed, the organisation revisits its designs on a defined cadence to confirm that every relevant security feature, control, and trust assumption is still addressed and still accurate. Design decisions, along with the rationale behind them, are documented and tracked over time so that the reasoning remains visible and auditable.\n\nThis represents a mature, measured practice in which the security architecture is treated as a living asset rather than a one-time deliverable. Because artifacts are kept up to date and decisions are traceable, drift between the documented design and the running system is caught early, new threats can be reflected back into existing designs, and the organisation can continuously demonstrate that its systems meet their intended security objectives.", "evidence": [ "A documented periodic review schedule keeps architecture and design artifacts current.", "Design artifacts map each relevant security feature, control, and trust assumption to confirm coverage.", "Design decisions and their rationale are documented and tracked over time for auditability." ], "diagram": "graph LR; Schedule-- periodic review -->Development-Team-- update -->Architecture-Artifacts-- tracked decisions -->Schedule;" } ], "further_reading": [ { "url": "https://owaspsamm.org/model/design/security-architecture/", "note": "OWASP SAMM - Design: Security Architecture - the SAMM practice that defines maturity for designing software with secure architecture in mind, useful for benchmarking and planning improvements." }, { "url": "https://owasp.org/www-project-application-security-verification-standard/", "note": "OWASP Application Security Verification Standard (ASVS) - V1 Architecture, Design and Threat Modeling - a set of verifiable requirements that give design reviews concrete criteria to check architectures against." }, { "url": "https://csrc.nist.gov/projects/ssdf", "note": "NIST SP 800-218 Secure Software Development Framework (SSDF) - guidance whose \"Protect the Software\" and design-time practices map closely to reviewing architecture for security." }, { "url": "https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet.html", "note": "OWASP Security Architecture Cheat Sheet - practical guidance and patterns to apply when conducting and acting on architecture design reviews." }, { "url": "https://owasp.org/www-project-developer-guide/draft/design/web_app_checklist/define_security_requirements/", "note": "OWASP Security by Design Principles - foundational principles such as least privilege and defence in depth that reviewers use to evaluate a design." } ], "mappings": { "owasp_samm": [ "Design > Security Architecture", "Design > Threat Assessment" ], "owasp_asvs": [ "V1 Architecture, Design and Threat Modeling" ], "nist_ssdf": [ "PW.1 Design Software to Meet Security Requirements and Mitigate Security Risks", "PO.1 Define Security Requirements for Software Development" ], "iso_27001": [ "A.8.25 Secure development life cycle", "A.8.27 Secure system architecture and engineering principles" ] } }, { "id": "DSOVS-DES-002", "code": "DES-002", "title": "Threat Modelling", "phase": "Design", "slug": "DES-002-Threat-Modelling", "status": "complete", "type": "tool", "summary": "Threat Modelling is a process of analyzing the threats that can potentially impact the security of an application before it is deployed.\n\nIt helps to identify potential risks, the security controls needed to protect the application, and the mitigation strategies that should be put in place.\n\nThreat Modelling is an important part of DevSecOps because it ensures that security considerations are taken into account throughout the entire development process, enabling organizations to build applications in a secure way from the start and minimise the risk of exploitation.", "doc_url": "https://github.com/OWASP/www-project-devsecops-verification-standard/blob/main/document/DES-002-Threat-Modelling.md", "levels": [ { "level": 0, "title": "No threat modelling exercise performed", "description": "At this level the organisation never deliberately reasons about how an application might be attacked. There is no exercise to enumerate assets, trust boundaries, entry points, or the threats an adversary could use against them.\n\nWithout threat modelling, security controls are chosen reactively or by habit rather than in response to a structured understanding of risk. Whole classes of threat can go unconsidered until they are discovered in production or exploited by an attacker, when remediation is slowest and most costly.", "evidence": [] }, { "level": 1, "title": "Verify that ad-hoc threat modelling is performed by security analyst", "description": "At level one, threat modelling starts to take place, but informally and only when a security analyst is engaged to do it. The analyst examines a design, identifies plausible threats and the controls needed to address them, and shares the findings with the team, typically for a system or change that is felt to be especially sensitive.\n\nThis is a clear step forward from never modelling threats at all, because at least some applications now benefit from a deliberate, structured look at how they could be attacked. The limitation is that the practice depends on a specialist's availability and on someone remembering to ask, so it is applied unevenly and many features are still built with no threat analysis behind them.", "evidence": [ "At least one threat model artifact exists, produced by a security analyst for a specific system or change.", "The artifact records identified threats and the controls or mitigations recommended to address them.", "Interview confirms how a security analyst is engaged and which changes trigger a threat modelling exercise." ], "diagram": "graph LR; Design-- ad-hoc engagement -->Security-Analyst-- identify threats -->Threat-Model-- findings -->Team;" }, { "level": 2, "title": "Verify that threat modelling is performed by development team on features", "description": "At level two, threat modelling becomes part of the normal development flow and is carried out by the development teams themselves as they build features, rather than being outsourced to a security analyst. As a feature is designed, the team works through what could go wrong, what an attacker might target, and which mitigations belong in the design, capturing the resulting actions alongside their other work.\n\nThe important advance is one of ownership and scale: because the teams who understand the feature best perform the analysis as a routine activity, far more of the product gets modelled, threats are identified while the design can still be changed cheaply, and developers steadily build an instinct for thinking like an attacker. Security specialists can then focus on coaching and on the highest-risk areas rather than being a bottleneck.", "evidence": [ "Development teams produce threat models for features as part of the normal design workflow.", "Mitigation actions identified during threat modelling are captured in the team's backlog or tracking system.", "Interview with a development team confirms threat modelling is a routine activity they own rather than relying on a security analyst.", "Threat model artifacts exist across multiple teams or features, demonstrating coverage at scale." ], "diagram": "graph LR; Feature-- identify threats -->Development-Team-- builds -->Threat-Model-- mitigations -->Backlog;" }, { "level": 3, "title": "Verify that periodic review schedule is defined to keep the threat model artifacts current", "description": "At level three, threat models are treated as living artifacts maintained on a defined, periodic review schedule. Rather than being produced once when a feature is first built and then forgotten, models are revisited on a regular cadence and whenever the system changes meaningfully, so that assets, trust boundaries, threats, and mitigations stay aligned with the application as it actually exists.\n\nThis is a mature, measured practice in which threat modelling continuously informs the organisation's security posture. Keeping the artifacts current means newly emerging threats can be reflected back into existing designs, controls can be verified as still appropriate, and the organisation retains an accurate, auditable picture of the risks facing each system over its whole lifetime.", "evidence": [ "A documented periodic review schedule or cadence exists for revisiting threat model artifacts.", "Version history or revision records show threat models being updated over time and on system change.", "Metrics or reports demonstrate threat model coverage and freshness across systems.", "Updated mitigations from reviews are tracked through to remediation in the backlog or issue tracker." ], "diagram": "graph LR; Schedule-- periodic review -->Development-Team-- update -->Threat-Model-- refreshed mitigations -->Backlog; Threat-Model-- next cadence -->Schedule;" } ], "tools": [ { "name": "OWASP Threat Dragon", "url": "https://github.com/OWASP/threat-dragon", "description": "Threat Dragon is an OWASP project providing a free, open-source threat modelling tool. It lets teams draw data-flow diagrams, identify threats against the elements in them, and record mitigations, with the model stored as a versionable file so it can live alongside the code it describes." }, { "name": "pytm", "url": "https://github.com/izar/pytm", "description": "pytm is a Pythonic framework for threat modelling as code. The system, its boundaries, and its dataflows are described in Python, and pytm generates data-flow diagrams, sequence diagrams, and a report of applicable threats, which makes threat models easy to keep under version control and to update as the design evolves." } ], "further_reading": [ { "url": "https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html", "note": "A concise, practical guide to running a threat modelling exercise and what good output looks like." }, { "url": "https://owaspsamm.org/model/design/threat-assessment/", "note": "The SAMM practice describing maturity levels for threat assessment, useful for measuring and planning improvement." }, { "url": "https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats", "note": "The widely used STRIDE methodology for categorising threats (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege)." } ], "mappings": { "owasp_samm": [ "Design > Threat Assessment" ], "owasp_asvs": [ "V1 Architecture, Design and Threat Modeling" ], "nist_ssdf": [ "PW.1 Design Software to Meet Security Requirements and Mitigate Security Risks" ], "iso_27001": [ "A.8.27 Secure system architecture and engineering principles", "A.8.25 Secure development life cycle" ] } }, { "id": "DSOVS-CODE-001", "code": "CODE-001", "title": "Secure Development Environment", "phase": "Code/Build", "slug": "CODE-001-Secure-Development-Environment", "status": "complete", "type": "tool", "summary": "It is important for developers to use a secure development environment in order to ensure the integrity of their code and avoid the risk of source-code theft.\n\nBy using an environment that is secure and isolated from other networks, developers can be sure that their code remains safe and secure.\n\nAdditionally, as development environments can be monitored and audited, it can help identify any potential vulnerabilities or malicious activity.\n\nThis provides an extra level of security, as developers can be sure that no one is accessing their code without permission.\n\nUsing a secure development environment also helps to reduce the risk of source-code theft, as the code is stored in a secure location and is not accessible to anyone outside of the development team.", "doc_url": "https://github.com/OWASP/www-project-devsecops-verification-standard/blob/main/document/CODE-001-Secure-Development-Environment.md", "levels": [ { "level": 0, "title": "No security hardening standards for development environments", "description": "At this level of maturity there are no defined security hardening standards for developer machines or environments. Developers configure their own laptops, workstations, and local toolchains however they see fit, and there is no agreed baseline for operating system settings, disk encryption, patching, or access controls.\n\nBecause every environment is set up differently and nothing is documented, the organisation has no way to know whether source code, credentials, or build tooling are adequately protected. Any security that exists is incidental and depends entirely on the individual developer.", "evidence": [] }, { "level": 1, "title": "Verify hardening standards or security checklist for development environment", "description": "At this stage the organisation has produced written hardening standards or a security checklist that describes how a development environment should be configured. This typically covers items such as full-disk encryption, automatic screen locking, operating system and dependency patching, restricting administrative privileges, and keeping secrets out of source code.\n\nThe standard exists as guidance and is applied manually. Developers are expected to read the checklist and configure their own environments accordingly, and compliance is reviewed on an ad-hoc basis rather than being enforced automatically. This is an improvement over Level 0 because there is now a shared, documented baseline that everyone can be measured against, even if adherence still relies on individual effort.", "evidence": [ "A written hardening standard or security checklist for development environments exists and is accessible to developers.", "The standard covers core controls such as full-disk encryption, screen locking, patching, privilege restriction, and secret handling.", "Interview confirms developers are aware of the checklist and configure their environments against it." ], "diagram": "graph LR; Developer-- follows checklist -->Dev-Environment;" }, { "level": 2, "title": "Verify implementation of harden template for development environment", "description": "Here the hardening standard is no longer just a document to follow by hand; it is implemented as a reusable, pre-configured template. This might take the form of a managed and golden machine image, a configuration-management profile (for example Ansible, Chef, or an MDM policy), or a containerised development environment such as a Dev Container that ships with the approved tooling and security settings baked in.\n\nBecause the secure baseline is delivered as a template, every developer starts from the same hardened state and the controls are applied consistently and repeatably instead of depending on each person to remember the checklist. Onboarding becomes faster and configuration drift between environments is significantly reduced.", "evidence": [ "A reusable hardened template exists, such as a golden image, configuration-management profile, or Dev Container definition.", "The template encodes the approved tooling and security settings from the hardening standard.", "Evidence shows new developers provision their environment from the template rather than configuring it manually.", "Pre-commit hooks or equivalent local checks are bundled with the template." ], "diagram": "graph LR;\nDeveloper-- provisions -->Hardened-Template-- pre-commit hooks -->Commit-- code push -->CICD-Pipeline; CICD-Pipeline-- Build -->Finish" }, { "level": 3, "title": "Verify that the security policies are enforced to align with in the development environment hardening standards", "description": "At the highest level of maturity the hardening standards are actively enforced rather than merely provided. Policies are applied and continuously monitored through tooling such as MDM/endpoint management, policy-as-code, and pre-commit or CI checks, so that non-compliant environments are detected and either remediated automatically or blocked from interacting with source code and pipelines.\n\nCompliance status is tracked centrally, giving the organisation visibility into which environments meet the baseline and which do not. The effectiveness of the hardening standards is reviewed periodically and the templates and policies are improved over time to keep pace with new threats, changes in tooling, and the organisation's risk appetite. This builds on Level 2 by closing the gap between having a hardened template and guaranteeing it is consistently in force.", "evidence": [ "MDM/endpoint management or policy-as-code tooling enforces the hardening standards on developer environments.", "Non-compliant environments are automatically remediated or blocked from interacting with source code and pipelines.", "A central dashboard or report tracks the compliance status of development environments against the baseline.", "A documented periodic review of the hardening standards and templates exists, with evidence of improvements over time." ], "diagram": "graph LR;\nDeveloper-- provisions -->Hardened-Template-- code push -->CICD-Pipeline-- Policy Check -->Source-Code--Compliance Status -->Centralised-Issue-Tracker; CICD-Pipeline-- Build -->Finish" } ], "tools": [ { "name": "pre-commit", "url": "https://github.com/pre-commit/pre-commit", "description": "pre-commit is a framework for managing and maintaining multi-language Git pre-commit hooks. It lets you enforce hardening checks - such as detecting hardcoded secrets, blocking large or private-key files, and validating configuration - directly in the developer environment before code is ever committed. Running the same hooks both locally and in CI ensures the secure baseline is applied consistently across every developer's machine.\n\nA typical `.pre-commit-config.yaml` defining a set of security and hygiene hooks:", "integrations": [ { "platform": "config", "label": null, "link": null, "code": "repos:\n - repo: https://github.com/pre-commit/pre-commit-hooks\n rev: v4.6.0\n hooks:\n - id: detect-private-key\n - id: check-added-large-files\n - id: end-of-file-fixer\n - id: trailing-whitespace\n - id: check-merge-conflict\n - repo: https://github.com/gitleaks/gitleaks\n rev: v8.18.4\n hooks:\n - id: gitleaks" }, { "platform": "github-actions", "label": null, "link": "https://github.com/pre-commit/action", "code": "name: pre-commit\n\non:\n pull_request:\n push:\n branches: [main]\n\njobs:\n pre-commit:\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v4\n - uses: actions/setup-python@v5\n with:\n python-version: \"3.x\"\n - uses: pre-commit/action@v3.0.1" } ] }, { "name": "Development Containers", "url": "https://github.com/devcontainers", "description": "Development Containers (Dev Containers) let a project define its development environment as code in a `devcontainer.json` file. By describing the base image, tooling, extensions, and settings declaratively, every developer - and the CI pipeline - works from the same standardised, hardened environment, which directly supports the Level 2 \"harden template\" and Level 3 enforcement goals. Editors such as VS Code and platforms like GitHub Codespaces can build and open these containers automatically.\n\nA minimal hardened `.devcontainer/devcontainer.json`:", "integrations": [ { "platform": "config", "label": null, "link": null, "code": "{\n \"name\": \"secure-dev-environment\",\n \"image\": \"mcr.microsoft.com/devcontainers/base:ubuntu\",\n \"runArgs\": [\"--cap-drop=ALL\", \"--security-opt=no-new-privileges\"],\n \"remoteUser\": \"vscode\",\n \"features\": {\n \"ghcr.io/devcontainers/features/git:1\": {}\n },\n \"postCreateCommand\": \"pre-commit install\"\n}" } ] } ], "further_reading": [ { "url": "https://owasp.org/www-project-devsecops-guideline/", "note": "OWASP DevSecOps Guideline." }, { "url": "https://github.com/pre-commit/pre-commit", "note": "pre-commit framework for managing Git pre-commit hooks." }, { "url": "https://containers.dev/", "note": "Development Containers specification and tooling." } ], "mappings": { "owasp_samm": [ "Operations > Environment Management", "Implementation > Secure Build" ], "owasp_asvs": [ "V14 Configuration" ], "nist_ssdf": [ "PO.5 Implement and Maintain Secure Environments for Software Development" ], "iso_27001": [ "A.8.31 Separation of development, test and production environments", "A.8.9 Configuration management" ] } }, { "id": "DSOVS-CODE-002", "code": "CODE-002", "title": "Hardcoded Secrets Detection", "phase": "Code/Build", "slug": "CODE-002-Hardcoded-Secrets-Detection", "status": "complete", "type": "tool", "summary": "Hardcoded secrets scanning is a security process used in DevSecOps that involves scanning code for hardcoded passwords, tokens, and other identifying information.\n\nThe goal of hardcoded secrets scanning is to identify and replace any insecurely stored credentials or secrets, as these can be exploited by malicious actors.\n\nThe process typically involves scanning source code, configuration files, and other related artifacts for secrets, which are then checked against appropriate levels of access control.\n\nAny secrets that are deemed insecure are then reported to the relevant parties and can be replaced with more secure alternatives.", "doc_url": "https://github.com/OWASP/www-project-devsecops-verification-standard/blob/main/document/CODE-002-Hardcoded-Secrets-Detection.md", "levels": [ { "level": 0, "title": "No tool to perform hardcoded secret scanning", "description": "At this level of security maturity, there are no tools available to perform secret scanning.", "evidence": [] }, { "level": 1, "title": "Verify use of tool to perform on-demand scan to identify hardcoded secrets in the source code", "description": "At this stage, a secrets detection tool is present but the scanning is performed on a case-by-case basis. It is not automated and the results may not be reported or recorded.", "evidence": [ "A secrets detection tool is installed and available to developers.", "At least one on-demand scan report against the source repository is available.", "Interview confirms who runs the scan and how it is triggered." ] }, { "level": 2, "title": "Verify the implementation of the hardcoded secrets scanning tool into the build pipeline to perform automated scans and report status to the build", "description": "Here, secrets scanning is implemented into the software build pipeline. This means that whenever a build is executed, an automated secrets scan will be triggered and the results will be reported.", "evidence": [ "Pipeline configuration shows a secrets scanning stage that runs automatically on each build or push.", "Build logs show the secrets scan executing and reporting status back to the build.", "A detected secret causes the build to fail or be flagged." ] }, { "level": 3, "title": "Verify that the findings are automatically recorded to a centralised issue tracker system and periodically review tool's effectiveness", "description": "Level 3 of secrets scannnig is the same as level 2, with the addition of all identified security vulnerabilities being recorded in a centralised issue tracking system and periodically reviewed to evaluate the effectiveness of the secrets detection tool. This means that the same type of automated scans are being performed, but the results are being collected, tracked and analysed for future use and improvement.", "evidence": [ "Findings are automatically created in a centralised issue tracker with severity and ownership.", "A documented schedule exists for reviewing the tool's effectiveness and tuning its rules and allow-lists.", "Metrics show secrets findings being triaged and remediated over time." ] } ], "tools": [ { "name": "Gitleaks", "url": "https://github.com/awslabs/git-secrets", "description": "Gitleaks is a SAST tool for detecting and preventing hardcoded secrets like passwords, api keys, and tokens in git repos. Gitleaks is an easy-to-use, all-in-one solution for detecting secrets, past or present, in your code.", "integrations": [ { "platform": "github-actions", "label": null, "link": "https://github.com/gitleaks/gitleaks-action", "code": "name: gitleaks\non:\n pull_request:\n push:\n workflow_dispatch:\n schedule:\n - cron: \"0 4 * * *\" # run once a day at 4 AM\njobs:\n scan:\n name: gitleaks\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v3\n with:\n fetch-depth: 0\n - uses: gitleaks/gitleaks-action@v2\n env:\n GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}\n GITLEAKS_LICENSE: ${{ secrets.GITLEAKS_LICENSE}} # Only requir" }, { "platform": "gitlab-ci", "label": null, "link": "https://badshah.io/experiment/adding-gitleaks-to-gitlab-pipeline/", "code": "stages:\n - secrets-detection\n\ngitleaks:\n stage: secrets-detection\n image:\n name: \"zricethezav/gitleaks\"\n entrypoint: [\"\"]\n script: gitleaks -v --pretty --repo-path . --commit-from=$CI_COMMIT_SHA --commit-to=$CI_COMMIT_BEFORE_SHA --branch=$CI_COMMIT_BRANCH" }, { "platform": "azure-devops", "label": null, "link": "https://github.com/JoostVoskuil/azure-devops-gitleaks", "code": "name: '2.0$(rev:.r)'\n\ntrigger:\n- main\n- feature/*\n- features/*\n- bugfix/*\n\npool:\n vmImage: 'ubuntu-latest'\n\nstages:\n- stage: 'Build'\n displayName: 'Build'\n jobs:\n - job:\n steps:\n - task: NodeTool@0\n inputs:\n versionSpec: '16.x'\n displayName: 'Install Node.js'\n\n - template: build-and-test.yml\n parameters:\n path: task/v2\n name: Gitleaks V2\n\n - task: TfxInstaller@3\n displayName: 'Use Node CLI for Azure DevOps'\n inputs:\n version: '0.9.x'\n checkLatest: true\n\n - task: PackageAzureDevOpsExtension@3\n displayName: 'Package Extension: $(Build.SourcesDirectory)'\n name: 'packageStep'\n inputs:\n rootFolder: '$(Build.SourcesDirectory)'\n outputPath: '$(Build.ArtifactStagingDirectory)/foxholenl-gitleaks.vsix'\n publisherId: 'foxholenl'\n extensionId: 'Gitleaks'\n extensionName: 'Gitleaks'\n extensionTag: '-build'\n extensionVersion: '$(Build.BuildNumber)'\n extensionVisibility: private\n\n - task: PublishPipelineArtifact@1\n displayName: 'Publish vsix'\n inputs:\n publishLocation: pipeline\n targetPath: '$(packageStep.Extension.OutputPath)'\n artifact: 'vsix'\n condition: succeededOrFailed()\n\n- stage: Test\n displayName: 'Publish to Marketplace (private)'\n condition: and(succeeded(), ne(variables['Build.Reason'], 'PullRequest'))\n dependsOn: 'Build'\n jobs:\n - deployment:\n environment: Test\n strategy:\n runOnce:\n deploy:\n steps:\n\n - task: TfxInstaller@3\n displayName: 'Use Node CLI for Azure DevOps'\n inputs:\n version: '0.9.x'\n checkLatest: true\n\n - task: PublishAzureDevOpsExtension@3\n name: 'PublishTest'\n inputs:\n connectTo: 'VsTeam'\n connectedServiceName: 'Marketplace'\n fileType: 'vsix'\n vsixFile: '$(Pipeline.Workspace)/vsix/foxholenl-gitleaks.vsix'\n publisherId: 'foxholenl'\n extensionId: 'Gitleaks'\n extensionTag: '-dev'\n updateTasksVersion: false\n extensionVisibility: 'privatepreview'\n shareWith: 'foxholenl'\n noWaitValidation: true\n\n- stage: Production\n displayName: 'Publish to Marketplace (Public)'\n condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))\n dependsOn: 'Test'\n jobs:\n - deployment:\n environment: Production\n strategy:\n runOnce:\n deploy:\n steps:\n - task: TfxInstaller@3\n displayName: 'Use Node CLI for Azure DevOps'\n inputs:\n version: '0.9.x'\n checkLatest: true\n\n - task: PublishAzureDevOpsExtension@3\n name: 'PublishProd'\n inputs:\n connectTo: 'VsTeam'\n connectedServiceName: 'Marketplace'\n fileType: 'vsix'\n vsixFile: '$(Pipeline.Workspace)/vsix/foxholenl-gitleaks.vsix'\n publisherId: 'foxholenl'\n extensionId: 'Gitleaks'\n updateTasksVersion: false\n extensionVisibility: 'public'\n noWaitValidation: true" } ] } ], "mappings": { "owasp_samm": [ "Verification > Security Testing" ], "owasp_asvs": [ "V2 Authentication", "V14 Configuration" ], "nist_ssdf": [ "PW.7 Review and/or Analyze Human-Readable Code", "RV.1 Identify and Confirm Vulnerabilities" ], "iso_27001": [ "A.8.8 Management of technical vulnerabilities", "A.5.17 Authentication information" ] }, "credits": [ { "name": "Joost Voskuil", "url": "https://github.com/JoostVoskuil" }, { "name": "Chandrapal Badshah", "url": "https://www.linkedin.com/in/bnchandrapal/?originalSubdomain=in" } ] }, { "id": "DSOVS-CODE-003", "code": "CODE-003", "title": "Manual Secure Code Review", "phase": "Code/Build", "slug": "CODE-003-Manual-Secure-Code-Review", "status": "complete", "type": "process", "summary": "In addition to automated source-code review, manual source-code review is an important part of a secure software development lifecycle.\n\nBy manually reviewing the code, developers can identify any potential security vulnerabilities that may have been overlooked.\n\nThis helps to ensure that any weaknesses are addressed and that the code is secure.\n\nAdditionally, manual source code review helps to ensure that there are no hidden backdoors or malicious code present in the source code.\n\nThis further helps to protect users from any potential attacks, and also helps maintain user trust in the software.\n\nManual source-code reviews also help to detect any irregularities or errors in the code, which can then be addressed quickly and effectively to ensure that the software remains secure.", "doc_url": "https://github.com/OWASP/www-project-devsecops-verification-standard/blob/main/document/CODE-003-Manual-Secure-Code-Review.md", "levels": [ { "level": 0, "title": "No security coding standards", "description": "At this level of maturity there is no manual secure code review taking place, and there are no security coding standards to guide developers. Code is written and merged based on functional correctness alone, with no documented expectations for how security concerns should be handled.\n\nWithout any shared standard or review step, security defects depend entirely on the individual knowledge of whoever happens to write the code. Common weaknesses such as injection flaws, broken access control, or insecure handling of secrets can pass into production unnoticed because no one is specifically looking for them.", "evidence": [] }, { "level": 1, "title": "Verify that security checklist is part of coding standards", "description": "At level one the organisation has begun to formalise its expectations by including a security checklist as part of its coding standards. The checklist captures the security concerns that reviewers and authors should keep in mind, such as input validation, output encoding, authentication and authorisation checks, error handling, and the safe use of cryptography and secrets.\n\nManual secure code review at this stage is typically ad-hoc. Developers may consult the checklist and perform a review when they remember to or when a change feels risky, but it is not yet a required step in the workflow. The improvement over level zero is that there is now a documented, shared reference describing what a secure review should cover, even if its application is inconsistent.", "evidence": [ "A documented security checklist exists as part of the coding standards and is accessible to developers.", "The checklist covers core concerns such as input validation, output encoding, authentication/authorisation, error handling, and safe use of cryptography and secrets.", "Interview confirms developers are aware of the checklist and consult it when reviewing code." ], "diagram": "graph LR; Developer-- ad-hoc review -->Source-Code;" }, { "level": 2, "title": "Verify that security coding standards is being used for peer review", "description": "At level two, manual secure code review becomes a required part of the development workflow rather than an optional activity. The security checklist and coding standards are actively used during peer review, most commonly as a mandatory step on every pull request before code can be merged.\n\nReviewers are expected to work through the checklist and confirm that the relevant security concerns have been addressed, and the review is recorded as part of the merge process. This consistency is the key improvement over level one: instead of depending on whether an individual developer chooses to review for security, every change is examined against the same standard by a second person before it reaches the main branch.", "evidence": [ "Branch protection or merge rules require a peer security review before code can be merged.", "Pull request records show reviewers working through the security checklist as part of the review.", "The security review outcome is recorded as part of the merge process for each change.", "Interview confirms that secure code review is a mandatory, not optional, step in the workflow." ], "diagram": "graph LR;\nDeveloper-- opens -->Pull-Request-- Mandatory Security Review -->Peer-Reviewer--Approve -->Merge; Peer-Reviewer-- Reject -->Pull-Request" }, { "level": 3, "title": "Verify that periodic review schedule is defined to review the security coding standard", "description": "At level three the practice is centrally tracked, measured, and continuously improved. Review activity and outcomes are captured so the organisation can report on coverage, such as the proportion of changes that received a security review, and on effectiveness, such as the types of issues found, missed, or repeated across teams.\n\nA defined periodic review schedule ensures the security coding standard and its checklist do not become stale. The standard is revisited on a regular cadence and updated to reflect new threats, lessons learned from incidents and findings, changes in technology, and feedback from reviewers. The improvement over level two is that the review process itself is treated as a measurable control that is monitored and refined over time, rather than a fixed checklist applied indefinitely.", "evidence": [ "Metrics capture review coverage (proportion of changes reviewed) and effectiveness (types of issues found or missed).", "Findings from secure code reviews are recorded in a centralised issue tracker.", "A documented periodic review schedule exists for revisiting the security coding standard and checklist.", "Revision history shows the standard being updated in response to new threats, incidents, and reviewer feedback." ], "diagram": "graph LR;\nDeveloper-- opens -->Pull-Request-- Mandatory Security Review -->Peer-Reviewer--Findings -->Centralised-Issue-Tracker; Peer-Reviewer-- Approve -->Merge" } ], "further_reading": [ { "url": "https://owasp.org/www-project-code-review-guide/", "note": "A comprehensive guide to performing manual secure code reviews and building a review process." }, { "url": "https://owaspsamm.org/model/design/security-architecture/", "note": "Guidance on establishing and reinforcing secure design and coding expectations." }, { "url": "https://owaspsamm.org/model/implementation/secure-build/", "note": "How review and standards fit into a repeatable, controlled build and delivery workflow." }, { "url": "https://owasp.org/www-project-application-security-verification-standard/", "note": "A catalogue of security requirements that can form the basis of a secure code review checklist." }, { "url": "https://cheatsheetseries.owasp.org/", "note": "Practical, topic-specific guidance useful when defining checklist items for common vulnerability classes." } ], "mappings": { "owasp_samm": [ "Implementation > Secure Build", "Verification > Security Testing" ], "owasp_asvs": [ "V1 Architecture, Design and Threat Modeling" ], "nist_ssdf": [ "PW.7 Review and/or Analyze Human-Readable Code", "PW.2 Review the Software Design to Verify Compliance with Security Requirements and Risk Information" ], "iso_27001": [ "A.8.28 Secure coding", "A.8.25 Secure development life cycle" ] } }, { "id": "DSOVS-CODE-004", "code": "CODE-004", "title": "Static Application Security Testing (SAST)", "phase": "Code/Build", "slug": "CODE-004-Static-Application-Security-Testing-SAST", "status": "complete", "type": "tool", "summary": "Static application security testing (SAST), also known as static code analysis, is a form of automated security testing that looks for security vulnerabilities in the source code of an application.\n\nIt is an important part of DevSecOps because it can detect potential security issues early in the development process.\n\nBy uncovering any vulnerabilities in the source code, developers can be sure that the application is secure before it is deployed.\n\nAdditionally, SAST can help identify any coding errors or irregularities that may have been overlooked during development, helping to ensure that the application works as expected.\n\nThis can help reduce the time and effort needed to manually check the code and ensure that any security issues are addressed before the application goes live.", "doc_url": "https://github.com/OWASP/www-project-devsecops-verification-standard/blob/main/document/CODE-004-Static-Application-Security-Testing-SAST.md", "levels": [ { "level": 0, "title": "No tool to perform static code security analysis", "description": "At this level of security maturity, there are no tools available to perform Static Application Security Testing (SAST). Source code is written and shipped without any automated analysis of its security properties, so any vulnerabilities introduced during development remain undetected until they are found in later testing phases or, worse, in production.", "evidence": [] }, { "level": 1, "title": "Verify use of tool to perform on-demand scan to identify insecure code", "description": "At this stage, a SAST tool is present but the scanning is performed on a case-by-case basis. A developer or security engineer runs the analyser manually against the source code when they choose to, rather than on a defined schedule or trigger. Because the process is not automated, scans are easily forgotten between releases and the results may not be reported or recorded in any consistent way.", "evidence": [ "A SAST tool is installed and available to the team.", "At least one on-demand scan report against the source code is available.", "Interview confirms who runs the scan and how it is triggered." ], "diagram": "graph LR; Start-- SAST Scan -->Source-Code;" }, { "level": 2, "title": "Verify the implementation of the security static code analysis scanning tool into the build pipeline to perform automated scans and report status to the build", "description": "Here, SAST scanning is implemented into the software build pipeline. This means that whenever a build is executed, an automated static analysis of the source code is triggered and the results are reported back to the build. Developers receive consistent, repeatable feedback on insecure code with every push, and the pipeline can be configured to fail or flag a build when issues of a given severity are detected.", "evidence": [ "Pipeline configuration shows a SAST stage that runs automatically on each build or push.", "Build logs show the static analysis executing and reporting status back to the build.", "A defined severity threshold causes the build to fail or be flagged." ], "diagram": "graph LR;\nStart-- code push -->CICD-Pipeline-- SAST Scan -->Source-Code--SAST Results -->CICD-Pipeline; CICD-Pipeline-- Build -->Finish" }, { "level": 3, "title": "Verify that the findings are automatically recorded to a centralised issue tracker system and periodically review tool's effectiveness", "description": "Level 3 of SAST is the same as level 2, with the addition of all identified security vulnerabilities being recorded in a centralised issue tracking system and periodically reviewed to evaluate the effectiveness of the SAST tool. The same automated scans run on every build, but the results are now collected, tracked and analysed over time so that findings can be triaged, assigned and remediated through an established workflow.\n\nReviewing the tool's effectiveness also allows teams to tune rule sets, suppress false positives and confirm that the analyser is keeping pace with the languages and frameworks in use. More mature organisations often provide teams with shared CI/CD templates and baseline configurations, making consistent SAST adoption across the organisation considerably easier.", "evidence": [ "Findings are automatically created in a centralised issue tracker with severity and ownership.", "A documented schedule exists for reviewing the tool's effectiveness, tuning rule sets and suppressing false positives.", "Shared CI/CD templates or baseline SAST configurations are available to teams across the organisation.", "Metrics show SAST findings being triaged and remediated over time." ], "diagram": "graph LR;\nStart-- code push -->CICD-Pipeline-- SAST Scan -->Source-Code--SAST Results -->Centralised-Issue-Tracker; CICD-Pipeline-- Build -->Finish" } ], "tools": [ { "name": "Semgrep", "url": "https://github.com/semgrep/semgrep", "description": "Semgrep is a fast, open-source static analysis engine for finding bugs, detecting vulnerabilities and enforcing code standards. It supports more than 30 languages and uses an intuitive, pattern-based rule syntax that closely resembles the source code being scanned, making it straightforward to write custom rules alongside the large community rule registry.", "integrations": [ { "platform": "github-actions", "label": null, "link": "https://semgrep.dev/docs/semgrep-ci/sample-ci-configs", "code": "name: Semgrep\non:\n pull_request: {}\n push:\n branches: [main, master]\n schedule:\n - cron: '0 0 * * 0' # weekly full scan\n\njobs:\n semgrep:\n name: semgrep/ci\n runs-on: ubuntu-latest\n container:\n image: semgrep/semgrep\n steps:\n - uses: actions/checkout@v4\n - run: semgrep ci\n env:\n SEMGREP_APP_TOKEN: ${{ secrets.SEMGREP_APP_TOKEN }}" }, { "platform": "gitlab-ci", "label": null, "link": "https://semgrep.dev/docs/semgrep-ci/sample-ci-configs", "code": "stages:\n - test\n\nsemgrep:\n stage: test\n image: semgrep/semgrep\n script:\n - semgrep ci --gitlab-sast > gl-sast-report.json || true\n variables:\n SEMGREP_APP_TOKEN: $SEMGREP_APP_TOKEN\n artifacts:\n reports:\n sast: gl-sast-report.json\n rules:\n - if: $CI_PIPELINE_SOURCE == \"merge_request_event\"\n - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH" } ] }, { "name": "CodeQL", "url": "https://github.com/github/codeql-action", "description": "CodeQL is GitHub's semantic code analysis engine. It treats code as data, building a queryable database from a codebase so that security researchers and developers can express vulnerability patterns as declarative queries. CodeQL ships with an extensive library of security queries and integrates natively with GitHub's code scanning to surface results directly in pull requests.", "integrations": [ { "platform": "github-actions", "label": null, "link": "https://docs.github.com/en/code-security/code-scanning/integrating-with-code-scanning/sarif-support-for-code-scanning", "code": "name: CodeQL\non:\n push:\n branches: [main]\n pull_request:\n branches: [main]\n schedule:\n - cron: '0 3 * * 1'\n\njobs:\n analyze:\n name: Analyze\n runs-on: ubuntu-latest\n permissions:\n security-events: write\n actions: read\n contents: read\n strategy:\n matrix:\n language: ['javascript', 'python']\n steps:\n - uses: actions/checkout@v4\n - name: Initialize CodeQL\n uses: github/codeql-action/init@v3\n with:\n languages: ${{ matrix.language }}\n - name: Autobuild\n uses: github/codeql-action/autobuild@v3\n - name: Perform CodeQL Analysis\n uses: github/codeql-action/analyze@v3" }, { "platform": "gitlab-ci", "label": null, "link": "https://docs.github.com/en/code-security/code-scanning/integrating-with-code-scanning/sarif-support-for-code-scanning", "code": "stages:\n - test\n\ncodeql:\n stage: test\n image:\n name: mcr.microsoft.com/cstsectools/codeql-container:latest\n entrypoint: [\"\"]\n script:\n - codeql database create codeql-db --language=javascript --source-root .\n - codeql database analyze codeql-db --format=sarif-latest --output=codeql-results.sarif\n artifacts:\n paths:\n - codeql-results.sarif" } ] } ], "mappings": { "owasp_samm": [ "Verification > Security Testing" ], "owasp_asvs": [ "V1 Architecture, Design and Threat Modeling", "V5 Validation, Sanitization and Encoding" ], "nist_ssdf": [ "PW.7 Review and/or Analyze Human-Readable Code", "PW.8 Test Executable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements", "RV.1 Identify and Confirm Vulnerabilities" ], "iso_27001": [ "A.8.8 Management of technical vulnerabilities", "A.8.28 Secure coding" ] } }, { "id": "DSOVS-CODE-005", "code": "CODE-005", "title": "Software Composition Analysis (SCA)", "phase": "Code/Build", "slug": "CODE-005-Software-Composition-Analysis-SCA", "status": "complete", "type": "tool", "summary": "Source composition analysis (SCA) is a security technology which scans source code and identifies libraries, dependencies, and other third-party components being used in an application.\n\nIt is an important part of DevSecOps because it helps to ensure that all components of the application are secure and up-to-date.\n\nBy detecting any known vulnerabilities or outdated versions of code, SCA can help ensure that applications remain secure, even when third-party components are used.\n\nAdditionally, SCA can help alert developers to new versions of code, so that they can update their applications accordingly.\n\nThis helps to ensure that the latest security patches and updates are applied, helping to further increase the security of the application.", "doc_url": "https://github.com/OWASP/www-project-devsecops-verification-standard/blob/main/document/CODE-005-Software-Composition-Analysis-SCA.md", "levels": [ { "level": 0, "title": "No tool to perform third-party dependency analysis", "description": "At this level of security maturity, there are no tools available to perform software composition analysis. The open-source and third-party components an application depends on are not inventoried, and there is no visibility into the known vulnerabilities or licensing obligations that those components introduce.", "evidence": [] }, { "level": 1, "title": "Verify use of tool to perform on-demand scan for out of date or insecure third-party components used by the application", "description": "At this stage, an SCA tool is present but the scanning is performed on a case-by-case basis. A developer or security engineer runs the tool manually against a project to enumerate its dependencies and check them against vulnerability and license databases. Because these scans are run ad hoc rather than on a schedule or trigger, they are easily forgotten, and the results may not be reported or recorded in a consistent way.", "evidence": [ "An SCA tool is installed and available to the team.", "At least one on-demand scan report enumerating the application's dependencies is available.", "Interview confirms who runs the scan and how it is triggered." ], "diagram": "graph LR; Start-- SCA Scan -->Application-Dependencies;" }, { "level": 2, "title": "Verify the implementation of the third-party components vulnerability scanning tool into the build pipeline to perform automated scans and report status to the build", "description": "Here, SCA scanning is implemented into the software build pipeline. Whenever a build is executed, the tool automatically resolves the application's dependency tree, generates a software bill of materials (SBOM), and checks each component against known vulnerability and license data, reporting the status back to the build. This ensures that every change is consistently evaluated for vulnerable or non-compliant third-party components before it progresses, and the pipeline can be configured to fail the build when high-severity issues are detected.", "evidence": [ "Pipeline configuration shows an SCA stage that runs automatically on each build or push.", "Build logs show the dependency scan executing and reporting status back to the build.", "An SBOM artefact is generated as part of the pipeline.", "A defined severity threshold causes the build to fail or be flagged." ], "diagram": "graph LR;\nStart-- code push -->CICD-Pipeline-- SCA Scan -->Application-Dependencies--SCA Results -->CICD-Pipeline; CICD-Pipeline-- Code Deployment -->Finish" }, { "level": 3, "title": "Verify that the findings are automatically recorded to a centralised issue tracker system and periodically review tool's effectiveness", "description": "Level 3 of SCA is the same as level 2, with the addition of all identified vulnerabilities and license violations being recorded automatically in a centralised issue tracking system and periodically reviewed to evaluate the effectiveness of the SCA tool. The same automated scans are performed on every build, but the results are now collected, tracked, and analysed over time, allowing teams to monitor remediation progress, measure dependency risk across the organisation, and tune the tool's configuration to reduce noise and false positives.\n\nAt this level, more mature organisations also provide teams with simplified adoption guidance, such as shared CI/CD templates, organisation-wide policy on acceptable licenses and severity thresholds, and managed allow-lists for known false positives, making consistent SCA coverage easier to achieve across many repositories.", "evidence": [ "Findings are automatically created in a centralised issue tracker with severity and ownership.", "A documented schedule exists for reviewing the tool's effectiveness and tuning its configuration.", "Organisation-wide policy on acceptable licenses and severity thresholds is documented.", "Metrics show SCA findings being triaged and remediated over time." ], "diagram": "graph LR;\nStart-- code push -->CICD-Pipeline-- SCA Scan -->Application-Dependencies--SCA Results -->Centralised-Issue-Tracker; CICD-Pipeline-- Code Deployment -->Finish" } ], "tools": [ { "name": "OWASP Dependency-Check", "url": "https://github.com/jeremylong/DependencyCheck", "description": "OWASP Dependency-Check is a software composition analysis tool that identifies project dependencies and checks whether there are any known, publicly disclosed vulnerabilities. It does this by determining a Common Platform Enumeration (CPE) identifier for each dependency and, if found, generating a report linking to the associated Common Vulnerabilities and Exposures (CVE) entries. It supports a wide range of ecosystems and integrates easily into build pipelines.", "integrations": [ { "platform": "github-actions", "label": null, "link": "https://github.com/dependency-check/Dependency-Check_Action", "code": "name: Dependency-Check\non:\n push:\n pull_request:\n schedule:\n - cron: '0 4 * * *' # run once a day at 4 AM\n\npermissions:\n contents: read\n\njobs:\n dependency-check:\n runs-on: ubuntu-latest\n name: Software Composition Analysis\n steps:\n - name: Checkout\n uses: actions/checkout@v4\n\n - name: Run Dependency-Check\n uses: dependency-check/Dependency-Check_Action@main\n with:\n project: 'my-application'\n path: '.'\n format: 'SARIF'\n out: 'reports'\n\n - name: Upload results to Security Dashboard\n uses: github/codeql-action/upload-sarif@v3\n with:\n sarif_file: reports/dependency-check-report.sarif" }, { "platform": "gitlab-ci", "label": null, "link": "https://jeremylong.github.io/DependencyCheck/dependency-check-cli/index.html", "code": "stages:\n - composition-analysis\n\ndependency-check:\n stage: composition-analysis\n image:\n name: owasp/dependency-check:latest\n entrypoint: [\"\"]\n script:\n - /usr/share/dependency-check/bin/dependency-check.sh\n --project \"$CI_PROJECT_NAME\"\n --scan .\n --format \"ALL\"\n --out reports\n artifacts:\n paths:\n - reports/" } ] }, { "name": "Trivy", "url": "https://github.com/aquasecurity/trivy", "description": "Trivy is an open-source, all-in-one security scanner that finds vulnerabilities and license issues across application dependencies, container images, filesystems, and infrastructure-as-code. For software composition analysis it parses lockfiles and manifests to build a complete picture of an application's third-party components, can emit an SBOM in CycloneDX or SPDX format, and reports any known vulnerabilities affecting them.", "integrations": [ { "platform": "github-actions", "label": null, "link": "https://github.com/aquasecurity/trivy-action", "code": "name: Trivy SCA\non:\n push:\n pull_request:\n\npermissions:\n contents: read\n security-events: write\n\njobs:\n trivy-scan:\n runs-on: ubuntu-latest\n name: Scan dependencies\n steps:\n - name: Checkout\n uses: actions/checkout@v4\n\n - name: Run Trivy filesystem scan\n uses: aquasecurity/trivy-action@master\n with:\n scan-type: 'fs'\n scan-ref: '.'\n scanners: 'vuln,license'\n format: 'sarif'\n output: 'trivy-results.sarif'\n\n - name: Upload Trivy results to Security Dashboard\n uses: github/codeql-action/upload-sarif@v3\n with:\n sarif_file: 'trivy-results.sarif'" }, { "platform": "gitlab-ci", "label": null, "link": "https://trivy.dev/latest/tutorials/integrations/gitlab-ci/", "code": "stages:\n - composition-analysis\n\ntrivy:\n stage: composition-analysis\n image:\n name: aquasec/trivy:latest\n entrypoint: [\"\"]\n script:\n - trivy fs --scanners vuln,license --format json --output gl-sca-report.json .\n artifacts:\n paths:\n - gl-sca-report.json" } ] } ], "mappings": { "owasp_samm": [ "Verification > Security Testing", "Implementation > Secure Build" ], "owasp_asvs": [ "V1 Architecture, Design and Threat Modeling", "V14 Configuration" ], "nist_ssdf": [ "PW.4 Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating Functionality", "PW.8 Test Executable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements", "RV.1 Identify and Confirm Vulnerabilities" ], "iso_27001": [ "A.8.8 Management of technical vulnerabilities", "A.8.30 Outsourced development" ] } }, { "id": "DSOVS-CODE-006", "code": "CODE-006", "title": "Software License Compliance", "phase": "Code/Build", "slug": "CODE-006-Software-License-Compliance", "status": "complete", "type": "tool", "summary": "Software license compliance is the process of ensuring that software applications, and the open-source components they depend on, are used in accordance with the terms of their respective license agreements.\n\nIt is an important part of DevSecOps because it helps ensure that developers consume third-party software in a legal and ethical manner, while also preventing potential copyright or intellectual property infringements. Modern applications pull in large transitive dependency trees, and a single permissively licensed package can introduce a copyleft or otherwise restrictive license deep in the graph.\n\nBy monitoring software license compliance, teams can be confident that third-party components are legally obtained, properly attributed, and free of obligations that conflict with how the application is distributed. License scanning also surfaces components with unknown or missing licenses, which often correlate with poorly maintained code and associated security risk.", "doc_url": "https://github.com/OWASP/www-project-devsecops-verification-standard/blob/main/document/CODE-006-Software-License-Compliance.md", "levels": [ { "level": 0, "title": "No tool to perform open-source software license compliance analysis", "description": "At this level there is no capability to identify the licenses of the open-source components used in the application. Dependencies are added freely and their license obligations are unknown, so the organisation has no visibility into whether it is meeting attribution requirements or whether copyleft and other restrictive licenses have been introduced. License risk is effectively invisible and is only discovered, if at all, during legal disputes, acquisition due diligence, or customer audits.", "evidence": [] }, { "level": 1, "title": "Verify use of tool to perform on-demand scan for license violations when using third-party components in the application", "description": "A license scanning tool is available and is run manually, typically by a developer or release engineer before pulling in a new dependency or preparing a release. The tool inventories the components in use and reports the license attached to each, allowing obligations and conflicts to be assessed against an approved policy.\n\nThis is a clear improvement on Level 0 because license information becomes visible and decisions can be made deliberately. However, because scanning is on-demand and depends on someone remembering to run it, coverage is inconsistent. Results may not be recorded, and dependencies added between scans can slip through unnoticed.", "evidence": [ "A license scanning tool is installed and available to developers or release engineers.", "At least one on-demand scan report exists listing components and their detected licenses.", "An approved/denied license policy exists against which scan results are assessed.", "Interview confirms who runs the scan and at what point in the workflow." ], "diagram": "graph LR; Build-- License Scan -->Dependencies-->Results;" }, { "level": 2, "title": "Verify the implementation of the third-party software licence scanning tool into the build pipeline to perform automated scans and report status to the build", "description": "License scanning is integrated into the build pipeline so that every build automatically inventories all direct and transitive dependencies and evaluates their licenses against the organisation's policy. The build reports the result, and a disallowed or unknown license can fail the build or raise a warning, providing fast and consistent feedback to developers.\n\nThis removes the reliance on manual effort that limited Level 1. Because the scan runs on every build, newly introduced dependencies are caught automatically and policy is applied uniformly across all projects that use the pipeline, giving the organisation continuous and repeatable visibility of its license posture.", "evidence": [ "Pipeline configuration shows a license scanning stage that runs automatically on each build.", "Build logs show the scan inventorying direct and transitive dependencies and reporting status to the build.", "A disallowed or unknown license causes the build to fail or raise a warning per defined policy.", "The same policy is applied uniformly across projects that use the pipeline." ], "diagram": "graph LR;\nBuild-- code push -->CICD-Pipeline-- License Scan -->Dependencies--License Results -->CICD-Pipeline; CICD-Pipeline-- Code Deployment -->Finish" }, { "level": 3, "title": "Verify that the findings are automatically recorded to a centralised issue tracker system and periodically review tool's effectiveness", "description": "Level 3 builds on the automated pipeline scanning of Level 2 by routing all findings into a centralised issue tracking or governance system. Every license violation, policy exception, and remediation is recorded, tracked over time, and made available for reporting across the whole portfolio rather than living only in transient build logs.\n\nThe organisation periodically reviews the effectiveness of the tool and its policy: it examines false positives, tunes the approved and denied license lists, validates that the dependency inventory (and any generated SBOM) is accurate, and confirms that obligations such as attribution are actually being met. This measured, continuously improved approach ensures license compliance scales with the organisation and adapts to new components and changing legal requirements.", "evidence": [ "License findings, policy exceptions, and remediations are automatically recorded in a centralised issue tracker or governance system.", "A documented schedule exists for reviewing tool effectiveness, tuning approved/denied license lists, and validating the dependency inventory or SBOM.", "Metrics show license findings being triaged and remediated over time across the portfolio.", "Evidence confirms attribution and other license obligations are being met." ], "diagram": "graph LR;\nBuild-- code push -->CICD-Pipeline-- License Scan -->Dependencies--License Results -->Policy-Gate-- recorded -->Centralised-Issue-Tracker; CICD-Pipeline-- Code Deployment -->Finish" } ], "tools": [ { "name": "ScanCode Toolkit", "url": "https://github.com/nexB/scancode-toolkit", "description": "ScanCode Toolkit is a widely used open-source tool that detects licenses, copyrights, package metadata, and dependencies in source code and binaries. It is highly accurate, produces machine-readable output (JSON, SPDX, CycloneDX), and is well suited to building a detailed, auditable inventory of the licenses present in a codebase.", "integrations": [ { "platform": "github-actions", "label": null, "link": null, "code": "name: scancode-license-scan\non:\n pull_request:\n push:\n workflow_dispatch:\njobs:\n scan:\n name: scancode\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v4\n - name: Set up Python\n uses: actions/setup-python@v5\n with:\n python-version: \"3.11\"\n - name: Install ScanCode Toolkit\n run: pip install scancode-toolkit\n - name: Run license and copyright scan\n run: |\n scancode --license --copyright --package \\\n --json-pp scancode-results.json .\n - name: Upload results\n uses: actions/upload-artifact@v4\n with:\n name: scancode-results\n path: scancode-results.json" } ] }, { "name": "Trivy", "url": "https://github.com/aquasecurity/trivy", "description": "Trivy is an open-source scanner from Aqua Security that, in addition to vulnerability detection, can scan project dependencies and report the licenses they use. It classifies findings by severity according to a configurable license policy and can fail the build when forbidden or restricted licenses are detected, making it a convenient single tool for combined license and security scanning.", "integrations": [ { "platform": "github-actions", "label": null, "link": "https://github.com/aquasecurity/trivy-action", "code": "name: trivy-license-scan\non:\n pull_request:\n push:\n workflow_dispatch:\njobs:\n scan:\n name: trivy-license\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v4\n - name: Run Trivy license scan\n uses: aquasecurity/trivy-action@master\n with:\n scan-type: fs\n scanners: license\n severity: HIGH,CRITICAL\n exit-code: \"1\"\n path: ." }, { "platform": "gitlab-ci", "label": null, "link": "https://aquasecurity.github.io/trivy/latest/tutorials/integrations/gitlab-ci/", "code": "stages:\n - license-compliance\n\ntrivy-license:\n stage: license-compliance\n image:\n name: aquasec/trivy:latest\n entrypoint: [\"\"]\n script:\n - trivy fs --scanners license --severity HIGH,CRITICAL --exit-code 1 ." } ] }, { "name": "FOSSA", "url": "https://fossa.com/", "description": "FOSSA is a commercial platform for open-source license compliance and vulnerability management. It provides automated dependency analysis, policy enforcement, attribution and notice file generation, and SBOM export, and integrates with CI pipelines to record findings centrally and report on license obligations across an organisation's portfolio." } ], "mappings": { "owasp_samm": [ "Operations > Environment Management", "Verification > Security Testing" ], "owasp_asvs": [ "V1 Architecture, Design and Threat Modeling" ], "nist_ssdf": [ "PW.4 Reuse Existing, Well-Secured Software When Feasible", "PO.1 Define Security Requirements for Software Development" ], "iso_27001": [ "A.5.32 Intellectual property rights", "A.8.8 Management of technical vulnerabilities" ] } }, { "id": "DSOVS-CODE-007", "code": "CODE-007", "title": "Inline IDE Secure Code Analysis", "phase": "Code/Build", "slug": "CODE-007-Inline-IDE-Secure-Code-Analysis", "status": "complete", "type": "tool", "summary": "Inline IDE secure code analysis is the practice of scanning source code for potential security vulnerabilities and hardcoded secrets directly within the developer's integrated development environment (IDE), as the code is being written.\n\nIt is an important part of DevSecOps because it shifts security findings as far left as possible, to the earliest point in the software lifecycle. Rather than waiting for a pipeline scan or a code review to flag an issue, the developer receives real-time feedback in the editor, alongside the code they are actively working on.\n\nBy surfacing problems while the relevant code is still fresh in the developer's mind, inline analysis makes issues faster and cheaper to fix and reinforces secure coding habits over time. It complements, rather than replaces, the automated scanning performed later in the build pipeline, catching many issues before they are ever committed.", "doc_url": "https://github.com/OWASP/www-project-devsecops-verification-standard/blob/main/document/CODE-007-Inline-IDE-Secure-Code-Analysis.md", "levels": [ { "level": 0, "title": "No tool to assist developer with inline code analysis", "description": "At this level developers write code without any security feedback in their IDE. Vulnerabilities and hardcoded secrets are only discovered later, if at all, through pipeline scans, manual code review, or after deployment. The feedback loop is long, issues are expensive to remediate by the time they surface, and developers receive no in-context guidance to help them avoid insecure patterns in the first place.", "evidence": [] }, { "level": 1, "title": "Verify the use of integrated development environment (IDE) plugin to perform inline secure code or hardcoded secrets analysis with locally defined rules", "description": "Developers install an IDE plugin or extension that performs secure code analysis and hardcoded secret detection as they type, highlighting findings inline. The rules are defined locally, configured by each developer or maintained within an individual project, so the analysis runs entirely on the developer's machine.\n\nThis is a significant improvement on Level 0 because feedback now arrives at the moment code is written, shortening the loop dramatically. However, because configuration is local and per-developer, rule sets drift between team members, coverage is inconsistent, and there is no guarantee that everyone is checking against the same standard.", "evidence": [ "An IDE plugin or extension performing secure code and hardcoded secret analysis is installed in developer environments.", "A demonstration shows findings highlighted inline in the editor as code is written.", "A locally or project-defined rule configuration exists for the plugin.", "Interview confirms which developers have the plugin enabled." ], "diagram": "graph LR; Developer-IDE-- real-time analysis -->Inline-Findings-- fix -->Developer-IDE;" }, { "level": 2, "title": "Verify implementation of centralised managed rules for integrated development environment (IDE) plugin", "description": "The IDE plugins are connected to a centrally managed configuration, so that every developer's editor enforces the same organisation-defined rule set. Rules, severities, and policies are maintained in one place (for example a shared server, configuration file, or policy repository) and distributed to all developers automatically.\n\nThis addresses the inconsistency of Level 1. Security standards are applied uniformly across the team regardless of individual setup, new or updated rules propagate to everyone without manual effort, and the organisation gains confidence that all developers are receiving the same, current security guidance in their IDE.", "evidence": [ "IDE plugins are bound to a centrally managed configuration (for example Connected Mode, a shared server, or a policy repository).", "A single source of truth defines the rule set, severities, and policies applied to all developers.", "Evidence shows updated rules propagating automatically to developer IDEs without manual per-developer effort.", "Interview or configuration confirms all developers enforce the same organisation-defined rule set." ], "diagram": "graph LR;\nCentral-Rules-- pushed to IDEs -->Developer-IDE-- real-time analysis -->Inline-Findings-- fix -->Developer-IDE" }, { "level": 3, "title": "Verify a mechanism to prevent insecure changes to be stored to source code repository", "description": "Level 3 builds on the centrally managed inline analysis of Level 2 by adding an enforcement gate that prevents insecure changes from reaching the source code repository. The same rules that provide inline feedback are enforced at commit or push time, typically through pre-commit hooks, server-side hooks, or branch protection that blocks code containing unresolved security findings or hardcoded secrets.\n\nThis ensures that inline analysis is not merely advisory: insecure code cannot be silently committed even if a developer ignores the in-editor warnings. The effectiveness of the rules and the gate is monitored and periodically reviewed, with findings tracked and rule sets continuously improved, giving the organisation a measured, consistently enforced control at the earliest point in the lifecycle.", "evidence": [ "An enforcement gate (pre-commit hook, server-side hook, or branch protection) blocks commits or pushes containing unresolved findings or hardcoded secrets.", "The gate enforces the same rule set used for inline feedback.", "Findings are tracked centrally and rule sets are continuously improved.", "A documented schedule exists for periodically reviewing the effectiveness of the rules and the gate." ], "diagram": "graph LR;\nCentral-Rules-- pushed to IDEs -->Developer-IDE-- real-time analysis -->Inline-Findings-- fix -->Developer-IDE; Developer-IDE-- commit -->Commit-Gate-- findings recorded -->Centralised-Issue-Tracker" } ], "tools": [ { "name": "SonarLint", "url": "https://github.com/SonarSource/sonarlint-core", "description": "SonarLint is a free IDE extension from SonarSource that provides real-time code quality and security analysis as you type, with support for IDEs such as VS Code, IntelliJ IDEA, Visual Studio, and Eclipse. Issues are highlighted inline with explanations and remediation guidance. In Connected Mode, SonarLint binds to a SonarQube or SonarCloud server so that the rule set and quality profile are managed centrally and shared consistently across the whole team, supporting the centrally managed rules expected at Level 2." }, { "name": "Semgrep", "url": "https://github.com/semgrep/semgrep", "description": "Semgrep is an open-source static analysis tool that uses lightweight, language-aware pattern rules to detect security issues. Its IDE extensions (for example for VS Code and IntelliJ) run rules as developers work and surface findings inline. Rules can be authored locally for a project or pulled from a centrally managed registry, so the same policy can be shared across developers and reused later in CI for end-to-end consistency.\n\nA typical project-level configuration pins the rule sets the IDE extension and CI should use:", "integrations": [ { "platform": "config", "label": null, "link": null, "code": "# .semgrep.yml\nrules:\n - p/security-audit\n - p/secrets\n - p/owasp-top-ten" } ] }, { "name": "Snyk", "url": "https://github.com/snyk/snyk", "description": "Snyk offers IDE plugins (for VS Code, the JetBrains IDEs, Visual Studio, and Eclipse) that bring its security analysis directly into the editor, covering code-level vulnerabilities (Snyk Code), open-source dependency issues, and secrets. Findings appear inline with severity and fix guidance, and when authenticated against a Snyk organisation the applicable rules and policies are governed centrally, keeping IDE feedback aligned with the organisation's standards and with scans performed later in the pipeline." } ], "mappings": { "owasp_samm": [ "Implementation > Secure Build", "Verification > Security Testing" ], "owasp_asvs": [ "V1 Architecture, Design and Threat Modeling", "V14 Configuration" ], "nist_ssdf": [ "PW.7 Review and/or Analyze Human-Readable Code", "PW.8 Test Executable Code to Identify Vulnerabilities and Verify Compliance" ], "iso_27001": [ "A.8.28 Secure coding", "A.8.25 Secure development life cycle" ] } }, { "id": "DSOVS-CODE-008", "code": "CODE-008", "title": "Container Security Scanning", "phase": "Code/Build", "slug": "CODE-008-Container-Security-Scanning", "status": "complete", "type": "tool", "summary": "Container security scanning is a process of analysing the contents of containers to detect any vulnerable components, configuration issues, and malicious code.\n\nThis process is important in DevSecOps as it allows developers to quickly identify any security risks in their container environment, allowing them to take steps to fix them before they become an issue.\n\nBy scanning containers on a regular basis, organisations are able to keep their environments secure and compliant with industry best practices while also allowing them to take advantage of the agility and cost advantages offered by containers.", "doc_url": "https://github.com/OWASP/www-project-devsecops-verification-standard/blob/main/document/CODE-008-Container-Security-Scanning.md", "levels": [ { "level": 0, "title": "No tool to perform container vulnerability analysis", "description": "At this level, there is no scanning tool in place, and vulnerabilities may go undetected until it is too late. Organizations operating at this level are more susceptible to cyber attacks, and may struggle to achieve compliance with industry standards.", "evidence": [] }, { "level": 1, "title": "Verify tool is used to perform on-demand scan for container vulnerability analysis", "description": "Using a tool for on-demand scanning provides some level of security, but requires manual intervention and may cause delays in detecting vulnerabilities. This level can help organizations to quickly identify and address security issues, but may not be sufficient to provide continuous protection.", "evidence": [ "A container scanning tool is installed and available to the team.", "Evidence of at least one scan report produced on demand against a built image.", "Interview confirms who runs the scan and when it is triggered." ] }, { "level": 2, "title": "Verify the implementation of container vulnerability analysis tool into the build pipeline to perform automated scans and report status to the build", "description": "By integrating a container scanning tool into the build pipeline, security checks become automated and vulnerabilities can be detected earlier in the development process. This level enables organizations to scale their DevSecOps practices and ensures that security is incorporated into the software development life cycle.", "evidence": [ "Pipeline configuration shows a container scanning stage that runs automatically on each build.", "Build logs show the scan executing and reporting status back to the build.", "A defined severity threshold causes the build to fail or be flagged." ] }, { "level": 3, "title": "Verify that the findings are automatically recorded to a centralised issue tracker system and periodically review tool's effectiveness", "description": "At this level, the container scanning process is not only automated but also integrated with a central issue tracker system, allowing for greater visibility and easier tracking of security issues. Periodic reviews of the effectiveness of the scanning tool can help organizations continuously improve their security posture and stay ahead of emerging threats.", "evidence": [ "Findings are automatically created in a centralised issue tracker with severity and ownership.", "A documented schedule exists for reviewing the scanner's effectiveness and tuning its configuration.", "Metrics show findings being triaged and remediated over time." ] } ], "tools": [ { "name": "Trivy", "url": "https://github.com/aquasecurity/trivy", "description": "Trivy is a container scanning tool that finds vulnerabilities, misconfigurations, secrets, SBOM in containers, Kubernetes, code repositories, clouds and more.", "integrations": [ { "platform": "github-actions", "label": null, "link": "https://github.com/aquasecurity/trivy-action", "code": "name: build\non:\n push:\n branches:\n - master\n pull_request:\njobs:\n build:\n name: Build\n runs-on: ubuntu-20.04\n steps:\n - name: Checkout code\n uses: actions/checkout@v2\n - name: Build an image from Dockerfile\n run: |\n docker build -t docker.io/my-organization/my-app:${{ github.sha }} .\n - name: Run Trivy vulnerability scanner\n uses: aquasecurity/trivy-action@master\n with:\n image-ref: 'docker.io/my-organization/my-app:${{ github.sha }}'\n format: 'table'\n exit-code: '1'\n ignore-unfixed: true\n vuln-type: 'os,library'\n severity: 'CRITICAL,HIGH'" }, { "platform": "gitlab-ci", "label": null, "link": "https://aquasecurity.github.io/trivy/v0.18.3/integrations/gitlab-ci/", "code": "Trivy_container_scanning:\n stage: test\n image:\n name: alpine:3.11\n variables:\n # Override the GIT_STRATEGY variable in your `.gitlab-ci.yml` file and set it to `fetch` if you want to provide a `clair-whitelist.yml`\n # file. See https://docs.gitlab.com/ee/user/application_security/container_scanning/index.html#overriding-the-container-scanning-template\n # for details\n GIT_STRATEGY: none\n IMAGE: \"$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA\"\n allow_failure: true\n before_script:\n - export TRIVY_VERSION=${TRIVY_VERSION:-v0.19.2}\n - apk add --no-cache curl docker-cli\n - docker login -u \"$CI_REGISTRY_USER\" -p \"$CI_REGISTRY_PASSWORD\" $CI_REGISTRY\n - curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin ${TRIVY_VERSION}\n - curl -sSL -o /tmp/trivy-gitlab.tpl https://github.com/aquasecurity/trivy/raw/${TRIVY_VERSION}/contrib/gitlab.tpl\n script:\n - trivy --exit-code 0 --cache-dir .trivycache/ --no-progress --format template --template \"@/tmp/trivy-gitlab.tpl\" -o gl-container-scanning-report.json $IMAGE\n cache:\n paths:\n - .trivycache/\n artifacts:\n reports:\n container_scanning: gl-container-scanning-report.json\n dependencies: []\n only:\n refs:\n - branches" }, { "platform": "azure-devops", "label": null, "link": "https://github.com/dvuln/devsecops/blob/test/containerscan/trivy-azure.yml", "code": "trigger:\n - master\n\npool:\n vmImage: ubuntu-latest\n\nparameters:\n - name: imageName\n displayName: Docker Image Name\n\nsteps:\n - script: |\n sudo apt-get install wget apt-transport-https gnupg lsb-release\n wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | sudo apt-key add -\n echo deb https://aquasecurity.github.io/trivy-repo/deb $(lsb_release -sc) main | sudo tee -a /etc/apt/sources.list.d/trivy.list\n sudo apt-get update\n sudo apt-get install trivy\n trivy image -f json --output '$(Build.ArtifactStagingDirectory)/trivy-result.json' ${{ parameters.imageName }}\n displayName: \"Run Trivy\"" } ] } ], "mappings": { "owasp_samm": [ "Verification > Security Testing" ], "owasp_asvs": [ "V14 Configuration" ], "nist_ssdf": [ "PW.7 Review and/or Analyze Human-Readable Code", "RV.1 Identify and Confirm Vulnerabilities" ], "iso_27001": [ "A.8.8 Management of technical vulnerabilities" ] }, "credits": [ { "name": "Simar Singh", "url": "https://github.com/simar7" }, { "name": "Teppei Fukuda", "url": "https://github.com/knqyf263" }, { "name": "Yudhi Yudhistira", "url": "https://github.com/devsecurityops" } ] }, { "id": "DSOVS-CODE-009", "code": "CODE-009", "title": "Secure Dependency Management", "phase": "Code/Build", "slug": "CODE-009-Secure-Dependency-Management", "status": "complete", "type": "tool", "summary": "Secure Dependency Management is the process of identifying, managing, and tracking all software dependencies when building, deploying, and managing applications.\n\nIt is an important part of DevSecOps because it helps to ensure that all applications built using open source and commercial dependencies are secure and up-to-date.\n\nBy properly managing dependencies, organizations can help mitigate risk from known vulnerabilities in their application stack and keep critical applications updated with the latest security patches.", "doc_url": "https://github.com/OWASP/www-project-devsecops-verification-standard/blob/main/document/CODE-009-Secure-Dependency-Management.md", "levels": [ { "level": 0, "title": "Direct use of public repositories for third-party dependencies and libraries", "description": "At this level of maturity there is no controlled approach to sourcing third-party code. Developers pull dependencies directly from public registries such as npm, PyPI, Maven Central, NuGet, or RubyGems, typically by adding a package name to a manifest or running an install command on a workstation or build agent.\n\nBecause there is no intermediary between the application and these public sources, the organisation has little visibility into what is being consumed and limited protection against availability outages, package tampering, typosquatting, or dependency confusion attacks. Any package that resolves at build time is trusted implicitly, and a registry change can break or compromise a build without warning.", "evidence": [] }, { "level": 1, "title": "Verity implementation of a private repository to manage third-party dependencies and libraries", "description": "At this stage the organisation introduces a private repository or proxy that sits between developers and the public registries. Tools such as JFrog Artifactory, Sonatype Nexus, or GitHub Packages cache and serve third-party dependencies, so all package requests are routed through a managed, organisation-controlled layer rather than reaching public sources directly.\n\nThis provides a consistent source of truth for builds, protects against upstream availability problems by caching artefacts locally, and gives the organisation a single point at which dependency traffic can later be observed and governed. Build agents and developer environments are configured to resolve packages only through this private repository.", "evidence": [ "A private repository or proxy (for example Artifactory, Nexus, or GitHub Packages) is deployed between developers and public registries.", "Build agent and developer environment configuration resolves packages only through the private repository.", "Evidence shows third-party artefacts being cached and served from the private repository.", "Interview confirms public registries are not accessed directly during builds." ], "diagram": "graph LR; Build-- pulls directly -->Public-Registry-->Dependencies;" }, { "level": 2, "title": "Verify that only verified third-party dependencies and libraries can be used by the application", "description": "Here the private repository is used not just as a cache but as a gate. Only dependencies that have been vetted and approved may be consumed, enforced through allow-lists, curated repositories, or policy rules that block packages failing defined criteria such as known vulnerabilities, restrictive licences, or low reputation.\n\nVerification is strengthened by validating the integrity and origin of artefacts, for example by checking package signatures or provenance attestations, so that consumers can be confident a dependency genuinely originates from its expected publisher. Automated update tooling such as Dependabot or Renovate is introduced to keep approved dependencies current, raising pull requests for new versions so that updates are reviewed and applied in a controlled, repeatable way rather than ad hoc.", "evidence": [ "Policy rules, allow-lists, or curated repositories block packages failing defined criteria (vulnerabilities, licences, reputation).", "Artefact integrity and origin are validated via signature checks or provenance attestations.", "Automated update tooling (Dependabot or Renovate) raises pull requests for new versions of approved dependencies.", "Evidence shows a non-approved package being blocked from consumption." ], "diagram": "graph LR;\nBuild-- code push -->CICD-Pipeline-- resolve via -->Private-Proxy-Registry-- verification -->Approved-Dependencies--verified -->CICD-Pipeline; CICD-Pipeline-- Code Deployment -->Finish" }, { "level": 3, "title": "Verify implementation to monitor application uses of third-party dependencies and libraries with process to retire unused or vulnerable dependencies", "description": "At the highest level of maturity, dependency usage is continuously monitored across the application portfolio. A maintained software bill of materials (SBOM) and ongoing composition analysis give the organisation an accurate, centralised picture of which dependencies each application consumes and how those dependencies map to newly disclosed vulnerabilities.\n\nThis visibility feeds a defined process for retiring dependencies that are no longer needed or that have become vulnerable. Unused packages are removed, vulnerable components are upgraded or replaced according to agreed service levels, and the effectiveness of the overall process is measured and periodically reviewed. Automated update tooling, policy enforcement, and monitoring work together so that the dependency estate is kept lean, current, and continuously improved.", "evidence": [ "A maintained SBOM and ongoing composition analysis provide a centralised inventory of dependencies per application.", "Newly disclosed vulnerabilities are mapped to consumed dependencies and findings recorded centrally.", "A documented process retires unused dependencies and upgrades or replaces vulnerable components according to agreed service levels.", "The effectiveness of the process is measured and periodically reviewed." ], "diagram": "graph LR;\nPrivate-Proxy-Registry-- continuous monitoring -->Dependency-Inventory--findings -->Centralised-Issue-Tracker-- retirement process -->Retire-or-Upgrade-- feeds back -->Private-Proxy-Registry" } ], "tools": [ { "name": "Renovate", "url": "https://github.com/renovatebot/renovate", "description": "Renovate is an automated dependency update tool that scans repositories across many ecosystems, detects outdated or vulnerable dependencies, and raises pull requests to update them. It is highly configurable through a `renovate.json` file, supporting grouping, scheduling, automerge, and vulnerability-driven updates, which makes it well suited to keeping approved dependencies current at scale.\n\nA minimal `renovate.json` configuration committed to the root of a repository:", "integrations": [ { "platform": "config", "label": null, "link": null, "code": "{\n \"$schema\": \"https://docs.renovatebot.com/renovate-schema.json\",\n \"extends\": [\n \"config:recommended\"\n ],\n \"schedule\": [\n \"before 6am on monday\"\n ],\n \"vulnerabilityAlerts\": {\n \"enabled\": true\n },\n \"packageRules\": [\n {\n \"matchUpdateTypes\": [\"minor\", \"patch\"],\n \"automerge\": true\n }\n ]\n}" }, { "platform": "github-actions", "label": null, "link": "https://github.com/renovatebot/github-action", "code": "name: Renovate\non:\n schedule:\n - cron: \"0 4 * * *\" # run once a day at 4 AM\n workflow_dispatch:\njobs:\n renovate:\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v4\n - name: Self-hosted Renovate\n uses: renovatebot/github-action@v40\n with:\n token: ${{ secrets.RENOVATE_TOKEN }}" } ] }, { "name": "Dependabot", "url": "https://github.com/dependabot", "description": "Dependabot is GitHub's native dependency update tool. It monitors a repository's manifests for outdated or vulnerable dependencies and automatically opens pull requests with the necessary updates. It is enabled by committing a `dependabot.yml` file under `.github/`, where update schedules and ecosystems are declared per package manager.\n\nA `.github/dependabot.yml` configuration enabling version and security updates:", "integrations": [ { "platform": "config", "label": null, "link": null, "code": "version: 2\nupdates:\n - package-ecosystem: \"npm\"\n directory: \"/\"\n schedule:\n interval: \"weekly\"\n open-pull-requests-limit: 10\n - package-ecosystem: \"github-actions\"\n directory: \"/\"\n schedule:\n interval: \"weekly\"" } ] } ], "mappings": { "owasp_samm": [ "Operations > Environment Management", "Implementation > Secure Build" ], "owasp_asvs": [ "V1 Architecture, Design and Threat Modeling", "V14 Configuration" ], "nist_ssdf": [ "PW.4 Reuse Existing, Well-Secured Software When Feasible", "PS.3 Archive and Protect Each Software Release", "RV.1 Identify and Confirm Vulnerabilities" ], "iso_27001": [ "A.8.8 Management of technical vulnerabilities", "A.8.28 Secure coding" ] } }, { "id": "DSOVS-TEST-001", "code": "TEST-001", "title": "Security Test Management", "phase": "Test", "slug": "TEST-001-Security-Test-Management", "status": "complete", "type": "process", "summary": "Security test management is concerned with how the environments and data used for security testing are provisioned, separated and maintained. Effective security testing depends on having somewhere safe to run intrusive checks, and on that environment behaving closely enough to production that the results are meaningful and trustworthy.\n\nA central concern is isolation. Security tests can be destructive, generate large volumes of traffic, or deliberately attempt to exploit weaknesses, so they should never run against live production systems or against real customer data. At the same time, an environment that drifts too far from production produces misleading results: vulnerabilities present in production may be missed, and findings raised in the test environment may not be reproducible where it matters.\n\nAs this capability matures, organisations move from ad-hoc, manually prepared environments towards environments that are kept aligned with production, populated with realistic but non-sensitive test data, and ultimately provisioned and refreshed on demand. The goal is to make high-fidelity, repeatable security testing cheap and routine rather than a bespoke effort each time.", "doc_url": "https://github.com/OWASP/www-project-devsecops-verification-standard/blob/main/document/TEST-001-Security-Test-Management.md", "levels": [ { "level": 0, "title": "Test environment is different from prod and test data is not prepared", "description": "At this level there is no managed approach to security test environments or test data. Testing, where it happens at all, may rely on whatever environment is convenient, and that environment differs from production in ways that are neither understood nor controlled. Configuration, dependencies and topology diverge arbitrarily, so any security testing performed against it gives little assurance about the real production system.\n\nNo deliberate test data is prepared. Testers either work with empty or trivial datasets that fail to exercise realistic code paths, or worse, resort to copies of production data containing sensitive information without proper handling. In both cases the foundations needed for credible, repeatable security testing are absent.", "evidence": [] }, { "level": 1, "title": "Verify that the environment used for testing is different from production environment and test data is prepared", "description": "At this level the organisation deliberately separates testing from production. Security testing is carried out in a dedicated environment that is isolated from live systems and customers, so intrusive or destructive checks can be performed without putting production stability or real data at risk.\n\nTest data is also prepared rather than left to chance. A purpose-built dataset is created to exercise the application's important functionality and security-relevant paths, and it avoids exposing real sensitive or personally identifiable information. This gives testers a stable, repeatable baseline and removes the temptation to test against raw production copies. The environment and data are still largely set up by hand and may be created once and reused, but the essential separation and intent are now in place.", "evidence": [ "A dedicated, named test environment exists that is documented as separate from production.", "Network or access controls demonstrate the test environment is isolated from live systems and customers.", "A prepared test dataset exists and review confirms it contains no real sensitive or personally identifiable information.", "Interview confirms security testing is performed against the test environment rather than production." ], "diagram": "graph LR; Test-Environment-- separated from -->Production; Test-Environment-- uses -->Prepared-Test-Data-- runs -->Security-Tests;" }, { "level": 2, "title": "Verify that the test environment is maintained and configured to align with changes to production environment and test data is prepared", "description": "This level improves on the previous one by keeping the test environment deliberately aligned with production over time. Rather than being stood up once and allowed to drift, the environment is actively maintained so that configuration, dependencies, infrastructure and topology track changes made to production. As production evolves, the test environment is updated to match, which keeps security testing representative and reduces the risk of false confidence or unreproducible findings.\n\nPrepared, non-sensitive test data continues to underpin testing, and it is curated to remain relevant as the application changes. Because the environment now mirrors production more faithfully, results carry greater weight: a vulnerability found in test is a strong indication of one in production, and a clean result is more credible. Maintaining this alignment typically requires documented configuration and a process to propagate production changes into the test environment.", "evidence": [ "A documented process exists for propagating production configuration and dependency changes into the test environment.", "Configuration management or change records show the test environment being updated to track production changes.", "The prepared test dataset is curated and updated as the application evolves.", "Comparison of test and production configuration shows them aligned within a defined tolerance." ], "diagram": "graph LR; Production-- changes propagated -->Aligned-Test-Environment-- uses -->Prepared-Test-Data-- runs -->Security-Tests;" }, { "level": 3, "title": "Verify that the test environment is identical to production and test data is created on-demands", "description": "At the highest level of maturity, the test environment is effectively identical to production, and both the environment and its data can be provisioned on demand. Infrastructure-as-code, automated provisioning and configuration management are used to spin up a faithful replica of production whenever it is needed, eliminating manual drift and removing the need to keep a long-lived environment carefully patched by hand.\n\nTest data is likewise generated on demand, producing realistic, fit-for-purpose datasets that are free of real sensitive information and tailored to the test at hand. This makes thorough security testing fast, repeatable and consistent: teams can create a clean, production-equivalent environment and dataset for any test run, exercise it intensively, and tear it down afterwards. The result is high-fidelity security testing that scales with the organisation and integrates naturally into routine delivery.", "evidence": [ "Infrastructure-as-code definitions exist that provision a production-equivalent test environment on demand.", "Pipeline or automation logs show an environment being spun up and torn down for a test run.", "Test data is generated on demand by an automated mechanism, and review confirms it is free of real sensitive information.", "The same IaC source is demonstrably used to provision both production and the test replica." ], "diagram": "graph LR; Infrastructure-as-Code-- provisions on-demand -->Identical-Test-Environment-- generates on-demand -->Test-Data-- runs -->Security-Tests-- teardown -->Infrastructure-as-Code;" } ], "further_reading": [ { "url": "https://owasp.org/www-project-web-security-testing-guide/", "note": "guidance on planning and executing web application security testing, including the testing environment." }, { "url": "https://owaspsamm.org/model/verification/", "note": "the Security Testing and Requirements-driven Testing practices that this capability supports." }, { "url": "https://csrc.nist.gov/Projects/ssdf", "note": "practices for preparing environments and protecting test data within the secure development lifecycle." }, { "url": "https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/", "note": "background on avoiding the use of real production/sensitive data in test environments." } ], "mappings": { "owasp_samm": [ "Verification > Security Testing" ], "owasp_asvs": [ "V1 Architecture, Design and Threat Modeling", "V14 Configuration" ], "nist_ssdf": [ "PO.3 Implement Supporting Toolchains", "RV.1 Identify and Confirm Vulnerabilities" ], "iso_27001": [ "A.8.31 Separation of development, test and production environments", "A.8.33 Test information" ] } }, { "id": "DSOVS-TEST-002", "code": "TEST-002", "title": "Dynamic Application Security Testing (DAST)", "phase": "Test", "slug": "TEST-002-Dynamic-Application-Security-Testing-DAST", "status": "complete", "type": "tool", "summary": "Dynamic Application Security Testing (DAST) involves analyzing an application's security while it is running in order to detect any vulnerabilities.\n\nIt focuses on assessing an application and examining the behavior of the application to identify potential issues without requiring a deep understanding of the source code.\n\nThis type of testing is operational and behavioral, as testers look for problems that occur in use and trace them back to their origins in the software design. DAST is useful for basic security on evolving projects and for meeting industry-standard compliance.", "doc_url": "https://github.com/OWASP/www-project-devsecops-verification-standard/blob/main/document/TEST-002-Dynamic-Application-Security-Testing-DAST.md", "levels": [ { "level": 0, "title": "No tool to perform dynamic application security testing", "description": "At this level of security maturity, there are no tools available to perform Dynamic Application Security (DAST) scanning.", "evidence": [] }, { "level": 1, "title": "Verify use of tool to perform on-demand scan to identify application vulnerabilities in its running state", "description": "At this stage, a DAST tool is present but the scanning is performed on a case-by-case basis. It is not automated and the results may not be reported or recorded.", "evidence": [ "A DAST tool is installed and available to the team.", "Evidence of at least one scan report produced on demand against a running instance of the application.", "Interview confirms who runs the scan and when it is triggered." ], "diagram": "graph LR; Start-- DAST Scan -->Target-Application;" }, { "level": 2, "title": "Verify the implementation of the dynamic application security testing tool into the build pipeline to perform automated scans and report status to the build", "description": "Here, DAST scanning is implemented into the software build pipeline. This means that whenever a build is executed, an automated DAST scan will be triggered and the results will be reported.", "evidence": [ "Pipeline configuration shows a DAST scanning stage that runs automatically on each build.", "Build logs show the DAST scan executing against the running application and reporting status back to the build.", "A defined severity threshold causes the build to fail or be flagged." ], "diagram": "graph LR;\nStart-- code push -->CICD-Pipeline-- DAST Scan -->Target-Application--DAST Results -->CICD-Pipeline; Target-Application-- Code Deployment -->Finish" }, { "level": 3, "title": "Verify that the findings are automatically recorded to a centralised issue tracker system and periodically review tool's effectiveness", "description": "Level 3 of Dynamic Application Security (DAST) is the same as level 2, with the addition of all identified security vulnerabilities being recorded in a centralised issue tracking system and periodically reviewed to evaluate the effectiveness of the DAST tool. This means that the same type of automated scans are being performed, but the results are being collected, tracked and analysed for future use and improvement.\n\nAdditionally, more mature organisations with DAST implementations often\nprovide teams simplified configuration guidance, such as example CI/CD templates and common configuration options that are organisation specific, such as proxy configuration or fetching an OpenAPI Specification (OAS) file - making adoption of DAST amongst teams easier.", "evidence": [ "DAST findings are automatically created in a centralised issue tracker with severity and ownership.", "A documented schedule exists for reviewing the DAST tool's effectiveness and tuning its configuration.", "Reusable CI/CD templates or organisation-specific configuration guidance (e.g. proxy settings or OAS files) are provided to teams." ], "diagram": "graph LR;\nStart-- code push -->CICD-Pipeline-- DAST Scan -->Target-Application--DAST Results -->Centralised-Issue-Tracker; Target-Application-- Code Deployment -->Finish" } ], "tools": [ { "name": "OWASP ZAP", "url": "https://github.com/zaproxy/zaproxy", "description": "The OWASP Zed Attack Proxy (ZAP) is one of the world's most popular free security tools and is actively maintained by a dedicated international team of volunteers. It can help you automatically find security vulnerabilities in your web applications while you are developing and testing your applications. It's also a great tool for experienced pentesters to use for manual security testing.", "integrations": [ { "platform": "github-actions", "label": null, "link": "https://github.com/zaproxy/zaproxy", "code": "on: [push]\n\njobs:\n zap_scan:\n runs-on: ubuntu-latest\n name: Scan the webapplication\n steps:\n - name: Checkout\n uses: actions/checkout@v2\n with:\n ref: master\n - name: ZAP Scan\n uses: zaproxy/action-baseline@v0.7.0\n with:\n token: ${{ secrets.GITHUB_TOKEN }}\n docker_name: 'owasp/zap2docker-stable'\n target: 'https://www.zaproxy.org'\n rules_file_name: '.zap/rules.tsv'\n cmd_options: '-a'" }, { "platform": "gitlab-ci", "label": null, "link": "https://gitlab.com/gitlab-org/security-products/dependencies/zaproxy", "code": "dast:\n image: registry.gitlab.com/gitlab-org/security-products/zaproxy\n variables:\n website: \"https://example.com\"\n script:\n - mkdir /zap/wrk/\n - /zap/zap-baseline.py -J gl-dast-report.json -t $website || true\n - cp /zap/wrk/gl-dast-report.json .\n artifacts:\n paths: [gl-dast-report.json]" }, { "platform": "azure-devops", "label": null, "link": "https://medium.com/adessoturkey/owasp-zap-security-tests-in-azure-devops-fe891f5402a4", "code": "resources:\n repositories:\n - repository: \n type: git\n name: /\n ref: refs/heads/master\n\ntrigger: none\n\nstages:\n- stage: 'buildstage'\n jobs:\n - job: 'buildjob'\n pool:\n vmImage: 'ubuntu-latest'\n steps:\n - checkout: self\n - checkout: \n\n - bash: docker run -d -p : \n displayName: 'App Container'\n\n - bash: |\n chmod -R 777 ./\n docker run --rm -v $(pwd):/zap/wrk/:rw -t owasp/zap2docker-stable zap-full-scan.py -t http://$(ip -f inet -o addr show docker0 | awk '{print $4}' | cut -d '/' -f 1): -x\nxml_report.xml\n true\n displayName: 'Owasp Container Scan'\n\n - powershell: |\n $XslPath = \"/xml_to_nunit.xslt\"\n $XmlInputPath = \"xml_report.xml\"\n $XmlOutputPath = \"converted_report.xml\"\n $XslTransform = New-Object System.Xml.Xsl.XslCompiledTransform\n $XslTransform.Load($XslPath)\n $XslTransform.Transform($XmlInputPath, $XmlOutputPath)\n displayName: 'PowerShell Script'\n - task: PublishTestResults@2\n displayName: 'Publish Test Results'\n inputs:\n testResultsFormat: 'NUnit'\n testResultsFiles: 'converted_report.xml'" } ] }, { "name": "Nuclei", "url": "https://github.com/projectdiscovery/nuclei", "description": "Nuclei is used to send requests across targets based on a template, leading to zero false positives and providing fast scanning on a large number of hosts. Nuclei offers scanning for a variety of protocols, including TCP, DNS, HTTP, SSL, File, Whois, Websocket, Headless etc. With powerful and flexible templating, Nuclei can be used to model all kinds of security checks.", "integrations": [ { "platform": "github-actions", "label": null, "link": "https://github.com/projectdiscovery/nuclei-action", "code": "name: Nuclei - Vulnerability Scan\n\non:\n schedule:\n - cron: '0 0 * * *'\n workflow_dispatch:\n\njobs:\n nuclei-scan:\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v2\n\n - name: Nuclei - Vulnerability Scan\n uses: projectdiscovery/nuclei-action@main\n with:\n target: https://example.com\n\n - name: GitHub Workflow artifacts\n uses: actions/upload-artifact@v2\n with:\n name: nuclei.log\n path: nuclei.log\n\n - name: GitHub Security Dashboard Alerts update\n uses: github/codeql-action/upload-sarif@v2\n with:\n sarif_file: nuclei.sarif" } ] } ], "mappings": { "owasp_samm": [ "Verification > Security Testing" ], "owasp_asvs": [ "V1 Architecture, Design and Threat Modeling", "V14 Configuration" ], "nist_ssdf": [ "PW.8 Test Executable Code to Identify Vulnerabilities", "RV.1 Identify and Confirm Vulnerabilities" ], "iso_27001": [ "A.8.8 Management of technical vulnerabilities", "A.8.29 Security testing in development and acceptance" ] }, "credits": [ { "name": "Manas Peçenek", "url": "https://www.linkedin.com/in/manas-pecenek-1812pr/" } ] }, { "id": "DSOVS-TEST-003", "code": "TEST-003", "title": "Interactive Application Security Testing (IAST)", "phase": "Test", "slug": "TEST-003-Interactive-Application-Security-Testing-IAST", "status": "complete", "type": "tool", "summary": "Interactive Application Security Testing (IAST) works from inside a running application. An instrumentation agent is attached to the application at runtime and observes code as it actually executes while the software is exercised by functional or automated tests. Because the agent can see the source code, data flow, configuration, libraries and HTTP traffic all at once, it can confirm whether a suspected weakness is genuinely reachable and exploitable.\n\nThis inside-out perspective lets IAST combine the strengths of SAST and DAST. Like SAST it can pinpoint the exact line of vulnerable code, and like DAST it only reports issues that occur during real execution. The result is high-accuracy findings with very low false-positive rates, produced as a natural by-product of the testing teams are already running.\n\nBy surfacing vulnerabilities earlier and tying them directly to the code that caused them, IAST helps developers and security teams triage and resolve issues quickly, across the entire application stack and for both known and previously unseen weaknesses.", "doc_url": "https://github.com/OWASP/www-project-devsecops-verification-standard/blob/main/document/TEST-003-Interactive-Application-Security-Testing-IAST.md", "levels": [ { "level": 0, "title": "No tool to perform interactive application security testing", "description": "At this level there is no IAST capability in place. No runtime instrumentation or agent is attached to the application, so no security analysis is gathered while the software runs. Any vulnerabilities that depend on real execution behaviour go undetected by this class of tooling, and the organisation relies solely on other techniques such as static or dynamic analysis.", "evidence": [] }, { "level": 1, "title": "Verify use of tool to perform on-demand scan to identify insecure code when the running application is being functionally tested", "description": "At this stage an IAST agent is available and used, but only on a case-by-case basis. A team will manually attach the agent to a running instance of the application and then exercise it through functional testing to observe what the instrumentation reports. This already improves on Level 0, because issues are now confirmed against live execution rather than missed entirely.\n\nHowever, the activity is ad-hoc and depends on someone remembering to run it. The agent is not part of any automated test run, and the findings are typically not recorded or reported in a consistent way, so coverage and follow-up vary from one effort to the next.", "evidence": [ "An IAST agent is installed and available to the team.", "Evidence that the agent has been attached to a running application and exercised through functional testing at least once.", "At least one set of IAST findings produced on demand is available for review.", "Interview confirms who attaches the agent and when it is run." ], "diagram": "graph LR; Functional-Test-- exercises -->Instrumented-Application-- IAST Findings -->Tester;" }, { "level": 2, "title": "Verify the implementation of the interactive application security testing tool into the build pipeline to perform automated scans and report status to the build", "description": "Here the IAST agent is integrated into the build pipeline and attached automatically whenever the application is launched for its automated test suite. As integration, end-to-end and QA tests drive the running application, the agent continuously observes execution and detects vulnerabilities in the background, then reports the outcome back to the build.\n\nThis removes the manual, on-demand nature of Level 1. Every pipeline run that exercises the application produces consistent IAST coverage and feeds the result into the build status, so security analysis happens repeatably without anyone having to remember to trigger it.", "evidence": [ "Pipeline configuration shows the IAST agent being attached automatically when the application is launched for testing.", "Build logs show the agent observing execution during automated tests and reporting status back to the build.", "IAST results are tied to a build outcome (e.g. a threshold that flags or fails the build)." ], "diagram": "graph LR;\nStart-- code push -->CICD-Pipeline-- attach IAST agent -->Instrumented-Application;\nCICD-Pipeline-- run automated tests -->Instrumented-Application-- IAST Findings -->CICD-Pipeline;\nInstrumented-Application-- Code Deployment -->Finish" }, { "level": 3, "title": "Verify that the findings are automatically recorded to a centralised issue tracker system and periodically review tool's effectiveness", "description": "Level 3 builds on the automated integration of Level 2 by ensuring that every finding flows automatically into a centralised issue tracking system, alongside vulnerabilities discovered by other means. Issues are managed, prioritised and remediated through the same workflow the organisation uses for the rest of its security work, so nothing slips through the gaps.\n\nIn addition, the effectiveness of the IAST tooling is reviewed periodically. Teams examine which weaknesses the agent is catching, tune its configuration and coverage, and feed lessons back into the process so the capability keeps improving over time rather than standing still.", "evidence": [ "IAST findings are automatically created in a centralised issue tracker with severity and ownership.", "A documented schedule exists for reviewing the IAST tool's effectiveness, coverage and configuration.", "Metrics show IAST findings being triaged and remediated through the same workflow as other security findings." ], "diagram": "graph LR;\nStart-- code push -->CICD-Pipeline-- attach IAST agent -->Instrumented-Application;\nCICD-Pipeline-- run automated tests -->Instrumented-Application-- IAST Findings -->Centralised-Issue-Tracker;\nInstrumented-Application-- Code Deployment -->Finish" } ], "tools": [ { "name": "Contrast Community Edition", "url": "https://www.contrastsecurity.com/contrast-community-edition", "description": "Contrast Community Edition (CE) provides runtime IAST (and runtime protection) for a single application, free of charge. The agent is attached to the application process rather than invoked as a separate scan step, so it observes vulnerabilities while your existing functional and automated tests exercise the app.", "integrations": [ { "platform": "cli", "label": "JVM agent attachment", "link": null, "code": "java -javaagent:/opt/contrast/contrast-agent.jar \\\n -Dcontrast.config.path=/etc/contrast/contrast_security.yaml \\\n -jar my-application.jar" } ] } ], "mappings": { "owasp_samm": [ "Verification > Security Testing" ], "owasp_asvs": [ "V1 Architecture, Design and Threat Modeling", "V14 Configuration" ], "nist_ssdf": [ "PW.8 Test Executable Code to Identify Vulnerabilities", "RV.1 Identify and Confirm Vulnerabilities" ], "iso_27001": [ "A.8.8 Management of technical vulnerabilities", "A.8.29 Security testing in development and acceptance" ] } }, { "id": "DSOVS-TEST-004", "code": "TEST-004", "title": "Penetration Testing", "phase": "Test", "slug": "TEST-004-Penetration-Testing", "status": "complete", "type": "process", "summary": "Penetration testing is manual, human-driven security testing in which skilled testers attempt to find and exploit weaknesses the way a real attacker would. It goes well beyond automated scanning: a tester reasons about business logic, chains together several lower-severity issues, and explores paths that tools cannot understand, surfacing vulnerabilities before malicious actors can.\n\nThis kind of testing provides genuine insight into the security posture of a system. Rather than a list of isolated scanner findings, it produces a picture of how an application could realistically be compromised, which helps organisations make informed decisions about where to invest in defences.\n\nBy revealing potential risks in context, penetration testing allows organisations to design and implement strategies that prevent security incidents, and to validate that their existing controls actually hold up under pressure.", "doc_url": "https://github.com/OWASP/www-project-devsecops-verification-standard/blob/main/document/TEST-004-Penetration-Testing.md", "levels": [ { "level": 0, "title": "Penetration testing activity is ad-hoc and not scheduled", "description": "At this level there is no planned penetration testing. If any manual testing happens at all, it is sporadic and reactive, perhaps prompted by an incident or an individual's initiative. There is no defined scope, no regular cadence and no expectation that significant changes will be tested, so the organisation has little assurance about the security posture of its applications.", "evidence": [] }, { "level": 1, "title": "Verify that annual penetration testing activity is performed", "description": "At this stage penetration testing is carried out on request or on a roughly annual basis, often to satisfy a compliance requirement or a customer expectation. A tester is engaged, given a scope, and produces a report of findings, which is a clear improvement on the ad-hoc situation at Level 0 because at least some human-led testing happens predictably.\n\nThe limitation is timing and coverage. A single annual engagement is easily outpaced by the rate of change in modern software, so meaningful changes shipped between tests may never receive manual scrutiny, and remediation of findings is not always tracked through to closure.", "evidence": [ "A penetration test report dated within the last twelve months exists for the application.", "A scope document or statement of work defines what was assessed for the engagement.", "Interview confirms a recurring (at least annual) cadence is planned or contractually required." ], "diagram": "graph LR; Annual-Request-- pentest -->Application-- findings -->Report;" }, { "level": 2, "title": "Verify that penetration testing is performed per release or per feature", "description": "Here penetration testing is scheduled and scoped around the software delivery process rather than the calendar. Significant releases and substantial new features are assessed before or shortly after they ship, with a defined scope agreed for each engagement. This ties manual testing to the moments when risk is actually introduced, so important changes are reviewed by a human while they are still fresh.\n\nBecause testing is now repeatable and aligned to delivery, coverage is far more consistent than an annual snapshot. Findings are reported back to the responsible teams and feed into the development lifecycle, although the depth and continuity of tracking can still vary between engagements.", "evidence": [ "Multiple test reports exist that correspond to specific releases or features rather than a calendar cadence.", "A documented policy or release checklist requires a penetration test for significant releases or features.", "Findings are demonstrably reported back to the responsible development teams." ], "diagram": "graph LR; Release-Scope-- pentest -->Application-- findings -->Report-- reported to -->Development-Teams;" }, { "level": 3, "title": "Verify that penetration testing is performed per feature regardless of release cycle and findings are recorded to a centralised issue tracker system", "description": "At the highest level penetration testing is a continuous, measured programme. Features are assessed as they are built, independent of the release cycle, and the activity is run as an ongoing capability rather than a series of disconnected projects. Every finding is recorded in a centralised issue tracking system and managed alongside the organisation's other security issues.\n\nCrucially, the loop is closed: remediation is tracked through to resolution and fixes are retested to confirm they hold. Metrics drawn from the tracker, such as time-to-remediate and recurring issue classes, let the organisation measure the programme's effectiveness and continuously improve both its testing and its underlying engineering practices.", "evidence": [ "Penetration test findings are recorded as tickets in a centralised issue tracker with severity and ownership.", "Evidence of retesting shows that remediated findings were re-verified and confirmed fixed.", "Programme metrics (e.g. time-to-remediate, recurring issue classes) are produced from the tracker and reviewed." ], "diagram": "graph LR; Per-Feature-Scope-- continuous pentest -->Application-- findings -->Centralised-Issue-Tracker-- remediation -->Retest-- metrics -->Continuous-Improvement;" } ], "tools": [ { "name": "Metasploit", "url": "https://www.metasploit.com/", "description": "Metasploit is a widely used exploitation framework that assists a tester in developing and executing exploit code against a target. It aids a skilled practitioner rather than replacing the judgement and attacker mindset that a penetration test depends on." }, { "name": "OWASP ZAP", "url": "https://github.com/zaproxy/zaproxy", "description": "OWASP ZAP (Zed Attack Proxy) is an open source web application security testing proxy commonly used to assist a tester in intercepting, inspecting and manipulating application traffic during a manual assessment." } ], "further_reading": [ { "url": "https://owasp.org/www-project-web-security-testing-guide/", "note": "OWASP Web Security Testing Guide (WSTG)" }, { "url": "http://www.pentest-standard.org/", "note": "Penetration Testing Execution Standard (PTES)" }, { "url": "https://csrc.nist.gov/publications/detail/sp/800-115/final", "note": "NIST SP 800-115 - Technical Guide to Information Security Testing and Assessment" } ], "mappings": { "owasp_samm": [ "Verification > Security Testing" ], "owasp_asvs": [ "V1 Architecture, Design and Threat Modeling" ], "nist_ssdf": [ "PW.8 Test Executable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements", "RV.1 Identify and Confirm Vulnerabilities on an Ongoing Basis" ], "iso_27001": [ "A.8.8 Management of technical vulnerabilities", "A.8.29 Security testing in development and acceptance" ] } }, { "id": "DSOVS-TEST-005", "code": "TEST-005", "title": "Security Test Coverage", "phase": "Test", "slug": "TEST-005-Security-Test-Coverage", "status": "complete", "type": "process", "summary": "Security test coverage is concerned with how comprehensively security testing actually exercises the application: its codebase, its attack surface and its security requirements. It is entirely possible to run security tests regularly yet still leave significant parts of the system unexamined, so this capability is about understanding, measuring and steadily increasing what the testing genuinely covers.\n\nCoverage is best understood relative to a defined baseline of expectations. Mapping tests to a control framework such as the OWASP Application Security Verification Standard (ASVS) gives an objective yardstick: it makes clear which security requirements are tested, which are not, and where gaps exist between the agreed scope and the work actually performed.\n\nAs this capability matures, organisations move from having no defined testing scope, through clearly delineating what is in and out of scope, to measuring coverage against requirements and finally to tracking coverage over time and continuously closing gaps. The aim is to replace a vague sense that \"security testing happens\" with a measured, improving picture of how much of the application is genuinely assured.", "doc_url": "https://github.com/OWASP/www-project-devsecops-verification-standard/blob/main/document/TEST-005-Security-Test-Coverage.md", "levels": [ { "level": 0, "title": "No security testing scope", "description": "At this level there is no defined scope for security testing, and consequently no notion of coverage at all. Testing, if it occurs, is opportunistic and undirected, and there is no statement of which components, interfaces or security requirements are meant to be examined.\n\nBecause nothing is defined, nothing can be measured. It is impossible to say whether the parts of the application most exposed to risk have been tested, and large portions of the attack surface may never be looked at. Any assurance the organisation has from security testing is incidental rather than the result of a deliberate, bounded effort.", "evidence": [] }, { "level": 1, "title": "Verify that the security testing scope and out-of-scope are defined", "description": "At this level the organisation explicitly defines what security testing is intended to cover and, just as importantly, what it is not. The in-scope and out-of-scope components, interfaces, environments and requirements are written down, giving testers a clear remit and stakeholders a clear understanding of the boundaries of the assurance being provided.\n\nThis is the first step towards meaningful coverage. With scope defined, it becomes possible to reason about whether testing has addressed everything it was meant to, and to make deliberate, recorded decisions about exclusions rather than leaving gaps by accident. Coverage at this stage is still understood largely qualitatively and assessed by hand, but the boundaries that make measurement possible are now in place.", "evidence": [ "A written scope document lists the in-scope components, interfaces, environments and requirements.", "The same document records explicit out-of-scope items and the rationale for excluding them.", "Interview confirms testers and stakeholders reference the scope document when planning testing." ], "diagram": "graph LR; Attack-Surface-- defines -->In-Scope; Attack-Surface-- defines -->Out-of-Scope; In-Scope-- guides -->Security-Tests;" }, { "level": 2, "title": "Verify implementation of security regression testing", "description": "This level improves on the previous one by ensuring that security coverage is not lost over time. Security regression testing is implemented so that previously identified vulnerabilities, and the security requirements already verified, are re-tested as the application changes. Fixes are confirmed to stay fixed, and controls that once passed are checked again after each significant change.\n\nBy turning past findings and verified requirements into a repeatable test suite, coverage becomes cumulative rather than a snapshot. Mapping these regression tests to security requirements - for example to ASVS controls - makes the growing body of covered behaviour explicit and prevents previously assured areas from quietly regressing. Coverage is now measured against a baseline of requirements rather than merely scoped, giving a clearer view of what is consistently protected.", "evidence": [ "A repeatable security regression test suite exists that re-tests previously identified vulnerabilities.", "Regression tests are mapped to security requirements (e.g. ASVS controls) and run on significant changes.", "A coverage report shows which requirements the regression suite exercises." ], "diagram": "graph LR; Security-Requirements-- mapped to -->Regression-Tests-- coverage measured -->Coverage-Report;" }, { "level": 3, "title": "Verify that security test coverage is continuously monitored and increased", "description": "At the highest level of maturity, security test coverage is continuously monitored and deliberately expanded over time. The proportion of the codebase, attack surface and security requirements exercised by testing is tracked as a metric, mapped against a framework such as ASVS, and reviewed so that gaps are visible and trends are understood.\n\nBuilding on the regression testing of the previous level, the organisation treats coverage as something to be actively improved rather than merely maintained. Identified gaps drive new tests, coverage targets are set and monitored, and the effectiveness of the testing is periodically reassessed against evolving threats and requirements. This turns security testing into a measured, continuously improving capability in which the organisation can state with confidence how much of its application is assured and demonstrate that the figure is rising.", "evidence": [ "A coverage metric mapped against a framework such as ASVS is tracked over time and trended.", "Coverage targets are defined and identified gaps are recorded as work items that drive new tests.", "Periodic reviews reassess testing effectiveness against evolving threats and requirements." ], "diagram": "graph LR; Security-Requirements-- mapped to -->Security-Tests-- coverage measured -->Coverage-Report-- gaps drive -->New-Tests-- continuously improved -->Security-Tests;" } ], "further_reading": [ { "url": "https://owasp.org/www-project-application-security-verification-standard/", "note": "OWASP Application Security Verification Standard (ASVS) - a framework of security requirements that testing coverage can be mapped against and measured." }, { "url": "https://owasp.org/www-project-web-security-testing-guide/", "note": "OWASP Web Security Testing Guide (WSTG) - a structured catalogue of tests that helps define and broaden the scope of security testing." }, { "url": "https://owasp.org/www-project-code-review-guide/", "note": "Code coverage vs. security coverage (OWASP Code Review Guide) - discussion of why traditional code coverage metrics do not equate to security coverage." }, { "url": "https://csrc.nist.gov/Projects/ssdf", "note": "NIST SP 800-218 Secure Software Development Framework (SSDF) - practices for defining, performing and continuously improving security testing across the development lifecycle." } ], "mappings": { "owasp_samm": [ "Verification > Security Testing", "Verification > Requirements-driven Testing" ], "owasp_asvs": [ "V1 Architecture, Design and Threat Modeling" ], "nist_ssdf": [ "PW.8 Test Executable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements", "RV.1 Identify and Confirm Vulnerabilities on an Ongoing Basis" ], "iso_27001": [ "A.8.29 Security testing in development and acceptance" ] } }, { "id": "DSOVS-REL-001", "code": "REL-001", "title": "Artifact Signing", "phase": "Release/Deploy", "slug": "REL-001-Artifact-Signing", "status": "complete", "type": "tool", "summary": "Artifact signing is a security process that ensures the integrity of an artifact/binary that is released by a developer.\n\nThis is done by using cryptographic and digital signing techniques to ensure that the artifact has not been tampered with and no malicious code has been inserted into it\n\nArtifact signing is important for DevSecOps because it allows organizations to quickly and easily verify the authenticity of their software or applications before allowing them to be deployed into production environments. More recently, Code Signing has gained in popularity due to Supply Chain Security attacks, and used as one method in the application of security to build pipelines.\n\nIt also provides a measure of assurance that their applications are secure and trustworthy, helping to build customer trust and loyalty.", "doc_url": "https://github.com/OWASP/www-project-devsecops-verification-standard/blob/main/document/REL-001-Artifact-Signing.md", "levels": [ { "level": 0, "title": "No package/code signing process defined", "description": "At this level, software deliverables are not digitally signed, leaving them vulnerable to unauthorized code access. There is no auditability or integrity assurance behind the software. Organizations operating at this level face significant security risks and lack the means to verify the authenticity of their code.", "evidence": [] }, { "level": 1, "title": "Basic code signing with self managed keys", "description": "In this stage, software deliverables are signed, but the tools and processes are fragmented. Developers may handle their own private keys without centralized control, which can lead to key misuse or compromise. While some level of security is introduced, it falls short of ensuring comprehensive code integrity, authenticity, non-falsifiability and is not tamper proof.", "evidence": [ "Released artifacts carry a verifiable digital signature that can be checked with a signing tool.", "A documented signing procedure exists, even if keys are managed by individual developers.", "Interview confirms which developers hold signing keys and how signatures are produced." ] }, { "level": 2, "title": "Centralized code signing with enhanced key security", "description": "Level 2 involves the use of a centralized platform for code signing policy, workflow, and auditability. It also emphasizes the protection of sensitive signing keys in a secure Hardware Security Module (HSM). However, at this stage, code signing is not yet fully integrated with CI/CD processes or workflows, and not all use cases are covered. While this level offers improved security, it still lacks the full automation and integration required for DevSecOps. Typically at this level, organisations leverage key manage solutions such as AWS KMS, HashiCorp Vault, etc.", "evidence": [ "Signing keys are stored in an HSM or managed key service (e.g. AWS KMS, HashiCorp Vault) rather than on developer machines.", "A centralized signing platform enforces signing policy and produces an audit log of signing operations.", "Access to signing keys is restricted and the access policy is documented." ] }, { "level": 3, "title": "Fully CI/CD integrated code signing and governance", "description": "At the highest level of this code signing maturity model, organizations have achieved full integration of code signing into their CI/CD processes. This means that all containers, artifacts, and software deliverables are signed. The implementation is seamlessly integrated with native signing tools and workflows, ensuring full auditability and governance over all signing processes. This level provides the highest level of security, code integrity, and authenticity, meeting the demands of modern DevSecOps practices. Typically at this level, organisations adopt keyless signing (a newer signing technique where you do not handle long-lived signing keys).", "evidence": [ "CI/CD pipeline configuration shows every container, artifact and deliverable is signed automatically as part of the build/release.", "Keyless / OIDC-based signing (e.g. Sigstore) is used so no long-lived signing keys are handled.", "Signature verification is enforced at deploy time and signing activity is fully auditable." ] } ], "tools": [ { "name": "cosign", "url": "https://github.com/sigstore/cosign", "description": "cosign is an open source CLI utility for signing softwae artifacts, such as container images or blob files (i.e. bundled AWS Lambda code in a .zip file, or any type of software artifact)", "integrations": [ { "platform": "gitlab-ci", "label": null, "link": "https://aquasecurity.github.io/trivy/v0.18.3/integrations/gitlab-ci/", "code": "container_scan:\n stage: devsecops\n script:\n - trivy image --scanners vuln $IMAGE_NAME --format cyclonedx > trivy-output-$DATE-cyclonedx.json\n artifacts:\n when: always\n paths:\n - trivy-output-$DATE-cyclonedx.json\n\ngenerate_sbom:\n stage: devsecops\n script:\n - syft $IMAGE_NAME -o cyclonedx-json > sbom-$DATE.syft.json\n artifacts:\n when: always\n paths:\n - sbom-$DATE.syft.json\n\nsigning_and_attestation:\n stage: publish\n id_tokens:\n SIGSTORE_ID_TOKEN:\n aud: sigstore\n variables:\n RUNNER_GENERATE_ARTIFACTS_METADATA: \"true\"\n script:\n - IMAGE_DIGEST=`docker inspect --format='{{index .RepoDigests 0}}' $IMAGE_NAME` # Grab image digest, rather than image tag\n - cosign sign $IMAGE_DIGEST --key $COSIGN_KEY_NAME # Sign the container image\n - cosign attest --key $COSIGN_KEY_NAME --type vuln --predicate trivy-output-$DATE-cyclonedx.json $OCI_IMAGE_DIGEST # Sign and create an attestation for our Trivy scan\n - cosign attest --key $COSIGN_KEY_NAME --type cyclonedx --predicate sbom-$DATE.syft.json $OCI_IMAGE_DIGEST # Sign and create an attestation for our SBOM\n needs:\n - devsecops\n artifacts:\n when: always\n paths:\n - \"artifacts*.json\"" }, { "platform": "github-actions", "label": null, "link": "https://github.com/aquasecurity/trivy-action", "code": "jobs:\n build-image:\n runs-on: ubuntu-latest\n\n permissions:\n contents: read\n packages: write\n id-token: write # needed for signing the images with GitHub OIDC Token\n\n name: build-image\n steps:\n - uses: actions/checkout@v3.5.2\n with:\n fetch-depth: 1\n\n - name: Install Cosign\n uses: sigstore/cosign-installer@v3.1.1\n\n - name: Set up QEMU\n uses: docker/setup-qemu-action@v2.1.0\n\n - name: Set up Docker Buildx\n uses: docker/setup-buildx-action@v2.5.0\n\n - name: Login to GitHub Container Registry\n uses: docker/login-action@v2.1.0\n with:\n registry: ghcr.io\n username: ${{ github.actor }}\n password: ${{ secrets.GITHUB_TOKEN }}\n\n - id: docker_meta\n uses: docker/metadata-action@v4.4.0\n with:\n images: ghcr.io/sigstore/sample-honk\n tags: type=sha,format=long\n\n - name: Build and Push container images\n uses: docker/build-push-action@v4.0.0\n id: build-and-push\n with:\n platforms: linux/amd64,linux/arm/v7,linux/arm64\n push: true\n tags: ${{ steps.docker_meta.outputs.tags }}\n\n # https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#using-an-intermediate-environment-variable\n - name: Sign image with a key\n run: |\n cosign sign --yes --key env://COSIGN_PRIVATE_KEY \"${TAGS}@${DIGEST}\"\n env:\n TAGS: ${{ steps.docker_meta.outputs.tags }}\n COSIGN_PRIVATE_KEY: ${{ secrets.COSIGN_PRIVATE_KEY }}\n COSIGN_PASSWORD: ${{ secrets.COSIGN_PASSWORD }}\n DIGEST: ${{ steps.build-and-push.outputs.digest }}\n\n - name: Sign the images with GitHub OIDC Token\n env:\n DIGEST: ${{ steps.build-and-push.outputs.digest }}\n TAGS: ${{ steps.docker_meta.outputs.tags }}\n run: cosign sign --yes \"${TAGS}@${DIGEST}\"" } ] } ], "further_reading": [ { "url": "https://github.com/marketplace/actions/cosign-installer", "note": "cosign-installer GitHub Action (source of the GitHub Actions example)." } ], "mappings": { "owasp_samm": [ "Operations > Environment Management" ], "owasp_asvs": [ "V10 Malicious Code" ], "nist_ssdf": [ "PS.2 Provide a Mechanism for Verifying Software Release Integrity", "PO.3 Implement Supporting Toolchains" ], "iso_27001": [ "A.8.28 Secure coding", "A.8.30 Outsourced development" ], "other": [ "SLSA (Supply-chain Levels for Software Artifacts)", "SLSA Build L3 - provenance generated by a hardened build platform" ] } }, { "id": "DSOVS-REL-002", "code": "REL-002", "title": "Secure Artifact Management", "phase": "Release/Deploy", "slug": "REL-002-Secure-Artifact-Management", "status": "complete", "type": "tool", "summary": "Secure Artifact Management is the practice of securing the artifacts produced throughout the software development lifecycle, such as build outputs, container images, packages, and binaries, from the moment they are created until they are deployed or retired.\n\nIt is important for organisations to have secure artifact management in place to ensure that the software being released is trustworthy, reliable, and up to date with current security standards. By storing artifacts in access-controlled, integrity-verified registries, teams can detect, control, and protect their software from tampering and unauthorised modification.\n\nA mature approach links every released artifact back to the build that produced it, preserving provenance and a verifiable chain of custody. This prevents unauthorised changes that could introduce vulnerabilities, supports incident investigation and rollback, and helps organisations remain compliant with industry regulations and standards.", "doc_url": "https://github.com/OWASP/www-project-devsecops-verification-standard/blob/main/document/REL-002-Secure-Artifact-Management.md", "levels": [ { "level": 0, "title": "No package management tool used for releases", "description": "At this level there is no dedicated repository or registry for release artifacts. Builds are distributed in an ad hoc manner, perhaps as files copied to shared drives, attached to tickets, or rebuilt directly on target hosts. Because artifacts are not stored in a controlled location, there is no reliable way to know which build is running in any given environment, who produced it, or whether it has been altered after the fact.\n\nThe absence of a managed store means there are no access controls, no integrity guarantees, and no audit trail. Organisations operating here face a high risk of deploying tampered or outdated artifacts and have little ability to reproduce or investigate a release once it has shipped.", "evidence": [] }, { "level": 1, "title": "Verify implementation of a centralised single storage location for release artifacts", "description": "At this stage the organisation has adopted a central repository or registry where release artifacts are published and retrieved, rather than scattering them across machines and shared folders. Developers push builds to a known location, and downstream consumers pull from that same place, giving teams a single authoritative source for each artifact.\n\nWhile this consolidation brings basic order and accountability, the process is still largely manual and trust is implicit. Artifacts are stored, but their integrity is not yet systematically verified before use, and retention is managed on an as-needed basis. The registry provides a foundation, but its protections depend on individuals following the agreed conventions.", "evidence": [ "A central artifact repository or registry is provisioned and reachable by both publishers and consumers.", "Build artifacts are present in the registry and downstream deployments pull from that registry rather than from local files or shared drives.", "Interview confirms teams treat the registry as the single authoritative source for release artifacts." ], "diagram": "graph LR; Build-- manual publish -->Artifact-Registry-- manual pull -->Deploy;" }, { "level": 2, "title": "Verify implementation of artifact integrity check before release to any environment", "description": "At this level integrity verification is automated and built directly into the delivery pipeline. As artifacts are published and consumed, their checksums or digests are recorded and validated, so that any artifact promoted to a test, staging, or production environment is confirmed to be exactly the one produced by the trusted build, with no tampering in transit or at rest.\n\nThese checks are enforced rather than optional, typically combined with vulnerability scanning of images and packages as they enter the registry. By failing the pipeline when an integrity check or scan does not pass, the organisation ensures that only verified, known-good artifacts move forward, closing the gap between building software and releasing it.", "evidence": [ "Pipeline configuration records and validates artifact checksums or digests before promotion to any environment.", "Pipeline logs show an integrity check (and/or vulnerability scan) running automatically on publish or consumption.", "A failing integrity check or scan blocks the release rather than merely warning.", "Promoted artifacts can be shown to match the digest of the artifact produced by the trusted build." ], "diagram": "graph LR;\nBuild-- publishes -->CICD-Pipeline-- integrity check and scan -->Artifact-Registry; Artifact-Registry-- Pass -->Deploy; Artifact-Registry-- Fail -->Blocked" }, { "level": 3, "title": "Verify implementation to archiving process for artifacts", "description": "At the highest level of maturity the registry is centrally governed, access-controlled, and fully audited, and a defined archiving and retention process governs the entire lifecycle of every artifact. Released builds and their associated metadata, including provenance, signatures, and scan results, are retained according to policy so that any previously shipped version can be retrieved, verified, and redeployed when required.\n\nPermissions are managed centrally with least-privilege access, and all push, pull, promotion, and deletion activity is logged for audit. Retention and immutability rules are continuously reviewed against compliance and operational needs, ensuring that the artifact store remains a trustworthy, traceable system of record that supports rollback, forensic investigation, and long-term reproducibility.", "evidence": [ "A documented archiving and retention policy governs how long artifacts and their metadata are kept and when they are retired.", "Provenance, signatures, and scan results are retained alongside artifacts so a previously shipped version can be retrieved, verified, and redeployed.", "Push, pull, promotion, and deletion activity is logged centrally for audit, with least-privilege access controls enforced.", "Retention and immutability rules are reviewed periodically against compliance and operational needs." ], "diagram": "graph LR;\nBuild-- signs and publishes -->Governed-Registry-- access-controlled scan and integrity -->Deploy; Governed-Registry-- provenance and retention -->Centralised-Audit-Tracker" } ], "tools": [ { "name": "Harbor", "url": "https://github.com/goharbor/harbor", "description": "Harbor is an open source, CNCF-graduated registry that stores, signs, and scans container images and other OCI artifacts. It adds the policy and governance controls expected at higher maturity levels, including role-based access control, project-level permissions, vulnerability scanning via Trivy, image signing, replication, and configurable retention and immutability rules.\n\nHarbor can block the pull or deployment of images that fail a vulnerability threshold, enforcing the integrity and quality gates described in Levels 2 and 3.", "integrations": [ { "platform": "github-actions", "label": null, "link": "https://github.com/aquasecurity/trivy-action", "code": "jobs:\n build-push-scan:\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v4\n\n - name: Log in to Harbor\n uses: docker/login-action@v3\n with:\n registry: harbor.example.com\n username: ${{ secrets.HARBOR_USERNAME }}\n password: ${{ secrets.HARBOR_PASSWORD }}\n\n - name: Build and push image\n uses: docker/build-push-action@v5\n with:\n push: true\n tags: harbor.example.com/team/app:${{ github.sha }}\n\n # Harbor scans on push; this gate fails the build on HIGH/CRITICAL findings\n - name: Verify image scan results\n uses: aquasecurity/trivy-action@master\n with:\n image-ref: harbor.example.com/team/app:${{ github.sha }}\n severity: HIGH,CRITICAL\n exit-code: \"1\"" } ] }, { "name": "Sonatype Nexus Repository / JFrog Artifactory", "url": "https://github.com/sonatype/nexus-public", "description": "Sonatype Nexus Repository and JFrog Artifactory are widely used universal artifact repositories that manage release binaries, packages, and container images across many formats (Maven, npm, PyPI, Docker, and more). Both provide centralised storage, fine-grained access control, retention and cleanup policies, and integrity verification through recorded checksums, as well as integration with vulnerability scanning to gate insecure components before they are consumed.", "integrations": [ { "platform": "gitlab-ci", "label": null, "link": "https://aquasecurity.github.io/trivy/v0.18.3/integrations/gitlab-ci/", "code": "publish_artifact:\n stage: publish\n script:\n # Generate and record a checksum for integrity verification\n - sha256sum build/app.jar > build/app.jar.sha256\n # Publish the artifact and its checksum to Nexus\n - |\n curl --fail --user \"$NEXUS_USER:$NEXUS_PASSWORD\" \\\n --upload-file build/app.jar \\\n \"https://nexus.example.com/repository/releases/com/example/app/$CI_COMMIT_TAG/app.jar\"\n - |\n curl --fail --user \"$NEXUS_USER:$NEXUS_PASSWORD\" \\\n --upload-file build/app.jar.sha256 \\\n \"https://nexus.example.com/repository/releases/com/example/app/$CI_COMMIT_TAG/app.jar.sha256\"\n rules:\n - if: $CI_COMMIT_TAG" } ] } ], "further_reading": [ { "url": "https://goharbor.io/docs/", "note": "Harbor documentation" }, { "url": "https://help.sonatype.com/repomanager3", "note": "Sonatype Nexus Repository" }, { "url": "https://jfrog.com/help/r/jfrog-artifactory-documentation", "note": "JFrog Artifactory" } ], "mappings": { "owasp_samm": [ "Operations > Secure Deployment", "Implementation > Secure Build" ], "owasp_asvs": [ "V14 Configuration" ], "nist_ssdf": [ "PS.1 Protect All Forms of Code from Unauthorized Access and Tampering", "PS.2 Provide a Mechanism for Verifying Software Release Integrity", "PO.5 Implement and Maintain Secure Environments for Software Development" ], "iso_27001": [ "A.8.4 Access to source code", "A.8.32 Change management" ] } }, { "id": "DSOVS-REL-003", "code": "REL-003", "title": "Secret Management", "phase": "Release/Deploy", "slug": "REL-003-Secret-Management", "status": "complete", "type": "tool", "summary": "Secret Management is the process of securely storing, centrally managing, and controlling access to sensitive data such as passwords, API keys, database credentials, and encryption keys throughout the deployment and runtime lifecycle.\n\nIt is an important part of DevSecOps because it enables secrets to be injected into applications at deploy or run time rather than being embedded in source code, configuration files, or images, where they could be exposed to malicious actors. Centralised secret management also supports secure sharing of credentials across teams, automated rotation, and revocation, reducing manual handling and enabling faster, safer delivery cycles.\n\nIt is worth distinguishing this control from hardcoded-secret scanning (DSOVS-CODE-002). That control is about detecting secrets that have already been committed into source code, whereas Secret Management is concerned with how secrets are stored, rotated, and supplied to applications at deploy time so that they never need to be hardcoded in the first place. The two are complementary: scanning catches mistakes, while sound secret management removes the need to take the risk at all.", "doc_url": "https://github.com/OWASP/www-project-devsecops-verification-standard/blob/main/document/REL-003-Secret-Management.md", "levels": [ { "level": 0, "title": "No secret store or vault used", "description": "At this level there is no dedicated secret store or vault. Credentials, tokens, and keys are kept in plaintext wherever it is convenient, such as in source code, configuration files, environment files committed to version control, build scripts, or deployment manifests. Because secrets travel with the code and infrastructure definitions, they are readily exposed to anyone with repository or system access.\n\nThere is no access control specific to secrets, no rotation, and no audit trail of who used a credential or when. A single leaked file can compromise multiple systems, and rotating a leaked secret is slow and error-prone because no one has a reliable inventory of where it is used.", "evidence": [] }, { "level": 1, "title": "Verity implementation of a centralised secure storage for credentials and secrets", "description": "At this stage the organisation has introduced a dedicated, centralised secret store where credentials and keys are kept encrypted and out of source code. Secrets are retrieved from this store rather than read from files checked into the repository, giving teams a single, protected place to manage sensitive values.\n\nUsage at this level is typically manual or on-demand: developers and operators fetch secrets when configuring an application or environment, and access is granted to the store rather than to scattered files. While this is a significant improvement over plaintext storage, retrieval and injection are not yet fully automated within the pipeline, and rotation is performed reactively rather than on a schedule.", "evidence": [ "A dedicated, centralised secret store or vault is provisioned and holds credentials encrypted at rest.", "Repository and configuration scans show secrets are retrieved from the store rather than committed in plaintext.", "Access to the secret store is granted to identities rather than by distributing secret files." ], "diagram": "graph LR; Operator-- manual retrieval -->Secret-Store-- secret -->Application;" }, { "level": 2, "title": "Verify periodic review and rotation schedule of secrets", "description": "At this level secret retrieval is automated and integrated into the delivery pipeline, so that applications receive their secrets at deploy or run time directly from the central store without manual handling. The pipeline authenticates to the secret manager, pulls the values it needs, and injects them into the running workload, keeping plaintext credentials out of build logs, images, and manifests.\n\nIn addition, secrets are subject to a defined review and rotation schedule. Credentials are rotated periodically and re-issued automatically, and access policies are reviewed so that only the workloads and identities that need a secret can read it. This limits the useful lifetime of any leaked credential and reduces the blast radius of a compromise.", "evidence": [ "Pipeline configuration authenticates to the secret manager and injects secrets at deploy or run time without manual handling.", "Build and deployment logs confirm plaintext secrets do not appear in logs, images, or manifests.", "A documented rotation schedule exists and rotation events can be evidenced from the secret store's history.", "Access policies are reviewed periodically so only required workloads and identities can read each secret." ], "diagram": "graph LR;\nPipeline-- authenticates and requests -->Secret-Store-- injects rotated secret -->Application; Secret-Store-- scheduled rotation -->Secret-Store" }, { "level": 3, "title": "Verify implementation of dynamic secrets or secretless process to avoid secrets to be stored within the application", "description": "At the highest level of maturity, secret management is centralised, access-controlled, and fully audited, and the organisation moves toward dynamic secrets or a secretless model so that long-lived credentials are never stored within the application at all. Rather than handing an application a static password, the secret manager issues short-lived, on-demand credentials that are generated when needed and automatically expire shortly afterwards, or the workload authenticates using its own platform identity so that no shared secret changes hands.\n\nEvery issuance and access is logged for audit, policies enforce least-privilege access per workload identity, and the effectiveness of rotation and revocation is continuously reviewed. Because credentials are ephemeral and tightly scoped, a leaked value is of little use to an attacker, and the organisation achieves strong, traceable, and continuously improved control over its secrets.", "evidence": [ "Workloads obtain short-lived dynamic credentials on demand or authenticate via platform/workload identity rather than holding static secrets.", "The secret manager configuration shows credential TTLs and automatic expiry/revocation.", "Every issuance and access is logged centrally for audit, with least-privilege policies enforced per workload identity.", "The effectiveness of rotation and revocation is reviewed periodically and tuned." ], "diagram": "graph LR;\nWorkload-- platform identity -->Secret-Store-- short-lived dynamic credential -->Application; Secret-Store-- every access logged -->Centralised-Audit-Tracker" } ], "tools": [ { "name": "HashiCorp Vault", "url": "https://github.com/hashicorp/vault", "description": "HashiCorp Vault is a widely adopted secret management platform that provides centralised, access-controlled, and audited storage of secrets. Beyond storing static secrets, Vault can generate dynamic, short-lived credentials on demand (for databases, cloud providers, and more) and supports workload identity authentication, making it a strong fit for the dynamic and secretless approaches expected at Level 3.", "integrations": [ { "platform": "github-actions", "label": null, "link": "https://github.com/hashicorp/vault-action", "code": "jobs:\n deploy:\n runs-on: ubuntu-latest\n permissions:\n id-token: write # authenticate to Vault via OIDC, no static token\n contents: read\n steps:\n - uses: actions/checkout@v4\n\n - name: Import secrets from Vault\n uses: hashicorp/vault-action@v3\n with:\n url: https://vault.example.com\n method: jwt\n role: ci-deploy\n secrets: |\n secret/data/app/prod DB_PASSWORD | DB_PASSWORD ;\n secret/data/app/prod API_KEY | API_KEY\n\n - name: Deploy with injected secrets\n run: ./deploy.sh # DB_PASSWORD and API_KEY are present only for this job" } ] }, { "name": "Mozilla SOPS", "url": "https://github.com/getsops/sops", "description": "SOPS (Secrets OPerationS) encrypts the values inside YAML, JSON, and other config files while leaving the structure readable, so encrypted secrets can be safely committed to a repository and decrypted only at deploy time. It integrates with KMS providers such as AWS KMS, GCP KMS, Azure Key Vault, and age/PGP keys, making it well suited to GitOps workflows.", "integrations": [ { "platform": "gitlab-ci", "label": null, "link": "https://github.com/getsops/sops", "code": "deploy:\n stage: deploy\n script:\n # SOPS_AGE_KEY (or a cloud KMS role) is provided as a protected CI variable\n - sops --decrypt secrets/prod.enc.yaml > secrets/prod.yaml\n - kubectl apply -f secrets/prod.yaml\n - rm -f secrets/prod.yaml # remove plaintext after use\n rules:\n - if: $CI_COMMIT_BRANCH == \"main\"" } ] }, { "name": "Sealed Secrets", "url": "https://github.com/bitnami-labs/sealed-secrets", "description": "Sealed Secrets is a Kubernetes-native approach that lets you encrypt a standard Secret into a `SealedSecret` custom resource that is safe to store in Git. Only the in-cluster controller, which holds the private key, can decrypt it back into a usable Secret, so plaintext credentials never live in the repository or in CI logs.", "integrations": [ { "platform": "cli", "label": null, "link": "https://github.com/bitnami-labs/sealed-secrets", "code": "# Encrypt a secret locally using the cluster's public key (offline-safe)\nkubectl create secret generic app-credentials \\\n --from-literal=DB_PASSWORD='s3cr3t' \\\n --dry-run=client -o yaml \\\n | kubeseal --controller-namespace kube-system --format yaml \\\n > sealed-app-credentials.yaml\n\n# Commit sealed-app-credentials.yaml to Git, then apply via your GitOps pipeline.\n# The controller decrypts it into a normal Secret inside the cluster:\nkubectl apply -f sealed-app-credentials.yaml" } ] } ], "further_reading": [ { "url": "https://developer.hashicorp.com/vault/docs", "note": "HashiCorp Vault documentation" }, { "url": "https://github.com/getsops/sops", "note": "Mozilla SOPS" }, { "url": "https://github.com/bitnami-labs/sealed-secrets", "note": "Sealed Secrets" } ], "mappings": { "owasp_samm": [ "Operations > Secure Deployment", "Implementation > Secure Deployment" ], "owasp_asvs": [ "V6 Stored Cryptography", "V14 Configuration" ], "nist_ssdf": [ "PS.1 Protect All Forms of Code from Unauthorized Access and Tampering", "PO.5 Implement and Maintain Secure Environments for Software Development" ], "iso_27001": [ "A.8.24 Use of cryptography", "A.5.17 Authentication information" ] } }, { "id": "DSOVS-REL-004", "code": "REL-004", "title": "Secure Configuration", "phase": "Release/Deploy", "slug": "REL-004-Secure-Configuration", "status": "complete", "type": "tool", "summary": "Secure configuration is a set of best practices for configuring systems and applications in order to maintain security and data integrity.\n\nIt is important in DevSecOps as it helps ensure that all environments, including development, test, and production, are configured in a secure manner.\n\nThis is especially important in a DevSecOps environment, since changes are quickly implemented and deployed, making it more likely that mistakes in configuration can result in security breaches.\n\nSecure configuration can help reduce the risk of such errors, by providing a standard approach to configuring devices and applications.", "doc_url": "https://github.com/OWASP/www-project-devsecops-verification-standard/blob/main/document/REL-004-Secure-Configuration.md", "levels": [ { "level": 0, "title": "No security hardening standards, secure configuration standards or baseline", "description": "At this level the organisation has no defined hardening standards or secure configuration baselines for its environments and services. Systems are deployed using vendor or framework defaults, which frequently leave insecure features enabled, debug interfaces exposed, default credentials in place and permissions far broader than necessary.\n\nBecause there is no agreed reference for what \"secure\" looks like, configuration decisions are left to individual engineers and vary widely between systems. The result is an inconsistent estate where weaknesses are introduced silently and there is no reliable way to know whether a given environment is safe to run in production.", "evidence": [] }, { "level": 1, "title": "Verify that the hardening standards for environment and secure configuration baseline exist and up to date", "description": "At this level the organisation has documented hardening standards and a secure configuration baseline, typically derived from recognised guidance such as the CIS Benchmarks or vendor security guides. These baselines describe how operating systems, services, containers and cloud resources should be configured, covering areas such as disabling insecure defaults, removing unused services and applying least privilege.\n\nThe baseline is applied manually, with engineers expected to follow the documented standard when they build or change an environment. While this establishes a clear and maintained reference point, enforcement still relies on individual discipline and periodic review, so configuration drift and human error remain likely between checks.", "evidence": [ "Documented hardening standards and a secure configuration baseline exist, referencing recognised guidance such as CIS Benchmarks or vendor security guides.", "The baseline covers operating systems, services, containers and cloud resources, including disabling insecure defaults and applying least privilege.", "The baseline document has an owner and a review date showing it is kept current." ], "diagram": "graph LR; Engineer-- Manually Apply -->Hardening-Baseline-- Configures -->Environment;" }, { "level": 2, "title": "Verify that the periodic review schedule for secure configuration baseline is in place and rebuild environment every application release using the latest configuration", "description": "At this level the secure configuration baseline is validated automatically rather than by hand. Infrastructure and configuration are defined as code, and the pipeline runs policy and configuration checks against that code on every change, flagging insecure settings such as public storage, permissive network rules or missing encryption before they reach an environment.\n\nA periodic review schedule keeps the baseline current as new threats and platform features emerge, and environments are rebuilt from the latest approved configuration on each application release rather than being patched in place. This combination of automated validation and routine rebuilds sharply reduces drift and ensures that what is deployed reflects the intended secure state.", "evidence": [ "Infrastructure and configuration are defined as code and stored in version control.", "Pipeline runs automated policy/configuration checks on every change and flags insecure settings before they reach an environment.", "A documented periodic review schedule keeps the baseline current.", "Environments are rebuilt from the latest approved configuration on each application release rather than patched in place." ], "diagram": "graph LR; Config-as-Code-- code push -->CICD-Pipeline-- validate -->Policy-Check-- pass or fail -->CICD-Pipeline; CICD-Pipeline-- Rebuild -->Environment;" }, { "level": 3, "title": "Verify implementation to detect outdated configuration and prevent any configuration drift", "description": "At this level secure configuration is enforced as a gate. Configuration policy is centrally defined and version controlled, and changes that violate the baseline are blocked in the pipeline or at deployment time rather than merely reported. Compliance results are tracked centrally so that the security posture of every environment is visible and measurable over time.\n\nContinuous monitoring detects outdated configuration and any drift in running environments, automatically remediating or rolling back deviations from the approved baseline. Trends and exceptions feed a continuous improvement loop in which the baseline, the detection rules and the enforcement policies are regularly refined, keeping the whole estate aligned with the organisation's security standards.", "evidence": [ "Configuration policy is centrally defined and version controlled, and violating changes are blocked in the pipeline or at deployment time rather than only reported.", "Compliance results are tracked centrally so the posture of every environment is visible and measurable over time.", "Continuous monitoring detects outdated configuration and drift in running environments and automatically remediates or rolls back deviations.", "A continuous improvement loop regularly refines the baseline, detection rules and enforcement policies." ], "diagram": "graph LR; Config-as-Code-- validate -->Policy-Gate-- pass -->Environment; Policy-Gate-- fail -->Blocked; Environment-- drift detected -->Compliance-Tracker-- remediate -->Environment;" } ], "tools": [ { "name": "Open Policy Agent (OPA)", "url": "https://github.com/open-policy-agent/opa", "description": "Open Policy Agent (OPA) is a general-purpose policy engine that lets you express secure configuration rules as code in the Rego language. OPA can evaluate Terraform plans, Kubernetes manifests, cloud configuration and other structured inputs against your baseline, making it a flexible foundation for validating configuration consistently across environments.\n\nThe Rego policy below denies any storage configuration that is publicly accessible or that has encryption disabled:", "integrations": [ { "platform": "config", "label": null, "link": null, "code": "package config.storage\n\n# Deny buckets that are publicly accessible\ndeny[msg] {\n input.resource.type == \"storage_bucket\"\n input.resource.public_access == true\n msg := sprintf(\"Storage bucket '%s' must not allow public access\", [input.resource.name])\n}\n\n# Deny buckets without encryption at rest\ndeny[msg] {\n input.resource.type == \"storage_bucket\"\n not input.resource.encryption.enabled\n msg := sprintf(\"Storage bucket '%s' must have encryption at rest enabled\", [input.resource.name])\n}" }, { "platform": "cli", "label": null, "link": null, "code": "opa eval --fail-defined \\\n --data policy/ \\\n --input plan.json \\\n 'data.config.storage.deny'" } ] }, { "name": "Checkov", "url": "https://github.com/bridgecrewio/checkov", "description": "Checkov is an open source static analysis tool for infrastructure as code. It ships with hundreds of built-in policies for Terraform, CloudFormation, Kubernetes, Helm, ARM and serverless definitions, detecting insecure defaults such as unencrypted volumes, open security groups and over-privileged IAM before resources are provisioned.\n\nThe GitHub Actions snippet below runs Checkov against the repository on every push and fails the build when a misconfiguration is found:", "integrations": [ { "platform": "github-actions", "label": null, "link": null, "code": "name: Secure Configuration Scan\n\non: [push, pull_request]\n\njobs:\n checkov:\n runs-on: ubuntu-latest\n steps:\n - name: Checkout\n uses: actions/checkout@v4\n\n - name: Run Checkov\n uses: bridgecrewio/checkov-action@master\n with:\n directory: .\n framework: terraform\n soft_fail: false\n output_format: sarif\n output_file_path: results.sarif\n\n - name: Upload results to GitHub Security\n uses: github/codeql-action/upload-sarif@v3\n with:\n sarif_file: results.sarif" } ] } ], "further_reading": [ { "url": "https://www.cisecurity.org/cis-benchmarks", "note": "CIS Benchmarks" }, { "url": "https://www.openpolicyagent.org/docs/latest/", "note": "Open Policy Agent documentation" }, { "url": "https://www.checkov.io/", "note": "Checkov documentation" } ], "mappings": { "owasp_samm": [ "Operations > Secure Deployment", "Implementation > Secure Deployment" ], "owasp_asvs": [ "V14 Configuration" ], "nist_ssdf": [ "PO.5 Implement and Maintain Secure Environments for Software Development", "PS.1 Protect All Forms of Code from Unauthorized Access and Tampering" ], "iso_27001": [ "A.8.9 Configuration management", "A.8.8 Management of technical vulnerabilities" ] } }, { "id": "DSOVS-REL-005", "code": "REL-005", "title": "Security Policy Enforcement", "phase": "Release/Deploy", "slug": "REL-005-Security-Policy-Enforcement", "status": "complete", "type": "tool", "summary": "Security Policy Enforcement (SPE) is a process that enables organizations to ensure that their security policies are adhered to.\n\nIt involves monitoring activities, systems, and users within the organization to ensure that they comply with the organization's established security policies.\n\nSPE is an important part of DevSecOps because it helps organizations to detect and respond to security threats in a timely manner, protect sensitive data and resources, and ensure compliance with relevant laws and regulations.\n\nAdditionally, by enforcing security policies, organizations can reduce their risk profile and guard against legal consequences.", "doc_url": "https://github.com/OWASP/www-project-devsecops-verification-standard/blob/main/document/REL-005-Security-Policy-Enforcement.md", "levels": [ { "level": 0, "title": "No security policy defined", "description": "At this level there are no security policies governing what may be deployed or how infrastructure changes are made. Teams are free to ship workloads and modify environments without any agreed constraints on, for example, privileged containers, exposed services or missing security controls.\n\nWith nothing defining acceptable practice, non-compliant changes pass through unchecked and are only discovered, if at all, after an incident. Security depends entirely on the awareness of individual engineers, leaving the organisation exposed to inconsistent and unsafe configurations.", "evidence": [] }, { "level": 1, "title": "Verify the security policies defined for guardrails and security gates", "description": "At this level the organisation has defined and documented security policies that describe the guardrails and gates expected to protect its pipelines and environments. These policies set out requirements such as prohibiting privileged containers, mandating resource limits, requiring approved base images and blocking the deployment of known-vulnerable components.\n\nThe policies exist as written guidance and are applied manually, with engineers and reviewers expected to check changes against them before release. This provides a shared understanding of what is and is not allowed, but enforcement is dependent on human review, so policy violations can still slip through when checks are skipped or misunderstood.", "evidence": [ "A documented security policy exists that defines the guardrails and gates expected for deployments and infrastructure changes.", "The policy explicitly states constraints such as prohibited privileged containers, mandatory resource limits and approved base images.", "Interview or review records confirm that changes are checked against the policy before release." ], "diagram": "graph LR; Deploy-Request-- Manual Review -->Reviewer-- checks against -->Security-Policy-- approved -->Cluster;" }, { "level": 2, "title": "Verify implementation of guardrails and gates to enforce security policies", "description": "At this level the documented policies are expressed as code and validated automatically within the pipeline. Policy-as-code checks run against manifests, infrastructure definitions and build artifacts on every change, evaluating them against the agreed guardrails and reporting any violations back to the build.\n\nBecause the same rules are applied consistently to every change, enforcement no longer relies on individual reviewers remembering each requirement. Non-compliant changes are surfaced early and predictably, and the policy set becomes a living artifact that is versioned and tested alongside the systems it protects.", "evidence": [ "Policy-as-code definitions are stored in version control alongside the systems they protect.", "Pipeline configuration shows a policy evaluation stage that runs automatically on every change.", "Build logs show policy violations being reported back to the build.", "A defined severity threshold causes the build to fail or be flagged when policies are violated." ], "diagram": "graph LR; Deploy-Request-- code push -->CICD-Pipeline-- evaluated by -->Policy-as-Code-- pass or fail -->CICD-Pipeline; CICD-Pipeline-- Deploy -->Cluster;" }, { "level": 3, "title": "Verify the chain of authorisation is implemented as part of the process of infrastructure changes deployment", "description": "At this level security policies are enforced as hard gates at admission and deploy time, so non-compliant changes are actively blocked rather than merely flagged. A clear chain of authorisation governs infrastructure changes, ensuring that deployments are admitted only when they satisfy policy and have passed the required approvals. Enforcement decisions are centrally tracked, giving full visibility of what was allowed, what was denied and why.\n\nThese centralised metrics drive continuous improvement: recurring violations, exceptions and emerging risks inform regular refinement of the policy set and the authorisation workflow. The result is a measured, self-correcting enforcement capability in which policies evolve with the environment and consistently prevent unsafe changes from reaching production.", "evidence": [ "An admission controller or deploy-time gate is configured to actively block non-compliant changes, demonstrated by a denied deployment.", "A documented chain of authorisation defines required approvals before infrastructure changes are admitted.", "Centralised metrics record enforcement decisions, including what was allowed, denied and why.", "A documented schedule exists for reviewing recurring violations and refining the policy set and authorisation workflow." ], "diagram": "graph LR; Deploy-Request-- evaluated by -->Admission-Controller-- allow -->Cluster; Admission-Controller-- deny -->Blocked; Admission-Controller-- decisions -->Central-Metrics;" } ], "tools": [ { "name": "OPA Gatekeeper", "url": "https://github.com/open-policy-agent/gatekeeper", "description": "OPA Gatekeeper is a Kubernetes admission controller built on Open Policy Agent that enforces policy as code at admission time. Policies are defined as reusable ConstraintTemplates and instantiated as Constraints, allowing the cluster to reject non-compliant resources before they are ever created.\n\nThe example below defines a constraint template and a constraint that block any Pod requesting privileged containers:", "integrations": [ { "platform": "config", "label": null, "link": null, "code": "apiVersion: templates.gatekeeper.sh/v1\nkind: ConstraintTemplate\nmetadata:\n name: k8sdenyprivileged\nspec:\n crd:\n spec:\n names:\n kind: K8sDenyPrivileged\n targets:\n - target: admission.k8s.gatekeeper.sh\n rego: |\n package k8sdenyprivileged\n\n violation[{\"msg\": msg}] {\n c := input.review.object.spec.containers[_]\n c.securityContext.privileged == true\n msg := sprintf(\"Privileged container '%s' is not allowed\", [c.name])\n }\n---\napiVersion: constraints.gatekeeper.sh/v1beta1\nkind: K8sDenyPrivileged\nmetadata:\n name: deny-privileged-containers\nspec:\n match:\n kinds:\n - apiGroups: [\"\"]\n kinds: [\"Pod\"]" } ] }, { "name": "Kyverno", "url": "https://github.com/kyverno/kyverno", "description": "Kyverno is a policy engine designed specifically for Kubernetes, where policies are written as native Kubernetes resources rather than in a separate language. It can validate, mutate and generate configurations, and in `Enforce` mode it blocks any admission request that violates a policy.\n\nThe ClusterPolicy below denies workloads that run as root, enforcing the policy as a gate across the cluster:", "integrations": [ { "platform": "config", "label": null, "link": null, "code": "apiVersion: kyverno.io/v1\nkind: ClusterPolicy\nmetadata:\n name: disallow-run-as-root\nspec:\n validationFailureAction: Enforce\n background: true\n rules:\n - name: check-run-as-non-root\n match:\n any:\n - resources:\n kinds:\n - Pod\n validate:\n message: \"Containers must not run as root; set runAsNonRoot to true.\"\n pattern:\n spec:\n =(securityContext):\n =(runAsNonRoot): true\n containers:\n - =(securityContext):\n =(runAsNonRoot): true" } ] } ], "further_reading": [ { "url": "https://open-policy-agent.github.io/gatekeeper/", "note": "Open Policy Agent Gatekeeper documentation." }, { "url": "https://kyverno.io/docs/", "note": "Kyverno documentation." }, { "url": "https://www.openpolicyagent.org/docs/latest/", "note": "Policy as Code overview." } ], "mappings": { "owasp_samm": [ "Operations > Operational Management", "Implementation > Secure Deployment" ], "owasp_asvs": [ "V14 Configuration" ], "nist_ssdf": [ "PO.3 Implement Supporting Toolchains", "PW.9 Configure the Compilation, Interpreter, and Build Processes to Improve Executable Security" ], "iso_27001": [ "A.5.1 Policies for information security", "A.8.9 Configuration management" ] } }, { "id": "DSOVS-REL-006", "code": "REL-006", "title": "Infrastructure-as-Code (IaC) Secure Deployment", "phase": "Release/Deploy", "slug": "REL-006-Infrastructure-as-Code-Secure-Deployment", "status": "complete", "type": "tool", "summary": "Infrastructure-as-Code (IaC) scanning is a process by which security scans are conducted on source code written for cloud infrastructure.\n\nIt is used to detect any potential vulnerabilities or weaknesses in the code that could be exploited by malicious actors. The scans are conducted using automated tools that look for common issues such as unsecured credentials, insecure configurations and other security misconfigurations.\n\nThis is an important part of DevSecOps because it helps to ensure that the code is secure before it is deployed, allowing organizations to minimize the risks associated with their cloud infrastructures.", "doc_url": "https://github.com/OWASP/www-project-devsecops-verification-standard/blob/main/document/REL-006-Infrastructure-as-Code-Secure-Deployment.md", "levels": [ { "level": 0, "title": "Manual infrastructure provisioning or without version control", "description": "At this level of security maturity, there is no tooling in place to security-scan Infrastructure-as-Code before it is deployed. Infrastructure may be provisioned manually through cloud consoles or applied directly from configuration files that are never assessed for misconfigurations, meaning that insecure defaults, overly permissive access policies and exposed credentials can reach production entirely unchecked.", "evidence": [] }, { "level": 1, "title": "Verify that the infrastructure configuration files are version controlled and release automation process is in place", "description": "At this stage an IaC security scanner is available and is run against the infrastructure definitions, but only on a case-by-case basis. A developer or engineer typically invokes the tool manually against their Terraform, CloudFormation or Kubernetes manifests before a release, and the results may not be reported, recorded or acted upon in any consistent way. Coverage therefore depends entirely on individual discipline rather than on any enforced process.", "evidence": [ "Infrastructure configuration files are stored in version control.", "An IaC security scanner is installed and available to the team.", "Evidence of at least one scan report produced on demand against the infrastructure definitions.", "Interview confirms who runs the scan and when it is triggered before a release." ], "diagram": "graph LR; Engineer-- Manual IaC Scan -->IaC-Definitions;" }, { "level": 2, "title": "Verify that least privilege principle is implemented for deployment of infrastructure changes", "description": "Here, IaC security scanning is integrated directly into the build pipeline. Whenever infrastructure code is pushed, an automated scan is triggered against the Terraform, CloudFormation or Kubernetes manifests and the findings are reported back to the build. Crucially, the scan acts as a gate: a definition that contains high-severity misconfigurations causes the pipeline to fail, blocking the insecure deployment before any resources are provisioned. This ensures that misconfigurations such as public storage buckets, unencrypted volumes or overly broad IAM permissions are caught consistently rather than relying on manual review.", "evidence": [ "Pipeline configuration shows an IaC scanning stage that runs automatically on every push of infrastructure code.", "Build logs show the scan executing and reporting findings back to the build.", "A high-severity misconfiguration causes the pipeline to fail and blocks deployment.", "Deployment credentials and IAM roles used for provisioning follow least privilege." ], "diagram": "graph LR;\nStart-- code push -->CICD-Pipeline-- IaC Scan -->IaC-Definitions--Scan Results -->CICD-Pipeline; CICD-Pipeline-- Pass -->Deploy-Infrastructure; CICD-Pipeline-- Fail -->Blocked" }, { "level": 3, "title": "Verify the chain of authorisation is implemented as part of the process of infrastructure changes deployment", "description": "Level 3 builds on Level 2 by automatically recording every identified misconfiguration in a centralised issue tracking system, where findings can be triaged, assigned and trended over time. The effectiveness of the IaC scanning is periodically reviewed so that rule sets, baselines and severity thresholds can be tuned, false positives suppressed and emerging misconfiguration patterns addressed. More mature organisations also provide teams with shared, organisation-specific policy packs and example CI/CD templates, making consistent IaC scanning easy to adopt across every project.", "evidence": [ "Misconfigurations are automatically recorded in a centralised issue tracker with severity and ownership.", "A documented schedule exists for reviewing scanner effectiveness and tuning rule sets, baselines and severity thresholds.", "Shared organisation-specific policy packs and example CI/CD templates are published for teams to adopt.", "Metrics show misconfigurations being triaged and remediated over time." ], "diagram": "graph LR;\nStart-- code push -->CICD-Pipeline-- IaC Scan -->IaC-Definitions--Scan Results -->Centralised-Issue-Tracker; CICD-Pipeline-- Pass -->Deploy-Infrastructure" } ], "tools": [ { "name": "Checkov", "url": "https://github.com/bridgecrewio/checkov", "description": "Checkov is an open-source static analysis tool for Infrastructure-as-Code. It scans Terraform, CloudFormation, Kubernetes, Helm, ARM templates and Serverless framework definitions against thousands of built-in policies to surface misconfigurations and compliance issues before deployment. Findings can be output as SARIF for native integration with code-scanning dashboards.", "integrations": [ { "platform": "github-actions", "label": null, "link": "https://github.com/bridgecrewio/checkov-action", "code": "name: checkov\non:\n push:\n pull_request:\n workflow_dispatch:\n\njobs:\n scan:\n runs-on: ubuntu-latest\n permissions:\n security-events: write\n steps:\n - uses: actions/checkout@v4\n\n - name: Run Checkov\n uses: bridgecrewio/checkov-action@master\n with:\n directory: .\n framework: terraform\n output_format: sarif\n output_file_path: results.sarif\n\n - name: Upload results to GitHub Security\n uses: github/codeql-action/upload-sarif@v3\n with:\n sarif_file: results.sarif" }, { "platform": "gitlab-ci", "label": null, "link": "https://www.checkov.io/4.Integrations/GitLab%20CI.html", "code": "stages:\n - iac-scan\n\ncheckov:\n stage: iac-scan\n image:\n name: bridgecrew/checkov:latest\n entrypoint: [\"\"]\n script:\n - checkov --directory . --output junitxml | tee checkov.test.xml\n artifacts:\n reports:\n junit: checkov.test.xml\n paths:\n - checkov.test.xml" } ] }, { "name": "tfsec / Trivy config", "url": "https://github.com/aquasecurity/tfsec", "description": "tfsec is a fast static analysis scanner for Terraform that highlights potential misconfigurations and security issues with clear, actionable output. Its capabilities are now incorporated into [Trivy](https://github.com/aquasecurity/trivy), which extends configuration scanning across Terraform, CloudFormation, Kubernetes, Helm and Dockerfiles alongside its vulnerability scanning, making it a convenient single tool for IaC security checks in the pipeline.", "integrations": [ { "platform": "github-actions", "label": null, "link": "https://github.com/aquasecurity/tfsec-action", "code": "name: tfsec\non:\n push:\n pull_request:\n\njobs:\n tfsec:\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v4\n\n - name: Run tfsec\n uses: aquasecurity/tfsec-action@v1.0.3\n with:\n working_directory: ." }, { "platform": "gitlab-ci", "label": null, "link": "https://aquasecurity.github.io/trivy/latest/docs/coverage/iac/", "code": "stages:\n - iac-scan\n\ntrivy-config:\n stage: iac-scan\n image:\n name: aquasec/trivy:latest\n entrypoint: [\"\"]\n script:\n - trivy config --exit-code 1 --severity HIGH,CRITICAL --format table ." } ] } ], "mappings": { "owasp_samm": [ "Implementation > Secure Deployment", "Verification > Security Testing" ], "owasp_asvs": [ "V14 Configuration" ], "nist_ssdf": [ "PW.7 Review and/or Analyze Human-Readable Code", "PW.9 Configure the Compilation, Interpreter, and Build Processes to Improve Executable Security", "RV.1 Identify and Confirm Vulnerabilities" ], "iso_27001": [ "A.8.8 Management of technical vulnerabilities", "A.8.9 Configuration management" ] } }, { "id": "DSOVS-REL-007", "code": "REL-007", "title": "Compliance Scanning", "phase": "Release/Deploy", "slug": "REL-007-Compliance-Scanning", "status": "complete", "type": "tool", "summary": "Compliance Scanning is a process of scanning system software and application to ensure that they are compliant with specific standards or regulations. It is an important part of DevSecOps as it enables the developers to quickly identify any potential compliance issues in their code and address them before they become a problem.\n\nThrough compliance scanning, developers can also examine their code for potential security vulnerabilities that could be exploited by attackers.\n\nCompliance Scanning ultimately helps increase the overall security and reliability of applications and systems during development, testing and production stages.", "doc_url": "https://github.com/OWASP/www-project-devsecops-verification-standard/blob/main/document/REL-007-Compliance-Scanning.md", "levels": [ { "level": 0, "title": "No tool to perform compliance check", "description": "At this level the organisation has no tooling or defined process for checking systems, hosts, or deployments against compliance benchmarks. Any assessment of whether infrastructure aligns with standards such as CIS Benchmarks, PCI DSS, or internal hardening baselines is carried out manually, if at all, and the results are neither consistent nor repeatable.\n\nWithout an automated compliance check, drift from a secure baseline goes unnoticed, misconfigurations accumulate over time, and the organisation cannot demonstrate to auditors or stakeholders that its environments meet the required controls.", "evidence": [] }, { "level": 1, "title": "Verify use of tool to perform on-demand scan to perform security compliance check", "description": "At this stage a compliance scanning tool has been adopted and is run on demand against systems or deployments to evaluate them against a chosen benchmark. An engineer might, for example, execute Chef InSpec, OpenSCAP, or a cloud posture scanner such as Prowler against a host or account and review the resulting report.\n\nBecause the scans are triggered manually and on a case-by-case basis, coverage is uneven and results may not be retained or acted upon in a structured way. The capability nonetheless gives teams a concrete, tool-backed view of their compliance posture at a point in time.", "evidence": [ "A compliance scanning tool is installed and available to the team.", "A chosen benchmark or profile (for example CIS, PCI DSS) is selected for evaluation.", "Evidence of at least one on-demand scan report produced against a system or account.", "Interview confirms who runs the scan and how results are reviewed." ], "diagram": "graph LR; Engineer-- on-demand scan -->System-- evaluated against -->Benchmark-Check-- results -->Report;" }, { "level": 2, "title": "Verify that the compliance scanning tool is scheduled to perform automated scans and report status to system owner through a centralised issue tracking system", "description": "At this level compliance scanning is automated and integrated into the delivery pipeline or run on a regular schedule, so every relevant build or environment is assessed without human intervention. The scan executes as a pipeline stage or scheduled job and its pass or fail status is reported back automatically.\n\nFindings are routed to the responsible system owner through a centralised issue tracking system, ensuring that compliance gaps are captured, assigned, and tracked through to resolution rather than being lost in ad-hoc reports. This gives the organisation continuous, consistent visibility of its compliance state across all in-scope systems.", "evidence": [ "Pipeline configuration or scheduled job shows compliance scans running automatically on a regular cadence.", "Scan output reports a pass or fail status back automatically.", "Findings are routed to the responsible system owner through a centralised issue tracking system.", "Issue tracker records show compliance gaps assigned and tracked to resolution." ], "diagram": "graph LR; CICD-Pipeline-- automated scan -->System-- evaluated against -->Benchmark-Check-- results -->Issue-Tracker;" }, { "level": 3, "title": "Verify that the mechanism to apply automatic remediation automatically exists at the time of vulnerability identified", "description": "At the highest level the organisation not only detects compliance violations automatically but also remediates them. When a scan identifies a deviation from the benchmark, an automated remediation mechanism, such as a configuration-management playbook, policy-as-code controller, or remediation pipeline, brings the affected system back into a compliant state without manual effort.\n\nCompliance results and remediation actions are centrally tracked and measured, and the effectiveness of the benchmarks, scanning rules, and remediation logic is reviewed periodically and continuously improved. This closes the loop between detection and correction, keeping environments aligned with the required standards over time.", "evidence": [ "An automated remediation mechanism (for example a configuration-management playbook or remediation pipeline) is triggered when a deviation is detected, demonstrated end to end.", "Compliance results and remediation actions are centrally tracked and measured.", "A documented schedule exists for periodically reviewing benchmarks, scanning rules and remediation logic.", "Metrics show deviations being detected and automatically remediated over time." ], "diagram": "graph LR; CICD-Pipeline-- automated scan -->System-- evaluated against -->Benchmark-Check-- results -->Central-Tracker-- auto remediate -->System; Central-Tracker-- periodic review -->Continuous-Improvement;" } ], "tools": [ { "name": "Chef InSpec", "url": "https://github.com/inspec/inspec", "description": "Chef InSpec is an open source framework for describing compliance and security requirements as human-readable code. Controls can be run against servers, containers, and cloud resources to test them against benchmarks such as the CIS Benchmarks, and the same profiles can be executed locally or from a pipeline.", "integrations": [ { "platform": "github-actions", "label": null, "link": "https://github.com/inspec/inspec", "code": "name: compliance-scan\non:\n push:\n workflow_dispatch:\njobs:\n inspec:\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v4\n - name: Install InSpec\n run: curl https://omnitruck.chef.io/install.sh | sudo bash -s -- -P inspec\n - name: Run CIS compliance profile\n run: |\n inspec exec https://github.com/dev-sec/linux-baseline \\\n --chef-license accept-silent \\\n --reporter cli json:inspec-report.json\n - name: Upload report\n if: always()\n uses: actions/upload-artifact@v4\n with:\n name: inspec-report\n path: inspec-report.json" } ] }, { "name": "OpenSCAP", "url": "https://github.com/OpenSCAP/openscap", "description": "OpenSCAP is an open source implementation of the Security Content Automation Protocol (SCAP). Using the `oscap` command line tool together with SCAP Security Guide content, it evaluates a host against standardised profiles (for example a PCI DSS or CIS profile) and can generate both machine-readable results and an HTML report.", "integrations": [ { "platform": "cli", "label": null, "link": null, "code": "# Evaluate the host against the PCI-DSS profile from the SCAP Security Guide\noscap xccdf eval \\\n --profile xccdf_org.ssgproject.content_profile_pci-dss \\\n --results scan-results.xml \\\n --report scan-report.html \\\n /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml" } ] }, { "name": "Prowler", "url": "https://github.com/prowler-cloud/prowler", "description": "Prowler is an open source security and compliance tool for cloud environments such as AWS, Azure, Google Cloud, and Kubernetes. It ships with checks mapped to frameworks including CIS, PCI DSS, and others, making it well suited to automated cloud compliance scanning in a pipeline.", "integrations": [ { "platform": "cli", "label": null, "link": null, "code": "# Scan an AWS account against the CIS benchmark and emit JSON + HTML output\nprowler aws \\\n --compliance cis_2.0_aws \\\n --output-formats json-ocsf html \\\n --output-directory ./prowler-output" } ] } ], "mappings": { "owasp_samm": [ "Verification > Security Testing", "Operations > Operational Management" ], "owasp_asvs": [ "V14 Configuration" ], "nist_ssdf": [ "PO.3 Implement Supporting Toolchains", "RV.1 Identify and Confirm Vulnerabilities", "RV.2 Assess, Prioritize, and Remediate Vulnerabilities" ], "iso_27001": [ "A.5.36 Compliance with policies, rules and standards for information security", "A.8.8 Management of technical vulnerabilities", "A.8.9 Configuration management" ] } }, { "id": "DSOVS-REL-008", "code": "REL-008", "title": "Secure Release Management", "phase": "Release/Deploy", "slug": "REL-008-Secure-Release-Management", "status": "complete", "type": "process", "summary": "Secure Release Management is the process of controlling and managing system and application releases in a secure manner. This includes ensuring that the release meets organization security standards and is free of any vulnerabilities.\n\nIt also ensures that the released code is properly tested, validated, and approved before deployment.\n\nSecure Release Management enables organizations to maintain high levels of trust in their systems and applications as it helps ensure that all software changes are properly implemented and tracked.", "doc_url": "https://github.com/OWASP/www-project-devsecops-verification-standard/blob/main/document/REL-008-Secure-Release-Management.md", "levels": [ { "level": 0, "title": "No security checklist used in release management", "description": "At this level releases are pushed to production in an ad-hoc fashion with no security checklist, approval gate, or change-management process governing them. Whether a release has been reviewed, tested, or authorised depends entirely on the individual performing it, and there is no consistent record of what was deployed, by whom, or why.\n\nThe absence of a controlled, auditable release process means insecure or unapproved changes can reach production unchallenged, and the organisation has little ability to trace, verify, or roll back a problematic release once it is live.", "evidence": [] }, { "level": 1, "title": "Verify that the security checklist in enforced in all release management with exception process in place", "description": "At this stage a defined security checklist is applied to every release, covering the key controls that must be satisfied before a change is approved for deployment, such as completion of required testing, vulnerability review, and sign-off by an accountable owner. A documented exception process exists so that any deviation from the checklist is consciously requested, justified, and recorded rather than silently bypassed.\n\nThis introduces a basic but consistent approval gate and audit trail across releases. Adherence is largely enforced through process and manual verification, but it establishes the discipline of controlled, authorised change as a precondition for release.", "evidence": [ "A documented release security checklist exists and lists the controls required before approval (testing complete, vulnerability review, accountable sign-off).", "Completed checklists or approval records can be produced for recent production releases.", "A documented exception process exists, and recorded exceptions show justification and approver." ], "diagram": "graph LR; Build-- manual checklist -->Approval-Gate-- approved -->Release-- audited -->Production; Production-- issue -->Rollback;" }, { "level": 2, "title": "Verify implementation of security checklist in non-production stage releases", "description": "At this level the security checklist is built into the delivery pipeline and enforced automatically against non-production stage releases, so that changes are validated in test, staging, or pre-production environments before they can progress towards production. Checklist items are implemented as automated gates within the pipeline, and a release that fails to satisfy them is blocked from promotion.\n\nBy integrating the controls into the pipeline and exercising them in non-production stages first, the organisation catches policy and security failures early, maintains a verifiable record of each promotion decision, and aligns its release flow with supply-chain integrity expectations such as those described by the SLSA framework.", "evidence": [ "Pipeline configuration shows checklist items implemented as automated gates that run against non-production stage releases.", "Pipeline logs show a release being blocked from promotion when a checklist gate fails.", "Each promotion decision produces a verifiable record (e.g. provenance or attestation) for the release." ], "diagram": "graph LR; Build-- automated checklist -->Pipeline-Gate-- passed -->Non-Prod-Release-- promoted -->Production; Production-- issue -->Rollback;" }, { "level": 3, "title": "Verify that periodic review schedule is defined to review the security checklist", "description": "At the highest level the release-management controls are not only automated and centrally tracked but also continuously improved. A defined, periodic review schedule governs the security checklist itself, ensuring that its items remain relevant as threats, regulations, and the organisation's architecture evolve, and that approval gates and rollback procedures are kept effective.\n\nRelease and approval data is centrally tracked and measured, and insights from incidents, exceptions, and audit findings feed back into the checklist and change-management process. This creates a closed loop in which the secure release process is regularly assessed against authoritative guidance such as SLSA, OWASP SAMM, and the NIST Secure Software Development Framework, and refined over time.", "evidence": [ "A documented schedule defines how often the release security checklist is reviewed and who owns the review.", "Release and approval data is centrally tracked, with metrics on releases, exceptions and rollbacks.", "Review records show insights from incidents, exceptions and audit findings feeding back into checklist or change-management updates." ], "diagram": "graph LR; Build-- automated checklist -->Pipeline-Gate-- passed -->Release-- audited -->Production; Production-- issue -->Rollback; Production-- release data -->Central-Tracker-- periodic review -->Continuous-Improvement;" } ], "tools": [ { "name": "Argo Rollouts", "url": "https://github.com/argoproj/argo-rollouts", "description": "Argo Rollouts is a Kubernetes controller that provides progressive-delivery release strategies such as blue-green and canary deployments, with automated analysis and the ability to halt and roll back a release automatically when health or analysis metrics fail. This supports controlled, auditable, and reversible releases as part of a secure release-management process." } ], "further_reading": [ { "url": "https://slsa.dev", "note": "SLSA (Supply-chain Levels for Software Artifacts)" }, { "url": "https://owaspsamm.org/model/operations/", "note": "OWASP SAMM - Operations domain" }, { "url": "https://csrc.nist.gov/projects/ssdf", "note": "NIST Secure Software Development Framework (SSDF), SP 800-218" } ], "mappings": { "owasp_samm": [ "Operations > Operational Management", "Operations > Environment Management" ], "owasp_asvs": [ "V14 Configuration" ], "nist_ssdf": [ "PS.3 Archive and Protect Each Software Release", "PW.1 Design Software to Meet Security Requirements and Mitigate Security Risks", "RV.3 Analyze Vulnerabilities to Identify Their Root Causes" ], "iso_27001": [ "A.8.32 Change management", "A.8.9 Configuration management" ], "other": [ "SLSA (Supply-chain Levels for Software Artifacts)" ] } }, { "id": "DSOVS-OPR-001", "code": "OPR-001", "title": "Environment Hardening", "phase": "Operate/Monitor", "slug": "OPR-001-Environment-Hardening", "status": "complete", "type": "tool", "summary": "Environment hardening is the process of securing a system or environment by reducing its attack surface. This is done by removing unnecessary components, services, ports and protocols, disabling insecure defaults, and applying security patches to the operating systems, container images and orchestration platforms that host an application.\n\nIt is an important part of DevSecOps because it mitigates potential vulnerabilities in the underlying infrastructure rather than the application code alone. Rather than relying on intuition, mature teams measure their infrastructure against an agreed baseline, most commonly the CIS Benchmarks, which provide consensus-driven configuration guidance for servers, containers and Kubernetes clusters.\n\nBy hardening the environment against such a baseline, organisations protect against data breaches, reduce the blast radius of a compromise, and demonstrate a defensible, repeatable security posture across every host they operate.", "doc_url": "https://github.com/OWASP/www-project-devsecops-verification-standard/blob/main/document/OPR-001-Environment-Hardening.md", "levels": [ { "level": 0, "title": "No environment vulnerability scanning tool", "description": "At this level there is no tooling or process in place to assess the security configuration of the environment. Servers, container images and clusters run with their out-of-the-box defaults, which typically prioritise ease of setup over security and leave unnecessary services, open ports and permissive permissions enabled.\n\nBecause nothing is measured against a recognised baseline, the team has no visibility into how exposed its infrastructure is, and misconfigurations accumulate silently until they are discovered by an attacker or an incident.", "evidence": [] }, { "level": 1, "title": "Verify use of tool to perform on-demand scan to identify environment vulnerabilities in production environment", "description": "At this stage a hardening or configuration-assessment tool is available and is run manually, on demand, against a defined baseline such as a CIS Benchmark. An engineer might run a scan against a server or a container image before it goes live, review the failed checks, and remediate the most important findings by hand.\n\nThis represents a meaningful improvement, because the environment is now being compared against an objective standard. However, scanning is ad hoc and depends on someone remembering to run it. Results are rarely recorded or tracked over time, so configuration drift between scans goes unnoticed and coverage across the estate is inconsistent.", "evidence": [ "A configuration-assessment or hardening tool is installed and available to operators.", "A defined baseline (e.g. a specific CIS Benchmark profile) is documented for the hosts or images being assessed.", "At least one on-demand scan report against the baseline can be produced for a production server or image.", "Interview confirms who runs the scan, when it is triggered, and how findings are remediated." ], "diagram": "graph LR; Operator-- runs benchmark scan -->Infrastructure-- checks vs CIS Baseline -->Operator;" }, { "level": 2, "title": "Verify that the vulnerability scanning tool is scheduled to perform automated scans and report status to system owner through a centralised issue tracking system", "description": "Here, hardening checks are integrated into the build and deployment pipeline so that they run automatically and consistently. Container images are scanned against a benchmark as they are built, infrastructure-as-code and host configurations are evaluated before promotion, and a build can be failed when a host or image falls below the required hardening threshold.\n\nBecause the checks are automated and gated, every artifact is verified against the same baseline before it reaches production, removing reliance on individual engineers. Findings are surfaced back to the system owner and routed into a tracking system, giving teams a consistent, auditable record of the environment's compliance status.", "evidence": [ "Pipeline configuration shows a benchmark/hardening scan stage that runs automatically on each build or deployment.", "A defined hardening threshold causes the build to fail or be flagged when a host or image falls below it.", "Scan findings are routed automatically into a centralised issue tracking system and surfaced to the system owner.", "Build logs show the scan executing and reporting status back to the pipeline." ], "diagram": "graph LR;\nStart-- code push -->CICD-Pipeline-- benchmark scan -->Infrastructure--CIS Results -->CICD-Pipeline; CICD-Pipeline-- Hardened Deployment -->Finish" }, { "level": 3, "title": "Verify implementation to apply automatic remediation at the time of vulnerability identified", "description": "At the highest level of maturity, hardening becomes a continuous process rather than a point-in-time check. Running hosts, images and clusters are monitored continuously for configuration drift away from the approved baseline, and deviations are detected as soon as they occur rather than at the next manual review.\n\nFindings from every source are consolidated into a centralised system, where they are correlated, prioritised and trended over time. Where it is safe to do so, remediation is applied automatically the moment a deviation is identified, for example by reapplying a hardening profile or rebuilding a non-compliant node from a known-good image. The effectiveness of the hardening programme itself is reviewed periodically so that baselines, exceptions and automated controls are refined as the threat landscape and the estate evolve.", "evidence": [ "Continuous monitoring is configured to detect configuration drift on running hosts, images or clusters against the approved baseline.", "Automated remediation (e.g. reapplying a hardening profile or rebuilding a non-compliant node) is demonstrated for at least one class of deviation.", "Findings from all sources are consolidated, correlated and trended in a centralised system.", "A documented schedule exists for periodically reviewing the hardening programme's effectiveness, baselines and exceptions." ], "diagram": "graph LR;\nInfrastructure-- continuous monitoring -->Drift-Detection-- compliance drift -->Centralised-Issue-Tracker-- auto remediation -->Infrastructure" } ], "tools": [ { "name": "OpenSCAP", "url": "https://github.com/OpenSCAP/openscap", "description": "OpenSCAP is an open source implementation of the Security Content Automation Protocol (SCAP). It evaluates a system against machine-readable security policies, including profiles aligned to the CIS Benchmarks and other standards such as STIG and PCI-DSS, and can both report on and remediate non-compliant settings. It is well suited to scanning operating systems and container images as part of an automated pipeline.", "integrations": [ { "platform": "github-actions", "label": null, "link": "https://github.com/OpenSCAP/openscap", "code": "name: openscap-hardening\non:\n push:\n pull_request:\n workflow_dispatch:\n schedule:\n - cron: \"0 4 * * *\" # run once a day at 4 AM\njobs:\n oscap-scan:\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v4\n - name: Install OpenSCAP and SCAP Security Guide\n run: sudo apt-get update && sudo apt-get install -y libopenscap8 ssg-base ssg-debderived\n - name: Evaluate host against the CIS profile\n run: |\n oscap xccdf eval \\\n --profile xccdf_org.ssgproject.content_profile_cis_level1_server \\\n --results results.xml \\\n --report report.html \\\n /usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xml || true\n - name: Upload OpenSCAP report\n uses: actions/upload-artifact@v4\n with:\n name: openscap-report\n path: report.html" } ] }, { "name": "Lynis", "url": "https://github.com/CISOfy/lynis", "description": "Lynis is a battle-tested security auditing tool for Unix-based systems. It performs an in-depth scan of a running host, checking configuration, installed software, and hardening of services against best practice, and produces a hardening index alongside actionable suggestions. It is lightweight, agentless and ideal for on-demand audits as well as scheduled scans of production servers.", "integrations": [ { "platform": "github-actions", "label": null, "link": "https://github.com/CISOfy/lynis", "code": "name: lynis-audit\non:\n workflow_dispatch:\n schedule:\n - cron: \"0 3 * * 1\" # run weekly on Monday at 3 AM\njobs:\n lynis:\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v4\n - name: Install Lynis\n run: sudo apt-get update && sudo apt-get install -y lynis\n - name: Run system audit\n run: sudo lynis audit system --no-colors --report-file lynis-report.dat || true\n - name: Upload Lynis report\n uses: actions/upload-artifact@v4\n with:\n name: lynis-report\n path: lynis-report.dat" } ] }, { "name": "kube-bench", "url": "https://github.com/aquasecurity/kube-bench", "description": "kube-bench checks whether a Kubernetes cluster is deployed securely by running the checks documented in the CIS Kubernetes Benchmark. It inspects control plane components, worker nodes and policies, reporting each control as pass, fail or warn, and can output results in JSON for ingestion into a centralised tracker. It is the de facto tool for verifying that clusters meet the CIS baseline.", "integrations": [ { "platform": "github-actions", "label": null, "link": "https://github.com/aquasecurity/kube-bench", "code": "name: kube-bench\non:\n workflow_dispatch:\n schedule:\n - cron: \"0 5 * * *\" # run once a day at 5 AM\njobs:\n kube-bench:\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v4\n - name: Run kube-bench against the CIS Kubernetes Benchmark\n run: |\n docker run --rm \\\n -v $(pwd):/out \\\n aquasec/kube-bench:latest \\\n run --json | tee /out/kube-bench-results.json || true\n - name: Upload kube-bench results\n uses: actions/upload-artifact@v4\n with:\n name: kube-bench-results\n path: kube-bench-results.json" } ] } ], "mappings": { "owasp_samm": [ "Operations > Environment Management" ], "owasp_asvs": [ "V14 Configuration" ], "nist_ssdf": [ "PO.5 Implement and Maintain Secure Environments for Software Development", "PW.9 Configure Software to Have Secure Settings by Default", "RV.1 Identify and Confirm Vulnerabilities" ], "iso_27001": [ "A.8.9 Configuration management", "A.8.8 Management of technical vulnerabilities" ] } }, { "id": "DSOVS-OPR-002", "code": "OPR-002", "title": "Application Hardening", "phase": "Operate/Monitor", "slug": "OPR-002-Application-Hardening", "status": "complete", "type": "tool", "summary": "Application hardening is the process of enhancing the security of an application by reducing its attack surface at runtime. This typically involves applying secure configuration defaults, removing features, sample content and debug endpoints that are not needed in production, enforcing strong transport security, and running the application with the least privilege it requires to function.\n\nIt is an important part of DevSecOps because even well-written code can be left dangerously exposed by weak runtime configuration: verbose error pages that leak internals, missing security HTTP headers, outdated TLS settings, or a process running as root. Hardening closes these gaps by aligning the deployed configuration with recognised best practice such as the OWASP Secure Headers Project guidance.\n\nBy taking these proactive measures and verifying them automatically, organisations ensure their applications meet industry best practices and remain resilient against the ever-evolving world of cyber threats.", "doc_url": "https://github.com/OWASP/www-project-devsecops-verification-standard/blob/main/document/OPR-002-Application-Hardening.md", "levels": [ { "level": 0, "title": "No application vulnerability scanning tool", "description": "At this level the application runs with its default configuration and no process exists to assess or harden it. Debug modes, default credentials, sample applications and administrative endpoints may remain enabled, security HTTP headers are typically absent, and transport security is whatever the framework or server happens to ship with.\n\nBecause nothing measures the runtime configuration against a baseline, weaknesses such as information-leaking error pages or weak TLS ciphers persist unnoticed and provide an easy foothold for attackers.", "evidence": [] }, { "level": 1, "title": "Verify use of tool to perform on-demand scan to identify application vulnerabilities in production environment", "description": "At this stage an engineer hardens the application manually against a defined baseline and verifies the result on demand. This might involve disabling debug and directory listing, removing unused modules and default content, configuring response headers such as `Content-Security-Policy`, `Strict-Transport-Security` and `X-Content-Type-Options` in line with the OWASP Secure Headers Project, and checking the TLS configuration with a tool such as testssl.sh before release.\n\nThis is a clear improvement because the running application is now compared against an objective standard. However, the work is ad hoc and relies on individual diligence, so hardening is applied inconsistently across services and configuration can drift back to insecure defaults between manual checks.", "evidence": [ "A documented hardening baseline exists for the application (e.g. required security headers, TLS policy, least-privilege runtime).", "An on-demand assessment can be produced showing the running application's headers and TLS configuration checked against the baseline (e.g. a testssl.sh report).", "Evidence that debug modes, default content and unused modules have been disabled or removed before release.", "Interview confirms who performs the hardening review and when it is triggered." ], "diagram": "graph LR; Engineer-- manual config review -->Application-- headers, TLS, least privilege -->Engineer;" }, { "level": 2, "title": "Verify that the vulnerability scanning tool is scheduled to perform automated scans and report status to system owner through a centralised issue tracking system", "description": "Here, application hardening is codified and verified automatically within the pipeline. Secure defaults are baked into base images, deployment manifests and configuration templates, and the pipeline checks that they hold, for example by asserting that the expected security headers are present, that TLS meets the required policy, and that the container does not run as root.\n\nBecause these checks are automated and can gate a release, every deployment is held to the same hardened baseline rather than depending on whoever shipped it. The status of each check is reported back to the system owner and recorded centrally, giving a consistent, auditable view of each application's hardening posture.", "evidence": [ "Pipeline configuration shows automated hardening checks (security headers present, TLS policy met, container not running as root) that run on each deployment.", "Secure defaults are codified in base images, deployment manifests or configuration templates under version control.", "A failing hardening check can gate or block a release.", "Check status is reported to the system owner and recorded in a centralised issue tracking system." ], "diagram": "graph LR;\nStart-- code push -->CICD-Pipeline-- hardening checks -->Application--Config Results -->CICD-Pipeline; CICD-Pipeline-- Hardened Release -->Finish" }, { "level": 3, "title": "Verify implementation to apply automatic remediation at the time of vulnerability identified", "description": "At the highest level of maturity, hardening is enforced and monitored continuously across the running estate. Deployed applications are checked on an ongoing basis for drift away from the approved configuration, such as a security header being dropped, a debug endpoint reappearing, or a TLS policy weakening, and deviations are detected as soon as they occur.\n\nFindings are consolidated into a centralised system where they are prioritised and trended over time, and remediation is applied automatically where it is safe to do so, for example by reapplying the hardened configuration or rejecting and redeploying a non-compliant release. The hardening standards themselves, including the required header set and TLS policy, are reviewed periodically so they keep pace with new guidance and emerging threats.", "evidence": [ "Continuous monitoring is configured to detect configuration drift on deployed applications (e.g. dropped header, reappearing debug endpoint, weakened TLS).", "Automated remediation (e.g. reapplying hardened configuration or redeploying a non-compliant release) is demonstrated for at least one class of deviation.", "Findings are consolidated into a centralised system where they are prioritised and trended over time.", "A documented schedule exists for periodically reviewing the hardening standards, including the required header set and TLS policy." ], "diagram": "graph LR;\nApplication-- continuous monitoring -->Drift-Detection-- config drift -->Centralised-Issue-Tracker-- auto remediation -->Application" } ], "tools": [ { "name": "OWASP Secure Headers Project", "url": "https://github.com/OWASP/www-project-secure-headers", "description": "The OWASP Secure Headers Project (OSHP) describes the HTTP response headers an application can set to harden its behaviour in the browser, along with recommended values and guidance on common pitfalls. It is the reference for configuring headers such as `Content-Security-Policy`, `Strict-Transport-Security`, `X-Content-Type-Options`, `Referrer-Policy` and `Permissions-Policy`, and is invaluable when defining the baseline that automated checks should enforce.", "integrations": [ { "platform": "config", "label": null, "link": "https://github.com/OWASP/www-project-secure-headers", "code": "add_header Strict-Transport-Security \"max-age=63072000; includeSubDomains; preload\" always;\nadd_header Content-Security-Policy \"default-src 'self'; frame-ancestors 'none'\" always;\nadd_header X-Content-Type-Options \"nosniff\" always;\nadd_header Referrer-Policy \"no-referrer\" always;\nadd_header Permissions-Policy \"geolocation=(), camera=(), microphone=()\" always;\nserver_tokens off;" } ] }, { "name": "testssl.sh", "url": "https://github.com/drwetter/testssl.sh", "description": "testssl.sh is a free command-line tool that checks a server's TLS/SSL configuration on any port, reporting on supported protocols, cipher suites, certificate details and known vulnerabilities such as Heartbleed and ROBOT. It is self-contained and easy to run in a pipeline, making it ideal for verifying that an application's transport security meets the required policy before and after deployment.", "integrations": [ { "platform": "github-actions", "label": null, "link": "https://github.com/drwetter/testssl.sh", "code": "name: testssl\non:\n workflow_dispatch:\n schedule:\n - cron: \"0 6 * * *\" # run once a day at 6 AM\njobs:\n testssl:\n runs-on: ubuntu-latest\n steps:\n - name: Clone testssl.sh\n run: git clone --depth 1 https://github.com/drwetter/testssl.sh.git\n - name: Run TLS assessment\n run: |\n ./testssl.sh/testssl.sh --quiet --severity HIGH \\\n --jsonfile testssl-report.json https://example.com || true\n - name: Upload testssl report\n uses: actions/upload-artifact@v4\n with:\n name: testssl-report\n path: testssl-report.json" } ] } ], "mappings": { "owasp_samm": [ "Operations > Environment Management" ], "owasp_asvs": [ "V14 Configuration" ], "nist_ssdf": [ "PW.9 Configure Software to Have Secure Settings by Default", "RV.1 Identify and Confirm Vulnerabilities" ], "iso_27001": [ "A.8.9 Configuration management", "A.8.8 Management of technical vulnerabilities" ] } }, { "id": "DSOVS-OPR-003", "code": "OPR-003", "title": "Environment Security Logging", "phase": "Operate/Monitor", "slug": "OPR-003-Environment-Security-Logging", "status": "complete", "type": "tool", "summary": "Environment Security Logging is a method of tracking and logging any changes that are made to an environment's security configurations.\n\nThis includes anything from changing firewall rules to user accounts being created or deleted.\n\nIt is an important part of DevSecOps because it helps identify security vulnerabilities and potential threats in an environment before they can be exploited by malicious actors.\n\nBy having a comprehensive log of system changes, DevSecOps teams can quickly respond to any suspicious activity or anomalies. Additionally, environment security logging helps with compliance requirements, ensuring that all necessary security measures are being taken.", "doc_url": "https://github.com/OWASP/www-project-devsecops-verification-standard/blob/main/document/OPR-003-Environment-Security-Logging.md", "levels": [ { "level": 0, "title": "No centralised logging for security events", "description": "At this level of maturity the environment produces little or no security telemetry, and whatever logs do exist are scattered across individual hosts, cloud accounts and network devices without any consistent collection. Operating system audit trails, cloud control-plane events, firewall and load-balancer records, and container runtime activity are either disabled or left in their local defaults.\n\nBecause nothing is gathered in a common place, investigating an incident means logging into machines one at a time and hoping the relevant records have not already rotated away. There is no reliable way to reconstruct who changed a security group, created a privileged account, or restarted a workload, which leaves the team effectively blind to malicious or accidental changes in the environment.", "evidence": [] }, { "level": 1, "title": "Verify that environment security events are logged and monitored in a centralised location", "description": "At level one the important sources of environment telemetry are switched on and their logs are deliberately captured. Host-level audit logs, cloud provider audit trails such as CloudTrail or Activity Log, VPC and network flow logs, and container runtime events are retained rather than discarded, so the raw material needed to answer security questions exists.\n\nReview of these logs, however, is still largely manual and reactive. Engineers query the logs on demand, usually after an alert from another system or during an incident or audit, rather than as part of a continuous process. The data is available and trustworthy enough to support an investigation, but coverage gaps and the human effort involved mean that suspicious activity can sit unnoticed until someone goes looking for it.", "evidence": [ "Cloud audit trails (e.g. CloudTrail, Azure Activity Log) and host audit logging are confirmed enabled across accounts and hosts.", "VPC/network flow logs and container runtime event logging are configured and retained rather than discarded.", "A sample query against the collected logs can answer who created a privileged account or changed a security group.", "Interview confirms which engineers query the logs and how investigations are initiated." ], "diagram": "graph LR; Hosts-- writes logs -->Local-Logs; Cloud-- writes logs -->Local-Logs; Network-- writes logs -->Local-Logs; Containers-- writes logs -->Local-Logs; Local-Logs-- on-demand review -->Analyst;" }, { "level": 2, "title": "Verify implementation of alert and notification to development team for abuse and anomalies", "description": "At level two the captured telemetry is shipped to a central platform, typically a SIEM or equivalent log analytics stack, where events from across hosts, cloud accounts, network and container layers are normalised and stored together. With everything in one place the team can write detection rules and dashboards that watch for known-bad patterns such as disabled audit logging, new privileged identities, security-group changes opening sensitive ports, or unexpected outbound connections from a workload.\n\nCrucially, these detections are wired to notifications so that the right development or operations team is alerted automatically when an anomaly or abuse pattern fires, instead of relying on someone happening to inspect a dashboard. The shift from on-demand review to automated, near-real-time alerting is what distinguishes this level: the environment now actively surfaces issues rather than merely recording them.", "evidence": [ "A central SIEM or log analytics platform aggregates and normalises host, cloud, network and container telemetry.", "Detection rules exist for patterns such as disabled audit logging, new privileged identities or security-group changes opening sensitive ports.", "Alerts are wired to a notification channel that automatically reaches the responsible development or operations team.", "Evidence of a past alert firing and being delivered to the team in near real time." ], "diagram": "graph LR; Hosts-->Log-Shipper; Cloud-->Log-Shipper; Network-->Log-Shipper; Containers-->Log-Shipper; Log-Shipper-- aggregates -->SIEM-- detection rules -->Alerts-- notifies -->Team;" }, { "level": 3, "title": "Verify that development team have ability to monitor and analyse environment security events", "description": "At level three logging is treated as an engineered, continuously improving capability. Detections are correlated across multiple sources so that a single suspicious sequence, for example an unusual cloud API call followed by a container spawning an unexpected process, is recognised as one incident rather than a handful of disconnected alerts. Coverage is measured against the environment's assets so the team can demonstrate which systems, accounts and event types are actually being collected, and can close gaps deliberately.\n\nRetention and integrity controls underpin the whole pipeline: logs are kept for a defined period to satisfy investigation and compliance needs, and they are protected from tampering through write-once storage, access controls and integrity checks so that an attacker cannot quietly erase their tracks. Finally, the detection content is tuned on an ongoing basis, with noisy rules refined, new threats modelled, and effectiveness reviewed, so that signal-to-noise improves over time and the team retains genuine, analyst-ready visibility into the security state of the environment.", "evidence": [ "Correlation rules link events across sources so a multi-step sequence is recognised as a single incident.", "A documented coverage map shows which systems, accounts and event types are collected, with a process to close gaps.", "Retention periods and tamper-protection controls (write-once storage, access controls, integrity checks) are documented and verifiable.", "A periodic review tunes detection content and records changes to noisy or new rules." ], "diagram": "graph LR; SIEM-- correlated detections -->Correlation-- measured coverage -->Centralised-Issue-Tracker; Centralised-Issue-Tracker-- continuous tuning -->SIEM;" } ], "tools": [ { "name": "Wazuh", "url": "https://github.com/wazuh/wazuh", "description": "Wazuh is an open source security platform that unifies host-based intrusion detection, log analysis, file integrity monitoring and cloud security monitoring. Agents collect operating system and application telemetry, evaluate it against a rule set, and forward matches to a central manager, making it a practical foundation for centralised environment logging with alerting and compliance mapping.", "integrations": [ { "platform": "config", "label": null, "link": null, "code": "# Wazuh rule: alert when an audit log is cleared on a monitored host\n\n \n 80700\n auditctl\n Audit configuration was modified on $(agent.name)\n \n T1562.001\n \n \n" } ] }, { "name": "Falco", "url": "https://github.com/falcosecurity/falco", "description": "Falco is a CNCF runtime security project that watches kernel-level system calls (and Kubernetes audit events) to detect anomalous behaviour inside containers and on hosts in real time. It ships with a maintained rule set and emits structured alerts that integrate cleanly with downstream SIEM and notification pipelines.", "integrations": [ { "platform": "config", "label": null, "link": null, "code": "# Falco rule: detect a shell spawned inside a container\n- rule: Terminal shell in container\n desc: A shell was used as the entrypoint/exec in a container\n condition: >\n spawned_process and container\n and shell_procs and proc.tty != 0\n output: >\n Shell spawned in container (user=%user.name container=%container.id\n image=%container.image.repository proc=%proc.cmdline)\n priority: WARNING\n tags: [container, shell, mitre_execution]" } ] }, { "name": "Elastic Stack / OpenSearch", "url": "https://github.com/opensearch-project/OpenSearch", "description": "The Elastic Stack and its open source fork OpenSearch provide the aggregation, search and visualisation layer that ties host, cloud, network and container telemetry together. Beats and Logstash (or the OpenSearch equivalents) ship and parse logs into a central store, while the bundled SIEM/security analytics features add correlation rules, dashboards and alerting on top of the indexed data." } ], "mappings": { "owasp_samm": [ "Operations > Operational Management", "Operations > Environment Management" ], "nist_ssdf": [ "RV.1 Identify and Confirm Vulnerabilities", "RV.3 Analyze Vulnerabilities to Identify Their Root Causes" ], "iso_27001": [ "A.8.15 Logging", "A.8.16 Monitoring activities" ] } }, { "id": "DSOVS-OPR-004", "code": "OPR-004", "title": "Application Security Logging", "phase": "Operate/Monitor", "slug": "OPR-004-Application-Security-Logging", "status": "complete", "type": "tool", "summary": "Application Security Logging is a process of collecting, analyzing and managing log data related to application security events.\n\nIt helps to detect security breaches, identify unauthorized access attempts, or monitor the performance and effectiveness of application security controls.\n\nIt is an important element of DevSecOps because it provides visibility into the security posture of applications.\n\nThis makes it easier to spot potential threats and respond swiftly in order to minimize damage.\n\nAdditionally, application security logging can also be used to detect and investigate suspicious behavior and quickly take corrective action to mitigate risk.", "doc_url": "https://github.com/OWASP/www-project-devsecops-verification-standard/blob/main/document/OPR-004-Application-Security-Logging.md", "levels": [ { "level": 0, "title": "No centralised logging for security events", "description": "At this level applications emit little in the way of security-relevant logging, and what they do produce is inconsistent and local to each service. Events that matter for security, such as authentication attempts, authorisation decisions, input validation failures and significant state changes, are either not recorded at all or buried in generic debug output that nobody collects.\n\nWithout deliberate, structured security logging there is no dependable trail to show who did what within the application. When an account is compromised or a flaw is exploited, the team has no way to reconstruct the sequence of events, and the absence of any guidance also means developers risk the opposite failure mode of logging passwords, tokens or personal data in plain text.", "evidence": [] }, { "level": 1, "title": "Verify that application security events are logged and monitored in a centralised location", "description": "At level one the application deliberately logs security-relevant events. Following guidance such as the OWASP Logging Cheat Sheet and ASVS V7, the team identifies the events worth recording, including successful and failed logins, access-control failures, input validation and output encoding failures, session lifecycle changes, and use of higher-risk functionality, and emits them in a consistent, structured format with enough context to be useful.\n\nEqual care is taken over what must never appear in logs: credentials, session tokens, API keys and sensitive personal data are excluded or masked at the point of logging. At this level review is still mostly manual and on demand, with developers or responders querying the logs when investigating a specific issue rather than monitoring them continuously, but the events being captured are meaningful and safe to retain.", "evidence": [ "A documented list of security-relevant events (logins, access-control failures, validation failures, session changes) the application logs.", "Sample log records show events emitted in a consistent, structured format with sufficient context.", "Code or configuration confirms credentials, tokens, API keys and sensitive personal data are excluded or masked at the point of logging.", "Interview confirms how developers query logs when investigating a specific issue." ], "diagram": "graph LR; AuthN-AuthZ-Events-- writes logs -->Local-Logs; Validation-Failures-- writes logs -->Local-Logs; Local-Logs-- on-demand review -->Developer;" }, { "level": 2, "title": "Verify implementation of alert and notification to development team for abuse and anomalies", "description": "At level two application security logs are forwarded to a central platform where events from every service are aggregated, normalised and stored together, typically a SIEM or log analytics stack. This consolidated view lets the team reason about behaviour across the whole application rather than one instance at a time, and to spot patterns such as credential-stuffing, repeated authorisation failures, or a spike in input validation rejections that would be invisible in isolated logs.\n\nDetection rules built on this data are connected to alerting, so that abuse and anomalies automatically notify the responsible development team in near real time. The move from passively storing application events to actively alerting on suspicious patterns is the defining step at this level, turning the log stream into an early-warning system rather than a forensic archive consulted only after the fact.", "evidence": [ "Application security logs from every service are forwarded to a central SIEM or log analytics platform and normalised.", "Detection rules exist for abuse patterns such as credential-stuffing, repeated authorisation failures or input validation spikes.", "Alerts automatically notify the responsible development team in near real time via a defined channel.", "Evidence of a past anomaly alert being raised and delivered to the team." ], "diagram": "graph LR; AuthN-AuthZ-Events-->Log-Shipper; Validation-Failures-->Log-Shipper; Log-Shipper-- aggregates -->SIEM-- detection rules -->Alerts-- notifies -->Team;" }, { "level": 3, "title": "Verify that development team have ability to monitor and analyse application security events", "description": "At level three application security logging is a measured and continuously refined discipline. Detections are correlated across events and with environment telemetry so that a meaningful attack narrative, for example a series of failed authorisations followed by a successful privilege change and an unusual data export, is recognised as a single incident. Coverage is tracked against the application's features and trust boundaries, so the team can show which security events are instrumented and can prioritise closing the gaps.\n\nUnderpinning this are retention and integrity controls: logs are kept for a defined period and protected against tampering so they remain trustworthy evidence, while continuing to exclude secrets and sensitive personal data. The team also tunes detection content on an ongoing basis, reducing noisy or low-value alerts and adding coverage for new abuse cases as the application evolves, giving developers genuine, analyst-ready insight into how their application is being used and attacked.", "evidence": [ "Correlation rules link application events (and environment telemetry) so an attack narrative is recognised as a single incident.", "A coverage map ties instrumented security events to the application's features and trust boundaries, with gaps prioritised.", "Retention periods and tamper-protection controls are documented, and logs continue to exclude secrets and sensitive personal data.", "A periodic review tunes detection content, reducing noisy alerts and adding coverage for new abuse cases." ], "diagram": "graph LR; SIEM-- correlated detections -->Correlation-- measured coverage -->Centralised-Issue-Tracker; Centralised-Issue-Tracker-- continuous tuning -->SIEM;" } ], "tools": [ { "name": "OWASP Security Logging", "url": "https://github.com/javabeanz/owasp-security-logging", "description": "The OWASP Security Logging project provides logging libraries (with bindings for Logback and Log4j2) that make it easier to emit consistent, security-relevant events from application code. It adds helpers for marking security events, masking sensitive values and enriching log entries with contextual metadata, which supports the structured, secret-free logging that the levels above require.\n\nStructured-logging libraries more generally (for example logback/log4j2 with JSON encoders in the JVM ecosystem, structlog in Python, or Serilog in .NET) are also worth adopting, because emitting events as structured, parseable records is what allows a central platform to search, correlate and alert on them reliably." } ], "further_reading": [ { "url": "https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html", "note": "OWASP Logging Cheat Sheet" }, { "url": "https://owasp.org/www-project-application-security-verification-standard/", "note": "OWASP Application Security Verification Standard (ASVS) - V7 Logging and Error Handling" }, { "url": "https://cheatsheetseries.owasp.org/cheatsheets/Logging_Vocabulary_Cheat_Sheet.html", "note": "OWASP Logging Vocabulary Cheat Sheet" }, { "url": "https://owasp.org/Top10/A09_2021-Security_Logging_and_Monitoring_Failures/", "note": "OWASP Top 10 - A09:2021 Security Logging and Monitoring Failures" } ], "mappings": { "owasp_samm": [ "Operations > Operational Management" ], "owasp_asvs": [ "V7 Logging and Error Handling" ], "nist_ssdf": [ "RV.1 Identify and Confirm Vulnerabilities", "RV.3 Analyze Vulnerabilities to Identify Their Root Causes" ], "iso_27001": [ "A.8.15 Logging", "A.8.16 Monitoring activities" ] } }, { "id": "DSOVS-OPR-005", "code": "OPR-005", "title": "Vulnerability Disclosure", "phase": "Operate/Monitor", "slug": "OPR-005-Responsible-Disclosure", "status": "complete", "type": "tool", "summary": "Responsible disclosure is a practice of reporting security vulnerabilities to software vendors in order to give them a chance to address the issue before it is made public.\n\nThis can help ensure that vulnerabilities are addressed quickly and efficiently, preventing potential malicious exploitation of them.\n\nResponsible disclosure is important for secure software development because it allows developers to be proactive in addressing any security weaknesses before they are exploited.\n\nIt also ensures that users are protected from potential attacks by ensuring that applications remain secure.", "doc_url": "https://github.com/OWASP/www-project-devsecops-verification-standard/blob/main/document/OPR-005-Responsible-Disclosure.md", "levels": [ { "level": 0, "title": "No vulnerability disclosure policy", "description": "At this level of security maturity, there are no defined ways to receive security vulnerabilities.", "evidence": [] }, { "level": 1, "title": "Vulnerability disclosure policy exists", "description": "At level one, the product has a defined responsible disclosure policy with clear instructions on how to send vulnerability reports, as well as a clear definition of scope.\n\nTypically this will be security e-mail such as (security@company.com) and will processed manually by internal teams.", "evidence": [ "A published vulnerability disclosure policy with clear reporting instructions and a defined scope.", "A monitored intake channel (e.g. security@company.com or a security.txt file) exists and is reachable.", "Interview confirms which internal team processes incoming reports." ] }, { "level": 2, "title": "Vulnerability disclosures are managed and tracked using software", "description": "Responsible vulnerabity disclosure enables external security researchers to report vulnerabilities that they have discovered in software.\n\nIt is important for these vulnerabilities to be stored and tracked the same way as internally found vulnerabilities, in order to ensure that they do not slip through the gaps.\n\nThis helps ensure that all issues are managed accordingly and that the vulnerabilities reported from external sources make their way into the secure software development lifecycle.\n\nBy properly tracking and managing these issues with issue tracking software, developers can ensure that any potential security threats are addressed quickly and effectively.\n\nThis helps ensure that applications remain secure and that users can trust the software they are using.", "evidence": [ "Externally reported vulnerabilities are recorded in the same issue tracker as internally found vulnerabilities.", "Tracked issues carry severity, ownership and remediation status and feed into the SDLC.", "Sample records show externally reported issues being triaged and resolved over time." ] }, { "level": 3, "title": "A Coordinated Vulnerability Disclosure program exists", "description": "A coordinated vulnerability disclosure program is critical for the maturity of a secure software development lifecycle.\n\nThis program helps ensure that any vulnerabilities discovered in software are addressed quickly and effectively, while also helping to build trust between software users and developers.\n\nBy providing an organized and standardized framework for vulnerability disclosure, firms can demonstrate their commitment to security and provide transparency around the process.\n\nAdditionally, by coordinating with other organizations, firms can benefit from the expertise and knowledge of others. This helps ensure that all vulnerabilities are managed accordingly and that secure software development is the priority.", "evidence": [ "A documented coordinated vulnerability disclosure program with defined timelines and researcher communication.", "Public transparency around the process (e.g. published policy, advisories or a bug bounty platform).", "Evidence of coordination with external parties or researchers on past disclosures." ] } ], "tools": [ { "name": "SECURITY.TXT", "url": "https://github.com/securitytxt/security-txt", "description": "security.txt provides a way for websites to define security policies. The security.txt file sets clear guidelines for security researchers on how to report security issues. security.txt is the equivalent of robots.txt, but for security issues.", "integrations": [ { "platform": "config", "label": null, "link": null, "code": "Contact: mailto:security@example.com\nExpires: 2026-12-31T23:59:00.000Z\nEncryption: https://example.com/pgp-key.txt\nAcknowledgments: https://example.com/hall-of-fame.html\nPolicy: https://example.com/security-policy.html\nPreferred-Languages: en" } ] } ], "mappings": { "owasp_samm": [ "Operations > Issue Management" ], "nist_ssdf": [ "RV.1 Identify and Confirm Vulnerabilities", "RV.3 Analyze Vulnerabilities to Identify Their Root Causes" ], "iso_27001": [ "A.5.7 Threat intelligence", "A.8.8 Management of technical vulnerabilities" ] }, "credits": [ { "name": "EdOverflow", "url": "https://github.com/EdOverflow" }, { "name": "Katie Moussouris", "url": "https://twitter.com/k8em0" } ] }, { "id": "DSOVS-OPR-006", "code": "OPR-006", "title": "Certificate Management", "phase": "Operate/Monitor", "slug": "OPR-006-Certificate-Management", "status": "complete", "type": "tool", "summary": "Certificate Management is the process of creating, storing, and managing certificates and private keys used in websites, applications, and other systems.\n\nThese digital certificates are what enable secure communication between browsers and websites, with the certificates containing critical information such as public and private keys and digital signatures.\n\nCertificate Management is an important part of DevSecOps because it ensures secure communication between applications and servers, and prevents malicious activity by verifying the identity of the entity communicating.\n\nIn addition, it provides a secure way to authenticate customers, which helps ensure that only authorized users can access sensitive data.", "doc_url": "https://github.com/OWASP/www-project-devsecops-verification-standard/blob/main/document/OPR-006-Certificate-Management.md", "levels": [ { "level": 0, "title": "Nominated role or team outside the development team that performs certificate life-cycle management tasks", "description": "At this level, responsibility for the certificate life cycle sits with a separate role or team outside of the development team, and the work is handled manually and reactively. Certificates are issued, renewed and replaced on request, often through a ticket or email to a central operations or networking function, with no shared inventory that the development team can see or act on.\n\nBecause the people running the services are not the people managing the certificates, knowledge is fragmented and renewals depend on individuals remembering deadlines. The common failure modes are predictable: expired certificates that cause sudden outages, weak or outdated cryptography that goes unnoticed, and private keys handled inconsistently. There is no systematic visibility into what certificates exist, where they are deployed, or when they expire.", "evidence": [] }, { "level": 1, "title": "Verify that the full-cycle management of PKI certificates is performed by the development team", "description": "At Level 1, ownership of the full certificate life cycle moves to the development team that runs the service, so the people who understand the application are also the ones issuing, deploying, rotating and revoking its certificates. This removes the hand-off delays of the previous level and lets renewals be planned alongside normal release work.\n\nThe team uses on-demand tooling to generate certificate signing requests, request certificates from a certificate authority, and install them where they are needed. The process is still largely human-driven and triggered when someone notices an upcoming expiry or a new endpoint, but accountability is now clear and the team can choose appropriate key sizes and signature algorithms rather than inheriting whatever a remote team configured. This shortens the feedback loop and reduces the chance of a certificate being forgotten, even though it does not yet remove the manual effort.", "evidence": [ "Documentation or a RACI shows the development team owns issuing, deploying, rotating and revoking certificates for its services.", "Evidence of an on-demand CSR being generated and a certificate obtained from a CA by the team.", "Configuration shows the team selecting approved key sizes and signature algorithms for its certificates.", "Interview confirms how the team tracks upcoming expiries and triggers renewals." ], "diagram": "graph LR; Team-- CSR -->CA-- certificate -->Service-- manual tracking -->Team;" }, { "level": 2, "title": "Verify implementation of automated PKI life-cycle management", "description": "Level 2 replaces the manual, on-demand work with automated PKI life-cycle management. Certificate issuance and renewal are driven by tooling that requests, validates, installs and rotates certificates without human intervention, typically through a protocol such as ACME and a controller that watches for certificates approaching expiry and renews them well in advance.\n\nBecause renewal is continuous and automatic, the entire class of expiry-related outages is largely designed out, and rotating certificates frequently becomes practical rather than painful. Automation also enforces consistency: every certificate is issued with approved key types, algorithms and validity periods, private keys are generated and stored in a controlled way, and short-lived certificates can be adopted safely. This is a clear improvement over Level 1, where strong practices depended on the team remembering to apply them each time.", "evidence": [ "An ACME client or controller (for example cert-manager or certbot) is configured to request and renew certificates automatically.", "Configuration shows automatic renewal triggering before expiry (for example a renewBefore window or scheduled certbot renew).", "Approved key types, algorithms and validity periods are enforced in the automation configuration.", "Logs or audit trail show at least one certificate renewed automatically without manual intervention." ], "diagram": "graph LR; ACME-Client-- CSR -->CA-- certificate -->Service-- nearing expiry -->Auto-Renew-- rotate -->Service;" }, { "level": 3, "title": "Verify implementation of end-to-end secure communication", "description": "At Level 3, automated certificate management is extended into a centralised, measured capability that underpins end-to-end secure communication across the estate. Every certificate, whether protecting an external endpoint or internal service-to-service traffic, is tracked in a central inventory that records its issuer, key parameters, deployment location and expiry, giving a single source of truth across teams.\n\nThis central view is actively monitored and measured. Dashboards and alerts surface upcoming expiries, weak or non-compliant cryptography and certificates issued outside policy, and these signals feed into the same tracking and reporting used for other security findings. The configuration and effectiveness of the certificate management programme are reviewed periodically so that algorithms, validity periods and automation coverage are tightened over time. The result is encrypted communication along the full path between components, continuously verified rather than assumed, building on the automation of Level 2 with oversight, metrics and continuous improvement.", "evidence": [ "A central certificate inventory records issuer, key parameters, deployment location and expiry for every certificate.", "Dashboards and alerts surface upcoming expiries, weak or non-compliant cryptography and out-of-policy issuance.", "Internal service-to-service traffic, not only external endpoints, is shown to be encrypted with managed certificates.", "A documented schedule exists for periodically reviewing the certificate management programme and tightening algorithms, validity periods and automation coverage." ], "diagram": "graph LR; ACME-Client-- certificate -->Service-- registers -->Central-Inventory-- expiry monitoring -->Alerts; Central-Inventory-- nearing expiry -->Auto-Rotate-- rotate -->Service;" } ], "tools": [ { "name": "cert-manager", "url": "https://github.com/cert-manager/cert-manager", "description": "cert-manager is a Kubernetes controller that automates the issuance, renewal and rotation of TLS certificates from sources such as Let's Encrypt, HashiCorp Vault and private PKIs. It models certificates as native Kubernetes resources, watches them for expiry, and renews them automatically before they lapse, removing manual life-cycle work for workloads running on a cluster.\n\nThe example below defines an ACME `ClusterIssuer` backed by Let's Encrypt and a `Certificate` that cert-manager keeps valid and stores in the named secret.", "integrations": [ { "platform": "config", "label": null, "link": null, "code": "apiVersion: cert-manager.io/v1\nkind: ClusterIssuer\nmetadata:\n name: letsencrypt-prod\nspec:\n acme:\n server: https://acme-v02.api.letsencrypt.org/directory\n email: security@example.com\n privateKeySecretRef:\n name: letsencrypt-prod-account-key\n solvers:\n - http01:\n ingress:\n ingressClassName: nginx\n---\napiVersion: cert-manager.io/v1\nkind: Certificate\nmetadata:\n name: example-com-tls\n namespace: web\nspec:\n secretName: example-com-tls\n duration: 2160h # 90 days\n renewBefore: 360h # rotate 15 days before expiry\n privateKey:\n algorithm: ECDSA\n size: 256\n dnsNames:\n - example.com\n - www.example.com\n issuerRef:\n name: letsencrypt-prod\n kind: ClusterIssuer\n group: cert-manager.io" } ] }, { "name": "Certbot / Let's Encrypt ACME", "url": "https://github.com/certbot/certbot", "description": "Certbot is the EFF's reference ACME client for obtaining and renewing free, automated certificates from Let's Encrypt. It is well suited to traditional virtual machines and standalone web servers, where it can configure popular web servers directly and install a renewal timer so certificates are rotated before they expire.\n\nThe command below issues a certificate for one or more domains and installs an automatic renewal job; `certbot renew` is then run on a schedule (typically twice daily) to rotate certificates as they approach expiry.", "integrations": [ { "platform": "cli", "label": null, "link": null, "code": "# Obtain and install a certificate for nginx, agreeing to the ACME terms\ncertbot --nginx \\\n -d example.com -d www.example.com \\\n --agree-tos -m security@example.com --non-interactive\n\n# Test the automatic renewal that certbot schedules (rotates near expiry)\ncertbot renew --dry-run" } ] } ], "mappings": { "owasp_samm": [ "Operations > Environment Management" ], "owasp_asvs": [ "V1.9 Communications Architecture", "V9 Communications" ], "nist_ssdf": [ "PO.5 Implement and Maintain Secure Environments for Software Development", "PS.2 Provide a Mechanism for Verifying Software Release Integrity" ], "iso_27001": [ "A.8.24 Use of cryptography" ] } }, { "id": "DSOVS-OPR-007", "code": "OPR-007", "title": "Attack Surface Management", "phase": "Operate/Monitor", "slug": "OPR-007-Attack-Surface-Management", "status": "complete", "type": "tool", "summary": "Attack surface management (ASM) solutions and tools are used to identify, track, and manage the vulnerabilities present in an organization's digital infrastructure, including software, hardware, and networks.\n\nThe goal of ASM is to reduce the organization's overall attack surface, which is the sum of all the points in its digital infrastructure that could potentially be exploited by cybercriminals. By reducing the attack surface, organizations can better protect themselves from cyber attacks and reduce their risk of a successful breach.\n\nASM solutions and tools typically provide a comprehensive view of an organization's digital assets, including those that are hidden or forgotten. They also identify vulnerabilities and misconfigurations in software, systems, and networks, which can be used by attackers to gain unauthorized access or cause damage.\n\nSome of the benefits of ASM solutions and tools for cybersecurity in organizations include:\n\n1. Improved visibility: ASM solutions provide a comprehensive view of an organization's digital assets, which allows for better visibility and understanding of the security risks and vulnerabilities present in the system.\n\n2. Proactive approach: ASM solutions enable organizations to take a proactive approach to security by identifying and addressing vulnerabilities before they are exploited by cybercriminals.\n\n3. Enhanced threat intelligence: ASM tools can provide valuable threat intelligence by tracking the latest threats and vulnerabilities, allowing organizations to prioritize and address the most critical risks.\n\n4. Compliance: ASM solutions can help organizations comply with various regulatory requirements and standards, such as the General Data Protection Regulation (GDPR) and the Payment Card Industry Data Security Standard (PCI DSS).\n\n5. Cost savings: ASM solutions can help organizations reduce the costs associated with data breaches and cyber attacks by addressing vulnerabilities and reducing the likelihood of a successful attack.\n\nOverall, ASM solutions and tools are essential for maintaining strong cybersecurity posture in organizations, providing better visibility, proactive approach, enhanced threat intelligence, compliance, and cost savings.", "doc_url": "https://github.com/OWASP/www-project-devsecops-verification-standard/blob/main/document/OPR-007-Attack-Surface-Management.md", "levels": [ { "level": 0, "title": "No tool to perform real-time discovery, classify, assess and monitor the security organisation's IT assets", "description": "At this level there is no tooling to discover, classify, assess or monitor the organisation's internet-facing assets. Whatever inventory exists is manual and quickly goes stale, captured in spreadsheets or tribal knowledge rather than derived from what is actually exposed.\n\nAs a result the organisation has no reliable picture of its true attack surface. Forgotten subdomains, shadow IT, abandoned cloud instances and newly exposed services accumulate unseen, and any one of them can become an entry point that defenders are unaware of. Without continuous visibility, exposures are typically only discovered after an incident or an external report.", "evidence": [] }, { "level": 1, "title": "Verify use of tool to perform continous discovery, classify, assess and monitor the security of organisation's IT assets", "description": "At Level 1 a dedicated tool is introduced to discover and enumerate the organisation's external assets, replacing manual record-keeping with active reconnaissance. Subdomains, hosts, open ports and exposed services are identified by the tool, giving a far more accurate and current view of what is reachable from the internet than any hand-maintained list.\n\nThe tool is run regularly and can be scheduled to refresh the inventory on an ongoing basis, so newly stood-up or decommissioned assets are reflected over time. The emphasis here is on visibility and coverage: the organisation now knows what it has exposed and can assess and monitor those assets, even if triage of the results still relies largely on human judgement.", "evidence": [ "An ASM or asset discovery tool (for example OWASP Amass) is installed and configured against the organisation's domains.", "Output of at least one discovery run enumerating subdomains, hosts, open ports or exposed services.", "A schedule or cron configuration shows the inventory being refreshed on an ongoing basis.", "Interview confirms who reviews the discovered assets and how new exposures are triaged." ], "diagram": "graph LR; ASM-Tool-- on-demand discovery -->Assets-- manual triage -->Analyst;" }, { "level": 2, "title": "Verify that discovered organisation's IT assets are properly classified and any identified possible attack vectors are automatically prioritised", "description": "Level 2 builds on continuous discovery by adding automated classification and prioritisation. Discovered assets are enriched and categorised, for example by technology, ownership or business criticality, and the tooling automatically probes them for misconfigurations, exposed services and known vulnerabilities, turning a raw inventory into an actionable view of attack vectors.\n\nRather than presenting every finding with equal weight, the pipeline ranks possible attack vectors so that the most serious exposures rise to the top. This continuous, automated flow means new assets are assessed as soon as they appear and the highest-risk issues are surfaced for attention first, a clear advance over Level 1 where discovery existed but interpretation and prioritisation were manual.", "evidence": [ "Discovered assets are automatically classified or enriched (for example by technology, ownership or business criticality).", "Automated probing (for example with Nuclei) checks discovered assets for misconfigurations, exposed services and known vulnerabilities.", "Findings are ranked or scored by severity so the highest-risk exposures are surfaced first.", "Pipeline configuration shows new assets being assessed automatically as they appear." ], "diagram": "graph LR; ASM-Tool-- continuous discovery -->Assets-- auto classify -->Classify-- auto prioritise -->Ranked-Findings;" }, { "level": 3, "title": "Verify that the findings are automatically recorded to a centralised issue tracker system and periodically review tool's effectiveness", "description": "At Level 3 the attack surface management process is the same continuous, automated and prioritised pipeline as Level 2, with the addition that findings are automatically recorded into a centralised issue tracking system. Each exposure becomes a tracked item that can be assigned, remediated and verified alongside other security work, ensuring nothing discovered is quietly lost.\n\nBecause findings are centralised, the programme can be measured: metrics such as time to remediate, recurrence of exposures and coverage of the known estate become visible and reportable. The effectiveness of the tooling and process is reviewed periodically, with detection rules, scoping and prioritisation tuned in response to what the data shows. This closes the loop from discovery through remediation to continuous improvement.", "evidence": [ "ASM findings are automatically created in a centralised issue tracker with severity and ownership.", "Metrics such as time to remediate, recurrence of exposures and estate coverage are visible and reportable.", "A documented schedule exists for periodically reviewing tool effectiveness and tuning detection rules, scoping and prioritisation.", "Evidence shows discovered exposures being tracked through to remediation and verification." ], "diagram": "graph LR; ASM-Tool-- continuous discovery -->Assets-- classify and prioritise -->Ranked-Findings-- auto record -->Centralised-Issue-Tracker-- periodic review -->Metrics;" } ], "tools": [ { "name": "OWASP Amass", "url": "https://github.com/owasp-amass/amass", "description": "The OWASP Amass project performs in-depth attack surface mapping and external asset discovery. It combines passive sources, DNS enumeration and active reconnaissance to discover subdomains, hosts and related infrastructure, making it well suited to continuously building and refreshing an inventory of what an organisation exposes on the internet.\n\nRunning Amass on a schedule lets you track how the external footprint of a domain changes over time and feed the results into downstream assessment.", "integrations": [ { "platform": "cli", "label": null, "link": null, "code": "# Enumerate subdomains and associated assets for a target domain\namass enum -d example.com -o amass-example.txt\n\n# Compare results between runs to detect newly exposed assets\namass enum -d example.com -json results.jsonl" } ] }, { "name": "Nuclei", "url": "https://github.com/projectdiscovery/nuclei", "description": "Nuclei is a fast, template-driven scanner that checks targets for misconfigurations, exposed services and known vulnerabilities using a large, community-maintained template library. Pointed at the assets discovered during attack surface mapping, it automates the assessment and prioritisation step by reporting findings with severity, making it a natural fit for continuous external monitoring.\n\nThe workflow below runs Nuclei on a schedule so that the known attack surface is re-checked regularly and new exposures are surfaced automatically.", "integrations": [ { "platform": "github-actions", "label": null, "link": "https://github.com/projectdiscovery/nuclei-action", "code": "name: nuclei-scan\non:\n workflow_dispatch:\n schedule:\n - cron: \"0 4 * * *\" # run once a day at 4 AM\njobs:\n scan:\n name: nuclei\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v4\n - name: Run Nuclei\n uses: projectdiscovery/nuclei-action@main\n with:\n target: https://example.com\n flags: \"-severity critical,high,medium\"" } ] } ], "mappings": { "owasp_samm": [ "Operations > Environment Management" ], "owasp_asvs": [ "V1 Architecture, Design and Threat Modeling" ], "nist_ssdf": [ "RV.1 Identify and Confirm Vulnerabilities on an Ongoing Basis", "PO.5 Implement and Maintain Secure Environments for Software Development" ], "iso_27001": [ "A.8.8 Management of technical vulnerabilities" ] } } ] }