exp-mock-usage-analysis — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited exp-mock-usage-analysis (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.
Trace each mock setup through the production code's execution path to determine which setups are actually exercised at runtime and which are dead, unreachable, redundant, or replaceable with real implementations.
test-anti-patterns)| Input | Required | Description |
|---|---|---|
| Test code | Yes | Test files to analyze |
| Production code | Yes | Code under test — essential for tracing execution paths |
Read the test files and always read the production code. You cannot determine whether a mock setup is necessary without understanding the production method's control flow.
Identify the mock framework by scanning for its patterns:
new Mock<T>(), .Setup(...), .Verify(...)Substitute.For<T>(), .Returns(...), .Received(...)A.Fake<T>(), A.CallTo(...), .MustHaveHappened()Use the correct framework's terminology throughout your analysis.
For each test method, do the following:
.Setup, .Returns, A.CallTo, etc.)| Classification | Meaning | Example |
|---|---|---|
| Used | The production code calls this mock during the test's execution path | GetStock setup when Reserve is called and stock is sufficient |
| Unreachable | The production code returns early, throws, or branches away before reaching this mock call | UpdateStock setup when the test expects the method to throw ArgumentOutOfRangeException on the first line |
| Unused | The mock method is never called by the production method under test at all, regardless of inputs | GetLowStockProducts setup when testing Reserve, which never calls that method |
| Redundant | Identical mock configurations are duplicated across multiple tests instead of being shared | Five tests each creating new Mock<IPaymentGateway>() with the same default setup |
Pay special attention to:
.Verify/.Received/.MustHaveHappened without asserting on the method's return valueFlag mocks of stable framework types that should use real implementations:
Mock<ILogger<T>> → NullLogger<T>.Instance (unless log output is asserted)Mock<IOptions<T>> → Options.Create(new T { ... })new T { ... } directlyExplicitly confirm which mocks are correctly placed — external boundaries (databases, HTTP clients, message queues, third-party APIs) and security-sensitive types should remain mocked.
For each finding, state:
When multiple tests duplicate mock configurations, provide a before/after example showing how to extract shared setup into a fixture or helper method.
| Pitfall | Solution |
|---|---|
| Analyzing test code without reading production code | Always read the production method to trace which mocks are actually called |
| Flagging mocks for external boundaries (HTTP, DB) | These are valid isolation boundaries — keep them mocked |
Flagging ILogger mock when log output is asserted | Only flag when the mock is set up but log output is never verified |
| Using wrong framework terminology | Match the framework in the code: Moq (Setup/Verify), NSubstitute (Returns/Received), FakeItEasy (A.CallTo/MustHaveHappened) |
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.