Skip to content
Checklists
Standards, specifications and principles

Standards, specifications and principles

Purpose: Overview of the standards, specifications and frameworks the checklists build on.

Digg’s governing documents

This handbook is a supporting document that concretises, complements and eases practical compliance with:

Principles

The policy sets out six guiding principles for working with open source software:

  1. 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.
  2. Reusability: shared investments yield efficiency. Digg’s solutions shall be designed to be reusable.
  3. Contribution: active participation in open collaboration strengthens both Digg’s own self-determination and the public sector at large.
  4. 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.
  5. Open standards: interoperability and reduced lock-in; freedom to switch suppliers.
  6. Transformation: shared digital administration requires openness as a foundation and continuous improvement through knowledge-sharing.

Compliance, metadata and SBOM formats

REUSE specification: standard for tagging every file with its licence and copyright.
→ See: Licensing, Release preparation

ISO/IEC 5230 (OpenChain): standard for how an organisation keeps its open source licences in order (OpenChain).
→ See: Licensing, Release preparation

SPDX (ISO/IEC 5962): format for licence information and a software bill of materials (SBOM).
→ See: Licensing, Security

CycloneDX: a list of the components that make up a piece of software (SBOM format), an alternative to SPDX.
→ See: Security

PublicCode.yml specification: a standard file describing a public-sector software project so it is easier to find and reuse.
→ See: Release preparation

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

Versioning and release practice

Basis for Release preparation and Release 1.0.0.

Conventional Commits: rules for commit messages that let changelogs and version numbers be generated automatically.

Keep a Changelog: user-friendly release history.

Semantic Versioning 2.0.0: consistent version numbering.

Community and contributions

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: Release preparation, Upstream contribution

TODO Group: practices and templates for running an open source program office (OSPO).
→ See: Upstream contribution

Secure development and vulnerability handling

Basis for Security; a few frameworks also point on to other checklists.

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

OpenSSF Concise Guide for Developing More Secure Software: a concise guide to secure software development.
→ See also: Working on a code-collaboration platform

ISO/IEC 27001/2: information classification and information security.

OWASP ASVS: checklist of requirements for verifying application security (Application Security Verification Standard). The guidelines explicitly cite OWASP as a reference framework.

OWASP Cheatsheets and OWASP Software Developer Guide: practical guidance for secure development.

SAFECode Fundamental Practices for Secure Software Development: established principles for secure software development.

Supply chain and release security

Basis for Security.

OpenSSF Scorecard: automated check that scores a project’s security practices and suggests improvements.

Sigstore: tooling to sign software artefacts and prove where they came from (e.g. cosign).

SLSA: framework of security levels that protect the software supply chain from tampering (Supply-chain Levels for Software Artifacts).

ISO/IEC 18974: standard for systematic security work in the supply chain (OpenChain Security Assurance).

CNCF Security TAG — Software Supply Chain Security Paper: best practices for secure software supply chains.

Licences

A selection of common licence choices per the guidelines and Digg’s recommendation on open licences and intellectual property rights; see the licensing checklist for choice and compatibility in practice.

EUPL 1.2: European Union Public Licence; copyleft (requires that further development stays open), legally binding in Swedish, handles SaaS and is compatible with several member states’ legislation. First choice among copyleft licences.

GPL-3.0 and AGPL-3.0: strong copyleft licences; AGPL also covers network distribution (SaaS).

LGPL-3.0: weaker copyleft for libraries; a common licence convention in some ecosystems.

MIT and Apache-2.0: permissive licences when both open and closed further development are to be allowed; Apache-2.0 provides an explicit patent grant.

CC0 1.0: waiver of copyright for documentation, examples and open data (not code).

External resources and community

Education and knowledge

Swedish public sector

International resources

Recordkeeping and archiving