docs(i18n): DevSecOps and AI coding English page quality pass

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
                                         ↓

website/i18n/en/docusaurus-plugin-content-docs-ai-coding/current/cicd-quick.mdx

@@ -18,11 +18,11 @@
 :::warning Hard Block is only possible in CI/CD
 :::
 
 AI rule files like `CLAUDE.md` or `.cursorrules` are ultimately just "recommendations." Even if developers intentionally ignore them or AI accidentally fails to follow them, nothing actually stops the result.
 
 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).
 
 ---
 

website/i18n/en/docusaurus-plugin-content-docs-ai-coding/current/iso42001.md

@@ -24,7 +24,7 @@
   │       (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
   │
@@ -37,7 +37,7 @@
 
 ## 1. AI Frameworks and Libraries
 
 Apply the ISO/IEC 5230 process just as you do for normal software dependencies.
 Scan AI code repositories with existing SBOM generation tools (such as syft, cdxgen, and FOSSLight).
 
 | Framework                 | License      | Commercial Use | Key Obligations                       |
@@ -50,7 +50,7 @@
 
 ---
 
-## 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.

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.
 :::

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,16 +153,16 @@ 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.
 
 ---
 
 ## Next steps
 
 - 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)

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)