The key terms around open-source operations, SBOM, security processes, regulation and the public sector — explained concisely and precisely. A reference for teams that own open-source responsibility.
An Open Source Program Office is the function in an organisation that owns how open source is handled: the inventory of components in use, licence questions, security processes and communication with the open-source projects. Large technology companies run dedicated teams for this; an external OSPO provides the same function as a contractually defined service.
Managed open source operations means the continuous, externally owned operation of an organisation’s open-source base: inventory and SBOM, monitoring of vulnerabilities and lifecycle, triage and support processes, and the work with upstream projects. The difference to classic consulting: it is not about recommendations, but about permanently assumed operational responsibility with defined processes.
Maintainers are the people who look after an open-source project: they review contributions, decide on changes, publish releases and handle security reports. Many critical components are maintained by a handful of volunteers — no outsider can guarantee their response times or priorities, which is why serious providers only commit to their own processes.
“Upstream” refers to the origin project of an open-source component — bug reports, patches and improvements flow back there. Upstream delivery means doing this professionally: issues filed by the project’s rules, security findings through private channels, own patches, and seeing a pull request through merge and release. Only problems solved upstream stay solved; local workarounds must be re-maintained with every update.
An SBOM is the machine-readable parts list of a piece of software: it records every contained component with version, origin and licence. It is the basis for knowing immediately whether and where you are affected when a new vulnerability appears — and is increasingly required as evidence by regulation such as the EU Cyber Resilience Act and by customers. The established formats are SPDX and CycloneDX.
SPDX and CycloneDX are the two established standard formats for SBOMs. SPDX originates from the Linux Foundation and is internationally standardised as ISO/IEC 5962; CycloneDX was developed in the OWASP community and published as an Ecma standard, with a focus on security use cases. Which one is required depends on the recipient — tools and providers should be able to produce both.
SOURCE: spdx.dev ↗ · cyclonedx.org ↗
Open-source licences permit use under conditions — from permissive licences such as MIT or Apache-2.0 to copyleft licences such as the GPL, which attach obligations to distribution. Licence compliance means knowing every component and its licence, meeting obligations such as source or attribution requirements, and avoiding conflicts between licences. The technical determination is diligent work on top of the inventory; the legal assessment of individual cases remains a matter for specialised lawyers.
The software supply chain covers everything that flows into a software product: direct and transitive dependencies, build tools, registries and update channels. Supply chain security means making this chain transparent and securing it — attacks such as compromised packages or hijacked maintainer accounts hit every user of a component at once. Inventory, SBOM and continuous monitoring are the basic tools.
CVE is the international system for uniquely identifying publicly known security vulnerabilities; each one receives an identifier such as CVE-2021-44228 (Log4Shell). A CVE announcement does not yet tell you whether your organisation is affected — that depends on the deployed version, configuration and context of use, and is the job of triage.
SOURCE: cve.org ↗
Triage is the structured initial assessment of a reported vulnerability or defect: does it affect us? In which version, in which system, with what exploitability? It is followed by prioritisation, workaround or patch, and tracking through to resolution. Without a defined triage process, chance decides which report gets attention — with one, you get a dependable, documented procedure with times and responsibilities.
Coordinated (also: responsible) vulnerability disclosure is the practice of reporting security flaws in an orderly way: first confidentially to the project’s maintainers through their private security channels, publishing only once a fix is available. This protects every user of the affected component. Public issues or social-media posts about unfixed vulnerabilities are considered unprofessional and increase the risk of active exploitation.
End-of-life is the point from which a component or version no longer receives maintenance — including security updates. In open source this often happens quietly: a maintainer moves on, a branch is discontinued. Lifecycle management means continuously watching release and support cycles, anticipating EOL dates and planning migrations before an unmaintained component becomes a security risk.
The Cyber Resilience Act (Regulation (EU) 2024/2847) obliges manufacturers of products with digital elements to ensure cybersecurity across the entire lifecycle: risk assessment, vulnerability handling, SBOM and security updates. The regulation entered into force on 10 December 2024; the reporting obligations under Art. 14 apply from 11 September 2026, the full manufacturer obligations from 11 December 2027. Anyone shipping community open source must actively own its security.
With the “open-source software steward”, the CRA introduces a category of actor of its own: organisations — foundations, for example — that provide sustained, systematic support for the development of specific open-source products intended for commercial activities. Stewards face a reduced set of obligations, not the full manufacturer catalogue. Importantly: merely building open source into your own products does not make you a steward — it makes you a manufacturer with the regular obligations for the overall product.
Technical Guideline TR-03183 of the German Federal Office for Information Security (BSI) specifies cyber-resilience requirements for manufacturers and products; its second part defines formal and content requirements for SBOMs. In Germany it serves as the practical benchmark for setting up SBOM capability and vulnerability processes in a CRA-ready way.
NIS2 (Directive (EU) 2022/2555) is the EU directive on network and information security. It obliges essential and important entities — including many operators of public infrastructure — to risk management, incident reporting and supply-chain security; national implementation specifies scope and duties. For organisations with a large open-source estate this means: demonstrable processes for inventory, vulnerabilities and the supply chain, including for software without a vendor.
IT-Grundschutz is the BSI’s methodology for information security management, firmly established in German public administration: modules, threats and requirements from which an auditable security concept is derived — compatible with ISO 27001. For open-source operations it provides the evidence framework that inventory, vulnerability management and operating processes feed into.
Evidence for NIS2 and IT-Grundschutz in the public-sector offering →
Digital sovereignty is the ability of states and organisations to shape and operate their digital infrastructure autonomously — without critical dependence on individual vendors. Open source is a central building block for this, but it shifts responsibility inward: with no vendor behind the software, a clearly assigned operational owner is needed for security, lifecycle and further development.
openDesk is the open-source workplace for German public administration, built from established open-source components and stewarded by the Centre for Digital Sovereignty (ZenDiS). It exemplifies the administration’s strategic turn towards open source — and the follow-on question of who permanently owns operations, security processes and upstream work for the components in use.
SOURCE: opendesk.eu ↗
Direct award (Direktauftrag) and the negotiated procedure without a call for competition (Verhandlungsvergabe) are simplified procedures of German procurement law below the EU thresholds: a direct award places a contract without a formal procedure, while in a negotiated procedure selected companies are invited directly to submit offers. Which value limits apply depends on the contracting authority and the current rules — the assessment always rests with the contracting authority.
ALVPHA Upstream takes on exactly the tasks described here as an external, contractually defined service — for manufacturers under the CRA and for the public sector.
This glossary explains terms in plain language and does not constitute legal advice. Only the respective legal texts and a case-by-case assessment are authoritative.
