Skip to main content
The Libraries tab of a Code Audit branch lists the dependency versions it collected and the advisories that match them. A version match and its impact on your code are judged separately from the source findings on the same branch.

​
Prerequisites

  • Code Audit, with library checking turned on. It’s on by default; if Libraries never appears, ask CloudThinker support, or whoever runs CloudThinker for your company.
  • A connected repository whose dependency files are supported and resolved.
  • One completed library inventory, before a branch can be monitored.

​
Inspect the inventory

An audit report lists the libraries collected at the commit that audit pinned. The tracked branch shows its last complete inventory and the advisory results behind it. An inventory lists what the repository declares, not what’s running in production. An unresolved package or an incomplete collection is not evidence that you’re safe.

​
Read vulnerability evidence

Select a library to see its version, where your code uses it, and the advisory evidence saved against it. Read the advisory and its affected versions before you decide how to fix it. A matching advisory says the dependency may be affected. The impact assessment goes further and looks at your own code: does it use the vulnerable behavior? When that can’t be settled, the assessment keeps the evidence or conditions it’s missing. A not-affected assessment doesn’t erase the advisory match underneath it. Source findings, dependency evidence, and pentest proof against the running app answer three different questions. A link to an older alert keeps the evidence it was written against, even after the branch upgrades that dependency. Click Download on the report to share an assessment.

​
Control monitoring

Once a complete inventory is published, monitoring checks for newly disclosed vulnerabilities on its own, without another source audit. It runs separately from any audit schedule.
  • Pause monitoring stops the refreshes and keeps the saved evidence.
  • Resume monitoring starts them again.
  • A later source audit keeps a pause you chose yourself.
Monitoring on doesn’t mean a check has finished. Read the last successful check time and the evidence date next to it. Paused, delayed, stale, and unresolved packages aren’t clean just because no new alert arrived.

​
Troubleshooting

For every Cyber problem in one place, see Cyber troubleshooting.
Run a Code Audit on a branch whose dependency files are supported and resolved. Monitoring needs one complete published inventory.
Run another audit to collect the current commit. Until it finishes, checks keep using the last complete inventory.
Click Resume monitoring if you paused it. If checks are only delayed, read the saved timestamps: the evidence you have stays readable while the check retries.
Library checking can be turned off without turning off source auditing. Ask CloudThinker support, or whoever runs CloudThinker for your company. Saved inventories and advisories stay readable, but they don’t tell you about today.

Run a Code Audit

Assess source code and follow a repository branch

Cyber troubleshooting

Every Cyber problem in one place, with cause, check and fix

Cyber

How source auditing and pentests fit together