binlog-generation — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited binlog-generation (Agent Skill) and scored it 45/100 (orange). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 7 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 7 flagged
A base64 string of 128+ characters appears in a documentation file. Encoded prompt injection hides the hostile instruction in base64 — invisible to keyword filters — and relies on the agent's ability to decode it at runtime. There is no normal authoring reason to embed a multi-hundred-byte base64 blob in skill docs.
*.sig, SIGNATURES) outside the documentation.A base64 string of 128+ characters appears in a documentation file. Encoded prompt injection hides the hostile instruction in base64 — invisible to keyword filters — and relies on the agent's ability to decode it at runtime. There is no normal authoring reason to embed a multi-hundred-byte base64 blob in skill docs.
*.sig, SIGNATURES) outside the documentation.A base64 string of 128+ characters appears in a documentation file. Encoded prompt injection hides the hostile instruction in base64 — invisible to keyword filters — and relies on the agent's ability to decode it at runtime. There is no normal authoring reason to embed a multi-hundred-byte base64 blob in skill docs.
*.sig, SIGNATURES) outside the documentation.A base64 string of 128+ characters appears in a documentation file. Encoded prompt injection hides the hostile instruction in base64 — invisible to keyword filters — and relies on the agent's ability to decode it at runtime. There is no normal authoring reason to embed a multi-hundred-byte base64 blob in skill docs.
*.sig, SIGNATURES) outside the documentation.A base64 string of 128+ characters appears in a documentation file. Encoded prompt injection hides the hostile instruction in base64 — invisible to keyword filters — and relies on the agent's ability to decode it at runtime. There is no normal authoring reason to embed a multi-hundred-byte base64 blob in skill docs.
*.sig, SIGNATURES) outside the documentation.A base64 string of 128+ characters appears in a documentation file. Encoded prompt injection hides the hostile instruction in base64 — invisible to keyword filters — and relies on the agent's ability to decode it at runtime. There is no normal authoring reason to embed a multi-hundred-byte base64 blob in skill docs.
*.sig, SIGNATURES) outside the documentation.A base64 string of 128+ characters appears in a documentation file. Encoded prompt injection hides the hostile instruction in base64 — invisible to keyword filters — and relies on the agent's ability to decode it at runtime. There is no normal authoring reason to embed a multi-hundred-byte base64 blob in skill docs.
*.sig, SIGNATURES) outside the documentation.Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Pass the `/bl` switch when running any MSBuild-based command. This is a non-negotiable requirement for all .NET builds.
You MUST add the /bl:{} flag to:
dotnet builddotnet testdotnet packdotnet publishdotnet restoremsbuild or msbuild.exe{} for Automatic Unique NamesNote: The {} placeholder requires MSBuild 17.8+ / .NET 8 SDK or later.The {} placeholder in the binlog filename is replaced by MSBuild with a unique identifier, guaranteeing no two builds ever overwrite each other — without needing to track or check existing files.
# Every invocation produces a distinct file automatically
dotnet build /bl:{}
dotnet test /bl:{}
dotnet build --configuration Release /bl:{}PowerShell requires quoting the complete switch:
# Keep the literal {} placeholder in one argument
dotnet build '-bl:{}'
dotnet test '-bl:{}'# ✅ CORRECT - {} generates a unique name automatically (bash/cmd)
dotnet build /bl:{}
dotnet test /bl:{}
# ✅ CORRECT - quote the complete PowerShell argument
dotnet build '-bl:{}'
dotnet test '-bl:{}'
# ❌ WRONG - Missing /bl flag entirely
dotnet build
dotnet test
# ❌ WRONG - No filename (overwrites the same msbuild.binlog every time)
dotnet build /bl
dotnet build /blAdd /bl:{} to every MSBuild invocation separately — never reuse a name and never rely on bare /bl:
command still gets its own /bl:{} so the logs never overwrite each other.
dotnet build -c Debug /bl:{} # unique file
dotnet build -c Release /bl:{} # another unique fileAfter the build, confirm a .binlog was actually produced before moving on to analysis — a build that fails before MSBuild starts (e.g. a bad argument) writes no binlog:
ls -1 *.binlog # bash
dir /b *.binlog # Windows cmdGet-ChildItem *.binlog # PowerShellNote the resulting path so binlog-failure-analysis or build-perf-diagnostics can consume it.
If the binlog filename needs to be known upfront (e.g., for CI artifact upload), or if {} is not available in the installed MSBuild version, pick a name that won't collide with existing files:
*.binlog files in the directory# Example: directory contains 3.binlog — use 4.binlog
dotnet build /bl:4.binlogWhen cleaning the repository with git clean, always exclude binlog files to preserve your build history:
# ✅ CORRECT - Exclude binlog files from cleaning
git clean -fdx -e "*.binlog"
# ❌ WRONG - This deletes binlog files (they're usually in .gitignore)
git clean -fdxThis is especially important when iterating on build fixes - you need the binlogs to analyze what changed between builds.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.