Attackers have the advantage of living through attacks every day and improving their technique, by targeting different victims around the world. On the other hand, security teams try to avoid facing advanced attacks and often don’t come across them until it’s too late.

🛡 В этот понедельник делимся серией из трёх статей, посвященных обнаружению атак на гибридное облако.

Первая часть серии — обзорная. Йотам рассказывает, чем гибридные облака привлекают злоумышленников.
Во второй части автор приводит пример реальной атаки.
В третьей — разбирает, как вовремя среагировать на инцидент из второй части.

#devsecops #гибридноеоблако #кибератака

5 мифов о DevSecOps, из-за которых теряется скорость релизов и контроль над безопасностью

🤝Сегодня обсудим, почему DevSecOps — не про замедление, бюрократию и ещё один набор инструментов. Разберём 5 мифов, которые мешают это увидеть.

💬DevSecOps замедляет разработку
Миф: проверки безопасности добавляют фрикцию — значит, релизы будут идти медленнее.
Реальность: скорость падает не из-за DevSecOps, а из-за ручных и разрозненных проверок.
Когда безопасность встроена в CI/CD-поток (например, через автоматические SAST-, SCA- и DAST-сканеры), разработчики получают обратную связь в момент сборки или при коммите — ещё до ревью. Такая интеграция позволяет исправлять уязвимости до того, как они попадут в прод. Например, по данным Veracode, клиенты, использующие Veracode Fix, сокращают время устранения уязвимостей примерно на 92 % по сравнению с ручными подходами.

💬DevSecOps — это просто ещё один набор инструментов
Миф: купим несколько сканеров, включим проверки — и у нас DevSecOps.
Реальность: сами инструменты ничего не дают без культуры взаимодействия между разработчиками, DevOps и специалистами по безопасности. Если сканеры не интегрированы с CI/CD, issue-трекерами (например, Jira, GitLab Issues) или IDE, безопасность превращается в хаос уведомлений, которые никто не успевает обработать.

💬Разработчики должны быть экспертами по безопасности
Миф: разработчик должен стать специалистом по кибербезопасности для внедрения DevSecOps.
Реальность: грамотно выстроенный DevSecOps-процесс автоматизирует рутину и даёт понятные подсказки там, где работает разработчик — в IDE (VS Code, IntelliJ), в pull-requestах или пайплайне CI. Безопасность становится частью привычного цикла: написал код → прогнал тесты → получил подсказку по уязвимости → исправил.

💬DevSecOps не подходит малому бизнесу
Миф: DevSecOps — это история для корпораций с большими бюджетами.
Реальность: DevSecOps можно начать с малого и масштабировать по мере роста.
Даже небольшие команды могут настроить:
- SAST-проверку через бесплатные инструменты — Semgrep, SonarQube Community, Bandit;
- SCA-анализ с помощью OWASP Dependency-Check, Snyk Open Source или GitHub Dependabot.
Малый бизнес выигрывают за счёт гибкости процессов: меньше согласований, быстрее адаптация.

💬DevSecOps — это только защита от внешних атак
Миф: DevSecOps нужен только для защиты от хакеров и DDoS.
Реальность: DevSecOps охватывает всю цепочку безопасности — от конфигураций инфраструктуры до зависимостей и прав доступа.

#DevSecOps #Security #CICD #Automation

🛡Безопасность в Docker: SBOM и выявление уязвимостей

Сегодня разбираем, как обеспечить безопасность цепочки поставок в Docker на примере практического гайда Shamsher Khan: Advanced Docker Security: From Supply Chain Transparency to Network Defense. Подробно разберем обеспечение прозрачности цепочки поставок с помощью SBOM, спецификации ПО (Lab 07), а подробнее об установке эшелонированной защиты от DDoS и ботов (Lab 08) можете прочесть здесь.

👀Почему тема важна в сообществе?
• В 2021 инцидент с Log4Shell, ошибкой в библиотеке Log4j, указал на большую проблему современной разработки – незнание состава контейнеров.
• Кибератака SolarWinds произошла в том же году, что инцидент выше.

⏺В статье представлены две лабы, задеплоить можно уже сегодня:
1. Обеспечение прозрачности цепочки поставок с помощью SBOM (Lab 07)
2. Эшелонированная защита от DDoS и ботов (Lab 08)

💬Обеспечиваем безопасность цепочки поставок со SBOM (Lab 07)
Рассмотрим Dockerfile:

FROM python:3.11-slim 
COPY requirements.txt . 
RUN pip install -r requirements.txt 
COPY app.py . CMD ["python", "app.py"]

Вопрос знатокам: какие пакеты в этом образе? Без SBOM мы можем догадаться: e.g. Python 3.11, requirements.txt и OS уязвимости.
SBOM позволяет получить полный список всех компонентов, версий и лицензий, сгенерированный за секунды.

🚀На старт, внимание, SBOM
В статье представлен демо-скрипт для выполнения с последовательностью из 12-ти шагов.

💬Шаг 1: установка инструментов.

# Install Syft (SBOM generation) 
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin 

# Install Grype (vulnerability scanning) 
curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin 

# Verify installation 
syft version grype version

💬Шаг 2: установка SBOM

From a Docker image
syft nginx:alpine -o spdx-json > nginx-sbom.json

# From a directory
syft dir:./myapp -o cyclonedx-json > myapp-sbom.json

# Multiple formats at once
syft nginx:alpine -o spdx-json=sbom.spdx.json -o cyclonedx-json=sbom.cdx.json

💬Шаг 3: выявляем уязвимости

# Scan the SBOM
grype sbom:./nginx-sbom.json

# Or scan image directly
grype nginx:alpine

💬Шаг 4: сравниваем версии SBOM

# Generate SBOMs for two versions
syft myapp:v1.0 -o json > v1.0-sbom.json
syft myapp:v2.0 -o json > v2.0-sbom.json

# Compare (using provided script)
./compare-sboms.sh v1.0-sbom.json v2.0-sbom.json



💬Шаг 5: выявляем уязвимости в SBOM

# Scan the SBOM
grype sbom:./nginx-sbom.spdx.json

# Or scan image directly
grype nginx:alpine

💬Шаг 6: определяем типы уязвимостей по параметрам

# Only show CRITICAL and HIGH
grype nginx:alpine --fail-on high

# Only show CRITICAL
grype nginx:alpine --fail-on critical

# Show only specific severity
grype nginx:alpine -o json | jq '.matches[] | select(.vulnerability.severity == "High")'

# Export vulnerabilities to JSON
grype nginx:alpine -o json > vulnerabilities.json

В шагах 7 и 8 сравниваем версии SBOM и ищем конкретные пакеты, а в 9 – рассматривает отчёт/журнал SBOM

💬Финальный шаг, 12: интеграция в CI/CD (Azure DevOps)

azure-pipeline.yml

- task: Docker@2
  inputs:
    command: build
    dockerfile: '**/Dockerfile'
    tags: $(Build.BuildId)

- script: |
    syft $(imageName):$(Build.BuildId) -o spdx-json > sbom.json
  displayName: 'Generate SBOM'

- script: |
    grype sbom:./sbom.json --fail-on high
  displayName: 'Scan for Vulnerabilities'

- task: PublishBuildArtifacts@1
  inputs:
    pathToPublish: 'sbom.json'
    artifactName: 'SBOM'

👨‍💻В результате, скорость реагирования при обнаружении уязвимостей сокращается с 14 до 2 дней, осуществляется поддержка 3-х форматов (SPDX, CycloneDX, Syft JSON) и гарантируется полное соответствие требованиям – EO 14028.

👩‍💻Делимся репозиториями:
• Syft – установка SBOM
• Grype – выявление уязвимостей
• Docker Security Practical Guide – полный гайд с Lab 07 и Lab 08

#devsecops #SBOM #zerotrust #kubernetes