propose-security-hardening

Propose Security Hardening

Objective

Turn a collection of security evidence into a decision-ready portfolio of structural or architectural hardening opportunities. The evidence may be a Codex Security scan that is still in final reporting or is already complete, ordinary vulnerability disclosure documents, supplied findings, incident or assessment material, relevant source code, or a mixture of these. Use the evidence as support and as leads for further source inspection. Produce proposals that a principal security engineer could circulate for design review, with meaningful options, before-and-after diagrams, explicit tradeoffs, migration plans, and an implementation handoff.

Do not require a Codex Security scan. A directory of disclosure documents is a valid input collection and should be analyzed directly. Do not require a scan seal before beginning: during automatic final reporting the canonical scan documents have not been sealed yet. When completed scan integrity metadata is available, use it as additional evidence and report any mismatch or missing artifact as a limitation rather than rejecting otherwise useful inputs.

Keep three products distinct:

• canonical scan artifacts and other supplied evidence remain read-only;
• the hardening analysis is a derived, revisable design product;
• implementation changes happen only after the user selects an option and explicitly asks Codex to modify the repository.

Do not turn the hardening analysis into another vulnerability report or treat an attractive architecture diagram as proof that a finding is fixed.

Write in the natural voice of a principal security engineer preparing a design proposal for peers. Keep the tone professionally warm, calm, precise, and conversational. Write the substantive reasoning as a shared design discussion: use first-person plural throughout the path from evidence to diagnosis, invariants, options, tradeoffs, and decision ("we can preserve the fast path", "if we choose this boundary"). Use first-person singular, truthfully and sparingly, to establish the author's analytical basis and recommendation ("I inspected these callers", "I could not validate the device exposure", "I recommend Option 2 under these constraints"). Never invent personal observations, tests, or measurements.