Seen on the 0.22.0 live verification against a small Node service (src/server.js, src/router.js, src/handlers/notes.js, src/store.js, …, 8 source files, language: javascript):
Broad-Side submitted 1 batch(es); 1 lens(es) produced none (see below).
Architecture, tech stack & module map: batch batch-… (1 request(s), ~$0.0118)
Security review: skipped (0 request(s), ~$0.0000)
The security lens reads server/**, **/auth*, **/middleware/**, SECURITY.md for non-Go repositories (core/broadside.ts, LENSES.security.globsFor). A service whose entry point is src/server.js and whose auth check lives inside it matches none of them, so the lens that exists to find exactly that code never sees it. The api lens has the same shape (server/**, api/**, src/server/**, src/api/**, **/*routes*, **/*router*, **/*handler*, **/*endpoint*) — it happened to match here through router/handlers, but a project that names things differently gets nothing.
Once the live-verification follow-up PR lands, the report names the globs that matched nothing, so the gap is at least visible. What it should do is the open question:
- Fallback to the language's source glob when the targeted globs match nothing. The security lens is
sliceBy: none with a 70k-char cap, so on a small repository the fallback costs about what the architecture lens costs; on a large one the cap truncates coverage, which the lens already reports through coverage_note. This keeps "a repository with server code gets a security review" true without changing the price for repositories the current globs already fit.
- Or widen the globs with the common layouts:
src/server.*, **/server.*, **/app.*, **/*auth*, **/security/**, **/*session*, **/*token*. Cheaper and more predictable than a fallback, but every layout it misses is a repeat of this issue.
I lean fallback-with-a-note (the report line becomes "no files matched the targeted patterns; scanned all javascript sources instead"), because the lens's job is to find the trust boundary wherever it lives. Either way the estimate should show the fallback before the user approves it.
Seen on the 0.22.0 live verification against a small Node service (
src/server.js,src/router.js,src/handlers/notes.js,src/store.js, …, 8 source files,language: javascript):The security lens reads
server/**,**/auth*,**/middleware/**,SECURITY.mdfor non-Go repositories (core/broadside.ts,LENSES.security.globsFor). A service whose entry point issrc/server.jsand whose auth check lives inside it matches none of them, so the lens that exists to find exactly that code never sees it. Theapilens has the same shape (server/**,api/**,src/server/**,src/api/**,**/*routes*,**/*router*,**/*handler*,**/*endpoint*) — it happened to match here throughrouter/handlers, but a project that names things differently gets nothing.Once the live-verification follow-up PR lands, the report names the globs that matched nothing, so the gap is at least visible. What it should do is the open question:
sliceBy: nonewith a 70k-char cap, so on a small repository the fallback costs about what the architecture lens costs; on a large one the cap truncates coverage, which the lens already reports throughcoverage_note. This keeps "a repository with server code gets a security review" true without changing the price for repositories the current globs already fit.src/server.*,**/server.*,**/app.*,**/*auth*,**/security/**,**/*session*,**/*token*. Cheaper and more predictable than a fallback, but every layout it misses is a repeat of this issue.I lean fallback-with-a-note (the report line becomes "no files matched the targeted patterns; scanned all javascript sources instead"), because the lens's job is to find the trust boundary wherever it lives. Either way the estimate should show the fallback before the user approves it.