Skip to main content

Vulnerability management

Every build of your app records exactly what went into it: the operating system packages in the image, the libraries your dependencies pull in, and the packages your source tree declares. AppHaven checks that inventory against published vulnerabilities, and keeps checking your production deployment as new ones are published.

There is nothing to switch on and nothing to point at your lockfiles. It happens on every build, for every app.

What gets checked​

Two things together, for each service AppHaven builds:

  • What ships in the image. The operating system packages and the libraries installed in the container that actually runs.
  • What your repository declares. The lockfiles and dependency manifests present at the commit being built.

Both matter, because a build often drops the file that names a dependency while keeping the result compiled from it. Looking only at the image would miss the JavaScript packages bundled into your static assets; looking only at your source would miss the operating system packages inherited from your base image. Together they cover what you wrote, what you depend on, and what your base image brought with it.

When it runs​

On every build. As soon as an image is built, its inventory is checked. This is the fast feedback: what did the change I just pushed bring in with it.

Every night, for production. Your production deployment is re-checked against current vulnerability data. Most vulnerabilities in a running app arrive this way: the code did not change, the world did. The nightly check is what turns that into something you find out about, rather than something you discover later.

Preview deployments are checked when they build, which is what you want from a branch you are about to merge. The standing, every-night obligation is production, the deployment running your production branch.

Reading the findings​

Open your app's Security section in the console. For each service it lists the current findings:

ColumnWhat it tells you
SeverityCritical, High, Medium, or Low
PackageThe affected package and the version you are running
FixThe version that resolves it, when one has been released
AdvisoryA link to the published advisory

Findings that appeared since the previous check are marked as new, which is what makes both checks readable at a glance: after a push, the new entries are what your change introduced; after a night, they are what was published while you slept.

The section also keeps the history of checks, so you can see when your app was last looked at and what each check found.

Fixing a finding​

The fix is almost always a version bump: raise the dependency to the version named in the Fix column, or move your Dockerfile's base image forward to pick up patched operating system packages. Push, and the next build is checked again, with resolved findings gone from the list.

finding in the console
raise the dependency
push
next build is clear

A finding never fails a build or blocks a deploy. AppHaven reports what it knows, with the severity and the fix, and you decide what is worth shipping for and when. Where no fixed version has been released yet, the finding says so, so you can tell "upgrade this" apart from "there is nothing to upgrade to."

Downloading the inventory​

The inventory itself is yours to take. Each service's is downloadable from the Security section as CycloneDX JSON, the standard format for a software bill of materials. That is the file to hand over when a customer, an auditor, or a security questionnaire asks what is inside your application, and the file to feed to your own tooling if you run any.

From the terminal, and from your agent​

The same findings are available to the apphaven CLI:

apphaven vulns my-app              # latest findings, per service
apphaven vulns my-app --history    # what previous checks found
apphaven vulns my-app --scan <id>  # one specific check in full

apphaven status carries a one-line summary alongside the deployment's state.

This closes a loop worth handing to a coding agent: it can read its own app's findings, raise the versions, and push, then check the next build's result itself. See Building with AI agents.

Where to go next​