How CommonLayer works · CommonLayer

Projects and repositories

A project is one upstream (for example NGINX) built into images and charts. Its repository stays in its maintainer's own GitHub account; CommonLayer connects to it through a GitHub App, checks it, backs it up and manages the maintainers' access. It never pushes to it.

In the documentation: Project onboarding

From build to published version

The project's CI builds, signs and submits each version by digest. CommonLayer checks the signature, the SBOMs and the provenance, scans it, and only then publishes it to its registry. Nobody can push to the registry directly.

In the documentation: Verification policy

Digests and tags

A digest (sha256:…) names exactly one version and never changes; a tag can move. Deploy by digest; a fix is always a new digest.

Which tags move (5)

Tag kinds
Tag	Example	Moves?
`<version>-r<revision>`	`1.30.6-r2`	Never — enforced by the platform
`<version>`	`1.30.6`	Yes, to the newest revision
`<version line>`	`1.30`	Yes
Channel	`stable`	Yes
`latest`		Yes

In the documentation: Using the registry

Funding

Contributions go to the project, once or monthly. Each month the project's published policy shares the money out: maintainer slots, infrastructure, a flexible pool and a reserve that keeps maintainers paid through a short shortfall. Every line of every month is public.

The default policy for a $500 monthly target

Default allocation policy for a $500 monthly target
Slot	Amount	Share
Primary maintainer	$200	40%
Secondary maintainer	$150	30%
Infrastructure	$50	10%
Flexible pool	$100	20%
Monthly target	$500

In the documentation: Funding model

Maintainers

Maintainers apply, are approved and are assigned to projects with named duties. After each month an evaluation checks those duties against evidence and explains its result; only eligible maintainers are paid. Pay is never per vulnerability.

Eligibility:Eligible
Eligibility:At risk
Eligibility:Under review
Eligibility:Ineligible
Eligibility:Temporarily suspended

In the documentation: Maintainer handbook

Security

Every supported version is scanned on submission and daily. Each finding gets deadlines by severity; exceptions are public with their reason. Anyone with an account can report a vulnerability privately.

Default deadlines by severity (4)

Default service levels by severity
Severity	Acknowledge within	Remediate within
Critical	24 hours	7 days
High	48 hours	14 days
Medium	7 days	30 days
Low	14 days	End of the next maintenance cycle

In the documentation: Security

Three separate states

Each project shows maintenance, funding and security separately, never as one score: a funded project can have overdue findings; an unfunded one can be clean.

Lifecycle ·ActiveFunding ·Partially fundedSecurity ·Open issues within SLA

What is public

Amounts, policies, monthly results, eligibility states and findings are public. Billing details, emails, payout destinations and private reports never are.

Public and private, area by area (6)

Public and private information
Area	Public	Never public
Project funding	Target, coverage, balances, allocation policy, cycle summaries and lines	Identities of anonymous contributors, payment references
Contributions	Amount, date, contributor name unless anonymous, message if given	Billing details, email addresses, provider identifiers
Maintainer compensation	Slot amounts; whether a cycle line was paid, held or forfeited, and why	Payout destinations, tax status, bank details
Eligibility	State per period and the rule summary	Private evidence notes, appeals
Security	Findings on public digests once not embargoed, exceptions, advisories, scan history	Embargoed findings, private reports, incident internals
People and organizations	Username, display name, bio, public contributions; public organizations' funded projects and totals	Email, sessions, tokens, organization members, notes and billing

In the documentation: Privacy rules