bakery-demo

Are shipped packages clear of every flaw the advisory feeds list?

drill advisories

Advisories: 232 package(s) checked in OSV, 14 advisory id(s); 0 shipped and 5 dev-only package(s) affected, 0 known exploited (CISA KEV, 0 day(s) old).

• 0days since the exploited-flaw list was releasedAge of the copy of CISA's known-exploited list the drill used.limit 14
• 0packages with a flaw known to be exploitedListed in CISA's catalogue of flaws attackers are known to use.limit 0
• 0shipped packages with a known advisoryPackages that ship in the app, as opposed to build tools. Not listed in a feed does not mean safe.limit 0

Ran 10 h ago · valid 25 h more

Is private data closed to a stranger with only the public key?

drill anonymous-access

A stranger can read no private rows and cannot write. Tables tried: the care plan and the database inventory (3). No readable listing.

• restrictedprivate rows a stranger can readRows in private tables the drill could read with only the public key every browser gets.kept private so no count leaks · limit 0
• 0tables a stranger can write toTables the drill could write to with only that public key.limit 0

Ran 10 h ago · valid 25 h more

Is Noxkeep's own CI hardened: pinned images, locked installs, no key files?

drill armour

Armour: 0 of 11 image(s) not pinned by digest, 0 of 43 install(s) not locked, 0 npm script setting(s) on, 0 key-shaped file(s). Not measured: 19 apt-get/apk install(s).

• 0files shaped like a cloud keyA cloud service-account key in the repo would let anyone who reads it act as that account.limit 0
• 0places where npm install scripts runnpm can run a package's own scripts during install; that is how a poisoned package usually runs its code.limit 0
• 0installs that do not use the lockfileThe lockfile pins the exact version of every package, so an install cannot quietly pull a different one.limit 0
• 0container images not pinned to a digestA digest pins a container image to exact bytes; a tag such as latest can change underneath you.limit 0

Ran 10 h ago · valid 25 h more

Are runtimes and website certificates still within their dates?

drill clock

nodejs 22: 2027-04-30; alpine 3.24: 2028-06-01; python 3.12: 2028-10-31; nginx 1.30, docker-engine 29, react 18: no date published; TLS: 55d left (renewed automatically by Google); Domain expiry: not applicable. No custom domain; the address is a Cloud Run default address owned by Google. (+1 more)

• 0runtimes reaching end of life within 90 daysEnd of life: the date after which a runtime gets no more security fixes.limit 0
• 3runtimes with no end-of-life date yetendoflife.date lists this release as maintained, with no end-of-life date yet.limit 3
• 0runtimes past end of lifeEnd of life: the date after which a runtime gets no more security fixes.limit 0
• 0website certificates (TLS) expiring within 14 daysTLS certificates are what give a website address its https padlock.limit 0

Ran 10 h ago · valid 25 h more

Are the live service's secrets kept out of plain text?

drill exposed-settings

Checked 6 Cloud Run setting(s): 0 plain secrets on the serving service or old revisions; GitLab CI variables not measured (no read-only GitLab token exists yet; CI variables are not measured).

Ran 10 h ago · valid 25 h more

• plain-text secrets on the live serviceSettings on the live service that look like secrets but are not kept in a secret store.0
• plain-text secrets in older revisions0
• settings checked6

Last run 2026-10-27 09:05 UTC · Valid until 2026-10-28 21:05 UTC

Are deploy jobs kept out of scheduled pipelines?

drill postmortem

0 deploy job(s) in a schedule pipeline; 1 scheduled by design: deploy-certificate (on_success); 0 seen in the newest schedule pipeline

• 0deploy jobs a schedule would runA deploy job in a scheduled pipeline could ship code nobody chose to release.limit 0
• 0rules the check could not work outRules the drill could not work out for certain. They count against it, never for it.limit 0

Ran 10 h ago · valid 25 h more

Does the newest backup really restore, and fast enough?

drill restore

Restored the backup taken 0.1 h before this drill in 0 s; 6 table(s) checked against its manifest, 0 differ.

• 6 minage of the newest backupHow old the newest backup was when the drill ran: the most data a restore would lose.limit 26 h
• 0.2 stime to restore itHow long restoring that backup into an empty throwaway database took.limit 15 min
• 0tables that did not matchTables whose restored copy did not match the original.limit 0

Ran 27 h ago · valid 6 days more

Do installs use the lockfile, with install scripts off?

drill supply-chain

Supply chain: 0 of 1 install(s) not locked, 0 npm script setting(s) on, 0 of 232 lockfile entries not verifiable, 2 package(s) with an install script.

• 0lockfile packages with no checkable downloadEach lockfile entry should say where the package came from, with a checksum to verify it.limit 0
• 0places where npm install scripts runnpm can run a package's own scripts during install; that is how a poisoned package usually runs its code.limit 0
• 0installs that do not use the lockfileThe lockfile pins the exact version of every package, so an install cannot quietly pull a different one.limit 0

Ran 10 h ago · valid 25 h more

In this CI job, is install-time code kept from credential-looking names and from pushing?

drill supply-chain-probe

Local package install measured 0 credential name(s) that count and 4 GitLab platform credential name(s) and 1 name(s) declared public that do not. GitLab refused Git push discovery (403) after the read discovery was accepted. Cloud metadata not measured in GitLab CI.

• 0an install could push to the repo (1 means yes)Whether the CI job's own credentials could push to the repository, checked without pushing anything.limit 0
• restrictedcredential-looking names an install could seeCredential-looking variable names (matched by name) a package's install script could read in this CI job. Names only, never values.kept private so no count leaks · limit 0

Ran 10 h ago · valid 25 h more