[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"question-bezopasnost-konteynerov-chto-takoe-supply-chain-security-v-kontekste-konteynerov":3},{"id":4,"slug":5,"topicId":6,"topicSlug":7,"topicName":8,"topicEmoji":9,"question":10,"answer":11,"codeLang":12,"codeSrc":12,"important":12,"commonMistakes":12,"modernUsage":12,"difficulty":13,"tags":14,"related":21,"progress":22,"seo":23},321,"chto-takoe-supply-chain-security-v-kontekste-konteynerov",9,"bezopasnost-konteynerov","Безопасность контейнеров","🛡️","Что такое Supply Chain Security в контексте контейнеров?","\u003C!-- grade: -->\n\n**Supply Chain Security (безопасность цепочки поставок)** — обеспечение целостности и безопасности всех компонентов, участвующих в создании и доставке программного обеспечения: от исходного кода и зависимостей до финального контейнерного образа, развёрнутого в production.\n\nАтаки на цепочку поставок (SolarWinds, Log4Shell, codecov) продемонстрировали, что компрометация одного звена цепочки может затронуть тысячи организаций-потребителей. В контексте контейнеров цепочка поставок включает: базовый образ, пакеты операционной системы, зависимости приложения (Maven\u002FGradle), инструменты сборки, CI\u002FCD-платформу и реестр образов.\n\n**Основные компоненты Supply Chain Security:**\n\n**1. SBOM (Software Bill of Materials) — перечень всех компонентов:**\n\nSBOM — это машинно-читаемый документ, содержащий полный список компонентов программного обеспечения: пакеты ОС, Java-зависимости (Maven\u002FGradle), их точные версии, лицензии и криптографические хеши. Два основных формата: CycloneDX и SPDX.\n\n```bash\n# Генерация SBOM с помощью Trivy (формат CycloneDX)\ntrivy image --format cyclonedx \\\n    --output sbom.cdx.json \\\n    registry.bank.local\u002Fbanking-service:1.0.0\n\n# Генерация SBOM с помощью Syft (Anchore)\nsyft registry.bank.local\u002Fbanking-service:1.0.0 -o spdx-json > sbom.spdx.json\n\n# Сканирование SBOM на уязвимости (отдельно от генерации)\ngrype sbom:.\u002Fsbom.cdx.json\n```\n\nSBOM позволяет быстро определить, содержит ли ваш образ уязвимый компонент. Например, при обнаружении новой CVE в Log4j можно за секунды проверить все SBOM и определить, какие именно сервисы затронуты, вместо того чтобы пересканировать каждый образ.\n\n**2. Проверка зависимостей на уязвимости:**\n\n```xml\n\u003C!-- Maven: OWASP Dependency Check Plugin -->\n\u003Cplugin>\n    \u003CgroupId>org.owasp\u003C\u002FgroupId>\n    \u003CartifactId>dependency-check-maven\u003C\u002FartifactId>\n    \u003Cversion>10.0.3\u003C\u002Fversion>\n    \u003Cconfiguration>\n        \u003CfailBuildOnCVSS>7\u003C\u002FfailBuildOnCVSS>\n        \u003CsuppressionFile>dependency-check-suppressions.xml\u003C\u002FsuppressionFile>\n    \u003C\u002Fconfiguration>\n\u003C\u002Fplugin>\n```\n\n```bash\n# Запуск проверки зависимостей\n.\u002Fmvnw dependency-check:check\n```\n\n```groovy\n\u002F\u002F Gradle\nplugins {\n    id 'org.owasp.dependencycheck' version '10.0.3'\n}\n\ndependencyCheck {\n    failBuildOnCVSS = 7.0f\n    analyzers {\n        nodeEnabled = false\n    }\n}\n```\n\nПараметр `failBuildOnCVSS=7` означает, что сборка будет автоматически провалена при обнаружении зависимости с уязвимостью, имеющей CVSS-балл 7.0 и выше (High и Critical). Файл `suppressionFile` позволяет задокументировать исключения для ложных срабатываний или принятых рисков.\n\n**3. Фиксация версий зависимостей:**\n\n```xml\n\u003C!-- Использовать конкретные версии, НЕ диапазоны -->\n\u003Cdependency>\n    \u003CgroupId>org.springframework.boot\u003C\u002FgroupId>\n    \u003CartifactId>spring-boot-starter-web\u003C\u002FartifactId>\n    \u003Cversion>3.3.0\u003C\u002Fversion> \u003C!-- Конкретная версия -->\n\u003C\u002Fdependency>\n\n\u003C!-- ЗАПРЕЩЕНО в банковских проектах: -->\n\u003Cversion>[3.0,4.0)\u003C\u002Fversion> \u003C!-- Диапазон версий — может подтянуть непроверенное обновление -->\n\u003Cversion>LATEST\u003C\u002Fversion>    \u003C!-- Последняя версия — непредсказуемый результат сборки -->\n```\n\nДиапазоны версий и метатеги (`LATEST`, `RELEASE`) создают **нереспроизводимые сборки**: один и тот же коммит может дать разный результат в зависимости от момента сборки. Это как минимум нарушает аудируемость, а в худшем случае позволяет злоумышленнику внедрить вредоносный пакет через подмену (dependency confusion attack).\n\n**4. Верификация артефактов в Docker:**\n\n```dockerfile\nFROM eclipse-temurin:21-jre-alpine@sha256:a1b2c3d4...  # Pin по digest\n\n# Проверка контрольной суммы скачиваемых файлов\nRUN wget https:\u002F\u002Fexample.com\u002Ftool.tar.gz && \\\n    echo \"expected_sha256  tool.tar.gz\" | sha256sum -c - && \\\n    tar xzf tool.tar.gz\n```\n\nPin по digest (`@sha256:...`) гарантирует, что будет использован ровно тот образ, который был протестирован. В отличие от тега, digest нельзя переназначить на другой образ. Проверка контрольной суммы скачиваемых файлов предотвращает использование подменённых артефактов.\n\n**5. SLSA (Supply-chain Levels for Software Artifacts):**\n\nSLSA (произносится «salsa») — это фреймворк, определяющий уровни зрелости безопасности цепочки поставок:\n\n| Уровень | Требования | Что это даёт |\n|---------|-----------|--------------|\n| SLSA 1 | Процесс сборки документирован | Базовая прозрачность |\n| SLSA 2 | Сборка выполняется на CI\u002FCD (не локально), подписанная provenance | Защита от ручного вмешательства |\n| SLSA 3 | CI\u002FCD-система аудитируемая и защищённая от вмешательства | Защита от компрометации pipeline |\n| SLSA 4 | Двусторонняя проверка изменений, hermetic build (изолированная сборка без доступа к сети) | Полная верифицируемость |\n\nДля банковских систем рекомендуется стремиться к SLSA 3 как минимум.\n\n**6. Provenance (происхождение артефакта):**\n\nProvenance — это подписанный документ (attestation), фиксирующий, кто собрал образ, из какого исходного кода, на какой CI\u002FCD-системе и с какими параметрами. Это позволяет проследить полную цепочку от коммита до деплоя.\n\n```bash\n# Генерация attestation с помощью cosign\ncosign attest --predicate provenance.json \\\n    --key cosign.key \\\n    registry.bank.local\u002Fbanking-service@sha256:abc123...\n\n# Верификация attestation\ncosign verify-attestation \\\n    --key cosign.pub \\\n    --type slsaprovenance \\\n    registry.bank.local\u002Fbanking-service@sha256:abc123...\n```\n\n**7. Полный пайплайн supply chain security (GitHub Actions):**\n\n```yaml\nname: Secure Build Pipeline\non: [push]\njobs:\n  build:\n    runs-on: ubuntu-latest\n    permissions:\n      contents: read\n      id-token: write  # Для keyless signing через Fulcio\u002FSigstore\n    steps:\n    - uses: actions\u002Fcheckout@v4\n\n    - name: Dependency Check\n      run: .\u002Fmvnw dependency-check:check\n\n    - name: Build\n      run: .\u002Fmvnw clean package -DskipTests\n\n    - name: Build & Push Image\n      id: build\n      run: |\n        docker build -t registry.bank.local\u002Fbanking-service:${{ github.sha }} .\n        docker push registry.bank.local\u002Fbanking-service:${{ github.sha }}\n\n    - name: Generate SBOM\n      uses: anchore\u002Fsbom-action@v0\n      with:\n        image: registry.bank.local\u002Fbanking-service:${{ github.sha }}\n        format: cyclonedx-json\n        output-file: sbom.cdx.json\n\n    - name: Scan for vulnerabilities\n      run: trivy image --exit-code 1 --severity CRITICAL registry.bank.local\u002Fbanking-service:${{ github.sha }}\n\n    - name: Sign Image\n      run: cosign sign --yes registry.bank.local\u002Fbanking-service:${{ github.sha }}\n\n    - name: Attach SBOM to Image\n      run: cosign attach sbom --sbom sbom.cdx.json registry.bank.local\u002Fbanking-service:${{ github.sha }}\n```\n\nЭтот пайплайн последовательно выполняет все этапы supply chain security: проверку зависимостей, сборку, генерацию SBOM, сканирование на уязвимости, подпись образа и прикрепление SBOM к образу в реестре. Каждый этап — это «ворота безопасности» (security gate), при провале которого пайплайн останавливается.","","senior",[15,16,17,18,19,20],"supply-chain","slsa","dependency-check","cosign","sbom","container-security",[],null,{"title":24,"description":25,"ogTitle":24,"ogDescription":26,"keywords":27,"schemaAnswer":36,"featuredSnippetReady":37},"Supply Chain Security контейнеров: SBOM, SLSA, Cosign — Gymterview","Что такое Supply Chain Security для контейнеров? SBOM (Software Bill of Materials), SLSA уровни, проверка зависимостей OWASP Dependency Check, подпись артефактов Cosign, provenance.","Безопасность цепочки поставок контейнеров: генерация SBOM, уровни SLSA, проверка зависимостей, подпись и верификация артефактов с Cosign.",[28,29,30,31,32,33,34,35],"Supply Chain Security","SBOM","SLSA","Cosign","Dependency Check","безопасность цепочки поставок","Trivy SBOM","CycloneDX","Supply Chain Security — обеспечение целостности и безопасности всех компонентов от исходного кода до финального образа. Включает: SBOM (Software Bill of Materials) — перечень всех компонентов образа (Trivy, Syft); проверку зависимостей (OWASP Dependency Check, failBuildOnCVSS); фиксацию версий и pin по digest; верификацию артефактов; SLSA (4 уровня зрелости безопасности); provenance — подтверждение происхождения артефакта через cosign attest. Полный пайплайн включает dependency check, сборку, генерацию SBOM, сканирование, подпись образа и прикрепление SBOM.",true]