Secure SDLC — безопасный жизненный цикл

Secure SDLC (Secure Software Development Life Cycle) — интеграция практик безопасности на каждом этапе разработки ПО: от проектирования до деплоя и эксплуатации. Цель: "shift left" — нашедший уязвимость в коде дешевле фиксит её, чем в production.

Зачем нужно

Устранение уязвимости в production стоит в 30–100 раз дороже, чем на этапе разработки. Secure SDLC встраивает безопасность в привычные процессы команды (code review, CI/CD) вместо отдельного аудита перед релизом.

Где используется

  • Enterprise-разработка с регуляторными требованиями (GDPR, PCI DSS, SOC 2)
  • SaaS-продукты, обрабатывающие персональные данные
  • Любая команда, выстраивающая DevSecOps-процессы

Основной контент

7 этапов Secure SDLC и практики безопасности

1. Training         → Security awareness, OWASP Top 10 для команды
2. Requirements     → Threat modeling, security user stories
3. Design           → Architecture review, принцип наименьших привилегий
4. Development      → SAST, code review чек-листы, secure coding guidelines
5. Testing          → DAST, penetration testing, fuzzing
6. Deployment       → Dependency scanning, secrets check, SBOM
7. Operations       → Мониторинг, incident response, patch management

Threat Modeling: STRIDE

S — Spoofing        → Аутентификация
T — Tampering       → Целостность данных, подписи
R — Repudiation     → Логирование, audit trail
I — Information     → Шифрование, access control
D — Denial of Service → Rate limiting, масштабирование
E — Elevation       → Авторизация, принцип минимальных привилегий

CI/CD Security Pipeline

# .github/workflows/security.yml
jobs:
  security:
    steps:
      - name: Dependency Scan
        run: npm audit --audit-level=high

      - name: SAST
        uses: semgrep/semgrep-action@v1
        with: { config: 'p/owasp-top-ten' }

      - name: Secrets Check
        uses: trufflesecurity/trufflehog-actions-scan@main

      - name: License Check
        run: npx license-checker --onlyAllow 'MIT;Apache-2.0;ISC;BSD-2-Clause;BSD-3-Clause'

Security requirements template

## Security Requirements: [Feature Name]

### Authentication & Authorization
-  Аутентификация обязательна для всех приватных эндпоинтов
-  Проверка принадлежности ресурса пользователю (anti-IDOR)

### Input Validation
-  Все входные данные валидируются на сервере
-  Параметризованные запросы для SQL

### Data Protection
-  PII шифруется at rest
-  Нет sensitive данных в логах и URL-параметрах

Частые ошибки

  • Безопасность как отдельный этап "после разработки" — слишком поздно и дорого
  • Отсутствие threat modeling для новых функций с высоким риском
  • Игнорирование security requirements в backlog — попадают в technical debt
  • Один пентест в год вместо continuous security testing

Связанные темы

Ресурсы