16 lines
1.8 KiB
Markdown
16 lines
1.8 KiB
Markdown
---
|
|
name: common-security-change
|
|
description: Review security-sensitive changes in Common-VS libraries or their BusinessMgr, Sandtrap, and Sandalwood consumers using the applicable migration records; not a general security workflow.
|
|
---
|
|
|
|
# Security-Sensitive Change
|
|
|
|
Use this workflow only for security-sensitive changes in Common-VS libraries or their BusinessMgr, Sandtrap, and Sandalwood consumers. It is not a general security checklist for unrelated repositories. Read the relevant repository `AGENTS.md` and trackers, then follow the specific design record for that component rather than treating this checklist as a substitute for it.
|
|
|
|
1. Identify sensitive data, trust boundaries, callers, persisted values, and independently deployed peers affected by the change.
|
|
2. Inspect the component's current design and migration records. For encryption, read `docs/authenticated-encryption-migration.md` and the applicable consumer inventory. Treat superseded analyses as historical, not implementation guidance.
|
|
3. Preserve fail-closed behavior. Authentication failures must not fall back to plaintext, weaker formats, or another purpose. Keep expiry, authorization, replay, and one-time-use checks explicit; encryption alone does not provide them.
|
|
4. Keep secrets, credentials, tokens, certificates, and machine-specific configuration out of source control and logs. Use environment-specific configuration as documented by the owning repository.
|
|
5. Add focused validation for both accepted and rejected cases, including malformed, tampered, wrong-purpose, and compatibility cases that the approved migration requires.
|
|
6. Validate each affected repository and consumer. Record deployment ordering, invalidated persisted data, configuration needs, and compatibility consequences in the owned tracker or design record.
|