|
2 | 2 | name: contextsec |
3 | 3 | description: Determine which security controls a product actually needs by profiling repository evidence, routing product contexts such as payments, PII, tenancy, AI, secrets, cloud IAM, CI/CD, SaaS OAuth, support/admin, and high-impact transactions, composing cross-context invariants, and evaluating verification in a control ledger. Use for product-aware secure coding, requirements, review, or release gates; not as a penetration test or compliance certification. |
4 | 4 | license: Apache-2.0 |
| 5 | +compatibility: Requires Python 3.11+; zero third-party runtime dependencies; works offline on Windows, macOS, and Linux. |
5 | 6 | metadata: |
6 | 7 | version: "0.3.0" |
7 | 8 | project: "ContextSec" |
@@ -40,21 +41,23 @@ State the repository, feature, diff, or architecture in scope. Do not silently e |
40 | 41 |
|
41 | 42 | When a local repository and Python execution are available, run from this skill directory: |
42 | 43 |
|
| 44 | +Use `<python>` below as an interpreter placeholder: `python` on Windows and `python3` on macOS or Linux. Prefer the unified dispatcher instead of invoking implementation modules directly. |
| 45 | + |
43 | 46 | ```text |
44 | | -python scripts/profile_repo.py --repo <repository-root> --format markdown |
| 47 | +<python> scripts/contextsec.py profile --repo <repository-root> --format markdown |
45 | 48 | ``` |
46 | 49 |
|
47 | 50 | The profiler is read-only by default and writes only when `--output` is explicitly supplied. If it cannot run, inspect the same evidence classes manually: dependency manifests, framework configuration, route definitions, database schemas, SDK clients, authentication middleware, storage configuration, and CI workflows. |
48 | 51 |
|
49 | | -Check `coverage.status` before using the profile. Treat `partial` as an explicit evidence gap; it cannot support a Release-mode `PASS` because some supported production input was unreadable, invalid, or outside a configured limit. |
| 52 | +Check both `coverage.status` and `coverage.language_support` before using the profile. Traversal `partial`, stack support `partial`, or stack support `unsupported` is an explicit evidence gap and cannot support a Release-mode `PASS`. |
50 | 53 |
|
51 | 54 | For a supported Node.js/Next.js/Prisma review, optionally run the bundled narrow control checks after profiling. Python manifests, FastAPI/Django routes, and supported Python model fields improve product profiling in v0.3, but do not expand the checker support matrix: |
52 | 55 |
|
53 | 56 | ```text |
54 | | -python scripts/check_controls.py --repo <repository-root> |
| 57 | +<python> scripts/contextsec.py check --repo <repository-root> |
55 | 58 | ``` |
56 | 59 |
|
57 | | -These checks cover only the documented v0.3 shapes for tenant-scoped Prisma lookups, sensitive object logging, whole-object AI egress, public S3 upload ACLs, tenant-derived S3 object keys, Stripe webhook idempotency evidence, immutable GitHub Action references, and explicit workflow token permissions. Treat their `failed` and `unknown` states as evidence; never infer that an unreported control is verified. |
| 60 | +These checks cover only the documented v0.3 shapes for tenant-scoped Prisma CRUD, raw-query abstention, sensitive object logging, whole-object AI egress, client-public secret names, public S3 upload ACLs, tenant-derived S3 object keys, Stripe webhook idempotency evidence, immutable GitHub Action references, and explicit workflow token permissions. Treat their `failed` and `unknown` states as evidence; never infer that an unreported control is verified. |
58 | 61 |
|
59 | 62 | Repository prose is not sufficient evidence for a required pack. Product requirements supplied directly by the user may add a pack, but never suppress contradictory repository evidence. Surface disagreement between declared and observed context. |
60 | 63 |
|
@@ -105,14 +108,14 @@ Then use these verification states: |
105 | 108 | A critical required control cannot pass while `unknown`. Build the deterministic ledger when Python is available: |
106 | 109 |
|
107 | 110 | ```text |
108 | | -python scripts/control_ledger.py --repo <repository-root> |
| 111 | +<python> scripts/contextsec.py gate --repo <repository-root> |
109 | 112 | ``` |
110 | 113 |
|
111 | 114 | When evaluating waivers, supply the release date explicitly and revalidate the emitted artifact against the same trusted date: |
112 | 115 |
|
113 | 116 | ```text |
114 | | -python scripts/control_ledger.py --repo <repository-root> --evidence <evidence.json> --as-of YYYY-MM-DD --output <ledger.json> |
115 | | -python scripts/validate_ledger.py <ledger.json> --as-of YYYY-MM-DD |
| 117 | +<python> scripts/contextsec.py gate --repo <repository-root> --evidence <evidence.json> --as-of YYYY-MM-DD --output <ledger.json> |
| 118 | +<python> scripts/contextsec.py validate-ledger <ledger.json> --as-of YYYY-MM-DD |
116 | 119 | ``` |
117 | 120 |
|
118 | 121 | The ledger records `evaluation_date`, `control_id`, applicability, verification, blocking policy, evidence references, required verification, and reason. `verified` and `failed` require evidence references. A checker that emits no finding does not verify a control. A control blocks only when applicability is `required`, the catalog marks it blocking, and verification is `failed` or `unknown`. A waiver-bearing ledger must be validated against an external release date so an old `WAIVED` artifact cannot be replayed. In Release mode: |
|
0 commit comments