cdk-insights 1.37.2 → 1.37.4
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/README.md +4 -2
- package/dist/cli/commands/fix.d.ts +34 -0
- package/dist/cli/commands/fix.test.d.ts +1 -0
- package/dist/entry.js +192 -192
- package/dist/index.js +2 -2
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -377,8 +377,10 @@ The AI tier adds deep analysis via AWS Bedrock: security analysis, findings cate
|
|
|
377
377
|
|
|
378
378
|
## 🧰 Requirements
|
|
379
379
|
|
|
380
|
-
- Node.js 22 or later
|
|
381
|
-
- AWS CDK v2 project
|
|
380
|
+
- Node.js 22 or later (to run the CLI itself)
|
|
381
|
+
- AWS CDK v2 project — in **any** CDK-supported language (TypeScript, JavaScript, Python, Java, C#/.NET, Go)
|
|
382
|
+
|
|
383
|
+
`scan` analyses the synthesized CloudFormation, so your CDK app's source language doesn't change what gets checked. A few features (in-process Aspect, source-line jump-to-file, `cdk-insights fix`) are TypeScript/JavaScript-only today — see [CDK language support](./docs/cdk-language-support.md) for the full feature matrix.
|
|
382
384
|
|
|
383
385
|
### Quick Compatibility Check
|
|
384
386
|
|
|
@@ -5,5 +5,39 @@ interface FixCommandArgs {
|
|
|
5
5
|
apply?: boolean;
|
|
6
6
|
all?: boolean;
|
|
7
7
|
}
|
|
8
|
+
export type SafePathResult = {
|
|
9
|
+
ok: true;
|
|
10
|
+
absolutePath: string;
|
|
11
|
+
} | {
|
|
12
|
+
ok: false;
|
|
13
|
+
reason: string;
|
|
14
|
+
};
|
|
15
|
+
/**
|
|
16
|
+
* Reject paths that would let a malicious CDK construct or manifest divert
|
|
17
|
+
* fix's write to somewhere outside the user's project. `filePath` originates
|
|
18
|
+
* from `sourceLocation.filePath` on a finding — that field comes from
|
|
19
|
+
* CDK manifest traces or cdk-insights aspect metadata, both of which a
|
|
20
|
+
* hostile construct can populate. We require:
|
|
21
|
+
*
|
|
22
|
+
* - after `path.resolve`, the path stays inside `projectRoot`
|
|
23
|
+
* - the target is NOT a symlink (so a planted `lib/Stack.ts -> ~/.zshrc`
|
|
24
|
+
* in an upstream project can't trick a downstream contributor's
|
|
25
|
+
* `fix --apply` into overwriting their dotfiles)
|
|
26
|
+
*
|
|
27
|
+
* The follow-up atomic-rename pattern is what actually replaces the file
|
|
28
|
+
* safely; this check makes the refusal explicit and surfaces a clear error
|
|
29
|
+
* outcome to the user rather than silently turning a symlink into a regular
|
|
30
|
+
* file.
|
|
31
|
+
*/
|
|
32
|
+
export declare const resolveSafeWritePath: (filePath: string, projectRoot: string) => SafePathResult;
|
|
33
|
+
/**
|
|
34
|
+
* Replace the file at `target` with `content` atomically: write to a
|
|
35
|
+
* sibling temp file then rename. POSIX rename(2) replaces the target
|
|
36
|
+
* inode atomically, which means a half-written file is never observable
|
|
37
|
+
* and — as a side effect — a symlink at `target` gets replaced rather
|
|
38
|
+
* than followed. The temp name is randomised so two concurrent fix
|
|
39
|
+
* invocations don't collide on the same path.
|
|
40
|
+
*/
|
|
41
|
+
export declare const atomicWriteFile: (target: string, content: string) => void;
|
|
8
42
|
export declare const fixCommand: CommandModule<Record<string, unknown>, FixCommandArgs>;
|
|
9
43
|
export {};
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
export {};
|