Standards, specifications and principles

Purpose: Overview of the standards, specifications and frameworks the checklists build on. For operational check-points, see the respective checklist.

Digg’s governing documents

The checklists put into practice and complement:

Digg: Policy on open source software (Reg. no. 2026-02796, decided 2026-04-07, valid until 2029-03-26)
Digg: Guidelines on open source software (Reg. no. 2026-02797, decided 2026-04-07, valid until 2029-03-06)

The guidelines explicitly state that checklists and templates are part of the supporting documents: “As a complement to the guidelines there are detailed procedures and supporting documents — checklists and templates that describe how the various activities shall be carried out in practice.”

Six principles (from the policy)

Openness: insight into technical solutions and processes builds trust. Restrictions shall apply only when required by personal integrity or security, and only to the extent necessary.
Reusability: shared investments yield efficiency. Digg’s solutions shall be designed to be reusable.
Contribution: active participation in open collaboration strengthens both Digg’s own self-determination and the public sector at large.
Security: transparency increases the ability to handle vulnerabilities; in-house operation reduces vulnerability in a crisis; control over the code makes security action possible across the lifetime.
Open standards: interoperability and reduced lock-in; freedom to switch suppliers.
Transformation: shared digital administration requires openness as a foundation and continuous improvement through knowledge-sharing.

Two main flows + common frames (from the guidelines)

The guidelines describe the work in two flows plus common frames:

Flow	Activities
Use and acquire	Lifecycle management, Acquiring open source software
Develop and publish	Lifecycle management, Develop, Publish, Handle contributions
Common frames	Security throughout the lifecycle, Licences and compatibility, Documentation/procedures/project health

Responsibility model

Department/operational manager (information owner): overall responsibility for compliance within their own operation.
System owner / operational unit manager: software is handled in line with the guidelines; risks, licences, dependencies and security are followed up.
Operational team: day-to-day work with code, dependencies, issues, external contributions, documentation.

Licence specifications

REUSE specification: clear and standardised licence compliance.
→ See: Licensing, Release preparation

ISO/IEC 5230 (OpenChain): Open Source License Compliance.
→ See: Publication and stewardship

SPDX (ISO/IEC 5962): licence and SBOM format.
→ See: Licensing, Security

EUPL 1.2: European Union Public Licence; legally binding in Swedish, handles SaaS, compatible with several member states’ legislation.
→ See: Licensing

Commits and versioning

Conventional Commits: structured project history.
→ See: Release preparation

Keep a Changelog: user-friendly release history.
→ See: Release preparation

Semantic Versioning 2.0.0: consistent version numbering.
→ See: Release preparation

Community and collaboration

Contributor Covenant: code of conduct for respectful and inclusive collaboration.
→ See: Issues and contributions

Developer Certificate of Origin (DCO): contributors certify the right to contribute.
→ See: Upstream contribution

TODO Group: OSPO practice and policy templates.
→ See: Upstream contribution

Security and quality

OpenSSF OSPS Baseline: minimum security controls at three maturity levels. (The guidelines explicitly state that recommendations from OpenSSF should be used where relevant.)
→ See: Security, Working on a code-collaboration platform, Release preparation

OpenSSF Concise Guide for Developing More Secure Software: 29 practices for secure software development.
→ See: Security, Working on a code-collaboration platform

OpenSSF Scorecard: assess and improve security health.
→ See: Security

Sigstore: artefact signing (cosign) and provenance.
→ See: Security

SLSA: Supply-chain Levels for Software Artifacts.
→ See: Security

ISO/IEC 18974: Security Assurance.
→ See: Security

ISO/IEC 27001/2: information classification and information security.
→ See: Security

OWASP ASVS: Application Security Verification Standard. (The guidelines explicitly cite OWASP as a reference framework.)
→ See: Security

OWASP Cheatsheets and OWASP Software Developer Guide.
→ See: Security

CycloneDX: SBOM format, alternative to SPDX.
→ See: Security

SAFECode Fundamental Practices for Secure Software Development
→ See: Security

CNCF Security TAG — Software Supply Chain Best Practices
→ See: Security

Metadata and discoverability

PublicCode.yml specification: metadata indexing for better discoverability.
→ See: Release preparation

Standard for Public Code: 16 criteria for quality and sustainability in public code.
→ See: Release preparation, Security, Issues and contributions

Regulations and ordinances

Interoperability Regulation (EU) 2024/903: EU regulation on measures for a high level of interoperability in the public sector. Referenced explicitly in Digg’s policy and guidelines.
→ See: Procurement

European Interoperability Framework (EIF): recommendations for interoperability.
→ See: Procurement

SOU 2009:86 (in Swedish): Strategy for the public agencies’ work with e-government. Defines open standards for procurement.
→ See: Procurement

Freedom of the Press Act (1949:105) (in Swedish): public access to records.
→ See: Recordkeeping and archiving

Public Access to Information and Secrecy Act (2009:400) (in Swedish)
→ See: Recordkeeping and archiving

GDPR / Data Protection Regulation: when personal data appears in open code, issues or pull requests.
→ See: Recordkeeping and archiving, Security

External resources and community