From 0586fea7cafb7e56d48ca5c1a5638f5cb056784d Mon Sep 17 00:00:00 2001 From: Haksung Jang Date: Sat, 6 Jun 2026 18:49:29 +0900 Subject: [PATCH] =?UTF-8?q?docs(i18n):=20DevSecOps=C2=B7AI=EC=BD=94?= =?UTF-8?q?=EB=94=A9=20=EC=98=81=EB=AC=B8=20=ED=8E=98=EC=9D=B4=EC=A7=80=20?= =?UTF-8?q?=ED=92=88=EC=A7=88=20=ED=8C=A8=EC=8A=A4?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit DevSecOps 11개 + AI 코딩 12개(도구별 5 포함) en 페이지의 기계번역 흔적을 자연스러운 기술 영어로 정리: - 쉼표 띄어쓰기, 붙은 괄호+번역 끼임, 직역체 어순, 코드 주석 속 한국어 조각 번역 - 오역 정정: pipeline-design "Transcription"→"Enterprise-wide"(전사), DevSecOps intro에서 누락된 섹션 복원, agents-repo URL 정정, Step→Stage 용어 통일 - 보존: front matter, import/JSX(.mdx), 링크 경로, admonition, 코드블록(Rules·설정 예시), 표, ISO 절번호, 도구명 - 누수 0(도구호출 XML 잔재), 한국어 잔재 0 확인. 수치 임의 변경 없음(깨진 부분만 ko 대조 복원) 검증: build ko/en SUCCESS, 0 broken, verify 12/12. --- .../current/ai-security-review.md | 18 ++-- .../current/cicd-quick.mdx | 2 +- .../current/iso42001.md | 4 +- .../current/tools/windsurf.md | 2 +- .../current/container-security.md | 32 +++---- .../current/dast.md | 54 ++++++------ .../current/intro.md | 68 ++++++++------ .../current/iso-mapping.md | 76 ++++++++-------- .../current/monitoring.md | 88 +++++++++---------- .../current/pipeline-design.md | 56 ++++++------ .../current/sast.mdx | 2 +- .../current/strategy.md | 78 ++++++++-------- 12 files changed, 244 insertions(+), 236 deletions(-) diff --git a/website/i18n/en/docusaurus-plugin-content-docs-ai-coding/current/ai-security-review.md b/website/i18n/en/docusaurus-plugin-content-docs-ai-coding/current/ai-security-review.md index 9360eba..ab35c9c 100644 --- a/website/i18n/en/docusaurus-plugin-content-docs-ai-coding/current/ai-security-review.md +++ b/website/i18n/en/docusaurus-plugin-content-docs-ai-coding/current/ai-security-review.md @@ -13,9 +13,9 @@ Sending the entire codebase to AI causes high token costs and excessive noise. It is more efficient for **Stage 3 tools (Semgrep and grype) to narrow candidates first, and AI to focus only on those results**. ``` -[Step 3] Semgrep · grype → findings.json +[Stage 3] Semgrep · grype → findings.json ↓ -[Step 4] AI: code context + findings → validation, deep interpretation, and related finding discovery +[Stage 4] AI: code context + findings → validation, deep interpretation, and related finding discovery ↓ PR comment (does not block build) ``` @@ -58,7 +58,7 @@ jobs: with: fetch-depth: 0 - # Step 3 Tools collect results (light rerun) + # Stage 3 tools collect results (light rerun) - name: Run Semgrep (SARIF) run: | pip install semgrep -q @@ -106,7 +106,7 @@ jobs: except Exception: pass - # grype CVE findings parse (High/Criticalonly) + # grype CVE findings parse (High/Critical only) grype_issues = [] try: grype = json.loads(pathlib.Path("grype.json").read_text()) @@ -143,7 +143,7 @@ Assess each item using the format below. Assessment format: - **[Item number]** Real vulnerability (TP) or false positive (FP) | Risk: High/Medium/Low | 1-2 sentence rationale -- TPif TP: add one-line real exploit scenario +- If TP: add a one-line real exploit scenario - For grype CVEs, determine whether the package is used in actual runtime paths --- @@ -152,7 +152,7 @@ Assessment format: {grype_block} --- -detected If there are no findings, output PASS.""" +If there are no detected items, output PASS.""" client = anthropic.Anthropic() response = client.messages.create( @@ -182,7 +182,7 @@ detected If there are no findings, output PASS.""" body: [ '## 🔍 AI Security Review (Findings-Driven)', '', - '> Step 3 Tools(Semgrep·grype) detected Results validated and interpreted by AI.', + '> AI validates and interprets the detection results from Stage 3 tools (Semgrep·grype).', '> False positives are possible; evaluate with context. This is not a build-blocking criterion.', '', result @@ -197,8 +197,8 @@ detected If there are no findings, output PASS.""" ``` PR opened │ - ├─ [Step 3] Semgrep → semgrep.sarif ─┐ - └─ [Step 3] grype → grype.json ─┤ + ├─ [Stage 3] Semgrep → semgrep.sarif ─┐ + └─ [Stage 3] grype → grype.json ─┤ ↓ findings parse + code context extract ↓ diff --git a/website/i18n/en/docusaurus-plugin-content-docs-ai-coding/current/cicd-quick.mdx b/website/i18n/en/docusaurus-plugin-content-docs-ai-coding/current/cicd-quick.mdx index 675dca3..d93bf03 100644 --- a/website/i18n/en/docusaurus-plugin-content-docs-ai-coding/current/cicd-quick.mdx +++ b/website/i18n/en/docusaurus-plugin-content-docs-ai-coding/current/cicd-quick.mdx @@ -22,7 +22,7 @@ AI rule files like `CLAUDE.md` or `.cursorrules` are ultimately just "recommenda In environments that rely only on rule files, policy-violating code can flow directly into production the moment a PR is merged. The faster AI tools generate code, the greater this risk becomes. -CI/CD gates are the only safety net that can mechanically block policy violations regardless of human or AI mistakes. True Hard Block starts working from the 3-step strategy (see also the [4-step strategy](./strategy)). +CI/CD gates are the only safety net that can mechanically block policy violations regardless of human or AI mistakes. True hard blocking begins at Stage 3 of the [5-stage strategy](./strategy). --- diff --git a/website/i18n/en/docusaurus-plugin-content-docs-ai-coding/current/iso42001.md b/website/i18n/en/docusaurus-plugin-content-docs-ai-coding/current/iso42001.md index 4c6eadf..45958e9 100644 --- a/website/i18n/en/docusaurus-plugin-content-docs-ai-coding/current/iso42001.md +++ b/website/i18n/en/docusaurus-plugin-content-docs-ai-coding/current/iso42001.md @@ -24,7 +24,7 @@ AI system │ (PyTorch, TensorFlow, Hugging Face Transformers, LangChain etc.) │ → Apply existing ISO 5230 process as-is │ - ├── 2. Pre-trained models (Pre-trained Model) + ├── 2. Pre-trained models │ (Llama, Mistral, Falcon, BERT etc.) │ → Custom licenses must be checked per model │ @@ -50,7 +50,7 @@ Scan AI code repositories with existing SBOM generation tools (such as syft, cdx --- -## 2. Pre-trained Models (Pre-trained Model) +## 2. Pre-trained Models Unlike common open source libraries, pre-trained models often use **custom licenses**. Be careful, because they may include commercial-use restrictions, MAU-based conditions, and derivative model disclosure obligations. diff --git a/website/i18n/en/docusaurus-plugin-content-docs-ai-coding/current/tools/windsurf.md b/website/i18n/en/docusaurus-plugin-content-docs-ai-coding/current/tools/windsurf.md index 2a21bc2..88e56a9 100644 --- a/website/i18n/en/docusaurus-plugin-content-docs-ai-coding/current/tools/windsurf.md +++ b/website/i18n/en/docusaurus-plugin-content-docs-ai-coding/current/tools/windsurf.md @@ -64,5 +64,5 @@ When adding new external packages/libraries, always verify and document the lice ## Notes :::info Good to know -`.windsurfrules` is only for the Cascade agent and does not apply to standard code completion (Autocomplete). Keep in mind that policy applies only to agent actions (file creation/modification, package additions, etc.), and extra caution is needed when using plain completion. Larger files can increase response latency, so keep only essential team policies concise from the full template. +`.windsurfrules` is only for the Cascade agent and does not apply to standard code completion (Autocomplete). Keep in mind that policy applies only to agent actions (file creation/modification, package additions, etc.), and extra caution is needed when using plain completion. Larger files can increase response latency, so trim the full template down to only the essential team policies. ::: diff --git a/website/i18n/en/docusaurus-plugin-content-docs-devsecops/current/container-security.md b/website/i18n/en/docusaurus-plugin-content-docs-devsecops/current/container-security.md index a7b33eb..477e6a4 100644 --- a/website/i18n/en/docusaurus-plugin-content-docs-devsecops/current/container-security.md +++ b/website/i18n/en/docusaurus-plugin-content-docs-devsecops/current/container-security.md @@ -9,23 +9,23 @@ sidebar_position: 6 ## What is container security? -This is a security check that detects vulnerabilities in OS package and application dependencies included in container images, Dockerfile configuration errors, and secret exposure before deployment. Blocking the build phase is especially important because once the image is deployed, the same vulnerability will spread across all instances. +Container security scanning detects vulnerabilities in the OS packages and application dependencies bundled into a container image, along with Dockerfile misconfigurations and exposed secrets, before deployment. Blocking these at the build stage is especially important because once an image is deployed, the same vulnerability propagates to every instance. --- ## Tool Comparison -| tools | Features | Detection range | License | -| ------ | ---------------------------------- | --------------------------- | ---------- | -| Trivy | All-in-one·Fast speed·Simple setup | Image·Filesystem·IaC·Secret | Apache-2.0 | -| Grype | SBOM integration optimization | Image/File System | Apache-2.0 | -| Dockle | Checking Dockerfile best practices | Image Settings | Apache-2.0 | +| Tool | Features | Detection range | License | +| ------ | -------------------------------- | --------------------------- | ---------- | +| Trivy | All-in-one, fast, simple setup | Image·Filesystem·IaC·Secret | Apache-2.0 | +| Grype | Optimized for SBOM integration | Image/Filesystem | Apache-2.0 | +| Dockle | Checks Dockerfile best practices | Image configuration | Apache-2.0 | -We recommend Trivy as a single container security tool, and if you are already using grype in your SCA pipeline, image scanning can also be unified with grype. +We recommend Trivy as a single container security tool. If you already use Grype in your SCA pipeline, you can unify image scanning on Grype as well. --- -## Trivy settings +## Trivy setup ### Basic usage @@ -130,8 +130,8 @@ container-security: ## Trivy policy file -Exclude unfixable vulnerabilities with :::info ignore-unfixed option -Vulnerabilities that are not yet patched upstream cannot be fixed by the development team, so excluding them allows us to focus on actionable notifications. +:::info Exclude unfixable vulnerabilities with the ignore-unfixed option +Vulnerabilities not yet patched upstream cannot be fixed by the development team, so excluding them lets you focus on actionable findings. ::: ```yaml @@ -153,11 +153,11 @@ secrets: ## Dockerfile security best practices -1. **Use minimal base image:** Select `alpine`·`distroless` instead of `ubuntu`. Fewer packages reduce your vulnerability surface area. -2. **Prohibit root execution:** Specify a non-root user with the `USER` command. Root execution magnifies the damage when a container escapes. -3. **Multi-stage build:** Exclude build tools and source code from the final image. Image size reduction and attack surface reduction are achieved simultaneously. -4. **No secret ARG/ENV:** Do not pass secrets as build arguments or environment variables. It remains as plain text in the image layer. -5. **Version Fixed:** Specify tags like `FROM ubuntu:22.04`. When using `latest`, unexpected vulnerabilities may be introduced. +1. **Use a minimal base image:** Choose `alpine` or `distroless` over `ubuntu`. Fewer packages mean a smaller vulnerability surface. +2. **Avoid running as root:** Specify a non-root user with the `USER` instruction. Running as root amplifies the damage if a container is compromised. +3. **Multi-stage builds:** Keep build tools and source code out of the final image. This reduces both image size and attack surface at once. +4. **No secrets in ARG/ENV:** Never pass secrets as build arguments or environment variables. They persist as plain text in the image layers. +5. **Pin versions:** Use explicit tags like `FROM ubuntu:22.04`. Using `latest` can silently introduce unexpected vulnerabilities. --- @@ -165,4 +165,4 @@ secrets: - Infrastructure code security: [IaC security](./iac-security) - Full pipeline integration: [Pipeline Design](./pipeline-design) -- Continuous monitoring of images after distribution: [Monitoring·Automatic Correction](./monitoring) +- Continuous monitoring of images after deployment: [Monitoring and Automated Remediation](./monitoring) diff --git a/website/i18n/en/docusaurus-plugin-content-docs-devsecops/current/dast.md b/website/i18n/en/docusaurus-plugin-content-docs-devsecops/current/dast.md index 80e1e3c..eb70364 100644 --- a/website/i18n/en/docusaurus-plugin-content-docs-devsecops/current/dast.md +++ b/website/i18n/en/docusaurus-plugin-content-docs-devsecops/current/dast.md @@ -13,24 +13,24 @@ sidebar_position: 8 SAST looks at the code and DAST looks at the running app. The two must be applied together to reduce blind spots. ::: -**Definition:** Sends actual HTTP requests to a running application to detect runtime vulnerabilities such as SQL injection, XSS, authentication bypass, and sensitive information disclosure. +**Definition:** DAST sends real HTTP requests to a running application to detect runtime vulnerabilities such as SQL injection, XSS, authentication bypass, and sensitive information disclosure. -**Differences from SAST:** SAST detects quickly during the code writing phase but cannot determine runtime behavior. DAST verifies actual behavior after deployment, helping you discover vulnerabilities that SAST misses. +**How it differs from SAST:** SAST scans quickly during the coding phase but cannot observe runtime behavior. DAST verifies actual behavior after deployment, helping you find vulnerabilities that SAST misses. --- ## Tool Comparison -| tools | Features | Main uses | License | -| --------- | ---------------------------------------------------- | ------------------------------------- | ---------- | -| OWASP ZAP | Supports all industry standards, GUI, and automation | Full scan of web app/API | Apache-2.0 | -| Nuclei | Template-based, fast, lightweight | Scan for known vulnerability patterns | MIT | +| Tool | Features | Main uses | License | +| --------- | --------------------------------------------- | ----------------------------------------- | ---------- | +| OWASP ZAP | Industry-standard, GUI and automation support | Full scan of web apps/APIs | Apache-2.0 | +| Nuclei | Template-based, fast, lightweight | Scanning for known vulnerability patterns | MIT | -We recommend OWASP ZAP for deep web app scanning, and Nuclei for quick checks for known CVE·unconfigured vulnerabilities. +We recommend OWASP ZAP for in-depth web application scanning, and Nuclei for quick checks of known CVEs and misconfigurations. --- -## OWASP ZAP settings +## OWASP ZAP setup ### GitHub Actions @@ -81,17 +81,17 @@ jobs: ### Select scan type -| Scan Type | Action | Time required | Recommended Situation | -| --------- | ---------------- | ------------- | ------------------------------------- | -| Baseline | action-baseline | 2~5 minutes | Basic inspection per PR | -| API Scan | action-api-scan | 5~15 minutes | OpenAPI When there is a specification | -| Full Scan | action-full-scan | 20 minutes+ | In-depth pre-release inspection | +| Scan Type | Action | Time required | Recommended situation | +| --------- | ---------------- | ------------- | ------------------------------------ | +| Baseline | action-baseline | 2~5 minutes | Basic check per PR | +| API Scan | action-api-scan | 5~15 minutes | When an OpenAPI specification exists | +| Full Scan | action-full-scan | 20 minutes+ | In-depth pre-release check | -We recommend a dual strategy of running Baseline during the PR phase and Full Scan before release. +We recommend a two-tier strategy: run Baseline during the PR phase and Full Scan before release. -### Rules file settings +### Rules file configuration -Rules to ignore or fail specific notifications are managed in the `zap-rules.tsv` file. +Rules that ignore or fail specific alerts are managed in the `zap-rules.tsv` file. ``` # zap-rules.tsv @@ -100,11 +100,11 @@ Rules to ignore or fail specific notifications are managed in the `zap-rules.tsv 10021 FAIL (Anti-CSRF token not set) ``` -You can specify processing for each item at three levels: `IGNORE`·`WARN`·`FAIL`. +You can set the handling for each item at three levels: `IGNORE`·`WARN`·`FAIL`. --- -## Nuclei settings +## Nuclei setup ### GitHub Actions @@ -149,27 +149,27 @@ jobs: | Category | Description | | ---------------- | ----------------------------------- | | cves | Known CVE vulnerability patterns | -| misconfiguration | Security settings error | +| misconfiguration | Security misconfigurations | | exposures | Sensitive information/file exposure | -| default-logins | Default account/password | -| takeovers | Possibility of subdomain hijacking | +| default-logins | Default accounts/passwords | +| takeovers | Potential subdomain takeover | --- -## Precautions when introducing DAST +## Precautions when adopting DAST -:::warning Be sure to run DAST in an isolated test environment. +:::warning Always run DAST in an isolated test environment. ::: -**Environment Separation:** Because DAST sends actual HTTP requests, running it in a production environment may cause data corruption and service disruption. Be sure to run it only in a staging/testing environment. +**Environment separation:** Because DAST sends real HTTP requests, running it against production can corrupt data and disrupt service. Always run it only in a staging or test environment. -**Authentication Settings:** Endpoints that require authentication must pass a token through ZAP's authentication settings or Nuclei's header option to ensure coverage. +**Authentication setup:** For endpoints that require authentication, pass a token through ZAP's authentication settings or Nuclei's header option to ensure full coverage. -**False positive management:** DAST has a higher false positive rate than SAST. We recommend a phased approach, starting with `WARN` and switching to `FAIL` after reviewing the results. +**False positive management:** DAST has a higher false positive rate than SAST. We recommend a phased approach: start with `WARN` and switch to `FAIL` after reviewing the results. --- ## Next steps - Full security pipeline integration: [Pipeline Design](./pipeline-design) -- Continuous security monitoring after deployment: [Monitoring·Automatic Correction](./monitoring) +- Continuous security monitoring after deployment: [Monitoring and Automated Remediation](./monitoring) diff --git a/website/i18n/en/docusaurus-plugin-content-docs-devsecops/current/intro.md b/website/i18n/en/docusaurus-plugin-content-docs-devsecops/current/intro.md index 4c22ece..4ab21ed 100644 --- a/website/i18n/en/docusaurus-plugin-content-docs-devsecops/current/intro.md +++ b/website/i18n/en/docusaurus-plugin-content-docs-devsecops/current/intro.md @@ -6,52 +6,62 @@ slug: intro # DevSecOps +:::note Optional stage — if you have a development team +This section is an optional stage that **automatically applies the policies built in [Governance](/docs) to your code and CI pipeline**. +If self-certification against the standards is your goal, finish the governance setup first. If you have a development team, this is where you enforce those policies in day-to-day development. +::: + ## What this guide covers -AI Covers how to enforce at the pipeline level that code produced by coding tools does not violate your organization's open source policies. This is a practical guide to building a company-wide DevSecOps system, including SBOM creation, vulnerability management, license governance, and continuous monitoring. It also explains how to link with the ISO/IEC 5230 (license compliance) and ISO/IEC 18974 (security assurance) standard requirements. +Covers how to enforce, at the pipeline level, that code generated by AI coding tools does not violate your organization's open source policies. This is a practical guide to building a company-wide DevSecOps system that spans SBOM generation, vulnerability management, license governance, and continuous monitoring. It also explains how to align with the requirements of the ISO/IEC 5230 (license compliance) and ISO/IEC 18974 (security assurance) standards. --- -## AI Relationship to coding guide +## Relationship to the AI Coding guide -:::info If you applied Quick CI/CD first, learn more here -The Quick CI/CD of the AI Coding Guide aims to help developers create a basic gate in 30 minutes. This DevSecOps guide covers enterprise policy design, multi-repository management, and audit response. The two guides can be used independently, but we recommend reading them in the following order: [AI Coding — 4-Step Strategy](/ai-coding/strategy) → [Quick CI/CD](/ai-coding/cicd-quick) → DevSecOps. +:::info If you applied Quick CI/CD first, go deeper here +The Quick CI/CD of the AI Coding guide aims to help developers create a basic gate in 30 minutes. This DevSecOps guide builds on that to cover company-wide policy design, multi-repository management, and audit response. The two guides can be used independently, but we recommend reading them in the following order: [AI Coding — 4-Step Strategy](/ai-coding/strategy) → [Quick CI/CD](/ai-coding/cicd-quick) → DevSecOps. ::: --- ## Structure of this menu -| Page | Contents covered | Recommended Readers | -| ----------------------------------------------- | ----------------------------------------------------- | -------------------- | -| [Introduction Strategy](./strategy) | Maturity model/step-by-step roadmap | Team Lead/Architect | -| [SAST](./sast) | Static analysis — CodeQL·Semgrep | Developer·DevOps | -| [SCA](./sca) | Dependency Analysis — syft·grype·SBOM | DevOps·Security Team | -| [Secret Detection](./secret-detection) | Prevent key/token leakage — Gitleaks | Developer·DevOps | -| [Container Security](./container-security) | Image vulnerability — Trivy | DevOps·Security Team | -| [IaC Security](./iac-security) | Infrastructure Code Inspection — Checkov | DevOps·SRE | -| [DAST](./dast) | Dynamic Analysis — OWASP ZAP·Nuclei | Security Team·QA | -| [Pipeline Design](./pipeline-design) | Full Integrated Design·GitHub Actions | DevOps Engineer | -| [Monitoring·Automatic Correction](./monitoring) | Continuous scanning and automatic PR after deployment | DevOps·Security Team | -| [ISO standard linkage](./iso-mapping) | ISO/IEC 18974 Requirements Mapping | Compliance Manager | +| Page | Contents covered | Recommended Readers | +| --------------------------------------------- | --------------------------------------------------- | ---------------------- | +| [Introduction Strategy](./strategy) | Maturity model · step-by-step roadmap | Team Lead · Architect | +| [SAST](./sast) | Static analysis — CodeQL · Semgrep | Developer · DevOps | +| [SCA](./sca) | Dependency analysis — syft · grype · SBOM | DevOps · Security Team | +| [Secret Detection](./secret-detection) | Prevent key/token leakage — Gitleaks | Developer · DevOps | +| [Container Security](./container-security) | Image vulnerabilities — Trivy | DevOps · Security Team | +| [IaC Security](./iac-security) | Infrastructure-as-code inspection — Checkov | DevOps · SRE | +| [DAST](./dast) | Dynamic analysis — OWASP ZAP · Nuclei | Security Team · QA | +| [Pipeline Design](./pipeline-design) | Full integrated design · GitHub Actions | DevOps Engineer | +| [Monitoring · Auto-Remediation](./monitoring) | Continuous post-deployment scanning · automatic PRs | DevOps · Security Team | +| [ISO Standard Mapping](./iso-mapping) | ISO/IEC 18974 requirements mapping | Compliance Manager | --- ## Where to start? -:::tip Starting point for each role +:::tip Starting point by role -- DevSecOps is the first - → From [Introduction Strategy](./strategy) -- I want to catch code quality and security vulnerabilities at the code stage. - → From [SAST](./sast) -- I am concerned about open source dependency vulnerabilities. - → From [SCA](./sca) -- API Key/Token has been exposed to code - → From [Secret Detection](./secret-detection) +- New to DevSecOps + → Start with [Introduction Strategy](./strategy) +- Want to catch code quality and security vulnerabilities at the code stage + → Start with [SAST](./sast) +- Concerned about open source dependency vulnerabilities + → Start with [SCA](./sca) +- An API key or token has been exposed in code + → Start with [Secret Detection](./secret-detection) - Running a container environment - → From [Container Security](./container-security) -- ISO/IEC 18974 Preparing for certification - → From [ISO standard linkage](./iso-mapping) - (However, we recommend reading the SCA page first) + → Start with [Container Security](./container-security) +- Preparing for ISO/IEC 18974 certification + → Start with [ISO Standard Mapping](./iso-mapping) + (we recommend reading the SCA page first) ::: + +## See also + +- To build a standards-based management system from the ground up, see the [Open Source Management Guide](/docs). +- To apply policies to AI coding tools (Cursor, Copilot, Claude Code, etc.), see [AI Coding Governance](/ai-coding/intro). diff --git a/website/i18n/en/docusaurus-plugin-content-docs-devsecops/current/iso-mapping.md b/website/i18n/en/docusaurus-plugin-content-docs-devsecops/current/iso-mapping.md index 269b6e6..07e0b14 100644 --- a/website/i18n/en/docusaurus-plugin-content-docs-devsecops/current/iso-mapping.md +++ b/website/i18n/en/docusaurus-plugin-content-docs-devsecops/current/iso-mapping.md @@ -5,87 +5,85 @@ sidebar_label: 'ISO/IEC 18974 Linkage' sidebar_position: 11 --- -# ISO/IEC 5230 · 18974 Linkage +# ISO/IEC 18974 Linkage (DevSecOps Implementation) This page focuses on **ISO/IEC 18974 (Open Source Security Assurance)**. -You can check which of the standard requirements your implementation meets in this DevSecOps guide. +It shows which of the standard's requirements the implementation in this DevSecOps guide satisfies. The license compliance standard ISO/IEC 5230 is outside the scope of this guide. ## What is ISO/IEC 18974? :::info ISO/IEC 18974 is an international standard for open source security assurance -Hosted by OpenChain Project -Through self-certification -Anyone can authenticate for free. +Hosted by the OpenChain Project, it lets anyone self-certify for free. ::: -**Purpose**: Define the minimum core requirements to identify, track, and respond to known security vulnerabilities (CVE, etc.) in open source software. We focus on minimum standards so organizations of all sizes can adopt without burden. +**Purpose**: To define the minimum core requirements for identifying, tracking, and responding to known security vulnerabilities (such as CVEs) in open source software. It focuses on a minimal baseline so that organizations of any size can adopt it without undue burden. -**Organization**: Consists of four sections: Program establishment, definition of related tasks, compliance assurance, and data provision. Each requirement is numbered in the format 4.x.x. +**Structure**: Consists of four sections — program establishment, definition of related tasks, compliance assurance, and data provision. Each requirement is numbered in the format 4.x.x. -**Authentication Method**: Complete and submit a self-certification checklist on the OpenChain official site. Since the organization declares itself without external audit, the procedure is simple and there is no cost. +**Certification method**: Complete and submit a self-certification checklist on the official OpenChain site. Because the organization declares conformance itself without an external audit, the process is simple and free. --- -## DevSecOps Implementation and requirements mapping +## Mapping the DevSecOps implementation to requirements -The table below shows how the DevSecOps pipeline implemented in this guide meets the key requirements of ISO/IEC 18974. +The table below shows how the DevSecOps pipeline built in this guide meets the key requirements of ISO/IEC 18974. -| Requirement Number | Requirements (Summary) | Implementation method | Related Pages | -| ------------------ | ------------------------------------- | --------------------------------------------------------------- | ------------------------------------ | -| 4.1.1 | Documenting Security Assurance Policy | DevSecOps Strategy/SLA Policy Document | [Introduction Strategy](./strategy) | -| 4.1.2 | Policy awareness and education | Guidance and documentation of pipeline failures within the team | [Pipeline Design](./pipeline-design) | -| 4.2.1 | Open source component identification | syft SBOM auto-generated | [SCA](./sca) | -| 4.2.2 | Check for known vulnerabilities | grype CVE Scan/PR blocking | [SCA](./sca) | -| 4.2.3 | vulnerability Response Procedure | SLA definition/exception handling process | [SCA](./sca) | -| 4.3.1 | Compliance assurance activities | Regular Scan·SBOM Artifact Storage | [Monitoring](./monitoring) | -| 4.3.2 | Data Preservation | SBOM Permanent storage by release | [Monitoring](./monitoring) | -| 4.4.1 | External Inquiry Response Procedure | vulnerability Response SLA·VEX Document | [SCA](./sca) | +| Requirement | Requirement (summary) | Implementation | Related pages | +| ----------- | -------------------------------------- | ---------------------------------------------------- | ------------------------------------ | +| 4.1.1 | Document the security assurance policy | DevSecOps strategy / SLA policy document | [Introduction Strategy](./strategy) | +| 4.1.2 | Policy awareness and training | Team guidance and documentation of pipeline failures | [Pipeline Design](./pipeline-design) | +| 4.2.1 | Identify open source components | Auto-generated syft SBOM | [SCA](./sca) | +| 4.2.2 | Check for known vulnerabilities | grype CVE scan / PR blocking | [SCA](./sca) | +| 4.2.3 | Vulnerability response procedure | SLA definition / exception-handling process | [SCA](./sca) | +| 4.3.1 | Compliance assurance activities | Scheduled scans · SBOM artifact storage | [Monitoring](./monitoring) | +| 4.3.2 | Data preservation | Permanent SBOM storage by release | [Monitoring](./monitoring) | +| 4.4.1 | External inquiry response procedure | Vulnerability response SLA · VEX document | [SCA](./sca) | --- ## Self-certification preparation checklist -:::tip Prepare a trace file that satisfies each item in advance -OpenChain Self-certification is a declaration method, but -You must be able to provide evidence when an audit is requested. +:::tip Prepare evidence files for each item in advance +OpenChain self-certification is declaration-based, but +you must be able to provide evidence if an audit is requested. ::: -1. **Security Policy Document** +1. **Security policy documents** -- DevSecOps Introduction Strategy Document (based on strategy.md) +- DevSecOps introduction strategy document (based on strategy.md) - SLA definition document by vulnerability severity -- Exception handling approval process document +- Exception-handling approval process document -2. **SBOM Accumulation** +2. **SBOM accumulation** -- SBOM files automatically generated from CI/CD (kept by release version) -- SBOM Creation tool/format/cycle specification document +- SBOM files automatically generated by CI/CD (retained by release version) +- SBOM generation tool / format / cadence specification document -3. **vulnerability management evidence** +3. **Vulnerability management evidence** - grype scan result artifacts -- Exception handled CVE list and approval records (including .grype.yaml comments) -- vulnerability discovery → Modification history (GitHub Issues·PR) +- List of CVEs handled via exception and their approval records (including .grype.yaml comments) +- Vulnerability discovery → remediation history (GitHub Issues·PRs) 4. **Continuous monitoring evidence** -- Regular scan workflow execution log +- Scheduled scan workflow execution logs - Dependabot·Renovate PR history -- New CVE Notification → Response Timeline +- New CVE alert → response timeline --- ## Certification registration process -1. **Self-Assessment**: Self-assess ISO/IEC 18974 items from the OpenChain official checklist and ensure that all requirements are met. -2. **Declaration**: After confirming that all requirements are met, declare that OpenChain has an eligible program. It is also recommended that this be stated in organizational policy documents. -3. **Registration**: Register the organization name in OpenChain Community of Conformance. Although optional, it helps improve supply chain reliability. +1. **Self-assessment**: Self-assess the ISO/IEC 18974 items against the official OpenChain checklist and confirm that all requirements are met. +2. **Declaration**: Once you have confirmed that all requirements are met, declare that your organization has a conforming program. Stating this in organizational policy documents is also recommended. +3. **Registration**: Register your organization in the OpenChain Community of Conformance. This is optional but helps improve supply chain trust. --- ## Limitations and precautions -**DevSecOps Scope**: This guide's implementation of DevSecOps focuses on the open source security assurances of ISO/IEC 18974. Additional areas such as SAST, DAST, and IaC security are security enhancement activities that go beyond standard requirements and are optional improvements beyond the scope of certification. +**DevSecOps scope**: The DevSecOps implementation in this guide focuses on the open source security assurance of ISO/IEC 18974. Additional areas such as SAST, DAST, and IaC security are security-hardening activities that go beyond the standard's requirements; they are optional improvements outside the scope of certification. -**ISO/IEC 5230 Separate preparation required**: The license compliance standard, ISO/IEC 5230, is outside the scope of this guide. Please refer to Trusted OSS’s Enterprise Open Source Governance Guide. +**ISO/IEC 5230 requires separate preparation**: The license compliance standard ISO/IEC 5230 is outside the scope of this guide. Please refer to Trusted OSS's Enterprise Open Source Governance Guide. diff --git a/website/i18n/en/docusaurus-plugin-content-docs-devsecops/current/monitoring.md b/website/i18n/en/docusaurus-plugin-content-docs-devsecops/current/monitoring.md index 3253c15..86e43c6 100644 --- a/website/i18n/en/docusaurus-plugin-content-docs-devsecops/current/monitoring.md +++ b/website/i18n/en/docusaurus-plugin-content-docs-devsecops/current/monitoring.md @@ -1,35 +1,35 @@ --- id: monitoring -title: Continuous monitoring and automatic correction -sidebar_label: Monitoring and automatic correction +title: Continuous Monitoring and Automated Remediation +sidebar_label: Monitoring and Automated Remediation sidebar_position: 10 --- -# Continuous monitoring and automatic correction +# Continuous monitoring and automated remediation -The CI/CD gate checks the code state at the time of deployment, but cannot respond to new vulnerabilities that occur after deployment. -Dependabot·Renovate·The combination of regular scans allows you to continuously detect vulnerabilities in your production environment and automatically generate patch PRs. +A CI/CD gate checks the state of the code at deployment time but cannot respond to new vulnerabilities that emerge afterward. +Combining Dependabot·Renovate with scheduled scans lets you continuously detect vulnerabilities in production and automatically generate patch PRs. ## Why post-deployment monitoring is necessary -:::info The CI/CD gate only checks snapshots at the time of deployment -The new CVE discovered after distribution is -The pipeline cannot detect it. +:::info A CI/CD gate only checks a snapshot taken at deployment time +The pipeline cannot detect a new CVE +discovered after deployment. ::: -**Characteristics of the new CVE**: Code deployed today may be vulnerable to the new CVE tomorrow. A representative example is Log4Shell, where a library that has been used for years becomes a Critical vulnerability overnight. Scan results at the time of distribution lose meaning over time. +**Nature of new CVEs**: Code deployed today may become vulnerable to a new CVE tomorrow. Log4Shell is a classic example, where a library used for years turned into a Critical vulnerability overnight. Scan results taken at deployment time lose their meaning over time. -**Limitations of a pipeline without monitoring**: Even code that passes the PR stage may have vulnerabilities after 30 days. Without continuous scanning, your service will operate without awareness of risks in your production environment. +**Limits of a pipeline without monitoring**: Even code that passed the PR stage may have vulnerabilities 30 days later. Without continuous scanning, your service runs unaware of the risks in production. -**Need for automation**: Manually tracking hundreds of dependencies is not realistically possible. The key is to minimize human intervention and speed up patching with automated tools like Dependabot·Renovate. +**Need for automation**: Manually tracking hundreds of dependencies is not realistic. The key is to minimize human intervention and accelerate patching with automated tools like Dependabot·Renovate. --- -## Dependabot settings +## Dependabot setup -###Default settings +### Basic configuration -Adding `.github/dependabot.yml` to the GitHub repository automatically creates a dependency update/security patch PR. +Adding `.github/dependabot.yml` to a GitHub repository automatically opens dependency-update and security-patch PRs. ```yaml # .github/dependabot.yml @@ -74,17 +74,17 @@ updates: interval: weekly ``` -### Automatically enable security notifications +### Enable security alerts -Dependabot Security Alerts on GitHub work automatically when you enable them in your repository settings. -Without separate settings, a PR is immediately created when a Critical or High vulnerability is discovered based on the GitHub Advisory Database. +Dependabot security alerts on GitHub work automatically once you enable them in your repository settings. +With no further configuration, a PR is opened immediately when a Critical or High vulnerability is found based on the GitHub Advisory Database. --- -## Renovate settings +## Renovate setup -Renovate allows more detailed policy settings than Dependabot, and supports all GitHub·GitLab·Bitbucket. -The same can be used in GitLab in a self-hosted manner. +Renovate allows finer-grained policy configuration than Dependabot and supports GitHub·GitLab·Bitbucket alike. +It can also be run self-hosted on GitLab. ```json // renovate.json @@ -117,17 +117,17 @@ The same can be used in GitLab in a self-hosted manner. | Item | Dependabot | Renovate | | ---------------- | ----------- | --------------------------------- | -| platform | GitHub only | GitHub·GitLab·Bitbucket | -| Setup complexity | low | High (high flexibility) | -| Auto Merge | LIMITED | Detailed policy settings possible | -| Group PR | possible | Possible (more detailed) | -| cost | Free | Free (self-hosted) | +| Platform | GitHub only | GitHub·GitLab·Bitbucket | +| Setup complexity | Low | High (very flexible) | +| Auto-merge | Limited | Configurable with detailed policy | +| Grouped PRs | Supported | Supported (more granular) | +| Cost | Free | Free (self-hosted) | --- -## Automate regular scans +## Automate scheduled scans -In addition to the PR phase, we separately operate a scheduled workflow that periodically scans distributed code. +Beyond the PR phase, run a separate scheduled workflow that periodically scans deployed code. ```yaml # .github/workflows/scheduled-scan.yml @@ -181,30 +181,30 @@ jobs: ## Notification and response system -:::tip Notifications must be delivered to the person in charge immediately +:::tip Alerts must reach the responsible owner immediately ::: -**GitHub Utilize the Security tab**: Dependabot·Code scan results are automatically aggregated to the repository Security tab. When a critical finding is made, response time can be greatly shortened by linking email and Slack notifications to the person in charge. +**Use the GitHub Security tab**: Dependabot and code-scan results are automatically aggregated in the repository's Security tab. For critical findings, wiring email and Slack notifications to the owner can greatly shorten response time. -**Automatically create issues**: When a new vulnerability is discovered in a schedule scan, an issue is automatically created with GitHub Actions to enable assigning a person in charge and tracking SLA. Once vulnerabilities are managed as issues, patch progress can be shared with the entire team. +**Create issues automatically**: When a scheduled scan finds a new vulnerability, automatically open an issue via GitHub Actions so you can assign an owner and track the SLA. Once vulnerabilities are managed as issues, patch progress can be shared across the whole team. -**SBOM Archive by Year**: Permanently archive SBOM generated from regular scans by release version. ISO/IEC 18974 Can be used as an audit response trace, and is also useful for reproducing the dependency status at a specific point in time. +**Archive SBOMs by year**: Permanently archive the SBOMs produced by scheduled scans, organized by release version. These serve as an audit-response trail for ISO/IEC 18974 and are also useful for reproducing the dependency state at a specific point in time. --- ## Self-Study — Level 2 Automation -:::tip Create automation workflow with Claude Code +:::tip Build automation workflows with Claude Code The agents below work in conjunction with the CI/CD pipeline. -Create workflow files to fully automate security analysis. +They generate workflow files that fully automate security analysis. ::: -**Prerequisite**: Requires clone of [Trusted OSS repository](https://github.com/trustedoss/trustedoss.github.io) +**Prerequisite**: Clone the [Trusted OSS repository](https://github.com/trustedoss/trustedoss.github.io) -### PR Security Analysis Automatic Comments +### Automated PR security-analysis comments -Every time a PR is created, Claude analyzes the security scan results and -Automatically post comments to PR. +Each time a PR is opened, Claude analyzes the security scan results and +automatically posts a comment on the PR. ```bash cd agents/level2-automation/pr-comment @@ -216,10 +216,10 @@ Generated output: - `.github/workflows/pr-security-comment.yml` (GitHub Actions) - `gitlab-pr-comment.yml` (GitLab CI conversion version) -### Automatic issue registration + Dependabot analysis +### Automatic issue creation + Dependabot analysis -Automatically creates issues when High/Critical vulnerabilities are found in regular scans -Dependabot Automatically publish impact analysis comments to PR. +Automatically opens issues when scheduled scans find High/Critical vulnerabilities, +and automatically posts impact-analysis comments on Dependabot PRs. ```bash cd agents/level2-automation/issue-tracker @@ -233,13 +233,13 @@ Generated output: - `gitlab-scheduled-scan.yml` (GitLab CI conversion version) :::info GitHub Actions vs GitLab CI -GitHub Actions provides YAML that has been verified to actually work. -GitLab CI contains conversion patterns and annotations for the same function. -Both platforms require ANTHROPIC_API_KEY to be registered as Secret/Variable. +GitHub Actions provides YAML verified to actually work. +GitLab CI provides conversion patterns and annotations for the same functionality. +Both platforms require ANTHROPIC_API_KEY to be registered as a Secret/Variable. ::: --- ## Next steps -- ISO/IEC 18974 Requirements and implementation mapping: [ISO standard linkage](./iso-mapping) +- Mapping ISO/IEC 18974 requirements to implementation: [ISO Standard Linkage](./iso-mapping) diff --git a/website/i18n/en/docusaurus-plugin-content-docs-devsecops/current/pipeline-design.md b/website/i18n/en/docusaurus-plugin-content-docs-devsecops/current/pipeline-design.md index 4db064b..46a23dd 100644 --- a/website/i18n/en/docusaurus-plugin-content-docs-devsecops/current/pipeline-design.md +++ b/website/i18n/en/docusaurus-plugin-content-docs-devsecops/current/pipeline-design.md @@ -1,30 +1,30 @@ --- id: pipeline-design -title: Transcription Pipeline Design -sidebar_label: pipeline design +title: Enterprise-wide Pipeline Design +sidebar_label: Pipeline Design sidebar_position: 9 --- -# Transcription pipeline design +# Enterprise-wide pipeline design -We guide you through a design method that integrates the six areas of SAST, SCA, secret detection, container security, IaC security, and DAST into one pipeline. -We focus on how to combine the individual settings covered on each area page to suit your actual operating environment. +This page walks through how to integrate the six areas — SAST, SCA, secret detection, container security, IaC security, and DAST — into a single pipeline. +It focuses on how to combine the individual configurations covered on each area page to fit your actual operating environment. ## Pipeline design principles -**Parallel execution**: Independent tests run in parallel to minimize overall pipeline time. SAST, SCA, and Secret detection do not depend on each other, so they can run simultaneously. +**Parallel execution**: Run independent scans in parallel to minimize overall pipeline time. SAST, SCA, and secret detection have no dependencies on each other, so they can run simultaneously. -**Step-by-step gate**: Place fast tests (Secret/SAST) at the front and slow tests (DAST) at the back. If the previous step fails, the later step does not need to be executed, thus reducing unnecessary resource consumption. +**Staged gating**: Place fast scans (secret/SAST) at the front and slow scans (DAST) at the back. If an earlier stage fails, later stages don't need to run, which reduces wasted resources. -**Separation of failure policies**: Clear distinction between hard fail and warning only (soft fail). Starting at an acceptable level and gradually strengthening the team increases the success rate of actual adoption. +**Separate failure policies**: Clearly distinguish hard fail from warning-only (soft fail). Starting at a tolerable level and tightening gradually increases the success rate of real-world adoption. -**Result Retention**: All test results are kept as artifacts. It is important to maintain it for a certain period of time for audit response, trend analysis, and reproduction. +**Result retention**: Keep all scan results as artifacts. Retaining them for a defined period is important for audit response, trend analysis, and reproduction. --- -## Pipeline overall structure +## Overall pipeline structure -| steps | Inspection items | When to run | failure policy | Time required | +| Stage | Checks | When to run | Failure policy | Time required | | ----- | --------------------------- | ----------- | -------------- | ------------- | | 1 | Secret detection (Gitleaks) | PR | Hard Fail | ~1 minute | | 2 | SAST (Semgrep) | PR | Hard Fail | 2~5 minutes | @@ -33,11 +33,11 @@ We focus on how to combine the individual settings covered on each area page to | 3 | Container Security (Trivy) | Push/Merge | Hard Fail | 3~5 minutes | | 4 | DAST (ZAP Baseline) | Push/Merge | Soft Fail→Hard | 5-10 minutes | -Two-stage tests can be run in parallel to keep the overall time within 5 minutes. +The stage-2 scans can run in parallel to keep the overall time within 5 minutes. --- -## GitHub Actions Integrated Workflow +## GitHub Actions integrated workflow ### PR phase (parallel execution) @@ -104,7 +104,7 @@ jobs: soft_fail: false ``` -### Push/Merge stage (Container·DAST) +### Push/Merge stage (Container, DAST) ```yaml # .github/workflows/devsecops-merge.yml @@ -141,7 +141,7 @@ jobs: - uses: zaproxy/action-baseline@v0.12.0 with: target: http://localhost:8080 - fail_action: false # during initial adoption Soft Fail + fail_action: false # Soft Fail during initial adoption - uses: actions/upload-artifact@v4 if: always() with: @@ -231,34 +231,34 @@ dast: --- -## Multi-store policy consistency +## Cross-repository policy consistency -:::tip Centrally manage policies with reusable workflows +:::tip Manage policies centrally with reusable workflows ::: -**GitHub Actions Reusable Workflow**: Manage common workflows in a separate repository (e.g. `your-org/security-workflows`) and reference them as `uses: your-org/security-workflows/.github/workflows/devsecops-pr.yml@main` in each project. When a policy change is made in just one location, it is immediately reflected in the entire repository. +**GitHub Actions reusable workflows**: Keep common workflows in a dedicated repository (e.g. `your-org/security-workflows`) and reference them from each project as `uses: your-org/security-workflows/.github/workflows/devsecops-pr.yml@main`. A policy change made in one place is immediately reflected across every repository. -**GitLab CI Template**: References a CI template in the central repository with the `include:` keyword. Project-specific overrides can be handled with `extends:` to allow exceptions while maintaining the default policy. +**GitLab CI templates**: Reference a CI template in a central repository with the `include:` keyword. Project-specific overrides can be handled with `extends:`, allowing exceptions while keeping the default policy intact. -**Policy file synchronization**: Manage policy files such as `.grype.yaml`·`.gitleaks.toml`·`.trivyignore.yaml` in a separate repository and distribute them to each project using git submodule or file copy script. The version history of the policy file is preserved, which is advantageous for audit response. +**Policy file synchronization**: Keep policy files such as `.grype.yaml`·`.gitleaks.toml`·`.trivyignore.yaml` in a dedicated repository and distribute them to each project via git submodule or a file-copy script. Preserving the version history of policy files is advantageous for audit response. --- -## Developer guidance when build fails +## Developer guidance when a build fails -:::warning Build failure messages should allow developers to act immediately -All you have to do is report a “vulnerability found” and developers won’t know what to do. +:::warning Build failure messages should let developers act immediately +Simply reporting "vulnerability found" leaves developers unsure what to do. ::: -**Clear cause of failure**: Include in the message which CVE in which package and which line in which file. Failures with unclear causes lead to developer distrust and ignoring notifications. +**Clear cause of failure**: State which CVE, in which package, on which line of which file. Failures with unclear causes erode developer trust and lead to ignored alerts. -**How ​​to Fix**: If possible, include a specific action in your message, such as “Upgrade to this version.” grype automatically displays the fix version, providing guidance on fixing it without any additional work. +**How to fix**: Where possible, include a concrete action in the message, such as "upgrade to this version." Grype automatically shows the fixed version, providing remediation guidance with no extra effort. -**Exception handling path**: If immediate correction is not possible, instructions on how to apply for an exception (person in charge/document link) will be provided in the build failure message. The absence of exception paths leaves developers feeling helpless or attempting to bypass security checks. +**Exception path**: When an immediate fix isn't possible, the build failure message should include how to request an exception (owner and document link). Without an exception path, developers feel stuck or try to bypass the security checks. --- ## Next steps -- Continuous monitoring/automatic patching after deployment: [Monitoring/automatic correction](./monitoring) -- ISO/IEC 18974 Requirements Mapping: [ISO Standard Linkage](./iso-mapping) +- Continuous monitoring and automated patching after deployment: [Monitoring and Automated Remediation](./monitoring) +- ISO/IEC 18974 requirements mapping: [ISO Standard Linkage](./iso-mapping) diff --git a/website/i18n/en/docusaurus-plugin-content-docs-devsecops/current/sast.mdx b/website/i18n/en/docusaurus-plugin-content-docs-devsecops/current/sast.mdx index f12d72f..6510cf0 100644 --- a/website/i18n/en/docusaurus-plugin-content-docs-devsecops/current/sast.mdx +++ b/website/i18n/en/docusaurus-plugin-content-docs-devsecops/current/sast.mdx @@ -109,7 +109,7 @@ on: pull_request: branches: [main] schedule: - - cron: '0 2 * * 1' # 매주 월요일 2 AM full scan + - cron: '0 2 * * 1' # full scan every Monday at 2 AM jobs: codeql: diff --git a/website/i18n/en/docusaurus-plugin-content-docs-devsecops/current/strategy.md b/website/i18n/en/docusaurus-plugin-content-docs-devsecops/current/strategy.md index 7c5d264..bdf26d5 100644 --- a/website/i18n/en/docusaurus-plugin-content-docs-devsecops/current/strategy.md +++ b/website/i18n/en/docusaurus-plugin-content-docs-devsecops/current/strategy.md @@ -9,89 +9,89 @@ sidebar_position: 2 ## What is DevSecOps? -It is a culture and methodology that integrates development (Dev), security (Sec), and operations (Ops) to internalize security throughout the software development life cycle. The key is to block threats early with automated inspection from the time code is written, rather than “security comes later.” +A culture and methodology that integrates development (Dev), security (Sec), and operations (Ops) to build security into the entire software development lifecycle. The core idea is to block threats early with automated checks from the moment code is written, rather than treating security as something to handle later. --- ## Shift Left — Why faster is better -:::info The cost of fixing a vulnerability varies dozens of times depending on when it is discovered. +:::info The cost of fixing a vulnerability can vary by orders of magnitude depending on when it is discovered. ::: -As vulnerabilities are discovered at the code writing stage, the cost and time to fix them decreases exponentially. +The earlier a vulnerability is found in the code-writing stage, the more the cost and time to fix it drop exponentially. -| When discovered | relative cost of correction | Contact person | -| ----------------------------- | --------------------------- | ----------------------- | -| Writing code (IDE·pre-commit) | 1x | Developer himself | -| PR/Code Review (CI) | 10x | Developer/Reviewer | -| Staging·QA | 25x | QA/DevOps | -| After production deployment | 100x | All Teams/Security Team | +| When discovered | Relative fix cost | Responsible | +| ----------------------------- | ----------------- | ------------------------- | +| Writing code (IDE·pre-commit) | 1x | The developer | +| PR · code review (CI) | 10x | Developer · reviewer | +| Staging · QA | 25x | QA · DevOps | +| After production deployment | 100x | All teams · security team | -The goal of DevSecOps is to move as many checks to the left (code writing phase) as possible. +The goal of DevSecOps is to shift as many checks as possible to the left (the code-writing stage). --- ## Maturity Model — Stage 4 -| steps | level | Features | Main tools | -| ------ | --------------- | ------------------------------------------- | ----------------------- | -| Step 1 | None | Security check manual or absent | — | -| Step 2 | Basic | Key Areas CI Automation | Gitleaks, grype | -| Step 3 | Systematization | Full-area pipeline integration | Semgrep, Trivy, Checkov | -| Step 4 | Optimization | Automatic calibration/continuous monitoring | Dependabot + AI | +| Stage | Level | Characteristics | Main tools | +| ------- | ------------ | ---------------------------------------- | ----------------------- | +| Stage 1 | None | Security checks manual or absent | — | +| Stage 2 | Basic | CI automation in key areas | Gitleaks, grype | +| Stage 3 | Systematized | Pipeline integration across all areas | Semgrep, Trivy, Checkov | +| Stage 4 | Optimized | Auto-remediation · continuous monitoring | Dependabot + AI | -For most teams, it is realistic to start in Stage 2 and move to Stage 3 over 6 to 12 months. +For most teams, it is realistic to start at Stage 2 and move to Stage 3 over 6 to 12 months. --- ## Step-by-step introduction roadmap -:::tip Don’t try to introduce everything at once -Stabilizing one area at a time and then moving on to the next is a sustainable way to avoid team fatigue. +:::tip Don't try to adopt everything at once +Stabilizing one area at a time before moving to the next is the sustainable way to avoid team fatigue. ::: -1. **Start Immediately (1-2 Weeks)** - Secret detection (Gitleaks) + SCA is applied starting from basic (grype). The setup is simple and the effects are immediate. Blocks secret leaks and critical vulnerabilities in the existing code base. +1. **Start immediately (1-2 weeks)** + Begin with secret detection (Gitleaks) and basic SCA (grype). The setup is simple and the effect is immediate. This blocks secret leaks and critical vulnerabilities in the existing codebase. -2. **Improvement of code quality (1 month)** - Add SAST(Semgrep). Choose a ruleset that matches the language your team uses, and initially print only a warning, then switch to block builds after 2-4 weeks. +2. **Strengthen code quality (1 month)** + Add SAST (Semgrep). Choose a ruleset that matches the languages your team uses; initially emit warnings only, then switch to blocking builds after 2-4 weeks. -3. **Build/Infrastructure Security (2~3 months)** - Add container security (Trivy) + IaC security (Checkov). Applies to teams that use container/cloud environments. +3. **Build and infrastructure security (2-3 months)** + Add container security (Trivy) and IaC security (Checkov). This applies to teams that use container or cloud environments. -4. **Completion of dynamic analysis and automation (3-6 months)** - Add DAST(OWASP ZAP). After integrating all areas of the pipeline, a monitoring and automatic correction system is established. +4. **Complete dynamic analysis and automation (3-6 months)** + Add DAST (OWASP ZAP). After integrating all areas of the pipeline, establish a monitoring and auto-remediation system. --- ## Location in the pipeline -| area | pre-commit | PR/CI | build | After Deployment | +| Area | pre-commit | PR/CI | Build | After deployment | | ------------------ | ---------- | ----- | ----- | ---------------- | | Secret Detection | ✓ | ✓ | — | — | | SAST | — | ✓ | — | — | | SCA | — | ✓ | ✓ | ✓ | | Container Security | — | — | ✓ | ✓ | -| IaC security | — | ✓ | — | — | +| IaC Security | — | ✓ | — | — | | DAST | — | — | — | ✓ | --- ## Self-study — step-by-step agent -:::tip Automate each step with Claude Code agent -If you run the agents below in order, -You can actually implement steps 1-4 on the strategy page. +:::tip Automate each stage with a Claude Code agent +Run the agents below in order to actually implement +Stages 1-4 from the strategy page. ::: -**Prerequisite**: Requires clone of [Trusted OSS repository](https://github.com/trustedoss/trustedoss.github.io) +**Prerequisite**: Clone the [Trusted OSS repository](https://github.com/trustedoss/trustedoss-agents) -| steps | agent | command | -| --------------------------------- | -------------------- | ----------------------------------------------------- | -| Step 2 — Internalize the AI rules | ai-coding-setup | `cd agents/ai-coding-setup && claude` | -| Step 3 — CI/CD Pipeline | devsecops-setup | `cd agents/devsecops-setup && claude` | -| Step 3 — PR Auto Comment | level2-pr-comment | `cd agents/level2-automation/pr-comment && claude` | -| Step 4 — Continuous monitoring | level2-issue-tracker | `cd agents/level2-automation/issue-tracker && claude` | +| Stage | agent | Command | +| ---------------------------------- | -------------------- | ----------------------------------------------------- | +| Stage 2 — Internalize the AI rules | ai-coding-setup | `cd agents/ai-coding-setup && claude` | +| Stage 3 — CI/CD pipeline | devsecops-setup | `cd agents/devsecops-setup && claude` | +| Stage 3 — PR auto-comment | level2-pr-comment | `cd agents/level2-automation/pr-comment && claude` | +| Stage 4 — Continuous monitoring | level2-issue-tracker | `cd agents/level2-automation/issue-tracker && claude` | ---