SEC / Безопасность
Чувствительные данные попадают в логи / Чувствительные данные достигают запрещённого получателя
security.sensitive-data-flow@1.0.0V-SEC-01 · Дефект
Чувствительные данные попадают в логи
Секрет, попавший в лог, может стать доступен гораздо более широкому кругу систем и людей, чем исходное хранилище.
Пример проблемы и направление исправления
Учебные сокращённые фрагменты Swift или схемы протокола. Вспомогательные API условны. Это не тестовые oracle и не обещание, что текущий subset выдаст диагностику именно на этот код.
Проблемный сценарий
logger.write("Authorization: \(token)")
Возможное исправление
logger.write("Authorization attempt completed")
Что изменить и что сохранить
Удалить секрет из сообщения или применить подтверждённую модель redaction. Маскирование должно учитывать все пути форматирования и downstream-политику логов.
Что нужно доказать
Credentials/PII source проходит wrappers до раскрывающего logging sink
Требуемые факты по контракту: sensitive/taint taxonomy, storage/log/network/SQL models
Безопасные случаи и границы
Logger privacy, полная redaction и разрешённый category contract
Если необходимые факты не получены, результат — unknown, а не «ошибки нет». Для review-сигнала также нужен наблюдаемый риск; нехватки данных недостаточно.
Что подтверждено сейчас
В срезе 022 требуется восстановление и квалификация source producer. Целевое доказательство и пример описывают желаемое поведение; они не являются свидетельством действующей диагностики.
V-SEC-02 · Нарушение контракта
Чувствительные данные достигают запрещённого получателя
Даже легитимная сетевая отправка становится нарушением, если чувствительные данные получает запрещённый policy адресат.
Пример проблемы и направление исправления
Учебные сокращённые фрагменты Swift или схемы протокола. Вспомогательные API условны. Это не тестовые oracle и не обещание, что текущий subset выдаст диагностику именно на этот код.
Проблемный сценарий
analytics.send(["email": account.email])
Возможное исправление
analytics.send(["event": "account_opened"])
Что изменить и что сохранить
Минимизировать payload и явно согласовать допустимые recipients. Хэширование идентификатора не автоматически делает персональные данные анонимными.
Что нужно доказать
Flow нарушает destination/storage/transport policy
Требуемые факты по контракту: sensitive/taint taxonomy, storage/log/network/SQL models
Безопасные случаи и границы
TLS не заменяет разрешение получателя; допустимое хранение отдельно
Если необходимые факты не получены, результат — unknown, а не «ошибки нет». Для review-сигнала также нужен наблюдаемый риск; нехватки данных недостаточно.
Что подтверждено сейчас
В срезе 022 требуется восстановление и квалификация source producer. Целевое доказательство и пример описывают желаемое поведение; они не являются свидетельством действующей диагностики.
Контракты и происхождение
Страница объединяет утверждённый реестр и редакционные объяснения из Git-среза 4558458d. Raw engineering contracts не входят в public artifact; точные пути остаются во внутреннем manifest.
- Целевой каталог:
docs/product/final-rule-catalog.md - Реестр RuleID:
docs/evidence/matrices/022-complete-rule-portfolio.md - Матрица условий:
openspec/specs/022-complete-rule-portfolio/coverage-matrix.md - Срез приёмки:
openspec/specs/022-complete-rule-portfolio/reports/source-authority-recovery.md - Приёмка: t008-t009-source-batch:
openspec/specs/022-complete-rule-portfolio/reports/t008-t009-source-batch.md - Приёмка: t012-t015-source-batch:
openspec/specs/022-complete-rule-portfolio/reports/t012-t015-source-batch.md - Приёмка: t011-delivery:
openspec/specs/022-complete-rule-portfolio/reports/t011-delivery.md - Приёмка: t014-delivery:
openspec/specs/022-complete-rule-portfolio/reports/t014-delivery.md
Изменение статуса требует обновления подтверждённого среза и проверки каталога. Количество страниц не является количеством полностью квалифицированных правил.