Debian Governance Explained: Constitution, DPL, Tech Committee and GRs

Debian has no owner. It is run by about a thousand volunteer Debian Developers under a written constitution first ratified on 2 December 1998, which splits power between an elected Debian Project Leader, a Technical Committee of up to eight developers, and the developers as a whole voting on General Resolutions with a ranked, Condorcet style ballot. Two Foundation Documents, the Social Contract and the Debian Free Software Guidelines, sit above everything and need a 3:1 supermajority to change.

If your products, servers or container images are built on Debian, that structure decides who ships your security fixes, how long they keep coming, which firmware lands on your installer, and what the project will and will not promise you. This guide walks through each body, the actual rules in the constitution, the vote results that changed things, and what a company that depends on Debian should do about it.

Key takeaways

• Debian is a project, not a company. The constitution states that nothing in it obliges anyone to do work for the project. There is no vendor you can put under contract for a fix.
• Six bodies make decisions: individual developers, the developers together by General Resolution or election, the Project Leader, the Technical Committee and its Chair, the Leader's Delegates, and the Project Secretary.
• The Project Leader is elected every year in a six week process and serves one year.
• The Technical Committee has up to 8 members, decides technical disputes as a last resort, and needs 3:1 to overrule a developer. The developers can overrule the committee with 2:1.
• General Resolutions need a proposer plus K sponsors (5 at today's membership), two to three weeks of discussion, and a two week ballot counted by dropping the weakest defeats inside the Schwartz set.
• Money and trademarks sit with trusted organisations, chiefly Software in the Public Interest (SPI), which holds the registered US Debian trademark but has no say over Debian's decisions.
• Governance reaches your patch queue. The Security Team supports each stable release for about three years; a separate LTS group extends that to at least five. A 2022 vote put non-free firmware on official installers, and a 2026 vote set the project's position on AI assisted contributions.

How is Debian organised?

Debian Developers are the membership

The constitution defines Developers as volunteers who further the project's aims and who either maintain packages or do other work that the Project Leader's delegates consider worthwhile. Section 8.1 also lets delegates designate people as Developers who do not maintain packages, so translators, infrastructure admins and documentation writers can be full voting members.

An individual Developer may, under section 3.1:

• make any technical or nontechnical decision about their own work;
• propose or sponsor draft General Resolutions;
• nominate themselves for Project Leader;
• vote on General Resolutions and in leadership elections.

The first power is the one outsiders miss. A package maintainer is, by default, the decision maker for that package. Nobody above them assigns work. The Technical Committee can overrule a maintainer, but only with a 3:1 majority and only after consensus has failed.

Admission and expulsion are handled by delegates (the Debian Account Managers), not by the leader. The constitution says this is meant to avoid concentrating power over membership in the leader's hands.

How many Developers are there? The vote pages let you work it out. The constitution defines Q as half the square root of the number of current Developers and sets quorum at 3Q. The 2026 leader election page lists a quorum of 48.3502843838586. Divide by 3 to get Q of about 16.117, double it to 32.234, square that, and you get 1,039 Developers at the time of that vote. The same arithmetic on the 2024 election page gives 1,010.

The Social Contract and the DFSG

The Debian Social Contract is the project's public promise to the free software community. The current text is version 1.2, ratified on 1 October 2022. Version 1.1 dates from 26 April 2004 and version 1.0 from 5 July 1997, so the Social Contract is about 17 months older than the constitution.

Its five commitments, in summary:

1. Debian will remain 100% free, judged by the Debian Free Software Guidelines (DFSG).
2. Debian will give back to the free software community.
3. Debian will not hide problems; the bug database is public.
4. Debian's priorities are its users and free software.
5. Works that do not meet Debian's standards get the contrib and non-free areas, and since 2022 official media may include firmware that is not otherwise part of Debian, so Debian can run on hardware that needs it.

The DFSG follows on the same page. It sets the license tests for the main archive: free redistribution, available source code, permission for derived works, a narrow allowance for licenses that protect the integrity of the author's source, no discrimination against persons, groups or fields of endeavour, and license terms that travel with the program. For a Debian user, the practical point is that a component in main has been judged against these tests by a Developer.

Foundation Documents need 3:1

Section 4.1(5) names exactly two Foundation Documents: the Social Contract and the DFSG. Superseding either needs a 3:1 majority. Adding or removing a Foundation Document means amending the constitution, which also needs 3:1. A narrow majority cannot change what "free" means for the archive or drop the promise to keep the bug tracker public. That is the strongest stability guarantee Debian offers.

The constitution and its versions

The constitution page lists every version. The current text is version 1.9.

The voting secrecy vote is a good illustration of how tight a supermajority can be. The winning option, "Hide identities of Developers casting a particular vote and allow verification," needed 3:1 and reached 185 to 61 against the default, a ratio of 3.033. A competing option needing 3:1 reached only 149 to 94 and was dropped.

The six decision makers

Section 2 lists who decides, in a rough order where earlier bodies can usually overrule or appoint later ones:

1. The Developers, by General Resolution or election.
2. The Project Leader.
3. The Technical Committee and/or its Chair.
4. The individual Developer working on a particular task.
5. Delegates appointed by the Project Leader.
6. The Project Secretary.

Two rules hold it together. The Project Leader, the Project Secretary and the Technical Committee Chair must be three different people. And the leader cannot appoint themselves as their own delegate.

What does the Debian Project Leader do?

Powers

Section 5.1 gives the Project Leader (DPL) a short list. The leader may:

• appoint Delegates, or delegate decisions to the Technical Committee;
• lend authority to other Developers through statements of support, which count only where the leader could have made the decision;
• make decisions that need urgent action, or that nobody else is responsible for;
• propose General Resolutions without sponsors;
• appoint Technical Committee members together with the committee;
• use a casting vote in developer ballots, in addition to a normal vote;
• vary discussion and voting periods within limits;
• lead discussions without using the post to push personal views;
• with Developers' consultation, decide on property held in trust for Debian, with major spending debated on a list first;
• add or remove trusted organisations after at least two weeks of public discussion.

What is missing matters as much. The leader cannot overrule a maintainer's technical choice, cannot admit or expel Developers directly, and cannot withdraw a delegated decision once made. Section 8.2 adds that the leader may not tie a delegation to particular decisions by the delegate, nor override a delegate's decision once made.

Delegates do the day to day work

Almost every team you deal with as a Debian user runs on a delegation. The organisation page lists, among others, the release team, archive operations, the Debian Account Managers, and the keyring maintainers who control which OpenPGP keys can upload packages. Each delegation is published by email and linked from that page. The Security Team is listed there too, with eight members and the address team@security.debian.org.

How the DPL is elected each year

Section 5.2 sets a fixed calendar starting six weeks before the post becomes vacant:

If nobody stands, nominations are extended a week at a time. If "None Of The Above" wins, the election is repeated. The quorum matches a General Resolution's.

The last three elections, from the official vote pages:

The 2026 race shows why "None Of The Above" is always on the ballot. Even with one candidate, Developers had a real choice to rerun the election. The leader page currently lists Sruthi Chandran as Project Leader.

Recall, stand ins and the Secretary

Developers can recall the leader by General Resolution. In October 2006 a recall resolution went to a vote and was dropped for failing a simple majority against Further Discussion, 48 to 277. A parallel resolution re-affirming support for the leader passed in the same week.

If there is no leader, the Technical Committee Chair and the Project Secretary may decide jointly, but only when they consider it imperative.

The Secretary runs votes, determines who counts as a Developer, and adjudicates disputes about interpreting the constitution. The leader and the current Secretary appoint the Secretary jointly for a one year term; if they disagree, the Developers decide by General Resolution. The organisation page lists Kurt Roeckx as Secretary.

What is the Technical Committee?

Powers and limits

Section 6.1 lets the Technical Committee (tech-ctte):

1. Decide any matter of technical policy, including the policy manual and the behaviour of non-experimental package build tools.
2. Decide technical matters where Developers' jurisdictions overlap, such as conflicting package priorities, ownership of a command name, or which package owns a bug.
3. Decide when asked by whoever would normally decide.
4. Overrule a Developer, with a 3:1 majority.
5. Offer advice through formal announcements.
6. With the leader, appoint or remove members, and elect its own Chair.

Section 6.3 adds two limits that shape its behaviour more than its powers do. It does no detailed design work, choosing only between proposals already discussed thoroughly elsewhere. And it decides only after consensus has been tried and failed, unless the responsible person asks it to decide. Above it sits the General Resolution: Developers can override any committee decision with 2:1.

Membership and term limits

The committee has up to 8 Developers and should usually have at least 4. Below 8, it recommends new members and the leader decides. At 5 or fewer, it can appoint up to 6 itself, and after a week at that level the leader can too. Anyone who was a member in the previous 12 months cannot be appointed.

Term limits came from the General Resolution "Limiting the term of the technical committee members," voted from 19 December 2014 to 8 January 2015 after a one week extension. It needed 3:1 and the winning option cleared it by 208 to 25, a ratio of 8.32. The rule: on 1 January each year, any member who has served more than 42 months and is one of the two most senior members has their term end on 31 December.

Committee votes run up to one week with a quorum of two, and the Chair has a casting vote. A member whose own decision is being overruled cannot vote on it. Discussion, drafts and votes are public on the debian-ctte list; only discussions about appointments may be private, and appointment votes must still be public.

The organisation page currently lists seven members, with Timo Röhling as Chair.

How to refer a question

The committee's page sets the process. Try to resolve the disagreement first. If that fails, write a summary, ideally agreed with the other side, and file it as a bug against the pseudo package tech-ctte, listing related bugs and list archives. Expect it to take weeks or longer. The committee only handles technical decisions; conduct problems go to the leader.

Notable decisions

The decision list on debian.org says it is not necessarily up to date, but it records the ones most people remember:

The committee repeals its own decisions when circumstances change, and outright overruling is rare.

The 2014 init system decision, and what came after

The init system question is the best example of how the layers interact.

1. February 2014, Technical Committee. In bug #727708 the committee decided systemd should be the default init system for Linux architectures in Debian 8 "jessie."
2. August 2014, Technical Committee. In bug #746715 it added that maintainers should keep supporting the other available init systems.
3. November 2014, General Resolution. Ian Jackson proposed "init system coupling" on 16 October 2014. The ballot offered "Packages may not (in general) require a specific init system," "Support for other init systems is recommended, but not mandatory," "Packages may require specific init systems if maintainers decide," "General Resolution is not required," and "Further Discussion." Voting ran from 5 to 18 November 2014. The vote page lists "General Resolution is not required" as the winner; it was preferred to the first option by 323 voters to 147 and to Further Discussion by 358 to 95.
4. December 2019, General Resolution. "Init systems and systemd" was proposed on 16 November 2019, with the leader moving the end of the minimum discussion period to 30 November. Eight options went to ballot and voting ran from 7 to 27 December 2019. The winner was "B: Systemd but we support exploring alternatives." Its closest rival, "F: Focus on systemd," lost head to head by 185 to 207. Option E, "Support for multiple init systems is Required," was dropped because it did not beat the default (173 to 214).

Read neutrally, the record shows the constitution working as designed. The committee settled a stalled technical dispute, Developers twice used General Resolutions to test whether they wanted to bound that decision, and the published ballots show where preferences landed.

How do General Resolutions work?

Who can propose

Under section 4.2, a resolution or ballot option is introduced by any Developer with at least K sponsors, or by the leader or the Technical Committee. K is Q or 5, whichever is smaller. With about 1,040 Developers, Q is about 16, so K is 5. Any Developer with five sponsors can put a question to the whole project. Proposals, sponsorships and calls for votes go to a public list designated by the leader's delegates, where any Developer may post.

The timeline

Appendix A, the Standard Resolution Procedure, sets the clock:

The three week cap came from "Change the resolution process," proposed by Russ Allbery. It needed 3:1, and voting ran from 15 to 28 January 2022. The winning option, "Amend resolution process, set maximum discussion period," beat Further Discussion by 180 to 24, a ratio of 7.5.

Majorities and supermajorities

A supermajority is tested against the default option, not against the other choices. In the notation of section A.5, an option A beats the default D by ratio N if the number of voters preferring A to D is at least N times the number preferring D to A, and strictly greater. An option that misses its required ratio is dropped before the main count.

How the votes are counted

Every ballot ranks options. Unranked options tie with each other below every ranked one. Section A.5 then runs:

1. Drop options that fail quorum: fewer than 3Q voters ranked them above the default.
2. Drop options that fail their required majority against the default.
3. For each pair of remaining options, A defeats B if more voters prefer A to B than the reverse.
4. Build transitive defeats, then the Schwartz set: the options not beaten, directly or through a chain, by anything they do not beat back.
5. If there are defeats inside the Schwartz set, drop the weakest and repeat.
6. When no defeats remain inside the set, its members win; if there are several, whoever holds the casting vote chooses.

The vote pages call this "Condorcet/Clone Proof SSD," after the 2003 amendment of that name. SSD stands for Schwartz Sequential Dropping, from the family of methods commonly called Schulze. The constitution describes the steps without naming an author.

Worked example 1: the 2022 non-free firmware vote

This vote shows the supermajority filter in action. Discussion ran from 18 August to 15 September 2022, extended by 7 days by the leader. Voting ran from 18 September to 1 October 2022. The seven options were:

1. Only one installer, including non-free firmware
2. Recommend installer containing non-free firmware
3. Allow presenting non-free installers alongside the free one
4. Installer with non-free software is not part of Debian
5. Change SC for non-free firmware in installer, one installer
6. Change SC for non-free firmware in installer, keep both installers
7. None of the above

Options 5 and 6 changed the Social Contract, so the vote page says they needed 3:1. The first filter, from the published majority table:

Then the pairwise stage. Option 5 was preferred to option 1 by 229 to 72, to option 2 by 219 to 121, to option 3 by 229 to 127, and to option 6 by 169 to 163. That last margin was six voters. Option 5 beat every other option head to head, so it was the only member of the Schwartz set and the official winner. Social Contract version 1.2 is dated 1 October 2022, the last day of voting.

The practical result appears in the Debian 12 "bookworm" release notes: a new archive area, non-free-firmware, was introduced, most non-free firmware packages moved into it, and official installation images could include packages from main and non-free-firmware without contrib or non-free.

Worked example 2: the 2026 vote on AI assisted contributions

The most recent General Resolution on the vote index is "LLM usage in Debian." Discussion ran from 23 July to 13 August 2026 (extended), and voting from 15 to 28 August 2026. Nine options appeared, from "Ban LLM contributions from Debian via Social Contract" through "Responsible Use of Generative AI" to "None of the above."

Option 1 would have changed the Social Contract, so the vote page says it needed 3:1. It reached 144 to 257 against None of the above, a ratio of 0.560, and was dropped. Option 3, "Reject LLMs as far as practical, update Code of Conduct," needed only a simple majority and was also dropped at 176 to 230. The six other options passed the default.

In the pairwise stage, option 5, "Responsible Use of Generative AI," was preferred to every other surviving option, including "Allow AI-Assisted Contributions with conditions" by 203 to 148 and "A cautious approach to generative AI" by 210 to 130. Against None of the above it stood at 281 to 126. The vote page lists it as the winner.

The winning text is a position statement under the section 4.1(5) power. It says Debian neither endorses nor prohibits generative AI tools, that all contributions must meet the same quality, correctness and legal standards however they were produced, that contributors remain responsible for what they submit and should review AI assisted output, and that disclosing AI assistance is encouraged but not required. It also says the position can evolve without another General Resolution.

For downstream users the change is narrow: no license rule or Foundation Document changed.

Other votes worth knowing

• Social Contract editorial amendments, 2004. Voting closed on 25 April 2004. The page notes 3:1 was required because the Social Contract is a foundation document; it passed 174 to 39 (4.462). Version 1.1 is dated the next day.
• EU Cyber Resilience Act and Product Liability Directive, 2023. Voting ran from 9 to 22 December 2023. The winner, "CRA and PLD proposals include regulations detrimental to FOSS," was preferred to None of the above by 121 to 35. It was a simple majority position statement.
• Firmware history. The index also lists "Handling source-less firmware in the Linux kernel" (2006) and "Lenny and resolving DFSG violations" (2008), so the 2022 vote was the latest step in a long running question.

Software in the Public Interest and the trusted organisations

Why Debian needs them

Section 9 of the constitution notes that in most jurisdictions Debian cannot directly hold funds or other property. It has no legal personality, so it cannot sign a contract, hold a bank account or register a trademark in its own name.

SPI

Software in the Public Interest describes itself as a New York nonprofit that acts as a fiscal sponsor for open source software and hardware projects. According to its website, it was incorporated on 16 June 1997, and in 1999 the US Internal Revenue Service determined it qualifies for 501(c)(3) status, so US donations to it and its projects are tax deductible. Its board includes four officers: President, Vice President, Secretary and Treasurer.

The constitution records that SPI was traditionally the sole organisation authorised to hold property and money for Debian. Debian's trademark page states that the Debian trademark is a registered United States trademark of SPI.

The firewall between money and decisions

Section 9.2 is what makes this work without a company. An organisation holding assets for Debian "has no authority regarding Debian's technical or nontechnical decisions," except that Debian cannot require it to act outside its legal authority. Debian in turn claims no authority over that organisation beyond the use of property held in trust.

Section 9.1 adds that Developers do not become agents or employees of SPI, of each other, or of anyone in authority in Debian just by being Developers. Section 9.3 lets the leader designate several trusted organisations, and Debian publishes a list of them with the commitments each has made about handling assets.

For a company, that means you can donate through a trusted organisation and sponsor events, but you cannot buy a technical decision that way, because the organisation that takes your money cannot make one. Companies influence Debian the way individuals do: by funding or employing people who do the work in public and become Developers.

How governance reaches security

The Security Team

The Security Team is a delegated team. Its FAQ answers what enterprise teams usually ask:

• How long is a release supported? The team supports a stable distribution for three years after its release, and does not support three distributions at once.
• Does every CVE get a Debian Security Advisory (DSA)? No. The team tracks every CVE, maps it to Debian packages and assesses impact in a Debian context. Low impact issues may be fixed in a point release, the next release, or folded into a later DSA.
• Can Debian assign CVE IDs? Yes, Debian is a CVE Numbering Authority and publishes a vulnerability disclosure policy.
• What about scanner reports listing open CVEs? The FAQ points to the public security tracker and suggests asking the scanning tool's vendor about triage differences.

Nothing in the constitution compels the Security Team to fix a particular bug by a particular date. Its scope comes from its delegation and the release support commitments.

Long Term Support is a separate group

Debian's LTS page says LTS aims to extend every stable release to at least five years, and that it is not handled by the Security Team but by a separate group of volunteers and companies. The LTS team takes over once the Security Team stops, and it publishes its own advisories, called DLAs. The same page notes that Extended Long Term Support exists beyond that. Check which packages and architectures LTS covers for your release before planning around it. Our post on Debian 11 bullseye end of life, LTS and ELTS dates walks through one release, and the Debian release history post lists every version's support dates.

Where votes change what you ship

The firmware vote is the one most likely to touch a build pipeline. If you build images or machine templates from Debian 12 or later, your apt sources decide whether non-free-firmware is enabled, and so whether firmware blobs land in your images.

Debian, a foundation hosted project and a single vendor project

For more on other models, see open source foundation governance models, Linux Foundation and Apache governance compared, and BDFL, meritocracy or liberal contribution governance. If you accept contributions to your own projects, the Developer Certificate of Origin post covers a lighter weight way to record contributor responsibility.

Step by step: what a company that depends on Debian should do

1. Find out where you run Debian

# On a host or inside a running container
cat /etc/debian_version
grep -E '^(ID|VERSION_CODENAME|VERSION_ID)=' /etc/os-release

# For an image you build or pull (read only)
docker run --rm --entrypoint cat debian:bookworm-slim /etc/os-release

Record each codename; it sets your security support window.

2. Subscribe to the lists that carry decisions

Subscribe at lists.debian.org. For a walkthrough of the advisory lists, see how to subscribe to Ubuntu and Debian security advisories.

3. Check what a decision changed in your sources

After the 2022 firmware vote, check which archive areas your systems enable.

# Classic one line format
grep -rhE '^\s*deb ' /etc/apt/sources.list /etc/apt/sources.list.d/*.list 2>/dev/null

# deb822 format used by newer installs
grep -rh -A4 '^Types:' /etc/apt/sources.list.d/*.sources 2>/dev/null

# Which firmware packages are installed
dpkg -l | awk '/^ii/ && $2 ~ /firmware/ {print $2, $3}'

A deb822 source for bookworm that allows firmware but not the rest of non-free:

Types: deb
URIs: http://deb.debian.org/debian
Suites: bookworm bookworm-updates
Components: main non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Decide on purpose whether base images include non-free-firmware. Containers rarely need it; bare metal and laptops often do.

4. Read vote results from the source

Every General Resolution page has the ballot, majority table, beat matrix and winner. You can pull the headline with a script:

curl -s https://www.debian.org/vote/2022/vote_003 \
  | sed -e 's/<[^>]*>//g' \
  | grep -A3 -E 'Majority Requirement|The winners'

Then read the winning text, linked from the same page.

5. Track security status per package

The Security Team triages in a Debian context. A CVE your scanner flags may be marked not affected, minor, postponed, or fixed by a backport with an older looking version number.

apt-get update
apt list --upgradable 2>/dev/null | grep -i security

# The changelog records the CVEs fixed in each upload
apt-get changelog openssl | head -n 40

See how to check a CVE in the Debian security tracker, what the tracker statuses mean and why a Debian version number can look vulnerable when it is not.

6. Plan against both windows

Put both end dates for each codename on your release calendar. Treat regular support as the target and LTS as a buffer.

7. Contribute through the proper channels

• Bugs: file with reportbug against the right package so they reach the maintainer.
• Security issues: contact the Security Team at the address on the organisation page, following Debian's disclosure policy.
• Technical disputes: after consensus fails, file against the tech-ctte pseudo package.
• Fixes: send patches to the maintainer or the package's team repository, and upstream where the bug starts.
• People: fund or employ engineers who work in public and, over time, become Developers. That is how companies earn a voice in Debian.

sudo apt-get install reportbug
reportbug <package-name>

Common mistakes

Assuming Debian has a corporate owner you can contract. There is none. SPI holds assets and the trademark but has no authority over decisions. If you need a fix on a schedule, you need your own engineers, a company that sells support, or your own patched build.

Treating LTS like the main security period. The Security Team supports a stable release for about three years. LTS is a separate group with separate advisories (DLAs). Plan upgrades against the regular window.

Ignoring General Resolutions that change packaging. The 2022 firmware vote changed what official installers contain and added an archive area. An image build script written before bookworm may include or exclude firmware in a way nobody chose.

Reading a headline instead of the ballot. The vote page shows every option, the majority test and the head to head counts. A margin like 169 to 163 between the two firmware options that changed the Social Contract is context summaries drop.

Assuming every CVE gets a DSA. Low impact issues may be fixed in a point release or the next release. Track the status in the tracker.

Forgetting decisions can be repealed. The committee has repealed its own past decisions. Re-check positions your architecture relies on.

FAQ

Who owns Debian?

No company. Debian is a volunteer project governed by its constitution. Its assets, including the registered US trademark, are held in trust by organisations such as Software in the Public Interest, which have no authority over Debian's decisions.

How is the Debian Project Leader elected?

Every year, starting six weeks before the term ends, Developers nominate themselves for one week, campaign for three and vote for two. Ballots rank the candidates and "None Of The Above." The winner serves one year.

Who is the current Debian Project Leader?

The debian.org leader page lists Sruthi Chandran. She was the sole candidate in the April 2026 election, with 289 voters ranking her above None of the above and 50 the other way. Her term began on 21 April 2026.

What does the Debian Technical Committee do?

It decides technical policy and disputes between Developers when consensus fails, answers questions referred to it, offers advice, and can overrule a Developer with 3:1. It has up to eight members and does not do design work.

What is a Debian General Resolution?

A decision by all Developers. Any Developer can propose one with K sponsors (currently 5). It is discussed for two to three weeks and voted on for two. It can override the leader, override the Technical Committee with 2:1, amend the constitution with 3:1, or issue position statements.

Does Debian include non-free firmware now?

Yes, on official media. Since the 2022 General Resolution, the Social Contract allows official media to include firmware that is not otherwise part of Debian. From Debian 12 it lives in a separate non-free-firmware archive area.

How long does Debian provide security updates?

The Security Team supports each stable release for about three years. The separate LTS group aims to extend each release to at least five years, with its own advisories.

What did Debian decide about AI generated contributions?

In August 2026 Developers adopted "Responsible Use of Generative AI." Debian neither endorses nor prohibits the tools, contributors stay responsible for everything they submit, and disclosure is encouraged but not required.

Where Safeguard fits

Safeguard does not govern, package or patch Debian, and it has no role in Debian's votes or its Security Team. The fit is indirect and sits one layer up: the open source dependencies and container layers your teams build on top of a Debian base image. Debian's own fixes still arrive through DSAs and DLAs, so rebuilding images when they land remains your job.

Debian's governance decides when a fix reaches the archive, and nothing in its constitution obliges anyone to ship one on your schedule. Your application dependencies carry the same gap between a published fix and a fix in production, which is why the practices below still matter for teams that build on Debian.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. You install it, run safeguard to open the interactive terminal and ask it to fix the lodash CVE in a repository. It reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same flow applies to the application layers you put on a Debian base image, and /scan . gives you a starting inventory.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. For teams that keep Debian based build hosts on their own network, this is how scans can run where the code already lives.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. Once connected, you can ask which projects in your account are affected by a vulnerability, which helps decide which Debian based images to rebuild first after an advisory.

Click through it at your own pace, or open it full screen.

To try it on your own projects, download Safeguard or read the CLI documentation.

Quick check

Sources

• Debian Constitution
• Debian Social Contract and Debian Free Software Guidelines
• Debian Project Leader
• Debian Technical Committee
• Debian Organizational Structure
• Debian Voting Information (vote index)
• Debian Project Leader Elections 2024
• Debian Project Leader Elections 2025
• Debian Project Leader Elections 2026
• GR: Editorial amendments to the social contract (2004)
• GR: Sarge Release Schedule in view of GR 2004-003
• Constitutional amendment: Handling assets for the project (2006)
• GR: Recall the project leader (2006)
• GR: Re-affirm support to the Debian Project Leader (2006)
• Constitutional amendment: Reduce the length of DPL election process (2007)
• GR: init system coupling (2014)
• GR: Limiting the term of the technical committee members (2014)
• GR: Update Standard Resolution Procedure (2015)
• GR: Replace Chairman with Chair (2016)
• GR: Init systems and systemd (2019)
• GR: Change the resolution process (2022)
• GR: Voting secrecy (2022)
• GR: non-free firmware (2022)
• GR: Statement about the EU Cyber Resilience Act and Product Liability Directive (2023)
• GR: LLM usage in Debian (2026)
• Debian 12 release notes: What's new
• Debian security FAQ
• Debian Long Term Support
• Debian Trademarks
• Software in the Public Interest

Last reviewed: 25 October 2026. Debian's leader, committee membership and delegations change over time; check the linked debian.org pages before relying on a specific name or date.