Context
stackbilt-engine generates code via string template literals — functions like `hmacVerifyFunction()` return multi-line strings that become `src/verify.ts` in scaffolded projects. Charter's drift scanner works on the repo's own source files, but in a code factory repo, the security-critical surface is the strings being emitted, not the TypeScript that emits them.
Example: `src/templates/integrations/hmac.ts` contained:
```typescript
return `...
return computed === signature; // ← timing attack, inside a template literal
...`;
```
Charter drift scanning this file would see a TypeScript file with template literals. It would NOT parse the content of those template strings as code and apply security patterns to it. The vulnerability lives inside the string, one abstraction layer deeper than drift's scanning surface.
Proposal
Add a template-content scanning mode to `charter drift`:
-
Detection: identify files that export functions returning template literal strings (`return \`...\``) — these are code generators.
-
Inner scanning: extract the string content from template literals and apply deny patterns to it as if it were standalone code. This lets patterns like `/=== signature/` match inside the generated output.
-
Configuration: new `.charter/config.json` key:
```json
"drift": {
"templateScanning": {
"enabled": true,
"paths": ["src/templates//*.ts", "src/engine/traits//*.ts"]
}
}
```
-
Output: drift results annotate whether the match is in "source code" or "emitted template content", so the developer knows which layer to fix.
Why this matters
Code factory repos are a growing pattern in the Stackbilt ecosystem (stackbilt-engine, tarotscript, charter itself via `charter scaffold`). A drift scanner that only sees the outer TypeScript misses the most impactful vulnerabilities — the ones that replicate into every downstream project.
Complexity
This is a non-trivial parser change — extracting template literal content, handling nested expressions (`${...}`), and re-scanning the extracted strings. Could start with a simpler v1: regex-based extraction of `return \`...\`` blocks with a 90% coverage heuristic, leaving full AST parsing for v2.
Evidence
- 4 CRITICALs in stackbilt-engine were all inside template literal strings
- CodeBeast's L4 test layer (`tests/security-l4.test.ts`) works by generating scaffolds and scanning the output — essentially doing what drift should do at the source level
- Without this, charter drift gives a false sense of security on code factory repos
Context
stackbilt-engine generates code via string template literals — functions like `hmacVerifyFunction()` return multi-line strings that become `src/verify.ts` in scaffolded projects. Charter's drift scanner works on the repo's own source files, but in a code factory repo, the security-critical surface is the strings being emitted, not the TypeScript that emits them.
Example: `src/templates/integrations/hmac.ts` contained:
```typescript
return `...
return computed === signature; // ← timing attack, inside a template literal
...`;
```
Charter drift scanning this file would see a TypeScript file with template literals. It would NOT parse the content of those template strings as code and apply security patterns to it. The vulnerability lives inside the string, one abstraction layer deeper than drift's scanning surface.
Proposal
Add a template-content scanning mode to `charter drift`:
Detection: identify files that export functions returning template literal strings (`return \`...\``) — these are code generators.
Inner scanning: extract the string content from template literals and apply deny patterns to it as if it were standalone code. This lets patterns like `/=== signature/` match inside the generated output.
Configuration: new `.charter/config.json` key:
```json
"drift": {
"templateScanning": {
"enabled": true,
"paths": ["src/templates//*.ts", "src/engine/traits//*.ts"]
}
}
```
Output: drift results annotate whether the match is in "source code" or "emitted template content", so the developer knows which layer to fix.
Why this matters
Code factory repos are a growing pattern in the Stackbilt ecosystem (stackbilt-engine, tarotscript, charter itself via `charter scaffold`). A drift scanner that only sees the outer TypeScript misses the most impactful vulnerabilities — the ones that replicate into every downstream project.
Complexity
This is a non-trivial parser change — extracting template literal content, handling nested expressions (`${...}`), and re-scanning the extracted strings. Could start with a simpler v1: regex-based extraction of `return \`...\`` blocks with a 90% coverage heuristic, leaving full AST parsing for v2.
Evidence