@codyswann/lisa 2.175.2 → 2.175.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/migrations/ensure-audit-ignore-local-exclusions.d.ts.map +1 -1
- package/dist/migrations/ensure-audit-ignore-local-exclusions.js.map +1 -1
- package/package.json +1 -1
- package/plugins/lisa/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa/rules/eager/security-audit-handling.md +20 -15
- package/plugins/lisa/rules/reference/security-audit-handling.md +38 -19
- package/plugins/lisa-agy/plugin.json +1 -1
- package/plugins/lisa-cdk/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-cdk/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-cdk-agy/plugin.json +1 -1
- package/plugins/lisa-cdk-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-cdk-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-copilot/rules/eager/security-audit-handling.md +20 -15
- package/plugins/lisa-copilot/rules/reference/security-audit-handling.md +38 -19
- package/plugins/lisa-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-cursor/rules/security-audit-handling-reference.mdc +38 -19
- package/plugins/lisa-cursor/rules/security-audit-handling.mdc +20 -15
- package/plugins/lisa-expo/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-expo/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-expo-agy/plugin.json +1 -1
- package/plugins/lisa-expo-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-expo-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-harper-fabric/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-harper-fabric/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-harper-fabric-agy/plugin.json +1 -1
- package/plugins/lisa-harper-fabric-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-harper-fabric-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-nestjs/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-nestjs/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-nestjs-agy/plugin.json +1 -1
- package/plugins/lisa-nestjs-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-nestjs-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-openclaw/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-openclaw/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-openclaw-agy/plugin.json +1 -1
- package/plugins/lisa-openclaw-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-openclaw-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-phaser/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-phaser/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-phaser-agy/plugin.json +1 -1
- package/plugins/lisa-phaser-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-phaser-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-rails/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-rails/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-rails-agy/plugin.json +1 -1
- package/plugins/lisa-rails-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-rails-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-typescript/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-typescript/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-typescript-agy/plugin.json +1 -1
- package/plugins/lisa-typescript-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-typescript-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-wiki/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-wiki/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-wiki-agy/plugin.json +1 -1
- package/plugins/lisa-wiki-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-wiki-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/src/base/rules/eager/security-audit-handling.md +20 -15
- package/plugins/src/base/rules/reference/security-audit-handling.md +38 -19
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"ensure-audit-ignore-local-exclusions.d.ts","sourceRoot":"","sources":["../../src/migrations/ensure-audit-ignore-local-exclusions.ts"],"names":[],"mappings":"AAIA,OAAO,KAAK,EACV,SAAS,EACT,gBAAgB,EAChB,eAAe,EAChB,MAAM,0BAA0B,CAAC;
|
|
1
|
+
{"version":3,"file":"ensure-audit-ignore-local-exclusions.d.ts","sourceRoot":"","sources":["../../src/migrations/ensure-audit-ignore-local-exclusions.ts"],"names":[],"mappings":"AAIA,OAAO,KAAK,EACV,SAAS,EACT,gBAAgB,EAChB,eAAe,EAChB,MAAM,0BAA0B,CAAC;AA+FlC;;;;;;;;;;;;;;GAcG;AACH,qBAAa,yCAA0C,YAAW,SAAS;IACzE,QAAQ,CAAC,IAAI,0CAA0C;IACvD,QAAQ,CAAC,WAAW,2GACsF;IAE1G,OAAO,CAAC,QAAQ,CAA4B;IAE5C;;;;;;;;;;;;OAYG;IACG,gBAAgB,CAAC,GAAG,EAAE,gBAAgB,GAAG,OAAO,CAAC,IAAI,CAAC;IAkC5D;;;;;OAKG;IACG,OAAO,CAAC,GAAG,EAAE,gBAAgB,GAAG,OAAO,CAAC,OAAO,CAAC;IAatD;;;;;;OAMG;IACG,KAAK,CAAC,GAAG,EAAE,gBAAgB,GAAG,OAAO,CAAC,eAAe,CAAC;CAkD7D"}
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"ensure-audit-ignore-local-exclusions.js","sourceRoot":"","sources":["../../src/migrations/ensure-audit-ignore-local-exclusions.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,IAAI,MAAM,WAAW,CAAC;AAClC,OAAO,KAAK,GAAG,MAAM,UAAU,CAAC;AAEhC,OAAO,EAAE,QAAQ,EAAE,cAAc,EAAE,SAAS,EAAE,MAAM,wBAAwB,CAAC;AAO7E,MAAM,YAAY,GAAG,0BAA0B,CAAC;AAChD,MAAM,WAAW,GAAG,yBAAyB,CAAC;
|
|
1
|
+
{"version":3,"file":"ensure-audit-ignore-local-exclusions.js","sourceRoot":"","sources":["../../src/migrations/ensure-audit-ignore-local-exclusions.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,IAAI,MAAM,WAAW,CAAC;AAClC,OAAO,KAAK,GAAG,MAAM,UAAU,CAAC;AAEhC,OAAO,EAAE,QAAQ,EAAE,cAAc,EAAE,SAAS,EAAE,MAAM,wBAAwB,CAAC;AAO7E,MAAM,YAAY,GAAG,0BAA0B,CAAC;AAChD,MAAM,WAAW,GAAG,yBAAyB,CAAC;AAwB9C;;;GAGG;AACH,MAAM,iBAAiB,GAA2B;IAChD,YAAY;IACZ,MAAM;IACN,KAAK;IACL,QAAQ;IACR,aAAa;CACd,CAAC;AAEF;;;;;;;;;GASG;AACH,KAAK,UAAU,sBAAsB,CACnC,OAAe,EACf,aAAqC;IAErC,KAAK,MAAM,IAAI,IAAI,iBAAiB,EAAE,CAAC;QACrC,IAAI,CAAC,aAAa,CAAC,QAAQ,CAAC,IAAI,CAAC,EAAE,CAAC;YAClC,SAAS;QACX,CAAC;QACD,MAAM,SAAS,GAAG,IAAI,CAAC,IAAI,CAAC,OAAO,EAAE,IAAI,EAAE,gBAAgB,EAAE,YAAY,CAAC,CAAC;QAC3E,IAAI,MAAM,GAAG,CAAC,UAAU,CAAC,SAAS,CAAC,EAAE,CAAC;YACpC,OAAO,SAAS,CAAC;QACnB,CAAC;IACH,CAAC;IACD,OAAO,IAAI,CAAC;AACd,CAAC;AAED;;;;;GAKG;AACH,SAAS,UAAU,CAAC,IAA4B;IAC9C,IAAI,CAAC,IAAI,IAAI,CAAC,KAAK,CAAC,OAAO,CAAC,IAAI,CAAC,UAAU,CAAC,EAAE,CAAC;QAC7C,OAAO,IAAI,GAAG,EAAE,CAAC;IACnB,CAAC;IACD,MAAM,GAAG,GAAG,IAAI,CAAC,UAAU;SACxB,GAAG,CAAC,KAAK,CAAC,EAAE,CAAC,KAAK,CAAC,EAAE,CAAC;SACtB,MAAM,CAAC,CAAC,EAAE,EAAgB,EAAE,CAAC,OAAO,EAAE,KAAK,QAAQ,IAAI,EAAE,CAAC,MAAM,GAAG,CAAC,CAAC,CAAC;IACzE,OAAO,IAAI,GAAG,CAAC,GAAG,CAAC,CAAC;AACtB,CAAC;AAED;;;;;;GAMG;AACH,KAAK,UAAU,aAAa,CAAI,QAAgB;IAC9C,IAAI,CAAC,CAAC,MAAM,GAAG,CAAC,UAAU,CAAC,QAAQ,CAAC,CAAC,EAAE,CAAC;QACtC,OAAO,IAAI,CAAC;IACd,CAAC;IACD,OAAO,QAAQ,CAAI,QAAQ,CAAC,CAAC;AAC/B,CAAC;AAED;;;;;;;;;;;;;;GAcG;AACH,MAAM,OAAO,yCAAyC;IAC3C,IAAI,GAAG,sCAAsC,CAAC;IAC9C,WAAW,GAClB,uGAAuG,CAAC;IAElG,QAAQ,GAAyB,EAAE,CAAC;IAE5C;;;;;;;;;;;;OAYG;IACH,KAAK,CAAC,gBAAgB,CAAC,GAAqB;QAC1C,IAAI,CAAC,QAAQ,GAAG,EAAE,CAAC;QAEnB,MAAM,iBAAiB,GAAG,IAAI,CAAC,IAAI,CAAC,GAAG,CAAC,UAAU,EAAE,YAAY,CAAC,CAAC;QAClE,MAAM,aAAa,GACjB,MAAM,cAAc,CAAkB,iBAAiB,CAAC,CAAC;QAC3D,IAAI,CAAC,aAAa,IAAI,CAAC,KAAK,CAAC,OAAO,CAAC,aAAa,CAAC,UAAU,CAAC,EAAE,CAAC;YAC/D,OAAO;QACT,CAAC;QAED,MAAM,YAAY,GAAG,MAAM,sBAAsB,CAC/C,GAAG,CAAC,OAAO,EACX,GAAG,CAAC,aAAa,CAClB,CAAC;QACF,MAAM,QAAQ,GAAG,YAAY;YAC3B,CAAC,CAAC,MAAM,cAAc,CAAkB,YAAY,CAAC;YACrD,CAAC,CAAC,IAAI,CAAC;QAET,IAAI,CAAC,QAAQ,EAAE,CAAC;YACd,OAAO;QACT,CAAC;QAED,MAAM,WAAW,GAAG,UAAU,CAAC,QAAQ,CAAC,CAAC;QAEzC,MAAM,eAAe,GAAG,aAAa,CAAC,UAAU,CAAC,MAAM,CAAC,KAAK,CAAC,EAAE;YAC9D,IAAI,OAAO,KAAK,CAAC,EAAE,KAAK,QAAQ,IAAI,KAAK,CAAC,EAAE,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;gBAC1D,OAAO,KAAK,CAAC;YACf,CAAC;YACD,OAAO,CAAC,WAAW,CAAC,GAAG,CAAC,KAAK,CAAC,EAAE,CAAC,CAAC;QACpC,CAAC,CAAC,CAAC;QAEH,IAAI,CAAC,QAAQ,GAAG,eAAe,CAAC;IAClC,CAAC;IAED;;;;;OAKG;IACH,KAAK,CAAC,OAAO,CAAC,GAAqB;QACjC,IAAI,IAAI,CAAC,QAAQ,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;YAC/B,OAAO,KAAK,CAAC;QACf,CAAC;QACD,MAAM,SAAS,GAAG,IAAI,CAAC,IAAI,CAAC,GAAG,CAAC,UAAU,EAAE,WAAW,CAAC,CAAC;QACzD,MAAM,KAAK,GAAG,MAAM,aAAa,CAAkB,SAAS,CAAC,CAAC;QAC9D,MAAM,QAAQ,GAAG,UAAU,CAAC,KAAK,CAAC,CAAC;QACnC,OAAO,IAAI,CAAC,QAAQ,CAAC,IAAI,CAAC,KAAK,CAAC,EAAE;YAChC,MAAM,EAAE,GAAG,KAAK,CAAC,EAAE,CAAC;YACpB,OAAO,OAAO,EAAE,KAAK,QAAQ,IAAI,CAAC,QAAQ,CAAC,GAAG,CAAC,EAAE,CAAC,CAAC;QACrD,CAAC,CAAC,CAAC;IACL,CAAC;IAED;;;;;;OAMG;IACH,KAAK,CAAC,KAAK,CAAC,GAAqB;QAC/B,MAAM,SAAS,GAAG,IAAI,CAAC,IAAI,CAAC,GAAG,CAAC,UAAU,EAAE,WAAW,CAAC,CAAC;QACzD,MAAM,KAAK,GAAG,MAAM,aAAa,CAAkB,SAAS,CAAC,CAAC;QAC9D,MAAM,QAAQ,GAAG,KAAK,CAAC,OAAO,CAAC,KAAK,EAAE,UAAU,CAAC,CAAC,CAAC,CAAC,KAAK,CAAC,UAAU,CAAC,CAAC,CAAC,EAAE,CAAC;QAC1E,MAAM,QAAQ,GAAG,UAAU,CAAC,KAAK,CAAC,CAAC;QAEnC,MAAM,OAAO,GAAG,IAAI,GAAG,CAAC,QAAQ,CAAC,CAAC;QAClC,MAAM,SAAS,GAAG,IAAI,CAAC,QAAQ,CAAC,MAAM,CAAC,KAAK,CAAC,EAAE;YAC7C,MAAM,EAAE,GAAG,KAAK,CAAC,EAAE,CAAC;YACpB,IAAI,OAAO,EAAE,KAAK,QAAQ,IAAI,OAAO,CAAC,GAAG,CAAC,EAAE,CAAC,EAAE,CAAC;gBAC9C,OAAO,KAAK,CAAC;YACf,CAAC;YACD,OAAO,CAAC,GAAG,CAAC,EAAE,CAAC,CAAC;YAChB,OAAO,IAAI,CAAC;QACd,CAAC,CAAC,CAAC;QAEH,IAAI,SAAS,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;YAC3B,OAAO,EAAE,IAAI,EAAE,IAAI,CAAC,IAAI,EAAE,MAAM,EAAE,MAAM,EAAE,CAAC;QAC7C,CAAC;QAED,MAAM,MAAM,GAAoB;YAC9B,GAAG,CAAC,KAAK,IAAI,EAAE,CAAC;YAChB,UAAU,EAAE,CAAC,GAAG,QAAQ,EAAE,GAAG,SAAS,CAAC;SACxC,CAAC;QAEF,MAAM,QAAQ,GAAG,SAAS;aACvB,GAAG,CAAC,KAAK,CAAC,EAAE,CAAC,KAAK,CAAC,EAAE,CAAC;aACtB,MAAM,CAAC,CAAC,EAAE,EAAgB,EAAE,CAAC,OAAO,EAAE,KAAK,QAAQ,CAAC,CAAC;QACxD,MAAM,OAAO,GAAG,aAAa,SAAS,CAAC,MAAM,+CAA+C,QAAQ,CAAC,IAAI,CAAC,IAAI,CAAC,GAAG,CAAC;QAEnH,IAAI,GAAG,CAAC,MAAM,EAAE,CAAC;YACf,GAAG,CAAC,MAAM,CAAC,GAAG,CAAC,8BAA8B,QAAQ,CAAC,IAAI,CAAC,IAAI,CAAC,EAAE,CAAC,CAAC;YACpE,OAAO;gBACL,IAAI,EAAE,IAAI,CAAC,IAAI;gBACf,MAAM,EAAE,SAAS;gBACjB,YAAY,EAAE,CAAC,WAAW,CAAC;gBAC3B,OAAO;aACR,CAAC;QACJ,CAAC;QAED,MAAM,GAAG,CAAC,SAAS,CAAC,IAAI,CAAC,OAAO,CAAC,SAAS,CAAC,CAAC,CAAC;QAC7C,MAAM,SAAS,CAAC,SAAS,EAAE,MAAM,CAAC,CAAC;QACnC,GAAG,CAAC,MAAM,CAAC,OAAO,CAAC,OAAO,CAAC,CAAC;QAC5B,OAAO;YACL,IAAI,EAAE,IAAI,CAAC,IAAI;YACf,MAAM,EAAE,SAAS;YACjB,YAAY,EAAE,CAAC,WAAW,CAAC;YAC3B,OAAO;SACR,CAAC;IACJ,CAAC;CACF"}
|
package/package.json
CHANGED
|
@@ -91,7 +91,7 @@
|
|
|
91
91
|
"ws": ">=8.20.1"
|
|
92
92
|
},
|
|
93
93
|
"name": "@codyswann/lisa",
|
|
94
|
-
"version": "2.175.
|
|
94
|
+
"version": "2.175.3",
|
|
95
95
|
"description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
|
|
96
96
|
"main": "dist/index.js",
|
|
97
97
|
"exports": {
|
|
@@ -1,35 +1,40 @@
|
|
|
1
1
|
# Security Audit Handling (load-bearing)
|
|
2
2
|
|
|
3
|
-
If `git push` fails because the pre-push hook reports security vulnerabilities,
|
|
3
|
+
If `git push` fails because the pre-push hook reports security vulnerabilities, work the decision ladder below **autonomously**. Do not stop to ask the user except at the one rung that explicitly requires it. **Never use `--no-verify`**, `HUSKY=0`, `core.hooksPath`, or any other hook bypass to skip the security audit.
|
|
4
4
|
|
|
5
|
-
##
|
|
5
|
+
## Decision ladder (do not skip rungs)
|
|
6
6
|
|
|
7
|
-
|
|
8
|
-
2. Only if no safe fix exists, ask the user to make the risk-acceptance decision. Add a narrow documented ignore for the specific advisory, package, and reason.
|
|
9
|
-
3. Never add a blanket audit bypass, lower an audit level, or self-approve a new risk-acceptance entry.
|
|
7
|
+
For each high/critical advisory the gate reports, take the **first** action that is possible:
|
|
10
8
|
|
|
11
|
-
|
|
9
|
+
1. **Update the offending package.** Upgrade the actually-vulnerable leaf package to a patched compatible version, regenerate the lockfile, retry the gate. Done.
|
|
10
|
+
2. **If an upgrade isn't possible** (no compatible patched version on the dependency graph): **force a resolution/override** on the vulnerable leaf package (both `resolutions` and `overrides`), regenerate the lockfile, retry. Done.
|
|
11
|
+
3. **If an override isn't possible either** (would break a dependent, or no fixed version exists anywhere): **evaluate whether the advisory actually affects this project** — is the vulnerable code path reachable, does it process untrusted input, is it runtime vs. dev/build-only?
|
|
12
|
+
4. **If it does affect the project** and neither (1) nor (2) was possible: **ask a human** what to do. This is the only rung that pauses for a person.
|
|
13
|
+
5. **If it does not affect the project**: **add a documented exclusion yourself** to `audit.ignore.local.json` (`{"id", "package", "reason"}` — reason states the impact evaluation), commit, retry. No human approval needed.
|
|
14
|
+
|
|
15
|
+
Steps 1, 2, 3, and 5 are autonomous. Only step 4 escalates.
|
|
16
|
+
|
|
17
|
+
## Core override rule
|
|
12
18
|
|
|
13
19
|
Override the actually-vulnerable **leaf package**, not its parent. The audit chain shows `parent › intermediate › vulnerable` — only the vulnerable leaf needs the override.
|
|
14
20
|
|
|
15
21
|
**Never override a parent package to force a lower major version.** Other packages may depend on the newer major; a forced downgrade breaks them.
|
|
16
22
|
|
|
17
|
-
Before adding any override, verify:
|
|
23
|
+
Before adding any override (step 2), verify:
|
|
18
24
|
- You are targeting the actually-vulnerable package, not a parent in the chain.
|
|
19
25
|
- The override is compatible with all dependents (check via `bun why <pkg>` or `npm ls <pkg>`).
|
|
20
26
|
- The override does not downgrade across a major version boundary other deps require.
|
|
21
27
|
|
|
22
|
-
|
|
28
|
+
If those checks fail, the override is "not possible" — drop to step 3.
|
|
29
|
+
|
|
30
|
+
## Never
|
|
23
31
|
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
32
|
+
- Never add a blanket audit bypass or lower the configured audit level.
|
|
33
|
+
- Never escalate to a human (step 4) before genuinely attempting steps 1–3.
|
|
34
|
+
- Never add an ignore entry (step 5) without an impact evaluation recorded in its `reason`. (This is a policy requirement enforced by convention. The `reason` field is not programmatically validated by Lisa tooling, so its presence relies on Claude following this rule faithfully.)
|
|
27
35
|
|
|
28
36
|
## Rails (bundler-audit)
|
|
29
37
|
|
|
30
|
-
|
|
31
|
-
2. If direct dep with patch: update Gemfile constraint, `bundle update <gem>`, commit, retry.
|
|
32
|
-
3. If transitive with patch: `bundle update <gem>` to bump the lockfile only, commit, retry.
|
|
33
|
-
4. If no patch but safe: document the exception, retry.
|
|
38
|
+
Same ladder. Note advisory ID, gem, URL. (1) Direct dep with patch → update Gemfile constraint, `bundle update <gem>`, retry. (2) Transitive with patch → `bundle update <gem>` to bump the lockfile only, retry. (3) No patch → evaluate impact. (4) Affects the project → ask a human. (5) Doesn't affect → document the exception, retry.
|
|
34
39
|
|
|
35
40
|
Full procedure with examples: [reference/security-audit-handling.md](../reference/security-audit-handling.md).
|
|
@@ -1,19 +1,28 @@
|
|
|
1
1
|
# Security Audit Handling
|
|
2
2
|
|
|
3
|
-
If `git push` fails because the pre-push hook reports security vulnerabilities,
|
|
3
|
+
If `git push` fails because the pre-push hook reports security vulnerabilities, work the decision ladder below **autonomously**. Only one rung pauses to ask a human. Never use `--no-verify`, `HUSKY=0`, `core.hooksPath`, or any other hook bypass to skip the security audit.
|
|
4
4
|
|
|
5
|
-
##
|
|
5
|
+
## The decision ladder
|
|
6
6
|
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
7
|
+
The remediation for any high/critical advisory is a simple, ordered decision — not a question to forward to the user. For each advisory, take the **first** action that is possible:
|
|
8
|
+
|
|
9
|
+
1. **Update the offending package** to a patched version.
|
|
10
|
+
2. **If that's not possible**, force a resolution/override on the vulnerable leaf package.
|
|
11
|
+
3. **If that's not possible**, evaluate whether the advisory actually affects the project.
|
|
12
|
+
4. **If it affects the project** (and 1 and 2 weren't possible), ask a human what to do.
|
|
13
|
+
5. **If it doesn't affect the project**, add it to the ignore list yourself.
|
|
14
|
+
|
|
15
|
+
Steps 1, 2, 3, and 5 are autonomous. Do not stop and ask the user except at step 4, and only after you have genuinely attempted steps 1 and 2 and performed the step-3 evaluation.
|
|
10
16
|
|
|
11
17
|
## Node.js Projects (GHSA advisories)
|
|
12
18
|
|
|
13
|
-
1. Note the GHSA ID(s), affected package(s), and advisory URL from the error output
|
|
14
|
-
2. Check the advisory URL to determine
|
|
15
|
-
3. If a patched version exists
|
|
16
|
-
4.
|
|
19
|
+
1. Note the GHSA ID(s), affected package(s), and advisory URL from the error output.
|
|
20
|
+
2. Check the advisory URL to determine whether a patched version of the vulnerable package exists.
|
|
21
|
+
3. **Step 1 — update:** If a patched version exists and is compatible, add a resolution/override in `package.json` to force the patched version (add to **both** `resolutions` and `overrides`), run the package manager install to regenerate the lockfile, commit, and retry the push.
|
|
22
|
+
4. **Step 2 — force override:** If no straight upgrade lands the patched version but a compatible patched version exists somewhere on the graph, pin it via `resolutions` + `overrides` on the **leaf** package (see "Override the vulnerable package, not its parent" below), regenerate the lockfile, commit, and retry.
|
|
23
|
+
5. **Step 3 — evaluate impact:** If neither an upgrade nor an override is possible (no fixed version exists, or every compatible pin breaks a dependent), determine whether the vulnerability actually affects this project. Consider: is the vulnerable code path reachable from this project's usage? Does it process untrusted input? Is the dependency runtime, or dev/build-only? Record the conclusion.
|
|
24
|
+
6. **Step 4 — escalate:** If the evaluation shows the vulnerability **does** affect the project and neither step 1 nor step 2 was possible, ask the user what to do. This is the only step that pauses for a human.
|
|
25
|
+
7. **Step 5 — ignore:** If the evaluation shows the vulnerability **does not** affect the project, add an exclusion entry to `audit.ignore.local.json` yourself, in the format `{"id": "GHSA-xxx", "package": "pkg-name", "reason": "<impact evaluation: why this advisory does not affect this project>"}`, then commit and retry the push. No human approval is required for this step — the `reason` field is the record of your evaluation.
|
|
17
26
|
|
|
18
27
|
### Critical: Override the vulnerable package, not its parent
|
|
19
28
|
|
|
@@ -21,16 +30,26 @@ When the audit output shows a dependency chain like `@expo/cli › glob › mini
|
|
|
21
30
|
|
|
22
31
|
**Never override a parent package to force a lower major version** — other packages in the project may depend on a newer major version, and a resolution/override forces ALL installations to the specified version. For example, overriding `glob` to `^8.1.0` will break `@expo/cli` which requires `glob@^13.0.0`, causing `expo prebuild` to fail with `files.map is not a function`.
|
|
23
32
|
|
|
24
|
-
Before adding a resolution/override, verify:
|
|
25
|
-
- You are targeting the **actually vulnerable package**, not a parent in the chain
|
|
26
|
-
- The override version is **compatible with all dependents** (check with `bun why <package>` or `npm ls <package>`)
|
|
27
|
-
- The override does not **downgrade** a package across a major version boundary that other dependencies require
|
|
33
|
+
Before adding a resolution/override (step 2), verify:
|
|
34
|
+
- You are targeting the **actually vulnerable package**, not a parent in the chain.
|
|
35
|
+
- The override version is **compatible with all dependents** (check with `bun why <package>` or `npm ls <package>`).
|
|
36
|
+
- The override does not **downgrade** a package across a major version boundary that other dependencies require.
|
|
37
|
+
|
|
38
|
+
If any of these checks fail, the override is "not possible" for the purposes of the ladder — drop to step 3 (evaluate impact).
|
|
39
|
+
|
|
40
|
+
### Never
|
|
41
|
+
|
|
42
|
+
- Never add a blanket audit bypass or lower the configured audit level.
|
|
43
|
+
- Never jump to step 4 (ask a human) before genuinely attempting steps 1–3.
|
|
44
|
+
- Never add a step-5 ignore entry without an impact evaluation recorded in its `reason`.
|
|
28
45
|
|
|
29
46
|
## Rails Projects (bundler-audit)
|
|
30
47
|
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
48
|
+
Same ladder, bundler mechanics:
|
|
49
|
+
|
|
50
|
+
1. Note the advisory ID, affected gem, and advisory URL from the error output.
|
|
51
|
+
2. Check whether a patched version of the gem exists.
|
|
52
|
+
3. **Step 1 — update:** If a patched version exists:
|
|
53
|
+
- **Direct dependency** (in Gemfile): update its version constraint, run `bundle update <gem>`, commit, retry.
|
|
54
|
+
- **Transitive dependency** (only in Gemfile.lock): run `bundle update <gem>` to pull the patched version without changing the Gemfile, commit the lockfile change, retry.
|
|
55
|
+
4. **Steps 3–5 — no patch:** If no patched version exists, evaluate whether the advisory affects the project. If it **does** and no fix is possible, ask the user (step 4). If it **does not**, document the exception and retry (step 5).
|
|
@@ -1,35 +1,40 @@
|
|
|
1
1
|
# Security Audit Handling (load-bearing)
|
|
2
2
|
|
|
3
|
-
If `git push` fails because the pre-push hook reports security vulnerabilities,
|
|
3
|
+
If `git push` fails because the pre-push hook reports security vulnerabilities, work the decision ladder below **autonomously**. Do not stop to ask the user except at the one rung that explicitly requires it. **Never use `--no-verify`**, `HUSKY=0`, `core.hooksPath`, or any other hook bypass to skip the security audit.
|
|
4
4
|
|
|
5
|
-
##
|
|
5
|
+
## Decision ladder (do not skip rungs)
|
|
6
6
|
|
|
7
|
-
|
|
8
|
-
2. Only if no safe fix exists, ask the user to make the risk-acceptance decision. Add a narrow documented ignore for the specific advisory, package, and reason.
|
|
9
|
-
3. Never add a blanket audit bypass, lower an audit level, or self-approve a new risk-acceptance entry.
|
|
7
|
+
For each high/critical advisory the gate reports, take the **first** action that is possible:
|
|
10
8
|
|
|
11
|
-
|
|
9
|
+
1. **Update the offending package.** Upgrade the actually-vulnerable leaf package to a patched compatible version, regenerate the lockfile, retry the gate. Done.
|
|
10
|
+
2. **If an upgrade isn't possible** (no compatible patched version on the dependency graph): **force a resolution/override** on the vulnerable leaf package (both `resolutions` and `overrides`), regenerate the lockfile, retry. Done.
|
|
11
|
+
3. **If an override isn't possible either** (would break a dependent, or no fixed version exists anywhere): **evaluate whether the advisory actually affects this project** — is the vulnerable code path reachable, does it process untrusted input, is it runtime vs. dev/build-only?
|
|
12
|
+
4. **If it does affect the project** and neither (1) nor (2) was possible: **ask a human** what to do. This is the only rung that pauses for a person.
|
|
13
|
+
5. **If it does not affect the project**: **add a documented exclusion yourself** to `audit.ignore.local.json` (`{"id", "package", "reason"}` — reason states the impact evaluation), commit, retry. No human approval needed.
|
|
14
|
+
|
|
15
|
+
Steps 1, 2, 3, and 5 are autonomous. Only step 4 escalates.
|
|
16
|
+
|
|
17
|
+
## Core override rule
|
|
12
18
|
|
|
13
19
|
Override the actually-vulnerable **leaf package**, not its parent. The audit chain shows `parent › intermediate › vulnerable` — only the vulnerable leaf needs the override.
|
|
14
20
|
|
|
15
21
|
**Never override a parent package to force a lower major version.** Other packages may depend on the newer major; a forced downgrade breaks them.
|
|
16
22
|
|
|
17
|
-
Before adding any override, verify:
|
|
23
|
+
Before adding any override (step 2), verify:
|
|
18
24
|
- You are targeting the actually-vulnerable package, not a parent in the chain.
|
|
19
25
|
- The override is compatible with all dependents (check via `bun why <pkg>` or `npm ls <pkg>`).
|
|
20
26
|
- The override does not downgrade across a major version boundary other deps require.
|
|
21
27
|
|
|
22
|
-
|
|
28
|
+
If those checks fail, the override is "not possible" — drop to step 3.
|
|
29
|
+
|
|
30
|
+
## Never
|
|
23
31
|
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
32
|
+
- Never add a blanket audit bypass or lower the configured audit level.
|
|
33
|
+
- Never escalate to a human (step 4) before genuinely attempting steps 1–3.
|
|
34
|
+
- Never add an ignore entry (step 5) without an impact evaluation recorded in its `reason`. (This is a policy requirement enforced by convention. The `reason` field is not programmatically validated by Lisa tooling, so its presence relies on Claude following this rule faithfully.)
|
|
27
35
|
|
|
28
36
|
## Rails (bundler-audit)
|
|
29
37
|
|
|
30
|
-
|
|
31
|
-
2. If direct dep with patch: update Gemfile constraint, `bundle update <gem>`, commit, retry.
|
|
32
|
-
3. If transitive with patch: `bundle update <gem>` to bump the lockfile only, commit, retry.
|
|
33
|
-
4. If no patch but safe: document the exception, retry.
|
|
38
|
+
Same ladder. Note advisory ID, gem, URL. (1) Direct dep with patch → update Gemfile constraint, `bundle update <gem>`, retry. (2) Transitive with patch → `bundle update <gem>` to bump the lockfile only, retry. (3) No patch → evaluate impact. (4) Affects the project → ask a human. (5) Doesn't affect → document the exception, retry.
|
|
34
39
|
|
|
35
40
|
Full procedure with examples: [reference/security-audit-handling.md](../reference/security-audit-handling.md).
|
|
@@ -1,19 +1,28 @@
|
|
|
1
1
|
# Security Audit Handling
|
|
2
2
|
|
|
3
|
-
If `git push` fails because the pre-push hook reports security vulnerabilities,
|
|
3
|
+
If `git push` fails because the pre-push hook reports security vulnerabilities, work the decision ladder below **autonomously**. Only one rung pauses to ask a human. Never use `--no-verify`, `HUSKY=0`, `core.hooksPath`, or any other hook bypass to skip the security audit.
|
|
4
4
|
|
|
5
|
-
##
|
|
5
|
+
## The decision ladder
|
|
6
6
|
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
7
|
+
The remediation for any high/critical advisory is a simple, ordered decision — not a question to forward to the user. For each advisory, take the **first** action that is possible:
|
|
8
|
+
|
|
9
|
+
1. **Update the offending package** to a patched version.
|
|
10
|
+
2. **If that's not possible**, force a resolution/override on the vulnerable leaf package.
|
|
11
|
+
3. **If that's not possible**, evaluate whether the advisory actually affects the project.
|
|
12
|
+
4. **If it affects the project** (and 1 and 2 weren't possible), ask a human what to do.
|
|
13
|
+
5. **If it doesn't affect the project**, add it to the ignore list yourself.
|
|
14
|
+
|
|
15
|
+
Steps 1, 2, 3, and 5 are autonomous. Do not stop and ask the user except at step 4, and only after you have genuinely attempted steps 1 and 2 and performed the step-3 evaluation.
|
|
10
16
|
|
|
11
17
|
## Node.js Projects (GHSA advisories)
|
|
12
18
|
|
|
13
|
-
1. Note the GHSA ID(s), affected package(s), and advisory URL from the error output
|
|
14
|
-
2. Check the advisory URL to determine
|
|
15
|
-
3. If a patched version exists
|
|
16
|
-
4.
|
|
19
|
+
1. Note the GHSA ID(s), affected package(s), and advisory URL from the error output.
|
|
20
|
+
2. Check the advisory URL to determine whether a patched version of the vulnerable package exists.
|
|
21
|
+
3. **Step 1 — update:** If a patched version exists and is compatible, add a resolution/override in `package.json` to force the patched version (add to **both** `resolutions` and `overrides`), run the package manager install to regenerate the lockfile, commit, and retry the push.
|
|
22
|
+
4. **Step 2 — force override:** If no straight upgrade lands the patched version but a compatible patched version exists somewhere on the graph, pin it via `resolutions` + `overrides` on the **leaf** package (see "Override the vulnerable package, not its parent" below), regenerate the lockfile, commit, and retry.
|
|
23
|
+
5. **Step 3 — evaluate impact:** If neither an upgrade nor an override is possible (no fixed version exists, or every compatible pin breaks a dependent), determine whether the vulnerability actually affects this project. Consider: is the vulnerable code path reachable from this project's usage? Does it process untrusted input? Is the dependency runtime, or dev/build-only? Record the conclusion.
|
|
24
|
+
6. **Step 4 — escalate:** If the evaluation shows the vulnerability **does** affect the project and neither step 1 nor step 2 was possible, ask the user what to do. This is the only step that pauses for a human.
|
|
25
|
+
7. **Step 5 — ignore:** If the evaluation shows the vulnerability **does not** affect the project, add an exclusion entry to `audit.ignore.local.json` yourself, in the format `{"id": "GHSA-xxx", "package": "pkg-name", "reason": "<impact evaluation: why this advisory does not affect this project>"}`, then commit and retry the push. No human approval is required for this step — the `reason` field is the record of your evaluation.
|
|
17
26
|
|
|
18
27
|
### Critical: Override the vulnerable package, not its parent
|
|
19
28
|
|
|
@@ -21,16 +30,26 @@ When the audit output shows a dependency chain like `@expo/cli › glob › mini
|
|
|
21
30
|
|
|
22
31
|
**Never override a parent package to force a lower major version** — other packages in the project may depend on a newer major version, and a resolution/override forces ALL installations to the specified version. For example, overriding `glob` to `^8.1.0` will break `@expo/cli` which requires `glob@^13.0.0`, causing `expo prebuild` to fail with `files.map is not a function`.
|
|
23
32
|
|
|
24
|
-
Before adding a resolution/override, verify:
|
|
25
|
-
- You are targeting the **actually vulnerable package**, not a parent in the chain
|
|
26
|
-
- The override version is **compatible with all dependents** (check with `bun why <package>` or `npm ls <package>`)
|
|
27
|
-
- The override does not **downgrade** a package across a major version boundary that other dependencies require
|
|
33
|
+
Before adding a resolution/override (step 2), verify:
|
|
34
|
+
- You are targeting the **actually vulnerable package**, not a parent in the chain.
|
|
35
|
+
- The override version is **compatible with all dependents** (check with `bun why <package>` or `npm ls <package>`).
|
|
36
|
+
- The override does not **downgrade** a package across a major version boundary that other dependencies require.
|
|
37
|
+
|
|
38
|
+
If any of these checks fail, the override is "not possible" for the purposes of the ladder — drop to step 3 (evaluate impact).
|
|
39
|
+
|
|
40
|
+
### Never
|
|
41
|
+
|
|
42
|
+
- Never add a blanket audit bypass or lower the configured audit level.
|
|
43
|
+
- Never jump to step 4 (ask a human) before genuinely attempting steps 1–3.
|
|
44
|
+
- Never add a step-5 ignore entry without an impact evaluation recorded in its `reason`.
|
|
28
45
|
|
|
29
46
|
## Rails Projects (bundler-audit)
|
|
30
47
|
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
48
|
+
Same ladder, bundler mechanics:
|
|
49
|
+
|
|
50
|
+
1. Note the advisory ID, affected gem, and advisory URL from the error output.
|
|
51
|
+
2. Check whether a patched version of the gem exists.
|
|
52
|
+
3. **Step 1 — update:** If a patched version exists:
|
|
53
|
+
- **Direct dependency** (in Gemfile): update its version constraint, run `bundle update <gem>`, commit, retry.
|
|
54
|
+
- **Transitive dependency** (only in Gemfile.lock): run `bundle update <gem>` to pull the patched version without changing the Gemfile, commit the lockfile change, retry.
|
|
55
|
+
4. **Steps 3–5 — no patch:** If no patched version exists, evaluate whether the advisory affects the project. If it **does** and no fix is possible, ask the user (step 4). If it **does not**, document the exception and retry (step 5).
|
|
@@ -5,20 +5,29 @@ alwaysApply: false
|
|
|
5
5
|
|
|
6
6
|
# Security Audit Handling
|
|
7
7
|
|
|
8
|
-
If `git push` fails because the pre-push hook reports security vulnerabilities,
|
|
8
|
+
If `git push` fails because the pre-push hook reports security vulnerabilities, work the decision ladder below **autonomously**. Only one rung pauses to ask a human. Never use `--no-verify`, `HUSKY=0`, `core.hooksPath`, or any other hook bypass to skip the security audit.
|
|
9
9
|
|
|
10
|
-
##
|
|
10
|
+
## The decision ladder
|
|
11
11
|
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
12
|
+
The remediation for any high/critical advisory is a simple, ordered decision — not a question to forward to the user. For each advisory, take the **first** action that is possible:
|
|
13
|
+
|
|
14
|
+
1. **Update the offending package** to a patched version.
|
|
15
|
+
2. **If that's not possible**, force a resolution/override on the vulnerable leaf package.
|
|
16
|
+
3. **If that's not possible**, evaluate whether the advisory actually affects the project.
|
|
17
|
+
4. **If it affects the project** (and 1 and 2 weren't possible), ask a human what to do.
|
|
18
|
+
5. **If it doesn't affect the project**, add it to the ignore list yourself.
|
|
19
|
+
|
|
20
|
+
Steps 1, 2, 3, and 5 are autonomous. Do not stop and ask the user except at step 4, and only after you have genuinely attempted steps 1 and 2 and performed the step-3 evaluation.
|
|
15
21
|
|
|
16
22
|
## Node.js Projects (GHSA advisories)
|
|
17
23
|
|
|
18
|
-
1. Note the GHSA ID(s), affected package(s), and advisory URL from the error output
|
|
19
|
-
2. Check the advisory URL to determine
|
|
20
|
-
3. If a patched version exists
|
|
21
|
-
4.
|
|
24
|
+
1. Note the GHSA ID(s), affected package(s), and advisory URL from the error output.
|
|
25
|
+
2. Check the advisory URL to determine whether a patched version of the vulnerable package exists.
|
|
26
|
+
3. **Step 1 — update:** If a patched version exists and is compatible, add a resolution/override in `package.json` to force the patched version (add to **both** `resolutions` and `overrides`), run the package manager install to regenerate the lockfile, commit, and retry the push.
|
|
27
|
+
4. **Step 2 — force override:** If no straight upgrade lands the patched version but a compatible patched version exists somewhere on the graph, pin it via `resolutions` + `overrides` on the **leaf** package (see "Override the vulnerable package, not its parent" below), regenerate the lockfile, commit, and retry.
|
|
28
|
+
5. **Step 3 — evaluate impact:** If neither an upgrade nor an override is possible (no fixed version exists, or every compatible pin breaks a dependent), determine whether the vulnerability actually affects this project. Consider: is the vulnerable code path reachable from this project's usage? Does it process untrusted input? Is the dependency runtime, or dev/build-only? Record the conclusion.
|
|
29
|
+
6. **Step 4 — escalate:** If the evaluation shows the vulnerability **does** affect the project and neither step 1 nor step 2 was possible, ask the user what to do. This is the only step that pauses for a human.
|
|
30
|
+
7. **Step 5 — ignore:** If the evaluation shows the vulnerability **does not** affect the project, add an exclusion entry to `audit.ignore.local.json` yourself, in the format `{"id": "GHSA-xxx", "package": "pkg-name", "reason": "<impact evaluation: why this advisory does not affect this project>"}`, then commit and retry the push. No human approval is required for this step — the `reason` field is the record of your evaluation.
|
|
22
31
|
|
|
23
32
|
### Critical: Override the vulnerable package, not its parent
|
|
24
33
|
|
|
@@ -26,16 +35,26 @@ When the audit output shows a dependency chain like `@expo/cli › glob › mini
|
|
|
26
35
|
|
|
27
36
|
**Never override a parent package to force a lower major version** — other packages in the project may depend on a newer major version, and a resolution/override forces ALL installations to the specified version. For example, overriding `glob` to `^8.1.0` will break `@expo/cli` which requires `glob@^13.0.0`, causing `expo prebuild` to fail with `files.map is not a function`.
|
|
28
37
|
|
|
29
|
-
Before adding a resolution/override, verify:
|
|
30
|
-
- You are targeting the **actually vulnerable package**, not a parent in the chain
|
|
31
|
-
- The override version is **compatible with all dependents** (check with `bun why <package>` or `npm ls <package>`)
|
|
32
|
-
- The override does not **downgrade** a package across a major version boundary that other dependencies require
|
|
38
|
+
Before adding a resolution/override (step 2), verify:
|
|
39
|
+
- You are targeting the **actually vulnerable package**, not a parent in the chain.
|
|
40
|
+
- The override version is **compatible with all dependents** (check with `bun why <package>` or `npm ls <package>`).
|
|
41
|
+
- The override does not **downgrade** a package across a major version boundary that other dependencies require.
|
|
42
|
+
|
|
43
|
+
If any of these checks fail, the override is "not possible" for the purposes of the ladder — drop to step 3 (evaluate impact).
|
|
44
|
+
|
|
45
|
+
### Never
|
|
46
|
+
|
|
47
|
+
- Never add a blanket audit bypass or lower the configured audit level.
|
|
48
|
+
- Never jump to step 4 (ask a human) before genuinely attempting steps 1–3.
|
|
49
|
+
- Never add a step-5 ignore entry without an impact evaluation recorded in its `reason`.
|
|
33
50
|
|
|
34
51
|
## Rails Projects (bundler-audit)
|
|
35
52
|
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
53
|
+
Same ladder, bundler mechanics:
|
|
54
|
+
|
|
55
|
+
1. Note the advisory ID, affected gem, and advisory URL from the error output.
|
|
56
|
+
2. Check whether a patched version of the gem exists.
|
|
57
|
+
3. **Step 1 — update:** If a patched version exists:
|
|
58
|
+
- **Direct dependency** (in Gemfile): update its version constraint, run `bundle update <gem>`, commit, retry.
|
|
59
|
+
- **Transitive dependency** (only in Gemfile.lock): run `bundle update <gem>` to pull the patched version without changing the Gemfile, commit the lockfile change, retry.
|
|
60
|
+
4. **Steps 3–5 — no patch:** If no patched version exists, evaluate whether the advisory affects the project. If it **does** and no fix is possible, ask the user (step 4). If it **does not**, document the exception and retry (step 5).
|
|
@@ -5,36 +5,41 @@ alwaysApply: true
|
|
|
5
5
|
|
|
6
6
|
# Security Audit Handling (load-bearing)
|
|
7
7
|
|
|
8
|
-
If `git push` fails because the pre-push hook reports security vulnerabilities,
|
|
8
|
+
If `git push` fails because the pre-push hook reports security vulnerabilities, work the decision ladder below **autonomously**. Do not stop to ask the user except at the one rung that explicitly requires it. **Never use `--no-verify`**, `HUSKY=0`, `core.hooksPath`, or any other hook bypass to skip the security audit.
|
|
9
9
|
|
|
10
|
-
##
|
|
10
|
+
## Decision ladder (do not skip rungs)
|
|
11
11
|
|
|
12
|
-
|
|
13
|
-
2. Only if no safe fix exists, ask the user to make the risk-acceptance decision. Add a narrow documented ignore for the specific advisory, package, and reason.
|
|
14
|
-
3. Never add a blanket audit bypass, lower an audit level, or self-approve a new risk-acceptance entry.
|
|
12
|
+
For each high/critical advisory the gate reports, take the **first** action that is possible:
|
|
15
13
|
|
|
16
|
-
|
|
14
|
+
1. **Update the offending package.** Upgrade the actually-vulnerable leaf package to a patched compatible version, regenerate the lockfile, retry the gate. Done.
|
|
15
|
+
2. **If an upgrade isn't possible** (no compatible patched version on the dependency graph): **force a resolution/override** on the vulnerable leaf package (both `resolutions` and `overrides`), regenerate the lockfile, retry. Done.
|
|
16
|
+
3. **If an override isn't possible either** (would break a dependent, or no fixed version exists anywhere): **evaluate whether the advisory actually affects this project** — is the vulnerable code path reachable, does it process untrusted input, is it runtime vs. dev/build-only?
|
|
17
|
+
4. **If it does affect the project** and neither (1) nor (2) was possible: **ask a human** what to do. This is the only rung that pauses for a person.
|
|
18
|
+
5. **If it does not affect the project**: **add a documented exclusion yourself** to `audit.ignore.local.json` (`{"id", "package", "reason"}` — reason states the impact evaluation), commit, retry. No human approval needed.
|
|
19
|
+
|
|
20
|
+
Steps 1, 2, 3, and 5 are autonomous. Only step 4 escalates.
|
|
21
|
+
|
|
22
|
+
## Core override rule
|
|
17
23
|
|
|
18
24
|
Override the actually-vulnerable **leaf package**, not its parent. The audit chain shows `parent › intermediate › vulnerable` — only the vulnerable leaf needs the override.
|
|
19
25
|
|
|
20
26
|
**Never override a parent package to force a lower major version.** Other packages may depend on the newer major; a forced downgrade breaks them.
|
|
21
27
|
|
|
22
|
-
Before adding any override, verify:
|
|
28
|
+
Before adding any override (step 2), verify:
|
|
23
29
|
- You are targeting the actually-vulnerable package, not a parent in the chain.
|
|
24
30
|
- The override is compatible with all dependents (check via `bun why <pkg>` or `npm ls <pkg>`).
|
|
25
31
|
- The override does not downgrade across a major version boundary other deps require.
|
|
26
32
|
|
|
27
|
-
|
|
33
|
+
If those checks fail, the override is "not possible" — drop to step 3.
|
|
34
|
+
|
|
35
|
+
## Never
|
|
28
36
|
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
37
|
+
- Never add a blanket audit bypass or lower the configured audit level.
|
|
38
|
+
- Never escalate to a human (step 4) before genuinely attempting steps 1–3.
|
|
39
|
+
- Never add an ignore entry (step 5) without an impact evaluation recorded in its `reason`. (This is a policy requirement enforced by convention. The `reason` field is not programmatically validated by Lisa tooling, so its presence relies on Claude following this rule faithfully.)
|
|
32
40
|
|
|
33
41
|
## Rails (bundler-audit)
|
|
34
42
|
|
|
35
|
-
|
|
36
|
-
2. If direct dep with patch: update Gemfile constraint, `bundle update <gem>`, commit, retry.
|
|
37
|
-
3. If transitive with patch: `bundle update <gem>` to bump the lockfile only, commit, retry.
|
|
38
|
-
4. If no patch but safe: document the exception, retry.
|
|
43
|
+
Same ladder. Note advisory ID, gem, URL. (1) Direct dep with patch → update Gemfile constraint, `bundle update <gem>`, retry. (2) Transitive with patch → `bundle update <gem>` to bump the lockfile only, retry. (3) No patch → evaluate impact. (4) Affects the project → ask a human. (5) Doesn't affect → document the exception, retry.
|
|
39
44
|
|
|
40
45
|
Full procedure with examples: [reference/security-audit-handling.md](security-audit-handling-reference.mdc).
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "2.175.
|
|
3
|
+
"version": "2.175.3",
|
|
4
4
|
"description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Cody Swann"
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "2.175.
|
|
3
|
+
"version": "2.175.3",
|
|
4
4
|
"description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, across Claude and Codex.",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Cody Swann"
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "2.175.
|
|
3
|
+
"version": "2.175.3",
|
|
4
4
|
"description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Cody Swann"
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "2.175.
|
|
3
|
+
"version": "2.175.3",
|
|
4
4
|
"description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Cody Swann"
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "2.175.
|
|
3
|
+
"version": "2.175.3",
|
|
4
4
|
"description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Cody Swann"
|
|
@@ -1,35 +1,40 @@
|
|
|
1
1
|
# Security Audit Handling (load-bearing)
|
|
2
2
|
|
|
3
|
-
If `git push` fails because the pre-push hook reports security vulnerabilities,
|
|
3
|
+
If `git push` fails because the pre-push hook reports security vulnerabilities, work the decision ladder below **autonomously**. Do not stop to ask the user except at the one rung that explicitly requires it. **Never use `--no-verify`**, `HUSKY=0`, `core.hooksPath`, or any other hook bypass to skip the security audit.
|
|
4
4
|
|
|
5
|
-
##
|
|
5
|
+
## Decision ladder (do not skip rungs)
|
|
6
6
|
|
|
7
|
-
|
|
8
|
-
2. Only if no safe fix exists, ask the user to make the risk-acceptance decision. Add a narrow documented ignore for the specific advisory, package, and reason.
|
|
9
|
-
3. Never add a blanket audit bypass, lower an audit level, or self-approve a new risk-acceptance entry.
|
|
7
|
+
For each high/critical advisory the gate reports, take the **first** action that is possible:
|
|
10
8
|
|
|
11
|
-
|
|
9
|
+
1. **Update the offending package.** Upgrade the actually-vulnerable leaf package to a patched compatible version, regenerate the lockfile, retry the gate. Done.
|
|
10
|
+
2. **If an upgrade isn't possible** (no compatible patched version on the dependency graph): **force a resolution/override** on the vulnerable leaf package (both `resolutions` and `overrides`), regenerate the lockfile, retry. Done.
|
|
11
|
+
3. **If an override isn't possible either** (would break a dependent, or no fixed version exists anywhere): **evaluate whether the advisory actually affects this project** — is the vulnerable code path reachable, does it process untrusted input, is it runtime vs. dev/build-only?
|
|
12
|
+
4. **If it does affect the project** and neither (1) nor (2) was possible: **ask a human** what to do. This is the only rung that pauses for a person.
|
|
13
|
+
5. **If it does not affect the project**: **add a documented exclusion yourself** to `audit.ignore.local.json` (`{"id", "package", "reason"}` — reason states the impact evaluation), commit, retry. No human approval needed.
|
|
14
|
+
|
|
15
|
+
Steps 1, 2, 3, and 5 are autonomous. Only step 4 escalates.
|
|
16
|
+
|
|
17
|
+
## Core override rule
|
|
12
18
|
|
|
13
19
|
Override the actually-vulnerable **leaf package**, not its parent. The audit chain shows `parent › intermediate › vulnerable` — only the vulnerable leaf needs the override.
|
|
14
20
|
|
|
15
21
|
**Never override a parent package to force a lower major version.** Other packages may depend on the newer major; a forced downgrade breaks them.
|
|
16
22
|
|
|
17
|
-
Before adding any override, verify:
|
|
23
|
+
Before adding any override (step 2), verify:
|
|
18
24
|
- You are targeting the actually-vulnerable package, not a parent in the chain.
|
|
19
25
|
- The override is compatible with all dependents (check via `bun why <pkg>` or `npm ls <pkg>`).
|
|
20
26
|
- The override does not downgrade across a major version boundary other deps require.
|
|
21
27
|
|
|
22
|
-
|
|
28
|
+
If those checks fail, the override is "not possible" — drop to step 3.
|
|
29
|
+
|
|
30
|
+
## Never
|
|
23
31
|
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
32
|
+
- Never add a blanket audit bypass or lower the configured audit level.
|
|
33
|
+
- Never escalate to a human (step 4) before genuinely attempting steps 1–3.
|
|
34
|
+
- Never add an ignore entry (step 5) without an impact evaluation recorded in its `reason`. (This is a policy requirement enforced by convention. The `reason` field is not programmatically validated by Lisa tooling, so its presence relies on Claude following this rule faithfully.)
|
|
27
35
|
|
|
28
36
|
## Rails (bundler-audit)
|
|
29
37
|
|
|
30
|
-
|
|
31
|
-
2. If direct dep with patch: update Gemfile constraint, `bundle update <gem>`, commit, retry.
|
|
32
|
-
3. If transitive with patch: `bundle update <gem>` to bump the lockfile only, commit, retry.
|
|
33
|
-
4. If no patch but safe: document the exception, retry.
|
|
38
|
+
Same ladder. Note advisory ID, gem, URL. (1) Direct dep with patch → update Gemfile constraint, `bundle update <gem>`, retry. (2) Transitive with patch → `bundle update <gem>` to bump the lockfile only, retry. (3) No patch → evaluate impact. (4) Affects the project → ask a human. (5) Doesn't affect → document the exception, retry.
|
|
34
39
|
|
|
35
40
|
Full procedure with examples: [reference/security-audit-handling.md](../reference/security-audit-handling.md).
|
|
@@ -1,19 +1,28 @@
|
|
|
1
1
|
# Security Audit Handling
|
|
2
2
|
|
|
3
|
-
If `git push` fails because the pre-push hook reports security vulnerabilities,
|
|
3
|
+
If `git push` fails because the pre-push hook reports security vulnerabilities, work the decision ladder below **autonomously**. Only one rung pauses to ask a human. Never use `--no-verify`, `HUSKY=0`, `core.hooksPath`, or any other hook bypass to skip the security audit.
|
|
4
4
|
|
|
5
|
-
##
|
|
5
|
+
## The decision ladder
|
|
6
6
|
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
7
|
+
The remediation for any high/critical advisory is a simple, ordered decision — not a question to forward to the user. For each advisory, take the **first** action that is possible:
|
|
8
|
+
|
|
9
|
+
1. **Update the offending package** to a patched version.
|
|
10
|
+
2. **If that's not possible**, force a resolution/override on the vulnerable leaf package.
|
|
11
|
+
3. **If that's not possible**, evaluate whether the advisory actually affects the project.
|
|
12
|
+
4. **If it affects the project** (and 1 and 2 weren't possible), ask a human what to do.
|
|
13
|
+
5. **If it doesn't affect the project**, add it to the ignore list yourself.
|
|
14
|
+
|
|
15
|
+
Steps 1, 2, 3, and 5 are autonomous. Do not stop and ask the user except at step 4, and only after you have genuinely attempted steps 1 and 2 and performed the step-3 evaluation.
|
|
10
16
|
|
|
11
17
|
## Node.js Projects (GHSA advisories)
|
|
12
18
|
|
|
13
|
-
1. Note the GHSA ID(s), affected package(s), and advisory URL from the error output
|
|
14
|
-
2. Check the advisory URL to determine
|
|
15
|
-
3. If a patched version exists
|
|
16
|
-
4.
|
|
19
|
+
1. Note the GHSA ID(s), affected package(s), and advisory URL from the error output.
|
|
20
|
+
2. Check the advisory URL to determine whether a patched version of the vulnerable package exists.
|
|
21
|
+
3. **Step 1 — update:** If a patched version exists and is compatible, add a resolution/override in `package.json` to force the patched version (add to **both** `resolutions` and `overrides`), run the package manager install to regenerate the lockfile, commit, and retry the push.
|
|
22
|
+
4. **Step 2 — force override:** If no straight upgrade lands the patched version but a compatible patched version exists somewhere on the graph, pin it via `resolutions` + `overrides` on the **leaf** package (see "Override the vulnerable package, not its parent" below), regenerate the lockfile, commit, and retry.
|
|
23
|
+
5. **Step 3 — evaluate impact:** If neither an upgrade nor an override is possible (no fixed version exists, or every compatible pin breaks a dependent), determine whether the vulnerability actually affects this project. Consider: is the vulnerable code path reachable from this project's usage? Does it process untrusted input? Is the dependency runtime, or dev/build-only? Record the conclusion.
|
|
24
|
+
6. **Step 4 — escalate:** If the evaluation shows the vulnerability **does** affect the project and neither step 1 nor step 2 was possible, ask the user what to do. This is the only step that pauses for a human.
|
|
25
|
+
7. **Step 5 — ignore:** If the evaluation shows the vulnerability **does not** affect the project, add an exclusion entry to `audit.ignore.local.json` yourself, in the format `{"id": "GHSA-xxx", "package": "pkg-name", "reason": "<impact evaluation: why this advisory does not affect this project>"}`, then commit and retry the push. No human approval is required for this step — the `reason` field is the record of your evaluation.
|
|
17
26
|
|
|
18
27
|
### Critical: Override the vulnerable package, not its parent
|
|
19
28
|
|
|
@@ -21,16 +30,26 @@ When the audit output shows a dependency chain like `@expo/cli › glob › mini
|
|
|
21
30
|
|
|
22
31
|
**Never override a parent package to force a lower major version** — other packages in the project may depend on a newer major version, and a resolution/override forces ALL installations to the specified version. For example, overriding `glob` to `^8.1.0` will break `@expo/cli` which requires `glob@^13.0.0`, causing `expo prebuild` to fail with `files.map is not a function`.
|
|
23
32
|
|
|
24
|
-
Before adding a resolution/override, verify:
|
|
25
|
-
- You are targeting the **actually vulnerable package**, not a parent in the chain
|
|
26
|
-
- The override version is **compatible with all dependents** (check with `bun why <package>` or `npm ls <package>`)
|
|
27
|
-
- The override does not **downgrade** a package across a major version boundary that other dependencies require
|
|
33
|
+
Before adding a resolution/override (step 2), verify:
|
|
34
|
+
- You are targeting the **actually vulnerable package**, not a parent in the chain.
|
|
35
|
+
- The override version is **compatible with all dependents** (check with `bun why <package>` or `npm ls <package>`).
|
|
36
|
+
- The override does not **downgrade** a package across a major version boundary that other dependencies require.
|
|
37
|
+
|
|
38
|
+
If any of these checks fail, the override is "not possible" for the purposes of the ladder — drop to step 3 (evaluate impact).
|
|
39
|
+
|
|
40
|
+
### Never
|
|
41
|
+
|
|
42
|
+
- Never add a blanket audit bypass or lower the configured audit level.
|
|
43
|
+
- Never jump to step 4 (ask a human) before genuinely attempting steps 1–3.
|
|
44
|
+
- Never add a step-5 ignore entry without an impact evaluation recorded in its `reason`.
|
|
28
45
|
|
|
29
46
|
## Rails Projects (bundler-audit)
|
|
30
47
|
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
48
|
+
Same ladder, bundler mechanics:
|
|
49
|
+
|
|
50
|
+
1. Note the advisory ID, affected gem, and advisory URL from the error output.
|
|
51
|
+
2. Check whether a patched version of the gem exists.
|
|
52
|
+
3. **Step 1 — update:** If a patched version exists:
|
|
53
|
+
- **Direct dependency** (in Gemfile): update its version constraint, run `bundle update <gem>`, commit, retry.
|
|
54
|
+
- **Transitive dependency** (only in Gemfile.lock): run `bundle update <gem>` to pull the patched version without changing the Gemfile, commit the lockfile change, retry.
|
|
55
|
+
4. **Steps 3–5 — no patch:** If no patched version exists, evaluate whether the advisory affects the project. If it **does** and no fix is possible, ask the user (step 4). If it **does not**, document the exception and retry (step 5).
|