wpsecadv: The Go Service That Teaches Composer About WordPress Security

The best security tools disappear into the workflow. `wpsecadv` does that by slipping WordPress plugin and theme advisories into composer audit, so the check happens where Bedrock and other Composer-based stacks already make dependency decisions.

That matters because WordPress security has often lived one layer too late. You could scan after installation, patch after exposure, or rely on runtime protections. `wpsecadv` moves the decision point left, before vulnerable code lands in the project at all.

Why Bedrock needed this

Composer-based WordPress projects already treat the site as code. Bedrock pushed that idea further, but the security tooling never fully caught up. Generic PHP advisories covered Packagist packages. WordPress plugins and themes remained a blind spot.

`wpsecadv` fills that gap without asking teams to learn a new scanner or adopt a separate dashboard. It speaks Composer’s language, which makes it useful in local development, CI, and deployment pipelines alike.

A repository provider, not a scanner

This is the project’s core trick. `wpsecadv` is not a WordPress vulnerability scanner with its own opinionated UI. It is a Composer repository provider that serves advisories in the format Composer expects, so native commands can make security decisions without extra ceremony.

That boundary matters. Wordfence data describes WordPress risk. Composer wants package names, version ranges, and advisories it can apply during dependency resolution. `wpsecadv` sits between those two worlds and converts one into the other.

The Go pipeline that keeps the data fresh

The service is small, but the maintenance loop is not. A Go generator pulls advisory data, reshapes it, and writes it into the repository as JSON assets. The result is a repo that behaves like a database without actually running one.

The workflow is deliberate. `go generate` refreshes the store. A scheduled job runs twice daily. A bot opens pull requests so the repository history reflects the advisory changes, which keeps the whole data pipeline visible and auditable.

That design also makes deployment simpler. There is no SQL backend to migrate, no separate indexing service to maintain, and no hidden cache to warm. The files in the repo are the source of truth.

type Advisory struct {
	PackageName       string   `json:"packageName"`
	Title             string   `json:"title"`
	CVE               string   `json:"cve,omitempty"`
	AffectedVersions   []string `json:"affectedVersions"`
	Severity          string   `json:"severity,omitempty"`
	Link              string   `json:"link,omitempty"`
}

// Composer expects package-level advisories with version constraints,
// not a generic scan result.

How the advisory schema maps WordPress risk into Composer rules

The schema work is where the project earns its credibility. The Go code does not just stash Wordfence records. It converts them into advisory objects that Composer can read, which means version constraints, severity, and package identity all have to line up cleanly.

That is a stricter contract than it looks. If the package slug is wrong, the advisory misses. If the version range is sloppy, the result is noisy or useless. The point is precision, not volume.

This is also why compatibility details matter. Composer’s security model is opinionated. `wpsecadv` respects that model instead of inventing its own.

Why the flat-file store is a feature, not a compromise

A conventional database would add moving parts without changing the core job. The flat-file store keeps the advisory dataset portable, versioned, and cheap to serve. For a repository whose whole purpose is distribution, that is a strong trade.

It also makes automation easier. File diffs show what changed. Pull requests show when the data changed. Releases and deploys stay lightweight because the server mostly serves static assets plus a thin HTTP layer.

The comparison is not about absolute superiority. It is about fit. `wpsecadv` wins when the problem is dependency hygiene inside a Composer-first WordPress stack.

What `wpsecadv` does better than the usual WordPress security options

WordPress security plugins defend a running site. Managed hosts defend the platform. WP-CLI-style checks inspect an installed site. `wpsecadv` sits earlier than all three, which is why it changes the outcome rather than just the alert surface.

That gives it a narrower but sharper job. It is best when the developer wants vulnerable packages blocked before install, before update, or before a lockfile makes it to production.

The real story is not that WordPress finally got another scanner. It is that WordPress security became part of dependency management, where modern PHP teams already expect risk to be enforced.

The real story: security that disappears into the workflow

Good infrastructure gets boring in the best way. `wpsecadv` matters because it makes WordPress security look like ordinary Composer hygiene. No new mental model. No extra toolchain. Just a familiar command that finally understands the ecosystem it is protecting.

That is a small project with a big consequence. It turns WordPress plugin risk from a special case into a standard dependency problem, which is exactly where it belongs.