Сначала договоримся с тобой так — тут зарыта главная подмена, где в STLC дефект — это баг, тест — тест-кейс, требование — функциональное требование. А теперь прикол в том, что:

• Дефект - это подтверждённая уязвимость True Positive
• Тест - правило/ политика анализатора ruleset
• Требование - класс угроз CWE, контроль ASVS, пункт безопасной разработки ГОСТ 56939-2024

— Низкая по ruleset, где правила сбоят или мертвы
— Аномально высокая на одном правиле, тут либо системный дефект кода, либо правило сбоит

— < 60% — токсично
— 60–85% — рабочая зона
— > 85% — зрелое покрытие

— высокая из-за FP, то инструмент сбоит, следовательно делаем аудит правил
— высокая из-за accepted risk, то есть то, что валит процесс, делай эскалацию

— < 1, показывает, что контроль покрыт формально
— несколько правил с разной логикой (AST + taint analys+ semantic ruleset)

— > 15% — фиксят не то и не там
— на каждую устранённую Critical/ High следует правило в Quality Gate

• Широту покрытия и глубину (плотность правил) считать в паре — раз в спринт детально по критичным CWE, общий срез раз в квартал или H
• Долю отклонённых всегда расщеплять на FP и accepted risk
• Плотность уязвимостей и долю регрессий смотреть каждый релиз
• Эффективность считать через стоимость Critical-находки
• Главный KPI зрелости — Defect Removal Efficiency для ИБ > 90%

Вектора:
• подмена пользователя, session fixation, replay токена
• подмена сервиса, как MITM, фальшивый endpoint, DNS-hijack, отсутствие mTLS между микросервисами
• подмена identity в логах через X-Forwarded-User без проверки

Контроли: MFA, mTLS с проверкой сертификатов, OAuth2/ OIDC с PKCE, привязка токенов, типа DPoP, mTLS-bound, WebAuthn/ FIDO2, anti-replay (nonce, timestamps, jti)

Вектора:
• модификация трафика
• подмена параметров запроса (IDOR через hidden fields, JWT с alg=none, манипуляции client-side state)
• модификация хранимых данных в обход приложения
• supply chain: подмена артефактов сборки, образов, зависимостей

Контроли: TLS актуальных версий, цифровые подписи и HMAC, контроль целостности (checksums, FIM), append-only / WORM журналы, signed commits, signed images, SBOM, контроль конфигураций)

Вектора:
• пользователь отрицает действие, а доказать нечем
• shared/ служебные аккаунты без идентификации
• админ модифицирует журналы постфактум
• разработчик коммитит без подписи в общую ветку

Контроли: централизованное журналирование с защитой целостности (append-only, WORM), синхронизация времени NTP, корреляция в SIEM, цифровая подпись чувствительных операций, signed commits, запрет shared accounts

Вектора:
• нешифрованная передача
• stack trace и подробные ошибки в ответе пользователю
• BOLA / IDOR — обращение к чужим объектам по перебору ID
• PII (персонификация) и секреты в логах
• side-channel: тайминг, размер ответа, кэш-различия

Контроли: TLS, шифрование at-rest (envelope / KMS / HSM), generic-ответы об ошибках без деталей, output filtering и явные DTO, маскирование PII в логах, минимизация данных, secret management

Вектора:
• объёмные DDoS уровней L3/ L4
• application-layer DoS: медленные запросы (slowloris), catastrophic regex backtracking, zip/XML-бомбы, billion laughs
• исчерпание ресурсов: утечки памяти, connection pool, unbounded queues

Контроли: rate limiting и throttling, WAF / DDoS-защита, ограничения размера, времени и глубины, circuit breakers, авто-масштабирование, бэкапы и DR, capacity planning

Вектора:
• BOLA / BFLA: нет проверки прав на объект или функцию
• вертикальная эскалация
• горизонтальная эскалация
• sandbox escape
• JWT-tampering
• RCE через десериализацию

Контроли: RBAC / ABAC с deny-by-default, проверка авторизации на каждом запросе (а не один раз на входе в API-gateway), Segregation of Duties, least privilege, изоляция контейнеров (rootless, seccomp, AppArmor / SELinux), валидация входа, role-claims с клиента

• Коды ошибок — 500 Internal Server Error со stack trace в теле ответа является именем фреймворка, версии, пути к файлам, иногда строка подключения к БД. А допустим 403 Forbidden отличается от 404 Not Found, где мы можем перебором найти закрытые endpoints. А 405 Method Not Allowed прямо говорит, что эндпоинт существует
• Verbose-ошибки в теле — например ASP.NET в режиме разработки отдаёт полный stack trace в HTML. А Spring Boot без server.error.include-stacktrace=never делает то же самое в JSON. К тому же Django с DEBUG=True — отдельная история и очен геморройная
• Заголовки ответа — Server: Microsoft-IIS/10.0, X-Powered-By: ASP.NET, X-AspNet-Version: 4.0.30319 дают нам понимание стека, версии рантайма и саму платформу, то есть самое первое перед эксплойтом
• TRACE-метод — отражает запрос обратно целиком, включая заголовки, где можно увидеть внутренние заголовки, которые добавляет reverse proxy или балансировщик, иногда токены (вот тут я рассмотрел подробнее)

# GET с несуществующим путём — смотрим что в теле ошибки
curl -i https://example.com/api/v1/doesnotexist123

# POST без тела и Content-Type — триггерим ошибку парсинга
curl -i -X POST https://example.com/api/v1/orders

# POST с кривым JSON — часто вытаскивает stack trace
curl -i -X POST https://example.com/api/v1/orders \
  -H "Content-Type: application/json" \
  -d '{"broken json'

# TRACE — проверяем включён ли метод
curl -i -X TRACE https://example.com

# Смотрим только заголовки — ищем Server, X-Powered-By, X-AspNet-Version
curl -s -D - https://example.com -o /dev/null | grep -iE \
  "server:|x-powered|x-aspnet|x-generator|x-runtime"

# verbose error с деталями стека
HTTP/1.1 500 Internal Server Error
X-Powered-By: ASP.NET

{
  "message": "Object reference not set to an instance of an object",
  "stackTrace": "at ProjectQueryRepository.GetById(Int32 id)\r\n
                 at C:\\inetpub\\b2b\\src\\Repositories\\ProjectQueryRepository.cs:75"
}

# TRACE отражает запрос обратно
HTTP/1.1 200 OK
TRACE /api/test HTTP/1.1
Host: example.com
Authorization: Bearer eyJhbGc...   ← токен в отражении

# А вот тут ничего лишнего
HTTP/1.1 500 Internal Server Error

{ "error": "Internal server error", "requestId": "a3f9c2" }

• 500 с телом ошибки — первое что проверяет DAST
• Разница между 403 и 404 на закрытых эндпоинтах — это enumeration, несуществующее и недоступное должны быть неразличимы снаружи
• Server: и X-Powered-By: убрать на уровне nginx/ IIS — они не нужны клиенту
• Единственное что отдаём при ошибке — requestId, всё остальное во внутренние логи прячем
• Всплески 500 и нестандартных методов — детектируемый паттерн активного поиска
• Единообразие кодов ответа - несуществующий ресурс и ресурс, к которому нет доступа, должны быть неразличимы снаружи — оба возвращают 404
• Server:, X-Powered-By:, X-AspNet-Version:, X-AspNetMvc-Version:, X-Generator:, X-Runtime: убирать на уровне веб-сервера или reverse proxy, так как не несёт никакой ценности при бизнес функции
• Сделать Whitelist разрешённых методов: GET, HEAD, POST, PUT, DELETE, PATCH в зависимости от API, сам TRACE отключается везде
• Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options и остальные заголовки безопасности — отдельный слой, который закрывает эксплуатацию даже если часть информации всё-таки утекла. Без них утечка версии фреймворка в связке с известным CVE и отсутствием CSP превращается в цепочку за один шаг

Инструмент анализирует шаблоны инфраструктуры как кода (IaC) и проверяет их на соответствие встроенным политикам безопасности. Сканирует конфиги HCL, YAML и JSON, на предмет ошибок, недостаток архитектуры, нарушений практик и проблем с соответствием требованиям.

Основной маппинг на CIS Benchmarks, NIST, SOC2, GDPR, HIPAA из коробки.

# Сканирование текущей директории с автоопределением типа IaC
terrascan scan
 
# Сканирование с указанием типа IaC и облачного провайдера
terrascan scan -i terraform -t aws
 
# Вывод результатов в формате JSON
terrascan scan -o json
 
# Фильтрация по severity
terrascan scan --severity "High"
 
#Dockerfile
terrascan scan -i docker
 
# Отображение уязвимостей в образах, упомянутых в IaC-файлах
terrascan scan -i terraform --find-vuln

# root пользователь
FROM node:18
COPY . /app
RUN npm install
CMD ["node", "server.js"]

# ADD на extrnl URL
ADD https://example.com/script.sh /tmp/

# policy/no_latest_tag.rego
package accurics.docker.image.latest

deny[msg] {
  input.type == "dockerfile"
  instruction := input.instructions[_]
  instruction.cmd == "from"
  contains(instruction.value, ":latest")
  msg := sprintf("Image uses ':latest' tag: %v", [instruction.value])
}

terrascan:
  image: tenable/terrascan:latest
  stage: security
  script:
    - terrascan scan -t terraform -d ./infra -o sarif > terrascan.sarif
    - terrascan scan -t docker -f Dockerfile -o json > docker.json
  artifacts:
    reports:
      sast: terrascan.sarif
  allow_failure: false       # блокируем pipeline при HIGH/CRITICAL

# .git/hooks/pre-commit
#!/bin/bash
terrascan scan -t terraform -d . --severity HIGH --exit-code 1
if [ $? -ne 0 ]; then
  echo "BLOCKED: Terrascan found HIGH/CRITICAL violations"
  exit 1
fi

• Единый IaC для Terraform, Kubernetes и Helm из коробки
• Возможность написания кастомных правил на Rego для внутренних требований
• Инструмент анализирует код до его развертывания и не отслеживает runtime-угрозы в работающей инфраструктуре. Параметризованные ресурсы проверяются по тому значению, что видно в конфиге
• Подходит больше для кластеров Kubernetes и связанных с ними технологий
• Можно указывать, какие правила игнорировать (--skip-rules)
• Позволяет настраивать критерии QG исходя их severity