Documentation Checks catalogue · Menu
Guardian checks catalogue
Every check Guardian documents, with what it looks at, why it matters, what it can get wrong, and whether it runs today. 14 entries: 2 verified, 6 in preview, 4 planned and2 blocked.
How to read this
The bundled CLI’s help output proves which command groups exist. It does not prove an inventory of individual rules. So a capability reachesVerified only where the help output demonstrates it, and specific checks sit at Preview where the labelled sample report illustrates the finding class.
That is why this catalogue is short. A longer one would be easy to write and worth nothing.
| Status | Meaning |
|---|---|
| Verified | Proven by the bundled CLI’s own help output or by evidence held in this repository. |
| Preview | Built or being built. The exact scope has not been independently verified, so treat it as direction rather than coverage. |
| Planned | Not built yet. Described in future tense, never as available. |
| Blocked | Present in the CLI, but not documented as a product capability until specific evidence exists. |
The catalogue
Filter by platform, category, analysis type or status. Selecting a filter again clears it.
Showing all 14 checks.
Mobile project detection
Verified- What it detects
- Which mobile platform or platforms a directory contains, and which analysis paths apply to it.
- Why it matters
- Every later check depends on this. A project Guardian cannot classify produces coverage gaps rather than silent success.
- Evidence used
- Project manifests and platform directory structure. `guardian detect` reports the result before any scan runs.
- Remediation
- If detection misses a platform, check that the project root is the directory you passed and that its manifests are present.
- False positives
- A monorepo containing several apps may detect the wrong root. Point Guardian at the specific application directory.
Software bill of materials generation
Verified- What it detects
- The dependency inventory of the project, exported as a bill of materials.
- Why it matters
- Most of a mobile application is other people’s code. A security reviewer usually asks for the inventory before anything else.
- Evidence used
- Dependency manifests and lockfiles. The CLI ships a dedicated SBOM command group.
- Remediation
- Not a finding in itself. Hand the inventory to whoever asks for it, and keep lockfiles committed so it stays reproducible.
- False positives
- An SBOM reflects declared dependencies. It is not a vulnerability assessment on its own.
Insecure transport configuration
Preview- What it detects
- Release configuration that permits cleartext traffic beyond a documented exception.
- Why it matters
- Traffic that leaves a device unencrypted is readable on any network the user joins, and both stores scrutinise it.
- Evidence used
- Platform network-security configuration and the application transport settings in the release build.
- Remediation
- Restrict the release network policy to encrypted transport. Where an exception is genuinely required, scope it narrowly, document it, and re-run the check.
- False positives
- A deliberately scoped exception for a specific host may be correct. Guardian reports it; the decision is yours.
Missing privacy purpose declarations
Preview- What it detects
- Privacy-sensitive capabilities represented in release metadata without the corresponding purpose text.
- Why it matters
- A missing declaration is a predictable store rejection, and it arrives after the work is already declared finished.
- Evidence used
- Release metadata and the capabilities the project declares.
- Remediation
- Review whether the capability is genuinely used. If it is, add accurate purpose text; if not, remove the capability.
- False positives
- A capability pulled in by a dependency may be reported even though your own code does not use it. Both are worth knowing about.
Broad dependency version constraints
Preview- What it detects
- Version ranges that accept dependency changes beyond the range the project has actually reviewed.
- Why it matters
- A wide range means the build you tested and the build you ship can differ without anyone changing a line of code.
- Evidence used
- Dependency declarations and the lockfile, where one exists.
- Remediation
- Constrain the accepted range, then commit and retain the lockfile so builds stay reproducible.
- False positives
- Intentionally wide ranges are common in libraries. The finding is about applications, where reproducibility matters more.
Suppressed failure states
Preview- What it detects
- Error paths that discard an actionable failure instead of surfacing or handling it.
- Why it matters
- A swallowed error becomes a support ticket describing behaviour nobody can reproduce.
- Evidence used
- Error-handling paths in the project source.
- Remediation
- Propagate a meaningful error result and add a test that exercises the failure path.
- False positives
- Some suppressions are deliberate and correct. Review in context rather than fixing every instance.
Test evidence not attached to the gate
Preview- What it detects
- A pipeline that never supplies test results to the release policy evaluation.
- Why it matters
- Confusing “we did not check” with “it passed” is how a known defect reaches production.
- Evidence used
- Pipeline configuration and the artefacts it produces.
- Remediation
- Attach the relevant test artefact to the release check, and require explicit handling of missing evidence.
- False positives
- A project that genuinely runs tests elsewhere still shows as incomplete here. That is the intended behaviour: coverage is reported, not assumed.
Module boundary coupling
Preview- What it detects
- Presentation components that own data access directly, and similar erosion of a module boundary.
- Why it matters
- Architecture debt is cheapest to discuss while it is still one module.
- Evidence used
- Structural relationships between modules in the source.
- Remediation
- Assess whether a separate data boundary would improve testability. This is a prompt for a conversation, not a defect.
- False positives
- Small applications often couple deliberately. Low severity, and never a blocker.
Release build hardening configuration
Planned- What it detects
- Debuggable release builds, missing minification or shrinking, and placeholder application identifiers reaching a release configuration.
- Why it matters
- These are the cheapest possible findings to fix and among the most embarrassing to ship.
- Evidence used
- Release build configuration files.
- Remediation
- Correct the release configuration and re-run the release check.
- False positives
- Not yet applicable — this check is not built.
Secrets and credentials in the project tree
Planned- What it detects
- API keys, tokens and credential material committed into the project.
- Why it matters
- A key in a shipped mobile binary is a key you have published, and rotating it is the only remedy.
- Evidence used
- Project files and configuration.
- Remediation
- Rotate anything exposed, then move it out of the project. Rotation first — removal alone does not undo publication.
- False positives
- Not yet applicable — this check is not built.
Exported components and privacy manifests
Planned- What it detects
- Android components exported without explicit protection, and missing iOS privacy manifest entries.
- Why it matters
- An exported component is an entry point into your application from any other application on the device.
- Evidence used
- Platform manifests and privacy metadata.
- Remediation
- Declare export intent explicitly and protect entry points that do not need to be public.
- False positives
- Not yet applicable — this check is not built.
Known-vulnerability matching
Planned- What it detects
- Dependencies with published advisories, matched against the generated inventory.
- Why it matters
- The inventory tells you what you ship; matching tells you which parts are already known to be a problem.
- Evidence used
- The dependency inventory, matched against advisory data available locally.
- Remediation
- Upgrade or replace the affected dependency.
- False positives
- Offline operation means results are only as fresh as the advisory data on the machine. That limitation is inherent, not a defect.
Binary artefact analysis
Blocked- What it detects
- Properties of the built artefact rather than the source it came from.
- Why it matters
- The build that reaches the store is not always the build you reviewed.
- Evidence used
- A built artefact you supply locally. Nothing is uploaded.
- Remediation
- Not documented yet — the individual checks in this group have no published inventory.
- False positives
- The CLI ships a binary-analysis command group, but its per-check behaviour has not been verified for publication. Run `--help` on the group against your installed build.
Runtime behaviour checks
Blocked- What it detects
- Behaviour observable only while the application is running.
- Why it matters
- Some classes of problem are invisible in source and only appear at runtime.
- Evidence used
- A running application on a device, emulator or simulator that you control.
- Remediation
- Not documented yet. See the dynamic analysis page for what is and is not ready.
- False positives
- The dynamic-analysis command group exists but is not production-ready. Treat any output as exploratory.
No check matches that combination. Clear a filter to widen the list.