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 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 {};