Candler / How it works
From software inventory to a useful next step.
Candler checks the software versions you provide against known vulnerability records. It turns those results into a shared team inventory, findings to review, and alerts to your chosen destinations.
1. Add an inventory you can identify
For WordPress, create a site and add plugin slugs and exact versions manually or through CSV. A site address is a label for the inventory, not a remote scan that discovers plugins.
For GitHub, authorize selected repositories and add them to your team. V1 imports root composer.lock and package-lock.json files from the default branch. Nested lockfiles, other lockfile formats, and version ranges in manifests are outside this import’s coverage.
2. Check exact versions against known records
WordPress checks use Wordfence records. Supported package checks use OSV. CISA’s Known Exploited Vulnerabilities catalog adds context about known exploitation when identifiers match.
The source’s affected ranges, identifiers, severity, and reported fixed versions remain available for review. A reported fix for one advisory may not fix every finding affecting that component.
3. Read matched, clean, and not checked correctly
Matched means a component has a known vulnerability match. Clean means no known match in the source checked. Not checked means Candler lacks a completed, supported check, for example because an exact version or lockfile is missing.
These counts describe components, not the number of advisories. A single component can have several findings. A failed check does not turn an earlier affected component into a clean one.
4. Make a review decision
Findings can be acknowledged, ignored with a reason, or reopened. Candler keeps the change history. Acknowledging a finding records a decision; it does not fix the software.
A later successful check can resolve a finding when the updated or removed component is no longer affected. The record remains available rather than disappearing from history.
5. Choose where the team hears about changes
Configure email, Slack, or Microsoft Teams destinations and confirm arrival with a test. Rules control the minimum severity and whether ordinary new findings send immediately or in a daily summary.
A finding newly linked to CISA KEV sends an immediate escalation, bypassing ordinary timing and severity rules. Repeat scans do not intentionally resend the same discovery alert. Adding a destination does not automatically replay all older findings.
Common questions
Does Candler fix vulnerabilities?
No. Candler provides findings, source references, reported fixes, and a review workflow. Your team chooses, tests, and applies software updates.
Does Candler run code from my repository?
No. The V1 GitHub connection reads supported root lockfiles. It does not install dependencies or execute repository code.
Does a clean result mean my site is safe?
No. It means no known match was found in the checked source for that component and version. Unknown flaws and coverage gaps can remain.
Are Dependabot, Patchstack, Snyk, or Dependency-Track connected?
Dependabot has an optional read-only preview for selected repositories with owner-approved access. It preserves provider reports and offers comparison links; it does not send Candler alerts. Patchstack, Snyk, and Dependency-Track remain planned. Wordfence Central is separate from the existing vulnerability feed.