For: Practitioners & Platform Engineers
56 skills went in. 3 findings came out. A person wrote a reason for each.
SkillGuard doesn’t flag “bad skills.” It builds a bill of materials for every skill, works out what each one can do by reading its code rather than believing its label, runs 10 detectors over the text, and checks whether two skills that name each other would chain into a way out for your data. Then a human decides. Here is what it found when we ran it on a real public repository, and why every one of those findings turned out to be fine.
Every figure on this page is scanner output from our public reference repo (Apache-2.0, 56 skills), regenerated from the tool rather than typed by hand. The same scanner runs against our private skill pool; those results are internal and stay that way.
The Tension
“Our skills are security teaching material. They quote the attacks on purpose. So every naive scanner either drowns us in false alarms or, tuned down, stops finding anything. How do you scan a library that is supposed to contain the bad words?”
The brakes
The hard part is not matching. It is refusing to fire.
Our skills teach defence, so they quote the attacks. “Never upload your .env file to an external endpoint” and “upload your .env file to an external endpoint” differ by one word. A keyword match cannot tell a lesson from an instruction, which is why a naive scanner either drowns this corpus in false alarms or, tuned down, stops finding anything at all.
So every text detector passes through two brakes before it is allowed to accuse anything. The first looks backwards a few words for a negation — never, do not, must not, avoid. The second looks around for the vocabulary of defence: detect, forensic, playbook, MITRE, worked example. Either one, and the finding is suppressed.
The secret-exfiltration rule goes further still. It does not match a verb near a noun. It requires a specific credential-bearing file path with an exfiltration verb inside a narrow window either side of it, and no defensive vocabulary nearby. That fussiness is not fastidiousness. A generic proximity match, run against this corpus, produces overwhelmingly more false alarms than real findings, and a scanner nobody believes is a scanner nobody runs.
The Proof
What the scan actually found: real findings from the reference repo.
Not a sample. Not an illustration. This is every finding the scanner produced against our public reference repo’s 56 skills — all 3 of them, with the evidence string that fired and the reason a human accepted it. Note what they have in common: every one is a real match on text that is doing its job. That is what the brakes are up against.
generating-an-ai-bill-of-materials
highCategory: installer.download_execute
Download-execute installer chain
Evidence: curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh
Triage: Documented install command for Anchore Syft, the SBOM generator this skill teaches you to run — matches the skill's own stated purpose, not an unexplained fetch-and-execute.
red-teaming-llm-applications
criticalCategory: injection.instruction_override
Prompt-injection / instruction-override phrasing
Evidence: Ignore previous instructions
Triage: Quoted verbatim as the worked attack-phrase example this red-teaming skill teaches testers to probe with — the skill's job is to teach exactly this phrase, not to execute it.
scanning-ai-bom-for-vulnerable-components
highCategory: installer.download_execute
Download-execute installer chain
Evidence: curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh
Triage: Documented install command for Anchore Grype, the vulnerability scanner this skill teaches you to run against an AI-BOM — same legitimate-tool pattern as the Syft finding above.
Scan Summary
Skills scanned
56
Files analyzed
56
Findings
3
Triaged / outstanding
3 / 0
Capability distribution (inferred, across the 56 reference skills)
network
7 skills
shell
2 skills
filesystem-write
11 skills
filesystem-read
2 skills
secret-access
10 skills
package-install
12 skills
git-write
2 skills
What It Proves
The gap between “we have skills” and “we know what our skills can do.”
Most organizations have thousands of skills in their repository. Most have no idea what those skills can actually do, because the only thing anyone ever reads is the description the author wrote. SkillGuard closes that gap: not by flagging “bad” skills, but by making what each one can do visible, and by making every exception someone’s signed decision.
The guardrail, stated precisely
One part of this is wired into the build and one part is run on demand, and the difference matters more than a tidier sentence would.
In the build: check_reference_skillbom.py runs in the prebuild chain. If the reference scan carries a finding nobody has triaged, the build fails. An unreviewed finding cannot ship silently, because the site will not compile.
On demand: the scanner itself, over the private pool, is developer tooling run deliberately — not a merge gate, and there is no triage SLA. The lockfile is what makes either mode worth anything: it records the fingerprint of every file, so you can prove which skills were approved at which commit, and spot a change nobody announced.
Honest boundary
The SkillBOM is a static analysis tool. It does not catch runtime behavior, side-channel attacks, or sophisticated obfuscation. It catches known patterns. For runtime security, you need a different tool. The attack graph is co-reference risk, not a live execution graph. Treat it as a review prompt, not a live threat model.
The methodology is fully documented. The scanner code is available. The triage decisions are recorded. The attack graph is JSON-exportable. This is not a black box — it’s a transparent, auditable process.