Product
ScannerReportsAI Integration
Resources
GuidesResearchSecurity checklistDocsStatus
Account
Sign inScan your app free
Reports · free scan

What the scan found. What it couldn't check.

A report shows everything the scan found, in plain words. Known issues are packages where a published advisory matches the version you use. Code findings are split into likely issues, where the scanner saw the risky code itself, and findings that need checking, where it looked for a protection and didn’t see it, or the match depends on context it can’t see. The report also names what the scan couldn't check.

KNOWN, LIKELY, NEEDS CHECKING · SECRETS MASKED · KEPT UNTIL YOU DELETE IT

example report · my-saas-app · 2 known · 5 likely · 9 need checking
Summary
Needs checkingNo row-level security on the profiles tablecheck before changing
supabase/migrations/0001_init.sql:12
What someone could do: anyone with your app's public Supabase key could read every row in this table. Suggested fix: turn on row-level security and add a policy so each user can only read their own row.
2Known issuesadvisory named
5Likely issuesstart here
9Needs checkingworth a look
2Couldn't checknamed, not counted as clean

Enough detail to check it yourself.

Each finding says where it is, shows the code, explains what someone could do with it, suggests a fix, and gives you a prompt for your AI tool. Epherem reads your code but doesn’t run your app, so look at the code before you change it.

01 / GROUP

Which group it's in

Likely issues are where the scanner saw the risky code itself. Findings that need checking are where it looked for a protection and didn’t see it, or where the match depends on context it can’t see.

  • Known issue (packages)
  • Likely issue
  • Needs checking
02 / LOCATION

Where it is

The file and line, with a short excerpt of the code so you can find it fast. Secret values in the excerpt are masked.

  • File path
  • Line number
  • Short code excerpt, secrets masked
03 / FIX

What it means

A plain explanation of what someone could do if the issue is real, and what to change.

  • What someone could do
  • A suggested fix
  • A prompt to paste into your AI tool

What's in a report.

A report starts with a summary: how many known issues, likely issues and findings that need checking it found, and what couldn't be checked. The detail follows.

01
Likely issues, and what needs checkingEverything the code checks found, in two groups: likely issues first, then what needs checking.
02
Known package issuesPackage versions that match a published advisory on OSV.dev, with the advisory named. Packages with exact versions (from a lockfile) are checked against published advisories. Without a lockfile, the report says which ones it couldn’t check. The scan doesn't check whether your app uses the affected part of the package.
03
What we couldn't checkLanguages or files that weren't analysed, and things outside your code, such as Supabase dashboard settings or your live site.
04
ExportCopy every finding for your AI tool, or download the report as Markdown, CSV, JSON or a PDF. Free on every report.
✓SummaryOVERVIEW
✓Likely issues, and what needs checkingFINDINGS
✓Known package issues and their advisoriesPACKAGES
✓What we couldn't checkCOVERAGE
✓Export reportEXPORT
✓Readable from Claude DesktopEXTENSION

Start with what’s likely.

One long list would waste your time. Known issues come first: a published advisory matches a package version you use. Then likely issues, where the scanner saw the risky code itself. Then findings that need checking, where it looked for a protection and didn’t see it, or where the match depends on context it can’t see. The protection may exist somewhere the scan couldn’t see.

Known issuesA published advisory matches a package version you use
Likely issuesThe scanner saw the risky code itself. Start here.
Needs checkingIt looked for a protection and didn’t see it, or the match depends on context it can’t see. It may exist somewhere the scan couldn’t see.
Not checkedNamed in your report, never counted as clean
example findings · known, likely, needs checking
Knownnext 14.1.0 has a published advisoryGHSA-fr5h-rqp8-mj6g
LikelySupabase service role key reaches the browsercomponents/ProfileCard.tsx:9
LikelyEnvironment file committed with the project.env:1
To checkNo row-level security on the profiles tablesupabase/migrations/0001_init.sql:12
To checkDelete doesn't check who owns the noteapp/api/notes/[id]/route.ts:18

Incomplete is a result, not something to hide.

If part of your project couldn't be analysed, the report says which part. Not analysed is never shown as clean. When you scan again, Epherem reads your code as it is now and writes a new report; it doesn’t compare it with the last one. A finding missing from the new report is not proof of a fix: a finding can disappear for reasons other than a fix.

What the report makes clear

  • Which findings are known, which are likely, and which need checking
  • Which files and languages were analysed, and which weren't
  • What sits outside your code, like Supabase dashboard settings
  • Which package issues are known, and the advisory behind each

What the report does not claim

  • That every possible problem was found
  • That a scan replaces a penetration test
  • That a finding is real before you check it
  • That a check it couldn't finish passed
  • That your app is safe to deploy
SortedKnown, likely, needs checking
KeptUntil you delete it
Re-scanAny time, within 5 a day
ExportFree on every report

Know what the scan knows, and what it doesn't.

Reports stay in your account until you delete them. You can also read them from Claude Desktop with the Epherem extension.

No automated report guarantees security. Look at each finding before you change code, and read what the scan couldn't check before you deploy.