From 1f403dde594948b5097f73c859ded097c191d451 Mon Sep 17 00:00:00 2001 From: Eddie Knight Date: Thu, 21 Aug 2025 06:18:33 -0500 Subject: [PATCH 1/2] chore: update cmd/ to use Gemara v0.4.1 Signed-off-by: Eddie Knight --- cmd/go.mod | 8 +- cmd/go.sum | 21 +++- cmd/internal/cmd/compile.go | 21 +--- cmd/internal/cmd/oscal.go | 14 +-- cmd/internal/cmd/validate.go | 9 +- .../{generator.go => export-markdown.go} | 22 ++-- cmd/pkg/baseline/generator_oscal.go | 119 ------------------ cmd/pkg/baseline/loader.go | 98 +++++---------- cmd/pkg/baseline/template-functions.go | 6 +- .../baseline/{validator.go => validate.go} | 12 +- cmd/pkg/types/types.go | 32 ----- cmd/template.md | 2 +- 12 files changed, 77 insertions(+), 287 deletions(-) rename cmd/pkg/baseline/{generator.go => export-markdown.go} (68%) delete mode 100644 cmd/pkg/baseline/generator_oscal.go rename cmd/pkg/baseline/{validator.go => validate.go} (75%) delete mode 100644 cmd/pkg/types/types.go diff --git a/cmd/go.mod b/cmd/go.mod index 7b014a3e..2cc6776d 100644 --- a/cmd/go.mod +++ b/cmd/go.mod @@ -5,13 +5,17 @@ go 1.24 toolchain go1.24.1 require ( - github.com/defenseunicorns/go-oscal v0.6.3 github.com/goccy/go-yaml v1.18.0 - github.com/revanite-io/sci v0.3.8 + github.com/ossf/gemara v0.4.1 github.com/spf13/cobra v1.9.1 ) require ( + github.com/defenseunicorns/go-oscal v0.6.3 // indirect + github.com/google/uuid v1.6.0 // indirect github.com/inconshreveable/mousetrap v1.1.0 // indirect + github.com/santhosh-tekuri/jsonschema/v6 v6.0.2 // indirect github.com/spf13/pflag v1.0.6 // indirect + golang.org/x/text v0.25.0 // indirect + gopkg.in/yaml.v3 v3.0.1 // indirect ) diff --git a/cmd/go.sum b/cmd/go.sum index 8d05305f..d69d5e40 100644 --- a/cmd/go.sum +++ b/cmd/go.sum @@ -1,23 +1,32 @@ github.com/cpuguy83/go-md2man/v2 v2.0.6/go.mod h1:oOW0eioCTA6cOiMLiUPZOpcVxMig6NIQQ7OS05n1F4g= -github.com/davecgh/go-spew v1.1.1 h1:vj9j/u1bqnvCEfJOwUhtlOARqs3+rkHYY13jYWTU97c= -github.com/davecgh/go-spew v1.1.1/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38= +github.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc h1:U9qPSI2PIWSS1VwoXQT9A3Wy9MM3WgvqSxFWenqJduM= +github.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38= github.com/defenseunicorns/go-oscal v0.6.3 h1:3j5aBobVX+Fy2GEIRCeg9MhsAgCKceOagVEDQPMuzZc= github.com/defenseunicorns/go-oscal v0.6.3/go.mod h1:m55Ny/RTh4xWuxVSOD/poCZs9V9GOjNtjT0NujoxI6I= +github.com/dlclark/regexp2 v1.11.0 h1:G/nrcoOa7ZXlpoa/91N3X7mM3r8eIlMBBJZvsz/mxKI= +github.com/dlclark/regexp2 v1.11.0/go.mod h1:DHkYz0B9wPfa6wondMfaivmHpzrQ3v9q8cnmRbL6yW8= github.com/goccy/go-yaml v1.18.0 h1:8W7wMFS12Pcas7KU+VVkaiCng+kG8QiFeFwzFb+rwuw= github.com/goccy/go-yaml v1.18.0/go.mod h1:XBurs7gK8ATbW4ZPGKgcbrY1Br56PdM69F7LkFRi1kA= +github.com/google/uuid v1.6.0 h1:NIvaJDMOsjHA8n1jAhLSgzrAzy1Hgr+hNrb57e+94F0= +github.com/google/uuid v1.6.0/go.mod h1:TIyPZe4MgqvfeYDBFedMoGGpEw/LqOeaOT+nhxU+yHo= github.com/inconshreveable/mousetrap v1.1.0 h1:wN+x4NVGpMsO7ErUn/mUI3vEoE6Jt13X2s0bqwp9tc8= github.com/inconshreveable/mousetrap v1.1.0/go.mod h1:vpF70FUmC8bwa3OWnCshd2FqLfsEA9PFc4w1p2J65bw= -github.com/pmezard/go-difflib v1.0.0 h1:4DBwDE0NGyQoBHbLQYPwSUPoCMWR5BEzIk/f1lZbAQM= -github.com/pmezard/go-difflib v1.0.0/go.mod h1:iKH77koFhYxTK1pcRnkKkqfTogsbg7gZNVY4sRDYZ/4= -github.com/revanite-io/sci v0.3.8 h1:XbbUmpGgWgf0VZouZhoMH0P/wntbJ98AydBgewk5kCw= -github.com/revanite-io/sci v0.3.8/go.mod h1:lEK7w8kfwWUXFKYoJYyqzTT74umE4OkOlRYp88uxHhc= +github.com/ossf/gemara v0.4.1 h1:cYhpx9UA6c5GtPopg1RAvcTbrYmXHTQq49aXka/axMk= +github.com/ossf/gemara v0.4.1/go.mod h1:QbrMmCw7Gt59wKY/GyDvTTxk1kd53qpF1K+Kd9szlAc= +github.com/pmezard/go-difflib v1.0.1-0.20181226105442-5d4384ee4fb2 h1:Jamvg5psRIccs7FGNTlIRMkT8wgtp5eCXdBlqhYGL6U= +github.com/pmezard/go-difflib v1.0.1-0.20181226105442-5d4384ee4fb2/go.mod h1:iKH77koFhYxTK1pcRnkKkqfTogsbg7gZNVY4sRDYZ/4= github.com/russross/blackfriday/v2 v2.1.0/go.mod h1:+Rmxgy9KzJVeS9/2gXHxylqXiyQDYRxCVz55jmeOWTM= +github.com/santhosh-tekuri/jsonschema/v6 v6.0.2 h1:KRzFb2m7YtdldCEkzs6KqmJw4nqEVZGK7IN2kJkjTuQ= +github.com/santhosh-tekuri/jsonschema/v6 v6.0.2/go.mod h1:JXeL+ps8p7/KNMjDQk3TCwPpBy0wYklyWTfbkIzdIFU= github.com/spf13/cobra v1.9.1 h1:CXSaggrXdbHK9CF+8ywj8Amf7PBRmPCOJugH954Nnlo= github.com/spf13/cobra v1.9.1/go.mod h1:nDyEzZ8ogv936Cinf6g1RU9MRY64Ir93oCnqb9wxYW0= github.com/spf13/pflag v1.0.6 h1:jFzHGLGAlb3ruxLB8MhbI6A8+AQX/2eW4qeyNZXNp2o= github.com/spf13/pflag v1.0.6/go.mod h1:McXfInJRrz4CZXVZOBLb0bTZqETkiAhM9Iw0y3An2Bg= github.com/stretchr/testify v1.10.0 h1:Xv5erBjTwe/5IxqUQTdXv5kgmIvbHo3QQyRwhJsOfJA= github.com/stretchr/testify v1.10.0/go.mod h1:r2ic/lqez/lEtzL7wO/rwa5dbSLXVDPFyf8C91i36aY= +golang.org/x/text v0.25.0 h1:qVyWApTSYLk/drJRO5mDlNYskwQznZmkpV2c8q9zls4= +golang.org/x/text v0.25.0/go.mod h1:WEdwpYrmk1qmdHvhkSTNPm3app7v4rsT8F2UD6+VHIA= +gopkg.in/check.v1 v0.0.0-20161208181325-20d25e280405 h1:yhCVgyC4o1eVCa2tZl7eS0r+SDo693bJlVdllGtEeKM= gopkg.in/check.v1 v0.0.0-20161208181325-20d25e280405/go.mod h1:Co6ibVJAznAaIkqp8huTwlJQCZ016jof/cbN4VW5Yz0= gopkg.in/yaml.v3 v3.0.1 h1:fxVm/GzAzEWqLHuvctI91KS9hhNmmWOoWu0XTYJS7CA= gopkg.in/yaml.v3 v3.0.1/go.mod h1:K4uyk7z7BCEPqu6E+C64Yfv1cQ7kz7rIZviUmN+EgEM= diff --git a/cmd/internal/cmd/compile.go b/cmd/internal/cmd/compile.go index 85ec8fd2..696287b1 100644 --- a/cmd/internal/cmd/compile.go +++ b/cmd/internal/cmd/compile.go @@ -87,16 +87,13 @@ func addCompile(parentCmd *cobra.Command) { // Load the baseline data loader := baseline.NewLoader() - loader.DataPath = opts.baselinePath - - bline, err := loader.Load() + err := loader.Load(opts.baselinePath) if err != nil { return err } // Validate the data - validator := baseline.NewValidator() - err = validator.Check(bline) + err = loader.Validate() if err != nil { if opts.validate { fmt.Fprint(os.Stderr, "\n❌ Error validating the baseline data:\n") @@ -108,28 +105,18 @@ func addCompile(parentCmd *cobra.Command) { fmt.Fprint(os.Stderr, "\n⚠️ Error validating the baseline data (still rendering)") } - // Generate the rendered version - gen := baseline.NewGenerator() - if opts.outPath == "" { fmt.Fprintf(os.Stderr, "\n⚠️ No output path specified. Not rendering Baseline.") } else { - if err := gen.ExportMarkdown(bline, opts.templatePath, opts.outPath); err != nil { + if err := loader.ExportMarkdown(opts.templatePath, opts.outPath); err != nil { return fmt.Errorf("writing markdown render: %w", err) } fmt.Printf("\n✅ Baseline rendered to %s\n", opts.outPath) } - fmt.Printf("\nℹ️ Counts\n") - for _, family := range bline.Catalog.ControlFamilies { - fmt.Printf(" OSPS-%s: %d controls\n", bline.ControlFamilyIDs[family.Title], len(family.Controls)) - } - fmt.Printf("\n+ %d mapped frameworks\n", len(bline.Catalog.Metadata.MappingReferences)) - fmt.Printf("\n+ %d lexicon entries\n", len(bline.Lexicon)) - // Print a checklist if they asked for it if opts.checklistOutPath != "" { - if err := gen.ExportMarkdown(bline, opts.checklistTemplatePath, opts.checklistOutPath); err != nil { + if err := loader.ExportMarkdown(opts.checklistTemplatePath, opts.checklistOutPath); err != nil { return fmt.Errorf("checklist creation: %w", err) } diff --git a/cmd/internal/cmd/oscal.go b/cmd/internal/cmd/oscal.go index 81ac690b..8049f62a 100644 --- a/cmd/internal/cmd/oscal.go +++ b/cmd/internal/cmd/oscal.go @@ -6,7 +6,7 @@ package cmd import ( "errors" "fmt" - "os" + "log" "github.com/spf13/cobra" @@ -73,20 +73,18 @@ OSCAL controls. cmd.SilenceUsage = true loader := baseline.NewLoader() - loader.DataPath = opts.baselinePath - - bline, err := loader.Load() + err := loader.Load(opts.baselinePath) if err != nil { return err } - // TODO: Open the output file + url := fmt.Sprintf("https://baseline.openssf.org/versions/%s.html", loader.Catalog.Metadata.Version) - gen := baseline.NewGenerator() - if err := gen.ExportOSCAL(bline, os.Stdout); err != nil { + oscalCatalog, err := loader.Catalog.ToOSCAL(url) + if err != nil { return err } - + log.Print(oscalCatalog) return nil }, } diff --git a/cmd/internal/cmd/validate.go b/cmd/internal/cmd/validate.go index 6c93a0c3..2a24982f 100644 --- a/cmd/internal/cmd/validate.go +++ b/cmd/internal/cmd/validate.go @@ -60,17 +60,14 @@ func addValidate(parentCmd *cobra.Command) { // Parse the data files loader := baseline.NewLoader() - loader.DataPath = opts.baselinePath - - bline, err := loader.Load() + err := loader.Load(opts.baselinePath) if err != nil { return err } // Generate the rendered version - validator := baseline.NewValidator() - - if err = validator.Check(bline); err != nil { + err = loader.Validate() + if err != nil { fmt.Fprint(os.Stderr, "\n❌ Error validating the baseline data:\n") return err } diff --git a/cmd/pkg/baseline/generator.go b/cmd/pkg/baseline/export-markdown.go similarity index 68% rename from cmd/pkg/baseline/generator.go rename to cmd/pkg/baseline/export-markdown.go index 6c4054a9..9bb7914b 100644 --- a/cmd/pkg/baseline/generator.go +++ b/cmd/pkg/baseline/export-markdown.go @@ -8,18 +8,10 @@ import ( "html/template" "os" "path/filepath" - - "github.com/ossf/security-baseline/pkg/types" ) -func NewGenerator() *Generator { - return &Generator{} -} - -type Generator struct{} - // ExportMarkdown runs the baseline data through the markdown template -func (g *Generator) ExportMarkdown(b *types.Baseline, templatePath, path string) error { +func (l *Loader) ExportMarkdown(templatePath, outPath string) error { // Read the markdown template from the external file templateContent, err := os.ReadFile(templatePath) if err != nil { @@ -27,13 +19,13 @@ func (g *Generator) ExportMarkdown(b *types.Baseline, templatePath, path string) } // Open or create the output file - if err := os.MkdirAll(filepath.Dir(path), os.FileMode(0o750)); err != nil { - return fmt.Errorf("error creating output directory %s: %w", filepath.Dir(path), err) + if err := os.MkdirAll(filepath.Dir(outPath), os.FileMode(0o750)); err != nil { + return fmt.Errorf("error creating output directory %s: %w", filepath.Dir(outPath), err) } - outputFile, err := os.Create(path) + outputFile, err := os.Create(outPath) if err != nil { - return fmt.Errorf("error creating output file %s: %w", path, err) + return fmt.Errorf("error creating output file %s: %w", outPath, err) } defer outputFile.Close() //nolint:errcheck @@ -42,7 +34,7 @@ func (g *Generator) ExportMarkdown(b *types.Baseline, templatePath, path string) // Template function to remove newlines and collapse text "collapseNewlines": collapseNewlines, "addLinks": func(s string) string { - return addLinksTemplateFunction(b.Lexicon, s) + return addLinksTemplateFunction(l.Lexicon, s) }, "asLink": asLinkTemplateFunction, "maxLevel": maxLevel, @@ -52,7 +44,7 @@ func (g *Generator) ExportMarkdown(b *types.Baseline, templatePath, path string) } // Execute the template and write to the output file - if err := tmpl.Execute(outputFile, b); err != nil { + if err := tmpl.Execute(outputFile, l); err != nil { return fmt.Errorf("error executing template: %w", err) } diff --git a/cmd/pkg/baseline/generator_oscal.go b/cmd/pkg/baseline/generator_oscal.go deleted file mode 100644 index a0a53931..00000000 --- a/cmd/pkg/baseline/generator_oscal.go +++ /dev/null @@ -1,119 +0,0 @@ -// SPDX-FileCopyrightText: Copyright 2025 The OSPS Authors -// SPDX-License-Identifier: Apache-2.0 - -package baseline - -import ( - "encoding/json" - "fmt" - "io" - "strings" - "time" - - oscal "github.com/defenseunicorns/go-oscal/src/types/oscal-1-1-3" - - "github.com/ossf/security-baseline/pkg/types" -) - -const ( - VersionOSPS = "devel" - controlHREF = "https://baseline.openssf.org/versions/%s#%s" - catalogUUID = "8c222a23-fc7e-4ad8-b6dd-289014f07a9f" - - // OpenSSFNS is the OSCAL namespace URI to define the baseline names. - OpenSSFNS = "http://baseline.openssf.org/ns/oscal" -) - -func (g *Generator) ExportOSCAL(b *types.Baseline, w io.Writer) error { - n := time.Now() - catalog := oscal.Catalog{ - UUID: catalogUUID, - Groups: nil, - Metadata: oscal.Metadata{ - LastModified: n, - Links: &[]oscal.Link{ - { - Href: fmt.Sprintf(controlHREF, VersionOSPS, ""), - Rel: "canonical", - }, - }, - OscalVersion: "1.1.3", - Published: &n, - Title: "Open Source Project Security Baseline", - Version: VersionOSPS, - }, - } - - catalogGroups := []oscal.Group{} - - for _, family := range b.Catalog.ControlFamilies { - group := oscal.Group{ - Class: "OSPS", - Controls: nil, - ID: b.ControlFamilyIDs[family.Title], - Title: family.Description, - } - - controls := []oscal.Control{} - for _, control := range family.Controls { - parts := []oscal.Part{} - for _, ar := range control.AssessmentRequirements { - parts = append(parts, oscal.Part{ - Class: control.Id, - ID: ar.Id, - Name: ar.Id, - Ns: "", - Parts: &[]oscal.Part{ - { - ID: ar.Id + ".R", - Name: "recommendation", - Ns: OpenSSFNS, - Prose: ar.Recommendation, - Links: &[]oscal.Link{ - { - Href: fmt.Sprintf(controlHREF, VersionOSPS, ar.Id), - Rel: "canonical", - }, - }, - }, - }, - Prose: ar.Text, - Title: "", - }) - } - - newCtl := oscal.Control{ - Class: b.ControlFamilyIDs[family.Title], - ID: control.Id, - Links: &[]oscal.Link{ - { - Href: fmt.Sprintf(controlHREF, VersionOSPS, strings.ToLower(control.Id)), - Rel: "canonical", - }, - }, - Parts: &parts, - Title: strings.TrimSpace(control.Title), - } - controls = append(controls, newCtl) - } - - group.Controls = &controls - catalogGroups = append(catalogGroups, group) - } - catalog.Groups = &catalogGroups - - // Wrap the catalog to render the required "catalog" wrapper - // in the JSON file: - wrapper := struct { - Catalog oscal.Catalog `json:"catalog"` - }{ - Catalog: catalog, - } - - enc := json.NewEncoder(w) - enc.SetIndent("", " ") - if err := enc.Encode(wrapper); err != nil { - return fmt.Errorf("encoding oscal json data: %w", err) - } - return nil -} diff --git a/cmd/pkg/baseline/loader.go b/cmd/pkg/baseline/loader.go index ba474f4c..0530ef93 100644 --- a/cmd/pkg/baseline/loader.go +++ b/cmd/pkg/baseline/loader.go @@ -9,9 +9,7 @@ import ( "path/filepath" "github.com/goccy/go-yaml" - "github.com/revanite-io/sci/layer2" - - "github.com/ossf/security-baseline/pkg/types" + "github.com/ossf/gemara/layer2" ) const ( @@ -21,7 +19,15 @@ const ( // Loader is an object that reads the baseline data type Loader struct { - DataPath string + layer2.Catalog + Lexicon []LexiconEntry +} + +type LexiconEntry struct { + Term string `yaml:"term"` + Definition string `yaml:"definition"` + Synonyms []string `yaml:"synonyms"` + References []string `yaml:"references"` } func NewLoader() *Loader { @@ -29,87 +35,45 @@ func NewLoader() *Loader { } // Load reads the baseline data and returns the representation types -func (l *Loader) Load() (*types.Baseline, error) { - b := &types.Baseline{} - - // Load the lexicon: - lexicon, err := l.loadLexicon() +func (l *Loader) Load(dataPath string) error { + lexicon, err := loadLexicon(dataPath) if err != nil { - return nil, fmt.Errorf("error reading lexicon: %w", err) + return fmt.Errorf("error reading lexicon: %w", err) } - frameworks, err := l.loadFrameworks() + l.Lexicon = lexicon + + dirFiles, err := os.ReadDir(dataPath) if err != nil { - return nil, fmt.Errorf("error reading frameworks: %w", err) + return fmt.Errorf("error reading data path: %w", err) } - - b.Lexicon = lexicon - controlFamilies := []layer2.ControlFamily{} - familyIDs := map[string]string{} - - for _, familyID := range types.ControlFamilies { - cf, err := l.loadControlFamily(familyID) - if err != nil { - return nil, fmt.Errorf("loading control family %s: %w", familyID, err) + var filepaths []string + for _, file := range dirFiles { + if file.Name() != LexiconFilename { + path := filepath.Join(dataPath, file.Name()) + filepaths = append(filepaths, path) } - familyIDs[cf.Title] = familyID - controlFamilies = append(controlFamilies, *cf) } - b.ControlFamilyIDs = familyIDs - b.Catalog = layer2.Catalog{ - ControlFamilies: controlFamilies, - Metadata: layer2.Metadata{ - MappingReferences: frameworks, - }, + + err = l.LoadFiles(filepaths) + if err != nil { + return fmt.Errorf("Error loading baseline directory (%s)\n%w", dataPath, err) } - return b, nil + return nil } // loadLexicon -func (l *Loader) loadLexicon() ([]types.LexiconEntry, error) { - file, err := os.Open(filepath.Join(l.DataPath, LexiconFilename)) +func loadLexicon(dataPath string) ([]LexiconEntry, error) { + file, err := os.Open(filepath.Join(dataPath, LexiconFilename)) if err != nil { return nil, fmt.Errorf("error opening file: %w", err) } defer file.Close() //nolint:errcheck - var lexicon []types.LexiconEntry + var lexicon []LexiconEntry decoder := yaml.NewDecoder(file, yaml.DisallowUnknownField()) if err := decoder.Decode(&lexicon); err != nil { - return nil, fmt.Errorf("error decoding YAML: %w", err) + return nil, fmt.Errorf("error decoding YAML: %s\n %w", file.Name(), err) } return lexicon, nil } - -func (l *Loader) loadFrameworks() ([]layer2.MappingReference, error) { - file, err := os.Open(filepath.Join(l.DataPath, FrameworksFilename)) - if err != nil { - return nil, fmt.Errorf("error opening file: %w", err) - } - defer file.Close() //nolint:errcheck - - var metadata layer2.Metadata - - decoder := yaml.NewDecoder(file, yaml.DisallowUnknownField()) - if err := decoder.Decode(&metadata); err != nil { - return nil, fmt.Errorf("error decoding YAML: %w", err) - } - return metadata.MappingReferences, nil -} - -// loadControlFamily loads a ControlFamily definition from its YAML source -func (l *Loader) loadControlFamily(familyID string) (*layer2.ControlFamily, error) { - file, err := os.Open(filepath.Join(l.DataPath, fmt.Sprintf("OSPS-%s.yaml", familyID))) - if err != nil { - return nil, fmt.Errorf("error opening file: %w", err) - } - defer file.Close() //nolint:errcheck - - controlFamily := &layer2.ControlFamily{} - - decoder := yaml.NewDecoder(file, yaml.Strict()) - if err := decoder.Decode(controlFamily); err != nil { - return nil, fmt.Errorf("error decoding %s YAML: %w", familyID, err) - } - return controlFamily, nil -} diff --git a/cmd/pkg/baseline/template-functions.go b/cmd/pkg/baseline/template-functions.go index 301ee261..83c5cf3b 100644 --- a/cmd/pkg/baseline/template-functions.go +++ b/cmd/pkg/baseline/template-functions.go @@ -8,8 +8,6 @@ import ( "regexp" "strconv" "strings" - - "github.com/ossf/security-baseline/pkg/types" ) func collapseNewlines(s string) string { @@ -43,7 +41,7 @@ func isWrapped(text, matched string) bool { } // Function to add links by wrapping terms with square brackets -func addLinks(lexicon []types.LexiconEntry, text, term string) string { +func addLinks(lexicon []LexiconEntry, text, term string) string { // Escape any special characters in the term to use in regex escapedTerm := regexp.QuoteMeta(term) @@ -67,7 +65,7 @@ func addLinks(lexicon []types.LexiconEntry, text, term string) string { } // Main function to apply the term replacements -func addLinksTemplateFunction(lexicon []types.LexiconEntry, text string) string { +func addLinksTemplateFunction(lexicon []LexiconEntry, text string) string { // Iterate over the lexicon and replace terms with brackets for _, entry := range lexicon { text = addLinks(lexicon, text, entry.Term) diff --git a/cmd/pkg/baseline/validator.go b/cmd/pkg/baseline/validate.go similarity index 75% rename from cmd/pkg/baseline/validator.go rename to cmd/pkg/baseline/validate.go index 3b986a2c..df05b565 100644 --- a/cmd/pkg/baseline/validator.go +++ b/cmd/pkg/baseline/validate.go @@ -7,21 +7,13 @@ import ( "errors" "fmt" "slices" - - "github.com/ossf/security-baseline/pkg/types" ) -func NewValidator() *Validator { - return &Validator{} -} - -type Validator struct{} - // Check verifies the data parsed for consistency and completeness -func (v *Validator) Check(b *types.Baseline) error { +func (l *Loader) Validate() error { var entryIDs []string errs := []error{} - for _, category := range b.Catalog.ControlFamilies { + for _, category := range l.Catalog.ControlFamilies { for _, entry := range category.Controls { if slices.Contains(entryIDs, entry.Id) { errs = append(errs, fmt.Errorf("duplicate ID for 'control' for %s", entry.Id)) diff --git a/cmd/pkg/types/types.go b/cmd/pkg/types/types.go deleted file mode 100644 index ac90a0df..00000000 --- a/cmd/pkg/types/types.go +++ /dev/null @@ -1,32 +0,0 @@ -// SPDX-FileCopyrightText: Copyright 2025 The OSPS Authors -// SPDX-License-Identifier: Apache-2.0 - -package types - -import "github.com/revanite-io/sci/layer2" - -var ControlFamilies = []string{ - "AC", - "BR", - "DO", - "GV", - "LE", - "QA", - "SA", - "VM", -} - -// Struct for holding the entire YAML structure -type Baseline struct { - // map of family names to IDs to support OSCAL groups - ControlFamilyIDs map[string]string - Catalog layer2.Catalog - Lexicon []LexiconEntry -} - -type LexiconEntry struct { - Term string `yaml:"term"` - Definition string `yaml:"definition"` - Synonyms []string `yaml:"synonyms"` - References []string `yaml:"references"` -} diff --git a/cmd/template.md b/cmd/template.md index 5b351a0a..5c10de66 100644 --- a/cmd/template.md +++ b/cmd/template.md @@ -115,7 +115,7 @@ For more information on the project and to make contributions, visit the [GitHub #### External Framework Mappings {{ if .GuidelineMappings }} {{ range .GuidelineMappings }} - - **{{ .ReferenceId | addLinks }}**: {{ range $index, $id := .Identifiers }}{{ if $index }}, {{ end }}{{ $id }}{{ end }} + - **{{ .ReferenceId | addLinks }}**: {{ range $index, $entry := .Entries }}{{ if $index }}, {{ end }}{{ $entry.ReferenceId }}{{ end }} {{- end }} {{ end }} From abf62bf6b7bf7a79a23b774524b0c6d9e8467e5c Mon Sep 17 00:00:00 2001 From: Eddie Knight Date: Thu, 21 Aug 2025 06:18:44 -0500 Subject: [PATCH 2/2] chore: upgraded yaml to Gemara v0.4.1 Signed-off-by: Eddie Knight --- baseline/OSPS-AC.yaml | 618 ++++++++++----------- baseline/OSPS-BR.yaml | 924 +++++++++++++++---------------- baseline/OSPS-DO.yaml | 888 +++++++++++++++--------------- baseline/OSPS-GV.yaml | 542 +++++++++--------- baseline/OSPS-LE.yaml | 386 ++++++------- baseline/OSPS-QA.yaml | 1080 ++++++++++++++++++------------------ baseline/OSPS-SA.yaml | 538 +++++++++--------- baseline/OSPS-VM.yaml | 1124 +++++++++++++++++++------------------- baseline/frameworks.yaml | 61 --- baseline/metadata.yaml | 343 ++++++------ 10 files changed, 3230 insertions(+), 3274 deletions(-) delete mode 100644 baseline/frameworks.yaml diff --git a/baseline/OSPS-AC.yaml b/baseline/OSPS-AC.yaml index aa2856e1..3b366699 100644 --- a/baseline/OSPS-AC.yaml +++ b/baseline/OSPS-AC.yaml @@ -1,312 +1,314 @@ -title: Access Control -description: | - Access Control focuses on the mechanisms and - policies that control access to the project's version - control system and CI/CD pipelines. These controls help - ensure that only authorized users can access sensitive - data, modify repository settings, or execute build and - release processes. -controls: - - id: OSPS-AC-01 - title: | - The project's version control system MUST require multi-factor - authentication for users modifying the project repository - settings or accessing sensitive data. - objective: | - Reduce the risk of account compromise or insider threats by requiring - multi-factor authentication for collaborators modifying the project - repository settings or accessing sensitive data. - guideline-mappings: - - reference-id: BPB - identifiers: - - CC-G-1 - - reference-id: CRA - identifiers: - - 1.2d - - 1.2e - - 1.2f - - reference-id: SSDF - identifiers: - - PO.3.2 - - PS.1 - - PS.2 - - reference-id: CSF - identifiers: - - PR.A-02 - - PR.A-05 - - reference-id: OpenCRE - identifiers: - - 486-813 - - 124-564 - - 347-352 - - 333-858 - - 152-725 - - 201-246 - - reference-id: PSSCRM - identifiers: - - G2.6 - - P3.3 - - E1.2 - - E1.3 - - E1.4 - - E3.1 - - reference-id: SAMM - identifiers: - - Operations -Environment Management -Configuration Hardening Lvl1 - - reference-id: PCIDSS - identifiers: - - 2.2.1 - - 8.2.1 - - 8.3.1 - - reference-id: UKSSCOP - identifiers: - - 2.1 - - reference-id: 800-161 - identifiers: - - AC-4(21) - - AC-17 - - CM-5 - - CM-6 - - IA-2 - - IA-5 - assessment-requirements: - - id: OSPS-AC-01.01 - text: | - When a user attempts to read or modify a sensitive resource in the project's - authoritative repository, the system MUST require the user to complete - a multi-factor authentication process. - applicability: - - Maturity Level 1 - - Maturity Level 2 - - Maturity Level 3 - recommendation: | - Enforce multi-factor authentication for the project's version - control system, requiring collaborators to provide a second form of - authentication when accessing sensitive data or modifying repository - settings. Passkeys are acceptable for this control. +control-families: + - id: AC + title: Access Control + description: | + Access Control focuses on the mechanisms and + policies that control access to the project's version + control system and CI/CD pipelines. These controls help + ensure that only authorized users can access sensitive + data, modify repository settings, or execute build and + release processes. + controls: + - id: OSPS-AC-01 + title: | + The project's version control system MUST require multi-factor + authentication for users modifying the project repository + settings or accessing sensitive data. + objective: | + Reduce the risk of account compromise or insider threats by requiring + multi-factor authentication for collaborators modifying the project + repository settings or accessing sensitive data. + guideline-mappings: + - reference-id: BPB + entries: + - reference-id: CC-G-1 + - reference-id: CRA + entries: + - reference-id: 1.2d + - reference-id: 1.2e + - reference-id: 1.2f + - reference-id: SSDF + entries: + - reference-id: PO.3.2 + - reference-id: PS.1 + - reference-id: PS.2 + - reference-id: CSF + entries: + - reference-id: PR.A-02 + - reference-id: PR.A-05 + - reference-id: OpenCRE + entries: + - reference-id: 486-813 + - reference-id: 124-564 + - reference-id: 347-352 + - reference-id: 333-858 + - reference-id: 152-725 + - reference-id: 201-246 + - reference-id: PSSCRM + entries: + - reference-id: G2.6 + - reference-id: P3.3 + - reference-id: E1.2 + - reference-id: E1.3 + - reference-id: E1.4 + - reference-id: E3.1 + - reference-id: SAMM + entries: + - reference-id: Operations -Environment Management -Configuration Hardening Lvl1 + - reference-id: PCIDSS + entries: + - reference-id: 2.2.1 + - reference-id: 8.2.1 + - reference-id: 8.3.1 + - reference-id: UKSSCOP + entries: + - reference-id: 2.1 + - reference-id: 800-161 + entries: + - reference-id: AC-4(21) + - reference-id: AC-17 + - reference-id: CM-5 + - reference-id: CM-6 + - reference-id: IA-2 + - reference-id: IA-5 + assessment-requirements: + - id: OSPS-AC-01.01 + text: | + When a user attempts to read or modify a sensitive resource in the project's + authoritative repository, the system MUST require the user to complete + a multi-factor authentication process. + applicability: + - maturity-1 + - maturity-2 + - maturity-3 + recommendation: | + Enforce multi-factor authentication for the project's version + control system, requiring collaborators to provide a second form of + authentication when accessing sensitive data or modifying repository + settings. Passkeys are acceptable for this control. - - id: OSPS-AC-02 - title: | - The project's version control system MUST restrict collaborator - permissions to the lowest available privileges by default. - objective: | - Reduce the risk of unauthorized access to the project's repository by - limiting the permissions granted to new collaborators. - guideline-mappings: - - reference-id: CRA - identifiers: - - 1.2f - - reference-id: SSDF - identifiers: - - PO.2 - - PO.3.2 - - PS.1 - - PS.2 - - reference-id: CSF - identifiers: - - PR.AA-02 - - PR.AA-05 - - reference-id: OpenCRE - identifiers: - - 486-813 - - 124-564 - - 802-056 - - 368-633 - - 152-725 - - reference-id: PSSCRM - identifiers: - - P2.3 - - E1.2 - - E3.3 - - reference-id: PCIDSS - identifiers: - - 2.2.1 - - reference-id: UKSSCOP - identifiers: - - 2.1 - - reference-id: 800-161 - identifiers: - - AC-2 - - AC-3 - - AC-4(21) - - AC-5 - - AC-6 - - CM-5 - - CM-7 - assessment-requirements: - - id: OSPS-AC-02.01 - text: | - When a new collaborator is added, the version control system MUST - require manual permission assignment, or restrict the collaborator + - id: OSPS-AC-02 + title: | + The project's version control system MUST restrict collaborator permissions to the lowest available privileges by default. - applicability: - - Maturity Level 1 - - Maturity Level 2 - - Maturity Level 3 - recommendation: | - Most public version control systems are configured in this manner. - Ensure the project's version control system always assigns the lowest - available permissions to collaborators by default when added, granting - additional permissions only when necessary. + objective: | + Reduce the risk of unauthorized access to the project's repository by + limiting the permissions granted to new collaborators. + guideline-mappings: + - reference-id: CRA + entries: + - reference-id: 1.2f + - reference-id: SSDF + entries: + - reference-id: PO.2 + - reference-id: PO.3.2 + - reference-id: PS.1 + - reference-id: PS.2 + - reference-id: CSF + entries: + - reference-id: PR.AA-02 + - reference-id: PR.AA-05 + - reference-id: OpenCRE + entries: + - reference-id: 486-813 + - reference-id: 124-564 + - reference-id: 802-056 + - reference-id: 368-633 + - reference-id: 152-725 + - reference-id: PSSCRM + entries: + - reference-id: P2.3 + - reference-id: E1.2 + - reference-id: E3.3 + - reference-id: PCIDSS + entries: + - reference-id: 2.2.1 + - reference-id: UKSSCOP + entries: + - reference-id: 2.1 + - reference-id: 800-161 + entries: + - reference-id: AC-2 + - reference-id: AC-3 + - reference-id: AC-4(21) + - reference-id: AC-5 + - reference-id: AC-6 + - reference-id: CM-5 + - reference-id: CM-7 + assessment-requirements: + - id: OSPS-AC-02.01 + text: | + When a new collaborator is added, the version control system MUST + require manual permission assignment, or restrict the collaborator + permissions to the lowest available privileges by default. + applicability: + - maturity-1 + - maturity-2 + - maturity-3 + recommendation: | + Most public version control systems are configured in this manner. + Ensure the project's version control system always assigns the lowest + available permissions to collaborators by default when added, granting + additional permissions only when necessary. - - id: OSPS-AC-03 - title: | - The project's version control system MUST prevent unintentional - modification of the primary branch. - objective: | - Reduce the risk of accidental changes or deletion of the primary branch - of the project's repository by preventing unintentional modification. - guideline-mappings: - - reference-id: CRA - identifiers: - - 1.2f - - reference-id: SSDF - identifiers: - - PO.3.2 - - PS.1 - - PS.2 - - reference-id: CSF - identifiers: - - PR.A-02 - - PR.A-05 - - reference-id: OpenCRE - identifiers: - - 486-813 - - 124-564 - - 152-725 - - reference-id: Scorecard - identifiers: - - Branch-Protection - - reference-id: PSSCRM - identifiers: - - P3.2 - - P3.5 - - E1.5 - - E3.1 - - reference-id: PCIDSS - identifiers: - - 2.2.1 - - reference-id: UKSSCOP - identifiers: - - 2.1 - - 2.2 - - reference-id: 800-161 - identifiers: - - AC-3 - - AC-5 - - CM-3 - - CM-3(2) - - CM-5 - assessment-requirements: - - id: OSPS-AC-03.01 - text: | - When a direct commit is attempted on the project's primary branch, - an enforcement mechanism MUST prevent the change from being applied. - applicability: - - Maturity Level 1 - - Maturity Level 2 - - Maturity Level 3 - recommendation: | - If the VCS is centralized, set branch protection on the primary branch - in the project's VCS. Alternatively, use a decentralized approach, - like the Linux kernel's, where changes are first proposed in another - repository, and merging changes into the primary repository requires a - specific separate act. - - id: OSPS-AC-03.02 - text: | - When an attempt is made to delete the project's primary branch, - the version control system MUST treat this as a sensitive activity - and require explicit confirmation of intent. - applicability: - - Maturity Level 1 - - Maturity Level 2 - - Maturity Level 3 - recommendation: | - Set branch protection on the primary branch in the project's version - control system to prevent deletion. + - id: OSPS-AC-03 + title: | + The project's version control system MUST prevent unintentional + modification of the primary branch. + objective: | + Reduce the risk of accidental changes or deletion of the primary branch + of the project's repository by preventing unintentional modification. + guideline-mappings: + - reference-id: CRA + entries: + - reference-id: 1.2f + - reference-id: SSDF + entries: + - reference-id: PO.3.2 + - reference-id: PS.1 + - reference-id: PS.2 + - reference-id: CSF + entries: + - reference-id: PR.A-02 + - reference-id: PR.A-05 + - reference-id: OpenCRE + entries: + - reference-id: 486-813 + - reference-id: 124-564 + - reference-id: 152-725 + - reference-id: Scorecard + entries: + - reference-id: Branch-Protection + - reference-id: PSSCRM + entries: + - reference-id: P3.2 + - reference-id: P3.5 + - reference-id: E1.5 + - reference-id: E3.1 + - reference-id: PCIDSS + entries: + - reference-id: 2.2.1 + - reference-id: UKSSCOP + entries: + - reference-id: 2.1 + - reference-id: 2.2 + - reference-id: 800-161 + entries: + - reference-id: AC-3 + - reference-id: AC-5 + - reference-id: CM-3 + - reference-id: CM-3(2) + - reference-id: CM-5 + assessment-requirements: + - id: OSPS-AC-03.01 + text: | + When a direct commit is attempted on the project's primary branch, + an enforcement mechanism MUST prevent the change from being applied. + applicability: + - maturity-1 + - maturity-2 + - maturity-3 + recommendation: | + If the VCS is centralized, set branch protection on the primary branch + in the project's VCS. Alternatively, use a decentralized approach, + like the Linux kernel's, where changes are first proposed in another + repository, and merging changes into the primary repository requires a + specific separate act. + - id: OSPS-AC-03.02 + text: | + When an attempt is made to delete the project's primary branch, + the version control system MUST treat this as a sensitive activity + and require explicit confirmation of intent. + applicability: + - maturity-1 + - maturity-2 + - maturity-3 + recommendation: | + Set branch protection on the primary branch in the project's version + control system to prevent deletion. - - id: OSPS-AC-04 - title: | - The project's permissions in CI/CD pipelines MUST follow the principle - of least privilege. - objective: | - Reduce the risk of unauthorized access to the project's build and release - processes by limiting the permissions granted to steps within the CI/CD - pipelines. - guideline-mappings: - - reference-id: CRA - identifiers: - - 1.2d - - 1.2e - - 1.2f - - reference-id: SSDF - identifiers: - - PO.2 - - PO.3.2 - - PS.1 - - PS.2 - - reference-id: CSF - identifiers: - - PR.AA-02 - - PR.AA-05 - - reference-id: OpenCRE - identifiers: - - 486-813 - - 124-564 - - 347-507 - - 263-284 - - 123-124 - - reference-id: SLSA - identifiers: - - Producer - Choose an appropriate build platform - - Build platform - Isolation strength - Isolated - - reference-id: PSSCRM - identifiers: - - P3.2 - - reference-id: SAMM - identifiers: - - Operations -Environment Management -Configuration Hardening Lvl1 - - reference-id: PCIDSS - identifiers: - - 2.2.1 - - 8.2.1 - - reference-id: UKSSCOP - identifiers: - - 2.1 - - 2.2 - - reference-id: 800-161 - identifiers: - - AC-3(8) - - AC-4 - - AC-4(6) - - AC-6 - - AC-20 - - AC-20(1) - - CM-5 - - CM-7 - assessment-requirements: - - id: OSPS-AC-04.01 - text: | - When a CI/CD task is executed with no permissions specified, the - project's version control system MUST default to the lowest available - permissions for all activities in the pipeline. - applicability: - - Maturity Level 2 - - Maturity Level 3 - recommendation: | - Configure the project's settings to assign the lowest available - permissions to new pipelines by default, granting additional - permissions only when necessary for specific tasks. - - id: OSPS-AC-04.02 - text: | - When a job is assigned permissions in a CI/CD pipeline, the source - code or configuration MUST only assign the minimum privileges - necessary for the corresponding activity. - applicability: - - Maturity Level 3 - recommendation: | - Configure the project's CI/CD pipelines to assign the lowest available - permissions to users and services by default, elevating permissions - only when necessary for specific tasks. In some version control - systems, this may be possible at the organizational or repository - level. If not, set permissions at the top level of the pipeline. + - id: OSPS-AC-04 + title: | + The project's permissions in CI/CD pipelines MUST follow the principle + of least privilege. + objective: | + Reduce the risk of unauthorized access to the project's build and release + processes by limiting the permissions granted to steps within the CI/CD + pipelines. + guideline-mappings: + - reference-id: CRA + entries: + - reference-id: 1.2d + - reference-id: 1.2e + - reference-id: 1.2f + - reference-id: SSDF + entries: + - reference-id: PO.2 + - reference-id: PO.3.2 + - reference-id: PS.1 + - reference-id: PS.2 + - reference-id: CSF + entries: + - reference-id: PR.AA-02 + - reference-id: PR.AA-05 + - reference-id: OpenCRE + entries: + - reference-id: 486-813 + - reference-id: 124-564 + - reference-id: 347-507 + - reference-id: 263-284 + - reference-id: 123-124 + - reference-id: SLSA + entries: + - reference-id: Producer - Choose an appropriate build platform + - reference-id: Build platform - Isolation strength - Isolated + - reference-id: PSSCRM + entries: + - reference-id: P3.2 + - reference-id: SAMM + entries: + - reference-id: Operations -Environment Management -Configuration Hardening Lvl1 + - reference-id: PCIDSS + entries: + - reference-id: 2.2.1 + - reference-id: 8.2.1 + - reference-id: UKSSCOP + entries: + - reference-id: 2.1 + - reference-id: 2.2 + - reference-id: 800-161 + entries: + - reference-id: AC-3(8) + - reference-id: AC-4 + - reference-id: AC-4(6) + - reference-id: AC-6 + - reference-id: AC-20 + - reference-id: AC-20(1) + - reference-id: CM-5 + - reference-id: CM-7 + assessment-requirements: + - id: OSPS-AC-04.01 + text: | + When a CI/CD task is executed with no permissions specified, the + project's version control system MUST default to the lowest available + permissions for all activities in the pipeline. + applicability: + - maturity-2 + - maturity-3 + recommendation: | + Configure the project's settings to assign the lowest available + permissions to new pipelines by default, granting additional + permissions only when necessary for specific tasks. + - id: OSPS-AC-04.02 + text: | + When a job is assigned permissions in a CI/CD pipeline, the source + code or configuration MUST only assign the minimum privileges + necessary for the corresponding activity. + applicability: + - maturity-3 + recommendation: | + Configure the project's CI/CD pipelines to assign the lowest available + permissions to users and services by default, elevating permissions + only when necessary for specific tasks. In some version control + systems, this may be possible at the organizational or repository + level. If not, set permissions at the top level of the pipeline. diff --git a/baseline/OSPS-BR.yaml b/baseline/OSPS-BR.yaml index e885527f..933c0209 100644 --- a/baseline/OSPS-BR.yaml +++ b/baseline/OSPS-BR.yaml @@ -1,467 +1,469 @@ -title: Build and Release -description: | - Build and Release focuses on the processes and - tools used to compile, package, and distribute the - project's software. These controls help ensure that the - project's build and release pipelines are secure, - consistent, and reliable, reducing the risk of - vulnerabilities or errors in the software distribution - process. -controls: - - id: OSPS-BR-01 - title: | - The project's build and release pipelines MUST NOT permit untrusted - input that allows access to privileged resources. - objective: | - Reduce the risk of code injection or other security vulnerabilities in the - project's build and release pipelines by preventing untrusted input from - accessing privileged resources. - guideline-mappings: - - reference-id: CRA - identifiers: - - 1.2f - - reference-id: SSDF - identifiers: - - PO.3.2 - - PO.5.2 - - PS.1 - - PS.2 - - reference-id: CSF - identifiers: - - PR.AA-02 - - reference-id: OpenCRE - identifiers: - - 486-813 - - 124-564 - - 357-352 - - reference-id: SLSA - identifiers: - - Choose an appropriate build platform - - reference-id: PSSCRM - identifiers: - - P2.3 - - P3.2 - - P3.5 - - E2.4 - - E2.5 - - D2.2 - - reference-id: PCIDSS - identifiers: - - 2.2.1 - - 6.4.1 - - reference-id: 800-161 - identifiers: - - AC-3 - - AC-4 - - AC-4(21) - - CM-5 - - CM-7 - - SI-7 - assessment-requirements: - - id: OSPS-BR-01.01 - text: | - When a CI/CD pipeline accepts an input parameter, that parameter MUST - be sanitized and validated prior to use in the pipeline. - applicability: - - Maturity Level 1 - - Maturity Level 2 - - Maturity Level 3 - recommendation: # TODO - - id: OSPS-BR-01.02 - text: | - When a CI/CD pipeline uses a branch name in its functionality, that - name value MUST be sanitized and validated prior to use in the - pipeline. - applicability: - - Maturity Level 1 - - Maturity Level 2 - - Maturity Level 3 - recommendation: # TODO +control-families: + - id: BR + title: Build and Release + description: | + Build and Release focuses on the processes and + tools used to compile, package, and distribute the + project's software. These controls help ensure that the + project's build and release pipelines are secure, + consistent, and reliable, reducing the risk of + vulnerabilities or errors in the software distribution + process. + controls: + - id: OSPS-BR-01 + title: | + The project's build and release pipelines MUST NOT permit untrusted + input that allows access to privileged resources. + objective: | + Reduce the risk of code injection or other security vulnerabilities in the + project's build and release pipelines by preventing untrusted input from + accessing privileged resources. + guideline-mappings: + - reference-id: CRA + entries: + - reference-id: 1.2f + - reference-id: SSDF + entries: + - reference-id: PO.3.2 + - reference-id: PO.5.2 + - reference-id: PS.1 + - reference-id: PS.2 + - reference-id: CSF + entries: + - reference-id: PR.AA-02 + - reference-id: OpenCRE + entries: + - reference-id: 486-813 + - reference-id: 124-564 + - reference-id: 357-352 + - reference-id: SLSA + entries: + - reference-id: Choose an appropriate build platform + - reference-id: PSSCRM + entries: + - reference-id: P2.3 + - reference-id: P3.2 + - reference-id: P3.5 + - reference-id: E2.4 + - reference-id: E2.5 + - reference-id: D2.2 + - reference-id: PCIDSS + entries: + - reference-id: 2.2.1 + - reference-id: 6.4.1 + - reference-id: 800-161 + entries: + - reference-id: AC-3 + - reference-id: AC-4 + - reference-id: AC-4(21) + - reference-id: CM-5 + - reference-id: CM-7 + - reference-id: SI-7 + assessment-requirements: + - id: OSPS-BR-01.01 + text: | + When a CI/CD pipeline accepts an input parameter, that parameter MUST + be sanitized and validated prior to use in the pipeline. + applicability: + - maturity-1 + - maturity-2 + - maturity-3 + recommendation: # TODO + - id: OSPS-BR-01.02 + text: | + When a CI/CD pipeline uses a branch name in its functionality, that + name value MUST be sanitized and validated prior to use in the + pipeline. + applicability: + - maturity-1 + - maturity-2 + - maturity-3 + recommendation: # TODO - - id: OSPS-BR-02 - title: | - All releases and released software assets MUST be assigned a unique - version identifier for each release intended to be used by users. - objective: | - Ensure that each software asset produced by the project is uniquely - identified, enabling users to track changes and updates to the project - over time. - guideline-mappings: - - reference-id: BPB - identifiers: - - CC-B-5 - - CC-B-6 - - CC-B-7 - - reference-id: CRA - identifiers: - - 1.2f - - reference-id: SSDF - identifiers: - - PO.3.2 - - PS.1 - - PS.2 - - PS.3 - - reference-id: OpenCRE - identifiers: - - 486-813 - - 124-564 - - reference-id: SLSA - identifiers: - - Follow a consistent build process - - Provenance generation- Exists, Authentic - - reference-id: PSSCRM - identifiers: - - G1.4 - - E1.2 - - E2.1 - - E2.6 - - reference-id: PCIDSS - identifiers: - - 6.4.3 - - reference-id: UKSSCOP - identifiers: - - 3.1 - - reference-id: 800-161 - identifiers: - - IA-4 - - SA-15 - - SI-7 - - SR-4 - assessment-requirements: - - id: OSPS-BR-02.01 - text: | - When an official release is created, that release MUST be assigned a - unique version identifier. - applicability: - - Maturity Level 2 - - Maturity Level 3 - recommendation: | - Assign a unique version identifier to each release produced by the - project, following a consistent naming convention or numbering scheme. - Examples include SemVer, CalVer, or git commit id. - - id: OSPS-BR-02.02 - text: | - When an official release is created, all assets within that release - MUST be clearly associated with the release identifier or another - unique identifier for the asset. - applicability: - - Maturity Level 3 - recommendation: | - Assign a unique version identifier to each software asset produced by - the project, following a consistent naming convention or numbering - scheme. Examples include SemVer, CalVer, or git commit id. + - id: OSPS-BR-02 + title: | + All releases and released software assets MUST be assigned a unique + version identifier for each release intended to be used by users. + objective: | + Ensure that each software asset produced by the project is uniquely + identified, enabling users to track changes and updates to the project + over time. + guideline-mappings: + - reference-id: BPB + entries: + - reference-id: CC-B-5 + - reference-id: CC-B-6 + - reference-id: CC-B-7 + - reference-id: CRA + entries: + - reference-id: 1.2f + - reference-id: SSDF + entries: + - reference-id: PO.3.2 + - reference-id: PS.1 + - reference-id: PS.2 + - reference-id: PS.3 + - reference-id: OpenCRE + entries: + - reference-id: 486-813 + - reference-id: 124-564 + - reference-id: SLSA + entries: + - reference-id: Follow a consistent build process + - reference-id: Provenance generation- Exists, Authentic + - reference-id: PSSCRM + entries: + - reference-id: G1.4 + - reference-id: E1.2 + - reference-id: E2.1 + - reference-id: E2.6 + - reference-id: PCIDSS + entries: + - reference-id: 6.4.3 + - reference-id: UKSSCOP + entries: + - reference-id: 3.1 + - reference-id: 800-161 + entries: + - reference-id: IA-4 + - reference-id: SA-15 + - reference-id: SI-7 + - reference-id: SR-4 + assessment-requirements: + - id: OSPS-BR-02.01 + text: | + When an official release is created, that release MUST be assigned a + unique version identifier. + applicability: + - maturity-2 + - maturity-3 + recommendation: | + Assign a unique version identifier to each release produced by the + project, following a consistent naming convention or numbering scheme. + Examples include SemVer, CalVer, or git commit id. + - id: OSPS-BR-02.02 + text: | + When an official release is created, all assets within that release + MUST be clearly associated with the release identifier or another + unique identifier for the asset. + applicability: + - maturity-3 + recommendation: | + Assign a unique version identifier to each software asset produced by + the project, following a consistent naming convention or numbering + scheme. Examples include SemVer, CalVer, or git commit id. - - id: OSPS-BR-03 - title: | - All official project URIs MUST be delivered using encrypted channels. - objective: | - Protect the confidentiality and integrity of project source code during - development, reducing the risk of eavesdropping or data tampering. - guideline-mappings: - - reference-id: BPB - identifiers: - - B-B-11 - - reference-id: CRA - identifiers: - - 1.2d - - 1.2e - - 1.2f - - 1.2i - - 1.2j - - 1.2k - - reference-id: SSDF - identifiers: - - PO.3.2 - - PO.5.2 - - PS.1 - - PS.2 - - reference-id: OpenCRE - identifiers: - - 483-813 - - 124-564 - - 263-184 - - reference-id: SLSA - identifiers: - - Choose an appropriate build platform - - reference-id: PSSCRM - identifiers: - - E1.1 - - E2.2 - - E2.4 - - E2.5 - - reference-id: PCIDSS - identifiers: - - 2.2.1 - - 2.2.7 - - 4.2.1 - - 4.2.2 - - 6.4.1 - - 8.3.2 - - reference-id: UKSSCOP - identifiers: - - 3.1 - - reference-id: 800-161 - identifiers: - - AC-4 - - AC-4(21) - assessment-requirements: - - id: OSPS-BR-03.01 - text: | - When the project lists a URI as an official project channel, that URI - MUST be exclusively delivered using encrypted channels. - applicability: - - Maturity Level 1 - - Maturity Level 2 - - Maturity Level 3 - recommendation: | - Configure the project's websites and version control systems to use - encrypted channels such as SSH or HTTPS for data transmission. - Ensure all tools and domains referenced in project documentation can - only be accessed via encrypted channels. - - id: OSPS-BR-03.02 - text: | - When the project lists a URI as an official distribution channel, - that URI MUST be exclusively delivered using encrypted channels. - applicability: - - Maturity Level 1 - - Maturity Level 2 - - Maturity Level 3 - recommendation: | - Configure the project's release pipeline to only fetch data from - websites, API responses, and other services which use encrypted - channels such as SSH or HTTPS for data transmission. + - id: OSPS-BR-03 + title: | + All official project URIs MUST be delivered using encrypted channels. + objective: | + Protect the confidentiality and integrity of project source code during + development, reducing the risk of eavesdropping or data tampering. + guideline-mappings: + - reference-id: BPB + entries: + - reference-id: B-B-11 + - reference-id: CRA + entries: + - reference-id: 1.2d + - reference-id: 1.2e + - reference-id: 1.2f + - reference-id: 1.2i + - reference-id: 1.2j + - reference-id: 1.2k + - reference-id: SSDF + entries: + - reference-id: PO.3.2 + - reference-id: PO.5.2 + - reference-id: PS.1 + - reference-id: PS.2 + - reference-id: OpenCRE + entries: + - reference-id: 483-813 + - reference-id: 124-564 + - reference-id: 263-184 + - reference-id: SLSA + entries: + - reference-id: Choose an appropriate build platform + - reference-id: PSSCRM + entries: + - reference-id: E1.1 + - reference-id: E2.2 + - reference-id: E2.4 + - reference-id: E2.5 + - reference-id: PCIDSS + entries: + - reference-id: 2.2.1 + - reference-id: 2.2.7 + - reference-id: 4.2.1 + - reference-id: 4.2.2 + - reference-id: 6.4.1 + - reference-id: 8.3.2 + - reference-id: UKSSCOP + entries: + - reference-id: 3.1 + - reference-id: 800-161 + entries: + - reference-id: AC-4 + - reference-id: AC-4(21) + assessment-requirements: + - id: OSPS-BR-03.01 + text: | + When the project lists a URI as an official project channel, that URI + MUST be exclusively delivered using encrypted channels. + applicability: + - maturity-1 + - maturity-2 + - maturity-3 + recommendation: | + Configure the project's websites and version control systems to use + encrypted channels such as SSH or HTTPS for data transmission. + Ensure all tools and domains referenced in project documentation can + only be accessed via encrypted channels. + - id: OSPS-BR-03.02 + text: | + When the project lists a URI as an official distribution channel, + that URI MUST be exclusively delivered using encrypted channels. + applicability: + - maturity-1 + - maturity-2 + - maturity-3 + recommendation: | + Configure the project's release pipeline to only fetch data from + websites, API responses, and other services which use encrypted + channels such as SSH or HTTPS for data transmission. - - id: OSPS-BR-04 - title: | - All releases MUST provide a descriptive log of functional and security - modifications. - objective: | - Provide transparency and accountability for changes made to the project's - software releases, enabling users to understand the modifications and - improvements included in each release. - guideline-mappings: - - reference-id: BPB - identifiers: - - CC-B-8 - - CC-B-9 - - Q-B-7 - - A-B-1 - - A-S-1 - - reference-id: CRA - identifiers: - - 1.2d - - 1.2f - - 1.2h - - 1.2j - - 1.2l - - 2.5 - - reference-id: SSDF - identifiers: - - PS.1 - - PS.2 - - PS.3 - - PW.1.2 - - reference-id: OpenCRE - identifiers: - - 483-813 - - 068-486 - - 124-564 - - 757-271 - - 347-352 - - 263-184 - - 208-355 - - 745-356 - - 732-148 - - reference-id: SLSA - identifiers: - - Choose an appropriate build platform - - Follow a consistent build process - - Build platform - Isolation strength - isolated - - reference-id: PSSCRM - identifiers: - - G1.4 - - E2.1 - - E2.4 - - E2.5 - - E3.1 - - E3.6 - - reference-id: PCIDSS - identifiers: - - 6.2.1 - - 6.4.1 - - 6.5.1 - - 6.5.2 - - 10.2.2 - - reference-id: UKSSCOP - identifiers: - - 3.1 - - 3.5 - - reference-id: 800-161 - identifiers: - - AU-2 - - AU-6 - - AU-10 - - CM-5 - - CM-6 - - MA-1 - - MA-8 - - SI-4 - - SI-5 - assessment-requirements: - - id: OSPS-BR-04.01 - text: | - When an official release is created, that release MUST contain - a descriptive log of functional and security + - id: OSPS-BR-04 + title: | + All releases MUST provide a descriptive log of functional and security modifications. - applicability: - - Maturity Level 2 - - Maturity Level 3 - recommendation: | - Ensure that all releases include a descriptive change log. It is - recommended to ensure that the change log is human-readable and - includes details beyond commit messages, such as descriptions of the - security impact or relevance to different use cases. To ensure - machine readability, place the content under a markdown header - such as "## Changelog". + objective: | + Provide transparency and accountability for changes made to the project's + software releases, enabling users to understand the modifications and + improvements included in each release. + guideline-mappings: + - reference-id: BPB + entries: + - reference-id: CC-B-8 + - reference-id: CC-B-9 + - reference-id: Q-B-7 + - reference-id: A-B-1 + - reference-id: A-S-1 + - reference-id: CRA + entries: + - reference-id: 1.2d + - reference-id: 1.2f + - reference-id: 1.2h + - reference-id: 1.2j + - reference-id: 1.2l + - reference-id: 2.5 + - reference-id: SSDF + entries: + - reference-id: PS.1 + - reference-id: PS.2 + - reference-id: PS.3 + - reference-id: PW.1.2 + - reference-id: OpenCRE + entries: + - reference-id: 483-813 + - reference-id: 068-486 + - reference-id: 124-564 + - reference-id: 757-271 + - reference-id: 347-352 + - reference-id: 263-184 + - reference-id: 208-355 + - reference-id: 745-356 + - reference-id: 732-148 + - reference-id: SLSA + entries: + - reference-id: Choose an appropriate build platform + - reference-id: Follow a consistent build process + - reference-id: Build platform - Isolation strength - isolated + - reference-id: PSSCRM + entries: + - reference-id: G1.4 + - reference-id: E2.1 + - reference-id: E2.4 + - reference-id: E2.5 + - reference-id: E3.1 + - reference-id: E3.6 + - reference-id: PCIDSS + entries: + - reference-id: 6.2.1 + - reference-id: 6.4.1 + - reference-id: 6.5.1 + - reference-id: 6.5.2 + - reference-id: 10.2.2 + - reference-id: UKSSCOP + entries: + - reference-id: 3.1 + - reference-id: 3.5 + - reference-id: 800-161 + entries: + - reference-id: AU-2 + - reference-id: AU-6 + - reference-id: AU-10 + - reference-id: CM-5 + - reference-id: CM-6 + - reference-id: MA-1 + - reference-id: MA-8 + - reference-id: SI-4 + - reference-id: SI-5 + assessment-requirements: + - id: OSPS-BR-04.01 + text: | + When an official release is created, that release MUST contain + a descriptive log of functional and security + modifications. + applicability: + - maturity-2 + - maturity-3 + recommendation: | + Ensure that all releases include a descriptive change log. It is + recommended to ensure that the change log is human-readable and + includes details beyond commit messages, such as descriptions of the + security impact or relevance to different use cases. To ensure + machine readability, place the content under a markdown header + such as "## Changelog". - - id: OSPS-BR-05 - title: | - All build and release pipelines MUST use standardized tooling where - available to ingest dependencies at build time. - objective: | - Ensure that the project's build and release pipelines use standardized tools - and processes to manage dependencies, reducing the risk of compatibility - issues or security vulnerabilities in the software. - guideline-mappings: - - reference-id: BPB - identifiers: - - Q-B-2 - - reference-id: CRA - identifiers: - - 1.2b - - 1.2d - - 1.2f - - 1.2h - - 1.2j - - 2.1 - - 2.2 - - 2.3 - - reference-id: SSDF - identifiers: - - PO.3.2 - - PS.1 - - PS.2 - - reference-id: OpenCRE - identifiers: - - 486-813 - - 124-564 - - 347-352 - - 715-334 - - reference-id: SLSA - identifiers: - - Isolation strength - isolated - - reference-id: PSSCRM - identifiers: - - P3.1 - - P3.5 - - E2.2 - - E2.3 - - E2.4 - - E2.5 - - reference-id: SAMM - identifiers: - - Implementation -Secure Build -Build Process Lvl2 - - reference-id: PCIDSS - identifiers: - - 6.4.3 - - reference-id: UKSSCOP - identifiers: - - 1.1 - - 1.2 - - reference-id: 800-161 - identifiers: - - AC-4 - - CM-2 - - CM-7(4) - - CM-7(5) - - RA-5 - - SA-15 - - SR-3 - assessment-requirements: - - id: OSPS-BR-05.01 - text: | - When a build and release pipeline ingests dependencies, it MUST - use standardized tooling where available. - applicability: - - Maturity Level 2 - - Maturity Level 3 - recommendation: | - Use a common tooling for your ecosystem, such as package managers or - dependency management tools to ingest dependencies at build time. This - may include using a dependency file, lock file, or manifest to specify - the required dependencies, which are then pulled in by the build - system. + - id: OSPS-BR-05 + title: | + All build and release pipelines MUST use standardized tooling where + available to ingest dependencies at build time. + objective: | + Ensure that the project's build and release pipelines use standardized tools + and processes to manage dependencies, reducing the risk of compatibility + issues or security vulnerabilities in the software. + guideline-mappings: + - reference-id: BPB + entries: + - reference-id: Q-B-2 + - reference-id: CRA + entries: + - reference-id: 1.2b + - reference-id: 1.2d + - reference-id: 1.2f + - reference-id: 1.2h + - reference-id: 1.2j + - reference-id: 2.1 + - reference-id: 2.2 + - reference-id: 2.3 + - reference-id: SSDF + entries: + - reference-id: PO.3.2 + - reference-id: PS.1 + - reference-id: PS.2 + - reference-id: OpenCRE + entries: + - reference-id: 486-813 + - reference-id: 124-564 + - reference-id: 347-352 + - reference-id: 715-334 + - reference-id: SLSA + entries: + - reference-id: Isolation strength - isolated + - reference-id: PSSCRM + entries: + - reference-id: P3.1 + - reference-id: P3.5 + - reference-id: E2.2 + - reference-id: E2.3 + - reference-id: E2.4 + - reference-id: E2.5 + - reference-id: SAMM + entries: + - reference-id: Implementation -Secure Build -Build Process Lvl2 + - reference-id: PCIDSS + entries: + - reference-id: 6.4.3 + - reference-id: UKSSCOP + entries: + - reference-id: 1.1 + - reference-id: 1.2 + - reference-id: 800-161 + entries: + - reference-id: AC-4 + - reference-id: CM-2 + - reference-id: CM-7(4) + - reference-id: CM-7(5) + - reference-id: RA-5 + - reference-id: SA-15 + - reference-id: SR-3 + assessment-requirements: + - id: OSPS-BR-05.01 + text: | + When a build and release pipeline ingests dependencies, it MUST + use standardized tooling where available. + applicability: + - maturity-2 + - maturity-3 + recommendation: | + Use a common tooling for your ecosystem, such as package managers or + dependency management tools to ingest dependencies at build time. This + may include using a dependency file, lock file, or manifest to specify + the required dependencies, which are then pulled in by the build + system. - - id: OSPS-BR-06 - title: | - Produce all released software assets with signatures and hashes. - objective: | - All released software assets MUST be signed or accounted for in a - signed manifest including each asset's cryptographic hashes. - guideline-mappings: - - reference-id: SSDF - identifiers: - - PO.5.2 - - PS.2 - - PS.2.1 - - PW.6.2 - - reference-id: Scorecard - identifiers: - - Signed-Releases - - reference-id: SLSA - identifiers: - - Distribute provenance - Exists - - reference-id: PSSCRM - identifiers: - - P1.2 - - P3.2 - - P3.3 - - E2.1 - - E2.2 - - E2.6 - - reference-id: SAMM - identifiers: - - Implementation -Secure Deployment -Deployment Process Lvl3 - - reference-id: PCIDSS - identifiers: - - 2.2.1 - - 2.2.7 - - 3.5.1 - - 4.2.1 - - 4.2.2 - - 6.4.1 - - 8.3.2 - - reference-id: UKSSCOP - identifiers: - - 3.1 - - reference-id: 800-161 - identifiers: - - AU-10 - - MP-1 - - SA-15 - - SI-7 - - SI-7(14) - assessment-requirements: - - id: OSPS-BR-06.01 - text: | - When an official release is created, that release MUST be signed or - accounted for in a signed manifest including each asset's - cryptographic hashes. - applicability: - - Maturity Level 2 - - Maturity Level 3 - recommendation: | - Sign all released software assets at build time with a cryptographic - signature or attestations, such as GPG or PGP signature, Sigstore - signatures, SLSA provenance, or SLSA VSAs. Include the cryptographic - hashes of each asset in a signed manifest or metadata file. + - id: OSPS-BR-06 + title: | + Produce all released software assets with signatures and hashes. + objective: | + All released software assets MUST be signed or accounted for in a + signed manifest including each asset's cryptographic hashes. + guideline-mappings: + - reference-id: SSDF + entries: + - reference-id: PO.5.2 + - reference-id: PS.2 + - reference-id: PS.2.1 + - reference-id: PW.6.2 + - reference-id: Scorecard + entries: + - reference-id: Signed-Releases + - reference-id: SLSA + entries: + - reference-id: Distribute provenance - Exists + - reference-id: PSSCRM + entries: + - reference-id: P1.2 + - reference-id: P3.2 + - reference-id: P3.3 + - reference-id: E2.1 + - reference-id: E2.2 + - reference-id: E2.6 + - reference-id: SAMM + entries: + - reference-id: Implementation -Secure Deployment -Deployment Process Lvl3 + - reference-id: PCIDSS + entries: + - reference-id: 2.2.1 + - reference-id: 2.2.7 + - reference-id: 3.5.1 + - reference-id: 4.2.1 + - reference-id: 4.2.2 + - reference-id: 6.4.1 + - reference-id: 8.3.2 + - reference-id: UKSSCOP + entries: + - reference-id: 3.1 + - reference-id: 800-161 + entries: + - reference-id: AU-10 + - reference-id: MP-1 + - reference-id: SA-15 + - reference-id: SI-7 + - reference-id: SI-7(14) + assessment-requirements: + - id: OSPS-BR-06.01 + text: | + When an official release is created, that release MUST be signed or + accounted for in a signed manifest including each asset's + cryptographic hashes. + applicability: + - maturity-2 + - maturity-3 + recommendation: | + Sign all released software assets at build time with a cryptographic + signature or attestations, such as GPG or PGP signature, Sigstore + signatures, SLSA provenance, or SLSA VSAs. Include the cryptographic + hashes of each asset in a signed manifest or metadata file. diff --git a/baseline/OSPS-DO.yaml b/baseline/OSPS-DO.yaml index aafd73dc..6d6fe1b8 100644 --- a/baseline/OSPS-DO.yaml +++ b/baseline/OSPS-DO.yaml @@ -1,448 +1,450 @@ -title: Documentation -description: | - Documentation focuses on the information - provided to users, contributors, and maintainers - of the project. These controls help ensure that - the project's documentation is comprehensive, - accurate, and up-to-date, enabling users to - understand the project's features and functionality, maintenance, support, - security and release practices. -controls: - - id: OSPS-DO-01 - title: | - The project documentation MUST provide user guides for all basic - functionality. - objective: | - Ensure that users have a clear and comprehensive understanding of the - project's current features in order to prevent damage from misuse or - misconfiguration. - guideline-mappings: - - reference-id: BPB - identifiers: - - B-B-1 - - B-B-9 - - B-S-7 - - B-S-9 - - reference-id: CRA - identifiers: - - 1.2b - - 1.2j - - 1.2k - - reference-id: SSDF - identifiers: - - PW.1.2 - - reference-id: CSF - identifiers: - - GV.OC-04 - - GV.OC-05 - - reference-id: ISO-18974 - identifiers: - - 4.1.4 - - reference-id: OpenCRE - identifiers: - - 036-275 - - reference-id: PSSCRM - identifiers: - - G5.1 - - E3.5 - - reference-id: PCIDSS - identifiers: - - 2.1.1 - - 2.2.1 - - 3.1.1 - - 4.1.1 - - 5.1.1 - - 6.1.1 - - 6.2.1 - - 7.1.1 - - 8.1.1 - - 11.1.1 - - 12.10.5 - - reference-id: UKSSCOP - identifiers: - - 4.1 - - reference-id: 800-161 - identifiers: - - CM-2 - - PL-2 - - PL-8 - - SA-15 - assessment-requirements: - - id: OSPS-DO-01.01 - text: | - When the project has made a release, the project documentation MUST - include user guides for all basic functionality. - applicability: - - Maturity Level 1 - - Maturity Level 2 - - Maturity Level 3 - recommendation: | - Create user guides or documentation for all basic functionality of the - project, explaining how to install, configure, and use the project's - features. If there are any known dangerous or destructive actions - available, include highly-visible warnings. +control-families: + - id: DO + title: Documentation + description: | + Documentation focuses on the information + provided to users, contributors, and maintainers + of the project. These controls help ensure that + the project's documentation is comprehensive, + accurate, and up-to-date, enabling users to + understand the project's features and functionality, maintenance, support, + security and release practices. + controls: + - id: OSPS-DO-01 + title: | + The project documentation MUST provide user guides for all basic + functionality. + objective: | + Ensure that users have a clear and comprehensive understanding of the + project's current features in order to prevent damage from misuse or + misconfiguration. + guideline-mappings: + - reference-id: BPB + entries: + - reference-id: B-B-1 + - reference-id: B-B-9 + - reference-id: B-S-7 + - reference-id: B-S-9 + - reference-id: CRA + entries: + - reference-id: 1.2b + - reference-id: 1.2j + - reference-id: 1.2k + - reference-id: SSDF + entries: + - reference-id: PW.1.2 + - reference-id: CSF + entries: + - reference-id: GV.OC-04 + - reference-id: GV.OC-05 + - reference-id: ISO-18974 + entries: + - reference-id: 4.1.4 + - reference-id: OpenCRE + entries: + - reference-id: 036-275 + - reference-id: PSSCRM + entries: + - reference-id: G5.1 + - reference-id: E3.5 + - reference-id: PCIDSS + entries: + - reference-id: 2.1.1 + - reference-id: 2.2.1 + - reference-id: 3.1.1 + - reference-id: 4.1.1 + - reference-id: 5.1.1 + - reference-id: 6.1.1 + - reference-id: 6.2.1 + - reference-id: 7.1.1 + - reference-id: 8.1.1 + - reference-id: 11.1.1 + - reference-id: 12.10.5 + - reference-id: UKSSCOP + entries: + - reference-id: 4.1 + - reference-id: 800-161 + entries: + - reference-id: CM-2 + - reference-id: PL-2 + - reference-id: PL-8 + - reference-id: SA-15 + assessment-requirements: + - id: OSPS-DO-01.01 + text: | + When the project has made a release, the project documentation MUST + include user guides for all basic functionality. + applicability: + - maturity-1 + - maturity-2 + - maturity-3 + recommendation: | + Create user guides or documentation for all basic functionality of the + project, explaining how to install, configure, and use the project's + features. If there are any known dangerous or destructive actions + available, include highly-visible warnings. - - id: OSPS-DO-02 - title: | - The project MUST provide a mechanism for reporting defects. - objective: | - Enable users and contributors to report defects or issues with the - released software assets, facilitating communication and collaboration on - defect fixes and improvements. - guideline-mappings: - - reference-id: BPB - identifiers: - - B-B-3 - - R-B-1+ - - R-B-1 - - R-B-2 - - R-S-2 - - reference-id: CRA - identifiers: - - 1.2c - - 1.2l - - 2.1 - - 2.2 - - 2.5 - - 2.6 - - reference-id: SSDF - identifiers: - - PW.1.2 - - RV.1.1 - - RV.2.1 - - RV.1.2 - - reference-id: CSF - identifiers: - - RS.MA-02 - - GV.RM-05 - - reference-id: ISO-18974 - identifiers: - - 4.2.1 - - reference-id: SAMM - identifiers: - - Implementation -Defect Management -Defect Tracking Lvl1 - - Implementation -Defect Management -Defect Tracking Lvl2 - - reference-id: PCIDSS - identifiers: - - 6.3.2 - - 6.3.3 - - 6.5.1 - - 6.5.2 - - 12.10.2 - - reference-id: UKSSCOP - identifiers: - - 1.1 - - 1.3 - - reference-id: 800-161 - identifiers: - - IR-6 - - SI-4 - - SI-5 - assessment-requirements: - - id: OSPS-DO-02.01 - text: | - When the project has made a release, the project documentation MUST - include a guide for reporting defects. - applicability: - - Maturity Level 1 - - Maturity Level 2 - - Maturity Level 3 - recommendation: | - It is recommended that projects use their VCS default issue tracker. - If an external source is used, ensure that the project documentation - and contributing guide clearly and visibly explain how to use the - reporting system. It is recommended that project documentation also - sets expectations for how defects will be triaged and resolved. + - id: OSPS-DO-02 + title: | + The project MUST provide a mechanism for reporting defects. + objective: | + Enable users and contributors to report defects or issues with the + released software assets, facilitating communication and collaboration on + defect fixes and improvements. + guideline-mappings: + - reference-id: BPB + entries: + - reference-id: B-B-3 + - reference-id: R-B-1+ + - reference-id: R-B-1 + - reference-id: R-B-2 + - reference-id: R-S-2 + - reference-id: CRA + entries: + - reference-id: 1.2c + - reference-id: 1.2l + - reference-id: 2.1 + - reference-id: 2.2 + - reference-id: 2.5 + - reference-id: 2.6 + - reference-id: SSDF + entries: + - reference-id: PW.1.2 + - reference-id: RV.1.1 + - reference-id: RV.2.1 + - reference-id: RV.1.2 + - reference-id: CSF + entries: + - reference-id: RS.MA-02 + - reference-id: GV.RM-05 + - reference-id: ISO-18974 + entries: + - reference-id: 4.2.1 + - reference-id: SAMM + entries: + - reference-id: Implementation -Defect Management -Defect Tracking Lvl1 + - reference-id: Implementation -Defect Management -Defect Tracking Lvl2 + - reference-id: PCIDSS + entries: + - reference-id: 6.3.2 + - reference-id: 6.3.3 + - reference-id: 6.5.1 + - reference-id: 6.5.2 + - reference-id: 12.10.2 + - reference-id: UKSSCOP + entries: + - reference-id: 1.1 + - reference-id: 1.3 + - reference-id: 800-161 + entries: + - reference-id: IR-6 + - reference-id: SI-4 + - reference-id: SI-5 + assessment-requirements: + - id: OSPS-DO-02.01 + text: | + When the project has made a release, the project documentation MUST + include a guide for reporting defects. + applicability: + - maturity-1 + - maturity-2 + - maturity-3 + recommendation: | + It is recommended that projects use their VCS default issue tracker. + If an external source is used, ensure that the project documentation + and contributing guide clearly and visibly explain how to use the + reporting system. It is recommended that project documentation also + sets expectations for how defects will be triaged and resolved. - - id: OSPS-DO-03 - title: | - The project documentation MUST contain instructions to verify the - integrity and authenticity of the release assets, including the - expected identity of the person or process authoring the software - release. - objective: | - Enable users to verify the authenticity and integrity of the project's - released software assets, reducing the risk of using tampered or - unauthorized versions of the software. - guideline-mappings: - - reference-id: BPB - identifiers: - - CC-B-8 - - reference-id: CRA - identifiers: - - 1.2d - - reference-id: SSDF - identifiers: - - PO.4.2 - - PS.2 - - PS.2.1 - - PS.3.1 - - RV.1.3 - - reference-id: OpenCRE - identifiers: - - 171-222 - - reference-id: PSSCRM - identifiers: - - G1.3 - - G2.5 - - P1.2 - - P3.1 - - P3.2 - - P3.3 - - E2.6 - - reference-id: PCIDSS - identifiers: - - 3.1.1 - - 3.5.1 - - 4.1.1 - - 5.1.1 - - 6.1.1 - - 6.2.1 - - 7.1.1 - - 8.1.1 - - 11.1.1 - - reference-id: UKSSCOP - identifiers: - - 3.1 - - reference-id: 800-161 - identifiers: - - CM-2 - - IR-1 - - MP-1 - - SA-15 - - SI-7 - - SI-7(14) - assessment-requirements: - - id: OSPS-DO-03.01 - text: | - When the project has made a release, the project documentation MUST - contain instructions to verify the integrity and authenticity of the - release assets. - applicability: - - Maturity Level 3 - recommendation: | - Instructions in the project should contain information about the - technology used, the commands to run, and the expected output. - When possible, avoid storing this documentation in the same location - as the build and release pipeline to avoid a single breach - compromising both the software and the documentation for verifying the - integrity of the software. - - id: OSPS-DO-03.02 - text: | - When the project has made a release, the project documentation MUST - contain instructions to verify the expected identity of the person or - process authoring the software release. - applicability: - - Maturity Level 3 - recommendation: | - The expected identity may be in the form of key IDs used to sign, - issuer and identity from a sigstore certificate, or other similar - forms. - When possible, avoid storing this documentation in the same location - as the build and release pipeline to avoid a single breach - compromising both the software and the documentation for verifying the - integrity of the software. + - id: OSPS-DO-03 + title: | + The project documentation MUST contain instructions to verify the + integrity and authenticity of the release assets, including the + expected identity of the person or process authoring the software + release. + objective: | + Enable users to verify the authenticity and integrity of the project's + released software assets, reducing the risk of using tampered or + unauthorized versions of the software. + guideline-mappings: + - reference-id: BPB + entries: + - reference-id: CC-B-8 + - reference-id: CRA + entries: + - reference-id: 1.2d + - reference-id: SSDF + entries: + - reference-id: PO.4.2 + - reference-id: PS.2 + - reference-id: PS.2.1 + - reference-id: PS.3.1 + - reference-id: RV.1.3 + - reference-id: OpenCRE + entries: + - reference-id: 171-222 + - reference-id: PSSCRM + entries: + - reference-id: G1.3 + - reference-id: G2.5 + - reference-id: P1.2 + - reference-id: P3.1 + - reference-id: P3.2 + - reference-id: P3.3 + - reference-id: E2.6 + - reference-id: PCIDSS + entries: + - reference-id: 3.1.1 + - reference-id: 3.5.1 + - reference-id: 4.1.1 + - reference-id: 5.1.1 + - reference-id: 6.1.1 + - reference-id: 6.2.1 + - reference-id: 7.1.1 + - reference-id: 8.1.1 + - reference-id: 11.1.1 + - reference-id: UKSSCOP + entries: + - reference-id: 3.1 + - reference-id: 800-161 + entries: + - reference-id: CM-2 + - reference-id: IR-1 + - reference-id: MP-1 + - reference-id: SA-15 + - reference-id: SI-7 + - reference-id: SI-7(14) + assessment-requirements: + - id: OSPS-DO-03.01 + text: | + When the project has made a release, the project documentation MUST + contain instructions to verify the integrity and authenticity of the + release assets. + applicability: + - maturity-3 + recommendation: | + Instructions in the project should contain information about the + technology used, the commands to run, and the expected output. + When possible, avoid storing this documentation in the same location + as the build and release pipeline to avoid a single breach + compromising both the software and the documentation for verifying the + integrity of the software. + - id: OSPS-DO-03.02 + text: | + When the project has made a release, the project documentation MUST + contain instructions to verify the expected identity of the person or + process authoring the software release. + applicability: + - maturity-3 + recommendation: | + The expected identity may be in the form of key IDs used to sign, + issuer and identity from a sigstore certificate, or other similar + forms. + When possible, avoid storing this documentation in the same location + as the build and release pipeline to avoid a single breach + compromising both the software and the documentation for verifying the + integrity of the software. - - id: OSPS-DO-04 - title: | - The project documentation MUST include a descriptive statement about - the scope and duration of support. - objective: | - Provide users with clear expectations regarding the project's support - lifecycle. This allows downstream consumers to take relevant actions to - ensure the continued functionality and security of their systems. - guideline-mappings: - - reference-id: BPB - identifiers: - - R-B-3 - - reference-id: SSDF - identifiers: - - PO.4.2 - - PS.3.1 - - RV.1.3 - - reference-id: ISO-18974 - identifiers: - - 4.1 - - 4.3.1 - - reference-id: PSSCRM - identifiers: - - E1.6 - - reference-id: SAMM - identifiers: - - Operations -Operational Management -System Decommissioning -Legacy Management Lvl1 - - reference-id: PCIDSS - identifiers: - - 2.1.1 - - 3.1.1 - - 3.2.1 - - 4.1.1 - - 5.1.1 - - 6.1.1 - - 6.3.3 - - 7.1.1 - - 8.1.1 - - 11.1.1 - - reference-id: UKSSCOP - identifiers: - - 4.1 - - 4.2 - - reference-id: 800-161 - identifiers: - - PL-1 - - PL-2 - - SI-4 - assessment-requirements: - - id: OSPS-DO-04.01 - text: | - When the project has made a release, the project documentation MUST - include a descriptive statement about the scope and duration of - support for each release. - applicability: - - Maturity Level 3 - recommendation: | - In order to communicate the scope and duration of support for the - project's released software assets, the project should have a - SUPPORT.md file, a "Support" section in SECURITY.md, or - other documentation explaining the support lifecycle, - including the expected duration of support for each release, the - types of support provided (e.g., bug fixes, security updates), and - any relevant policies or procedures for obtaining support. + - id: OSPS-DO-04 + title: | + The project documentation MUST include a descriptive statement about + the scope and duration of support. + objective: | + Provide users with clear expectations regarding the project's support + lifecycle. This allows downstream consumers to take relevant actions to + ensure the continued functionality and security of their systems. + guideline-mappings: + - reference-id: BPB + entries: + - reference-id: R-B-3 + - reference-id: SSDF + entries: + - reference-id: PO.4.2 + - reference-id: PS.3.1 + - reference-id: RV.1.3 + - reference-id: ISO-18974 + entries: + - reference-id: 4.1 + - reference-id: 4.3.1 + - reference-id: PSSCRM + entries: + - reference-id: E1.6 + - reference-id: SAMM + entries: + - reference-id: Operations -Operational Management -System Decommissioning -Legacy Management Lvl1 + - reference-id: PCIDSS + entries: + - reference-id: 2.1.1 + - reference-id: 3.1.1 + - reference-id: 3.2.1 + - reference-id: 4.1.1 + - reference-id: 5.1.1 + - reference-id: 6.1.1 + - reference-id: 6.3.3 + - reference-id: 7.1.1 + - reference-id: 8.1.1 + - reference-id: 11.1.1 + - reference-id: UKSSCOP + entries: + - reference-id: 4.1 + - reference-id: 4.2 + - reference-id: 800-161 + entries: + - reference-id: PL-1 + - reference-id: PL-2 + - reference-id: SI-4 + assessment-requirements: + - id: OSPS-DO-04.01 + text: | + When the project has made a release, the project documentation MUST + include a descriptive statement about the scope and duration of + support for each release. + applicability: + - maturity-3 + recommendation: | + In order to communicate the scope and duration of support for the + project's released software assets, the project should have a + SUPPORT.md file, a "Support" section in SECURITY.md, or + other documentation explaining the support lifecycle, + including the expected duration of support for each release, the + types of support provided (e.g., bug fixes, security updates), and + any relevant policies or procedures for obtaining support. - - id: OSPS-DO-05 - title: | - The project documentation MUST provide a descriptive statement when - releases or versions will no longer receive security updates. - objective: | - Communicating when the project maintainers will no longer fix defects or - security vulnerabilities is crucial for downstream consumers to find - alternative solutions or alternative means of support for the project. - guideline-mappings: - - reference-id: CRA - identifiers: - - 1.2c - - 2.6 - - reference-id: ISO-18974 - identifiers: - - 4.1.1 - - 4.3.1 - - reference-id: OpenCRE - identifiers: - - 673-475 - - 053-751 - - reference-id: PSSCRM - identifiers: - - E1.6 - - reference-id: SAMM - identifiers: - - Operations -Operational Management -System Decommissioning -Legacy Management Lvl1 - - Operations -Operational Management -System Decommissioning -Legacy Management Lvl2 - - reference-id: PCIDSS - identifiers: - - 3.1.1 - - 3.2.1 - - 4.1.1 - - 5.1.1 - - 6.1.1 - - 6.3.2 - - 7.1.1 - - 8.1.1 - - 11.1.1 - - reference-id: UKSSCOP - identifiers: - - 3.5 - - 4.1 - - reference-id: 800-161 - identifiers: - - PL-1 - - PL-2 - - SI-4 - - SI-5 - assessment-requirements: - - id: OSPS-DO-05.01 - text: | - When the project has made a release, the project documentation MUST - provide a descriptive statement when releases or versions will no - longer receive security updates. - applicability: - - Maturity Level 3 - recommendation: | - In order to communicate the scope and duration of support for security - fixes, the project should have a SUPPORT.md or other documentation - explaining the project's policy for security updates. + - id: OSPS-DO-05 + title: | + The project documentation MUST provide a descriptive statement when + releases or versions will no longer receive security updates. + objective: | + Communicating when the project maintainers will no longer fix defects or + security vulnerabilities is crucial for downstream consumers to find + alternative solutions or alternative means of support for the project. + guideline-mappings: + - reference-id: CRA + entries: + - reference-id: 1.2c + - reference-id: 2.6 + - reference-id: ISO-18974 + entries: + - reference-id: 4.1.1 + - reference-id: 4.3.1 + - reference-id: OpenCRE + entries: + - reference-id: 673-475 + - reference-id: 053-751 + - reference-id: PSSCRM + entries: + - reference-id: E1.6 + - reference-id: SAMM + entries: + - reference-id: Operations -Operational Management -System Decommissioning -Legacy Management Lvl1 + - reference-id: Operations -Operational Management -System Decommissioning -Legacy Management Lvl2 + - reference-id: PCIDSS + entries: + - reference-id: 3.1.1 + - reference-id: 3.2.1 + - reference-id: 4.1.1 + - reference-id: 5.1.1 + - reference-id: 6.1.1 + - reference-id: 6.3.2 + - reference-id: 7.1.1 + - reference-id: 8.1.1 + - reference-id: 11.1.1 + - reference-id: UKSSCOP + entries: + - reference-id: 3.5 + - reference-id: 4.1 + - reference-id: 800-161 + entries: + - reference-id: PL-1 + - reference-id: PL-2 + - reference-id: SI-4 + - reference-id: SI-5 + assessment-requirements: + - id: OSPS-DO-05.01 + text: | + When the project has made a release, the project documentation MUST + provide a descriptive statement when releases or versions will no + longer receive security updates. + applicability: + - maturity-3 + recommendation: | + In order to communicate the scope and duration of support for security + fixes, the project should have a SUPPORT.md or other documentation + explaining the project's policy for security updates. - - id: OSPS-DO-06 - title: | - The project documentation MUST include a description of how the - project selects, obtains, and tracks its dependencies. - objective: | - Provide information about how the project selects, obtains, and tracks - dependencies, libraries, frameworks, etc. to help downstream consumers - understand how the project operates in regards to third-party components - that are required necessary for the software to function. - guideline-mappings: - - reference-id: BPB - identifiers: - - A-S-1 - - reference-id: CRA - identifiers: - - 2.1 - - reference-id: OpenCRE - identifiers: - - 613-286 - - 053-751 - - reference-id: Scorecard - identifiers: - - Pinned-Dependencies - - reference-id: PSSCRM - identifiers: - - G1.4 - - G2.4 - - P3.1 - - P3.2 - - P3.4 - - reference-id: SAMM - identifiers: - - Design -Security Requirements -Supplier Security Lvl2 - - reference-id: PCIDSS - identifiers: - - 2.1.1 - - 3.1.1 - - 4.1.1 - - 5.1.1 - - 6.1.1 - - 6.3.2 - - 6.4.3 - - 7.1.1 - - 8.1.1 - - 11.1.1 - - 12.5.2 - - reference-id: UKSSCOP - identifiers: - - 1.2 - - 3.3 - - reference-id: 800-161 - identifiers: - - CA-7 - - CM-7(5) - - CM-8 - - PM-30 - - RA-3(1) - - SA-11 - - SI-4 - - SR-3 - - SR-5 - - SR-6 - - SR-7 - assessment-requirements: - - id: OSPS-DO-06.01 - text: | - When the project has made a release, the project documentation MUST - include a description of how the project selects, obtains, and tracks - its dependencies. - applicability: - - Maturity Level 2 - - Maturity Level 3 - recommendation: | - It is recommended to publish this information alongside the project's - technical & design documentation on a publicly viewable resource such - as the source code repository, project website, or other channel. + - id: OSPS-DO-06 + title: | + The project documentation MUST include a description of how the + project selects, obtains, and tracks its dependencies. + objective: | + Provide information about how the project selects, obtains, and tracks + dependencies, libraries, frameworks, etc. to help downstream consumers + understand how the project operates in regards to third-party components + that are required necessary for the software to function. + guideline-mappings: + - reference-id: BPB + entries: + - reference-id: A-S-1 + - reference-id: CRA + entries: + - reference-id: 2.1 + - reference-id: OpenCRE + entries: + - reference-id: 613-286 + - reference-id: 053-751 + - reference-id: Scorecard + entries: + - reference-id: Pinned-Dependencies + - reference-id: PSSCRM + entries: + - reference-id: G1.4 + - reference-id: G2.4 + - reference-id: P3.1 + - reference-id: P3.2 + - reference-id: P3.4 + - reference-id: SAMM + entries: + - reference-id: Design -Security Requirements -Supplier Security Lvl2 + - reference-id: PCIDSS + entries: + - reference-id: 2.1.1 + - reference-id: 3.1.1 + - reference-id: 4.1.1 + - reference-id: 5.1.1 + - reference-id: 6.1.1 + - reference-id: 6.3.2 + - reference-id: 6.4.3 + - reference-id: 7.1.1 + - reference-id: 8.1.1 + - reference-id: 11.1.1 + - reference-id: 12.5.2 + - reference-id: UKSSCOP + entries: + - reference-id: 1.2 + - reference-id: 3.3 + - reference-id: 800-161 + entries: + - reference-id: CA-7 + - reference-id: CM-7(5) + - reference-id: CM-8 + - reference-id: PM-30 + - reference-id: RA-3(1) + - reference-id: SA-11 + - reference-id: SI-4 + - reference-id: SR-3 + - reference-id: SR-5 + - reference-id: SR-6 + - reference-id: SR-7 + assessment-requirements: + - id: OSPS-DO-06.01 + text: | + When the project has made a release, the project documentation MUST + include a description of how the project selects, obtains, and tracks + its dependencies. + applicability: + - maturity-2 + - maturity-3 + recommendation: | + It is recommended to publish this information alongside the project's + technical & design documentation on a publicly viewable resource such + as the source code repository, project website, or other channel. diff --git a/baseline/OSPS-GV.yaml b/baseline/OSPS-GV.yaml index 0611e726..5af9d713 100644 --- a/baseline/OSPS-GV.yaml +++ b/baseline/OSPS-GV.yaml @@ -1,273 +1,275 @@ -title: Governance -description: | - Governance focuses on the policies and - procedures that guide the project's decision-making - and community interactions. These controls help ensure - that the project is well positioned to respond to - both threats and opportunities. -controls: - - id: OSPS-GV-01 - title: | - The project documentation MUST include the roles and responsibilities - for members of the project. - objective: | - Documenting project roles and responsibilities helps project participants, - potential contributors, and downstream consumers have an accurate - understanding of who is working on the project and what areas of authority - they may have. - guideline-mappings: - - reference-id: BPB - identifiers: - - B-S-3 - - B-S-4 - - reference-id: OpenCRE - identifiers: - - 013-021 - - reference-id: PSSCRM - identifiers: - - G2.3 - - E3.1 - - E3.3 - - reference-id: PCIDSS - identifiers: - - 2.1.2 - - 3.1.1 - - 3.1.2 - - 4.1.1 - - 4.1.2 - - 5.1.1 - - 5.1.2 - - 6.1.1 - - 6.1.2 - - 6.5.4 - - 7.1.1 - - 7.1.2 - - 8.1.1 - - 8.1.2 - - 11.1.1 - - 11.1.2 - - 12.1.3 - - 12.5.2 - - reference-id: 800-161 - identifiers: - - AC-2 - - AC-3 - - IA-2 - - PL-1 - - PL-4 - - PM-30 - assessment-requirements: - - id: OSPS-GV-01.01 - text: | - While active, the project documentation MUST include a list of - project members with access to sensitive resources. - applicability: - - Maturity Level 2 - - Maturity Level 3 - recommendation: | - Document project participants and their roles through such artifacts - as members.md, governance.md, maintainers.md, or similar file within - the source code repository of the project. - This may be as simple as including names or account handles in a list - of maintainers, or more complex depending on the project's governance. - - id: OSPS-GV-01.02 - text: | - While active, the project documentation MUST include descriptions of - the roles and responsibilities for members of the project. - applicability: - - Maturity Level 2 - - Maturity Level 3 - recommendation: | - Document project participants and their roles through such artifacts - as members.md, governance.md, maintainers.md, or similar file within - the source code repository of the project. +control-families: + - id: GV + title: Governance + description: | + Governance focuses on the policies and + procedures that guide the project's decision-making + and community interactions. These controls help ensure + that the project is well positioned to respond to + both threats and opportunities. + controls: + - id: OSPS-GV-01 + title: | + The project documentation MUST include the roles and responsibilities + for members of the project. + objective: | + Documenting project roles and responsibilities helps project participants, + potential contributors, and downstream consumers have an accurate + understanding of who is working on the project and what areas of authority + they may have. + guideline-mappings: + - reference-id: BPB + entries: + - reference-id: B-S-3 + - reference-id: B-S-4 + - reference-id: OpenCRE + entries: + - reference-id: 013-021 + - reference-id: PSSCRM + entries: + - reference-id: G2.3 + - reference-id: E3.1 + - reference-id: E3.3 + - reference-id: PCIDSS + entries: + - reference-id: 2.1.2 + - reference-id: 3.1.1 + - reference-id: 3.1.2 + - reference-id: 4.1.1 + - reference-id: 4.1.2 + - reference-id: 5.1.1 + - reference-id: 5.1.2 + - reference-id: 6.1.1 + - reference-id: 6.1.2 + - reference-id: 6.5.4 + - reference-id: 7.1.1 + - reference-id: 7.1.2 + - reference-id: 8.1.1 + - reference-id: 8.1.2 + - reference-id: 11.1.1 + - reference-id: 11.1.2 + - reference-id: 12.1.3 + - reference-id: 12.5.2 + - reference-id: 800-161 + entries: + - reference-id: AC-2 + - reference-id: AC-3 + - reference-id: IA-2 + - reference-id: PL-1 + - reference-id: PL-4 + - reference-id: PM-30 + assessment-requirements: + - id: OSPS-GV-01.01 + text: | + While active, the project documentation MUST include a list of + project members with access to sensitive resources. + applicability: + - maturity-2 + - maturity-3 + recommendation: | + Document project participants and their roles through such artifacts + as members.md, governance.md, maintainers.md, or similar file within + the source code repository of the project. + This may be as simple as including names or account handles in a list + of maintainers, or more complex depending on the project's governance. + - id: OSPS-GV-01.02 + text: | + While active, the project documentation MUST include descriptions of + the roles and responsibilities for members of the project. + applicability: + - maturity-2 + - maturity-3 + recommendation: | + Document project participants and their roles through such artifacts + as members.md, governance.md, maintainers.md, or similar file within + the source code repository of the project. - - id: OSPS-GV-02 - title: | - The project MUST have one or more mechanisms for public discussions - about proposed changes and usage obstacles. - objective: | - Encourages open communication and collaboration within the project - community, enabling users to provide feedback and discuss proposed changes - or usage challenges. - guideline-mappings: - - reference-id: BPB - identifiers: - - B-B-3 - - B-B-12 - - reference-id: CRA - identifiers: - - 1.2l - - 2.3 - - 2.4 - - 2.6 - - reference-id: SSDF - identifiers: - - PS.3 - - PW.1.2 - - reference-id: PCIDSS - identifiers: - - 12.5.2 - - reference-id: 800-161 - identifiers: - - AC-21 - - AU-6 - - PL-1 - assessment-requirements: - - id: OSPS-GV-02.01 - text: | - While active, the project MUST have one or more mechanisms for public - discussions about proposed changes and usage obstacles. - applicability: - - Maturity Level 1 - - Maturity Level 2 - - Maturity Level 3 - recommendation: | - Establish one or more mechanisms for public discussions within the - project, such as mailing lists, instant messaging, or issue trackers, - to facilitate open communication and feedback. + - id: OSPS-GV-02 + title: | + The project MUST have one or more mechanisms for public discussions + about proposed changes and usage obstacles. + objective: | + Encourages open communication and collaboration within the project + community, enabling users to provide feedback and discuss proposed changes + or usage challenges. + guideline-mappings: + - reference-id: BPB + entries: + - reference-id: B-B-3 + - reference-id: B-B-12 + - reference-id: CRA + entries: + - reference-id: 1.2l + - reference-id: 2.3 + - reference-id: 2.4 + - reference-id: 2.6 + - reference-id: SSDF + entries: + - reference-id: PS.3 + - reference-id: PW.1.2 + - reference-id: PCIDSS + entries: + - reference-id: 12.5.2 + - reference-id: 800-161 + entries: + - reference-id: AC-21 + - reference-id: AU-6 + - reference-id: PL-1 + assessment-requirements: + - id: OSPS-GV-02.01 + text: | + While active, the project MUST have one or more mechanisms for public + discussions about proposed changes and usage obstacles. + applicability: + - maturity-1 + - maturity-2 + - maturity-3 + recommendation: | + Establish one or more mechanisms for public discussions within the + project, such as mailing lists, instant messaging, or issue trackers, + to facilitate open communication and feedback. - - id: OSPS-GV-03 - title: | - The project documentation MUST include an explanation of the - contribution process. - objective: | - Provide guidance to new contributors on how to participate in the project, - outlining the steps required to submit changes or enhancements to the - project's codebase. - guideline-mappings: - - reference-id: BPB - identifiers: - - B-B-4 - - B-S-3 - - B-B-4+ - - R-B-1 - - Q-G-2 - - reference-id: CRA - identifiers: - - 1.2l - - 2.4 - - reference-id: SSDF - identifiers: - - PW.1.2 - - reference-id: ISO-18974 - identifiers: - - 4.1.2 - - reference-id: PSSCRM - identifiers: - - G2.4 - - P2.2 - - reference-id: PCIDSS - identifiers: - - 2.1.1 - - 6.5.4 - - 8.2.1 - - 12.5.2 - - reference-id: 800-161 - identifiers: - - AC-3 - - AC-20 - - PL-1 - assessment-requirements: - - id: OSPS-GV-03.01 - text: | - While active, the project documentation MUST include an explanation - of the contribution process. - applicability: - - Maturity Level 1 - - Maturity Level 2 - - Maturity Level 3 - recommendation: | - Create a CONTRIBUTING.md or CONTRIBUTING/ directory to outline the - contribution process including the steps for submitting changes, and - engaging with the project maintainers. - - id: OSPS-GV-03.02 - text: | - While active, the project documentation MUST include a guide for code - contributors that includes requirements for acceptable contributions. - applicability: - - Maturity Level 2 - - Maturity Level 3 - recommendation: | - Extend the CONTRIBUTING.md or CONTRIBUTING/ contents in the project - documentation to outline the requirements for acceptable - contributions, including coding standards, testing requirements, and - submission guidelines for code contributors. It is recommended that - this guide is the source of truth for both contributors and approvers. + - id: OSPS-GV-03 + title: | + The project documentation MUST include an explanation of the + contribution process. + objective: | + Provide guidance to new contributors on how to participate in the project, + outlining the steps required to submit changes or enhancements to the + project's codebase. + guideline-mappings: + - reference-id: BPB + entries: + - reference-id: B-B-4 + - reference-id: B-S-3 + - reference-id: B-B-4+ + - reference-id: R-B-1 + - reference-id: Q-G-2 + - reference-id: CRA + entries: + - reference-id: 1.2l + - reference-id: 2.4 + - reference-id: SSDF + entries: + - reference-id: PW.1.2 + - reference-id: ISO-18974 + entries: + - reference-id: 4.1.2 + - reference-id: PSSCRM + entries: + - reference-id: G2.4 + - reference-id: P2.2 + - reference-id: PCIDSS + entries: + - reference-id: 2.1.1 + - reference-id: 6.5.4 + - reference-id: 8.2.1 + - reference-id: 12.5.2 + - reference-id: 800-161 + entries: + - reference-id: AC-3 + - reference-id: AC-20 + - reference-id: PL-1 + assessment-requirements: + - id: OSPS-GV-03.01 + text: | + While active, the project documentation MUST include an explanation + of the contribution process. + applicability: + - maturity-1 + - maturity-2 + - maturity-3 + recommendation: | + Create a CONTRIBUTING.md or CONTRIBUTING/ directory to outline the + contribution process including the steps for submitting changes, and + engaging with the project maintainers. + - id: OSPS-GV-03.02 + text: | + While active, the project documentation MUST include a guide for code + contributors that includes requirements for acceptable contributions. + applicability: + - maturity-2 + - maturity-3 + recommendation: | + Extend the CONTRIBUTING.md or CONTRIBUTING/ contents in the project + documentation to outline the requirements for acceptable + contributions, including coding standards, testing requirements, and + submission guidelines for code contributors. It is recommended that + this guide is the source of truth for both contributors and approvers. - - id: OSPS-GV-04 - title: | - The project documentation MUST have a policy that code contributors - are reviewed prior to granting escalated permissions to sensitive - resources. - objective: | - Ensure that code contributors are vetted and reviewed before being granted - elevated permissions to sensitive resources within the project, reducing - the risk of unauthorized access or misuse. - guideline-mappings: - - reference-id: BPB - identifiers: - - B-B-5 - - B-S-3 - - B-B-4+ - - Q-G-2 - - reference-id: CRA - identifiers: - - 1.2d - - 1.2l - - 2.1 - - 2.2 - - 2.5 - - 2.6 - - reference-id: SSDF - identifiers: - - PO.2 - - PO.3.2 - - reference-id: CSF - identifiers: - - PR.AA-02 - - PR.AA-05 - - reference-id: OpenCRE - identifiers: - - 123-124 - - 152-725 - - reference-id: ISO-18974 - identifiers: - - 4.1.2 - - reference-id: PSSCRM - identifiers: - - E3.1 - - E3.3 - - reference-id: PCIDSS - identifiers: - - 2.1.1 - - 6.5.4 - - 8.2.1 - - 8.2.2 - - reference-id: 800-161 - identifiers: - - AC-2 - - AC-3 - - AC-4(21) - - AC-5 - - AC-6 - - AC-20 - - CM-7 - - IR-4(6) - - PM-30 - - SI-4 - assessment-requirements: - - id: OSPS-GV-04.01 - text: | - While active, the project documentation MUST have a policy that code - contributors are reviewed prior to granting escalated permissions to - sensitive resources. - applicability: - - Maturity Level 3 - recommendation: | - Publish an enforceable policy in the project documentation that - requires code contributors to be reviewed and approved before being - granted escalated permissions to sensitive resources, such as merge - approval or access to secrets. It is recommended that vetting includes - establishing a justifiable lineage of identity such as confirming the - contributor's association with a known trusted organization. \ No newline at end of file + - id: OSPS-GV-04 + title: | + The project documentation MUST have a policy that code contributors + are reviewed prior to granting escalated permissions to sensitive + resources. + objective: | + Ensure that code contributors are vetted and reviewed before being granted + elevated permissions to sensitive resources within the project, reducing + the risk of unauthorized access or misuse. + guideline-mappings: + - reference-id: BPB + entries: + - reference-id: B-B-5 + - reference-id: B-S-3 + - reference-id: B-B-4+ + - reference-id: Q-G-2 + - reference-id: CRA + entries: + - reference-id: 1.2d + - reference-id: 1.2l + - reference-id: 2.1 + - reference-id: 2.2 + - reference-id: 2.5 + - reference-id: 2.6 + - reference-id: SSDF + entries: + - reference-id: PO.2 + - reference-id: PO.3.2 + - reference-id: CSF + entries: + - reference-id: PR.AA-02 + - reference-id: PR.AA-05 + - reference-id: OpenCRE + entries: + - reference-id: 123-124 + - reference-id: 152-725 + - reference-id: ISO-18974 + entries: + - reference-id: 4.1.2 + - reference-id: PSSCRM + entries: + - reference-id: E3.1 + - reference-id: E3.3 + - reference-id: PCIDSS + entries: + - reference-id: 2.1.1 + - reference-id: 6.5.4 + - reference-id: 8.2.1 + - reference-id: 8.2.2 + - reference-id: 800-161 + entries: + - reference-id: AC-2 + - reference-id: AC-3 + - reference-id: AC-4(21) + - reference-id: AC-5 + - reference-id: AC-6 + - reference-id: AC-20 + - reference-id: CM-7 + - reference-id: IR-4(6) + - reference-id: PM-30 + - reference-id: SI-4 + assessment-requirements: + - id: OSPS-GV-04.01 + text: | + While active, the project documentation MUST have a policy that code + contributors are reviewed prior to granting escalated permissions to + sensitive resources. + applicability: + - maturity-3 + recommendation: | + Publish an enforceable policy in the project documentation that + requires code contributors to be reviewed and approved before being + granted escalated permissions to sensitive resources, such as merge + approval or access to secrets. It is recommended that vetting includes + establishing a justifiable lineage of identity such as confirming the + contributor's association with a known trusted organization. \ No newline at end of file diff --git a/baseline/OSPS-LE.yaml b/baseline/OSPS-LE.yaml index 5fb73498..d3844097 100644 --- a/baseline/OSPS-LE.yaml +++ b/baseline/OSPS-LE.yaml @@ -1,195 +1,197 @@ -title: Legal -description: | - Legal focuses on the policies and - procedures that govern the project's licensing - and intellectual property. These controls help - ensure that the project's source code is - distributed under a recognized and legally - enforceable open source software license, - reducing the risk of intellectual property - disputes or licensing violations. -controls: - - id: OSPS-LE-01 - title: | - The version control system MUST require all code contributors to assert - that they are legally authorized to make the associated contributions - on every commit. - objective: | - Ensure that code contributors are aware of and acknowledge their legal - responsibility for the contributions they make to the project, reducing - the risk of intellectual property disputes against the project. - guideline-mappings: - - reference-id: BPB - identifiers: - - B-S-1 - - reference-id: CRA - identifiers: - - 1.2b - - 1.2f - - reference-id: SSDF - identifiers: - - PO.3.2 - - PS.1 - - PW.1.2 - - PW.2.1 - - reference-id: PSSCRM - identifiers: - - E3.1 - - reference-id: PCIDSS - identifiers: - - 12.8.5 - - reference-id: 800-161 - identifiers: - - PL-4 - assessment-requirements: - - id: OSPS-LE-01.01 - text: | - While active, the version control system MUST require all code - contributors to assert that they are legally authorized to make the - associated contributions on every commit. - applicability: - - Maturity Level 2 - - Maturity Level 3 - recommendation: | - Include a DCO in the project's repository, requiring code - contributors to assert that they are legally authorized to commit the - associated contributions on every commit. Use a status check to ensure - the assertion is made. A CLA also satisfies this requirement. - Some version control systems, such as GitHub, may include this in the - platform terms of service. +control-families: + - id: LE + title: Legal + description: | + Legal focuses on the policies and + procedures that govern the project's licensing + and intellectual property. These controls help + ensure that the project's source code is + distributed under a recognized and legally + enforceable open source software license, + reducing the risk of intellectual property + disputes or licensing violations. + controls: + - id: OSPS-LE-01 + title: | + The version control system MUST require all code contributors to assert + that they are legally authorized to make the associated contributions + on every commit. + objective: | + Ensure that code contributors are aware of and acknowledge their legal + responsibility for the contributions they make to the project, reducing + the risk of intellectual property disputes against the project. + guideline-mappings: + - reference-id: BPB + entries: + - reference-id: B-S-1 + - reference-id: CRA + entries: + - reference-id: 1.2b + - reference-id: 1.2f + - reference-id: SSDF + entries: + - reference-id: PO.3.2 + - reference-id: PS.1 + - reference-id: PW.1.2 + - reference-id: PW.2.1 + - reference-id: PSSCRM + entries: + - reference-id: E3.1 + - reference-id: PCIDSS + entries: + - reference-id: 12.8.5 + - reference-id: 800-161 + entries: + - reference-id: PL-4 + assessment-requirements: + - id: OSPS-LE-01.01 + text: | + While active, the version control system MUST require all code + contributors to assert that they are legally authorized to make the + associated contributions on every commit. + applicability: + - maturity-2 + - maturity-3 + recommendation: | + Include a DCO in the project's repository, requiring code + contributors to assert that they are legally authorized to commit the + associated contributions on every commit. Use a status check to ensure + the assertion is made. A CLA also satisfies this requirement. + Some version control systems, such as GitHub, may include this in the + platform terms of service. - It is understood that projects with a lengthy history prior to - adopting OSPS Baseline may not be able to retroactively enforce this - requirement. + It is understood that projects with a lengthy history prior to + adopting OSPS Baseline may not be able to retroactively enforce this + requirement. - - id: OSPS-LE-02 - title: | - All licenses for the project MUST meet the OSI Open Source Definition - or the FSF Free Software Definition. - objective: | - Ensure that the project's source code is distributed under a recognized - and legally enforceable open source software license, providing clarity on - how the code can be used and shared by others. - guideline-mappings: - - reference-id: BPB - identifiers: - - B-B-6 - - B-B-7 - - reference-id: CRA - identifiers: - - 1.2b - - reference-id: SSDF - identifiers: - - PO.3.2 - - reference-id: CSF - identifiers: - - GV.OC-03 - - reference-id: Scorecard - identifiers: - - License - - reference-id: PSSCRM - identifiers: - - G1.2 - - reference-id: PCIDSS - identifiers: - - 3.2.1 - - reference-id: 800-161 - identifiers: - - PL-4 - assessment-requirements: - - id: OSPS-LE-02.01 - text: | - While active, the license for the source code MUST meet the OSI Open - Source Definition or the FSF Free Software Definition. - applicability: - - Maturity Level 1 - - Maturity Level 2 - - Maturity Level 3 - recommendation: | - Add a LICENSE file to the project's repo with a license that is an - approved license by the Open Source Initiative (OSI), or a free - license as approved by the Free Software Foundation (FSF). Examples of - such licenses include the MIT, BSD 2-clause, BSD 3-clause revised, - Apache 2.0, Lesser GNU General Public License (LGPL), and the GNU - General Public License (GPL). Releasing to the public domain meets - this control if there are no other encumbrances such as patents. - - id: OSPS-LE-02.02 - text: | - While active, the license for the released software assets MUST meet - the OSI Open Source Definition or the FSF Free Software Definition. - applicability: - - Maturity Level 1 - - Maturity Level 2 - - Maturity Level 3 - recommendation: | - If a different license is included with released software assets, - ensure it is an approved license by the Open Source Initiative (OSI), - or a free license as approved by the Free Software Foundation (FSF). - Examples of such licenses include the MIT, BSD 2-clause, BSD 3-clause - revised, Apache 2.0, Lesser GNU General Public License (LGPL), and the - GNU General Public License (GPL). Note that the license for the - released software assets may be different than the source code. + - id: OSPS-LE-02 + title: | + All licenses for the project MUST meet the OSI Open Source Definition + or the FSF Free Software Definition. + objective: | + Ensure that the project's source code is distributed under a recognized + and legally enforceable open source software license, providing clarity on + how the code can be used and shared by others. + guideline-mappings: + - reference-id: BPB + entries: + - reference-id: B-B-6 + - reference-id: B-B-7 + - reference-id: CRA + entries: + - reference-id: 1.2b + - reference-id: SSDF + entries: + - reference-id: PO.3.2 + - reference-id: CSF + entries: + - reference-id: GV.OC-03 + - reference-id: Scorecard + entries: + - reference-id: License + - reference-id: PSSCRM + entries: + - reference-id: G1.2 + - reference-id: PCIDSS + entries: + - reference-id: 3.2.1 + - reference-id: 800-161 + entries: + - reference-id: PL-4 + assessment-requirements: + - id: OSPS-LE-02.01 + text: | + While active, the license for the source code MUST meet the OSI Open + Source Definition or the FSF Free Software Definition. + applicability: + - maturity-1 + - maturity-2 + - maturity-3 + recommendation: | + Add a LICENSE file to the project's repo with a license that is an + approved license by the Open Source Initiative (OSI), or a free + license as approved by the Free Software Foundation (FSF). Examples of + such licenses include the MIT, BSD 2-clause, BSD 3-clause revised, + Apache 2.0, Lesser GNU General Public License (LGPL), and the GNU + General Public License (GPL). Releasing to the public domain meets + this control if there are no other encumbrances such as patents. + - id: OSPS-LE-02.02 + text: | + While active, the license for the released software assets MUST meet + the OSI Open Source Definition or the FSF Free Software Definition. + applicability: + - maturity-1 + - maturity-2 + - maturity-3 + recommendation: | + If a different license is included with released software assets, + ensure it is an approved license by the Open Source Initiative (OSI), + or a free license as approved by the Free Software Foundation (FSF). + Examples of such licenses include the MIT, BSD 2-clause, BSD 3-clause + revised, Apache 2.0, Lesser GNU General Public License (LGPL), and the + GNU General Public License (GPL). Note that the license for the + released software assets may be different than the source code. - - id: OSPS-LE-03 - title: | - All licenses for the project's source code MUST be maintained in a - standard location within the corresponding repository. - objective: | - Ensure that the project's source code and released software assets are - distributed with the appropriate license terms, making it clear to users - and contributors how each can be used and shared. - guideline-mappings: - - reference-id: BPB - identifiers: - - B-B-8 - - reference-id: CRA - identifiers: - - 1.2b - - reference-id: SSDF - identifiers: - - PO.3.2 - - reference-id: Scorecard - identifiers: - - License - - reference-id: PSSCRM - identifiers: - - G1.2 - - reference-id: PCIDSS - identifiers: - - 3.2.1 - - reference-id: 800-161 - identifiers: - - PL-4 - assessment-requirements: - - id: OSPS-LE-03.01 - text: | - While active, the license for the source code MUST be maintained in - the corresponding repository's LICENSE file, COPYING file, or - LICENSE/ directory. - applicability: - - Maturity Level 1 - - Maturity Level 2 - - Maturity Level 3 - recommendation: | - Include the project's source code license in the project's LICENSE - file, COPYING file, or LICENSE/ directory to provide visibility and - clarity on the licensing terms. The filename MAY have an extension. - If the project has multiple repositories, ensure that each repository - includes the license file. - - id: OSPS-LE-03.02 - text: | - While active, the license for the released software assets MUST be - included in the released source code, or in a LICENSE file, COPYING - file, or LICENSE/ directory alongside the corresponding release - assets. - applicability: - - Maturity Level 1 - - Maturity Level 2 - - Maturity Level 3 - recommendation: | - Include the project's released software assets license in the released - source code, or in a LICENSE file, COPYING file, or LICENSE/ directory - alongside the corresponding release assets to provide visibility and - clarity on the licensing terms. The filename MAY have an extension. - If the project has multiple repositories, ensure that each repository - includes the license file. + - id: OSPS-LE-03 + title: | + All licenses for the project's source code MUST be maintained in a + standard location within the corresponding repository. + objective: | + Ensure that the project's source code and released software assets are + distributed with the appropriate license terms, making it clear to users + and contributors how each can be used and shared. + guideline-mappings: + - reference-id: BPB + entries: + - reference-id: B-B-8 + - reference-id: CRA + entries: + - reference-id: 1.2b + - reference-id: SSDF + entries: + - reference-id: PO.3.2 + - reference-id: Scorecard + entries: + - reference-id: License + - reference-id: PSSCRM + entries: + - reference-id: G1.2 + - reference-id: PCIDSS + entries: + - reference-id: 3.2.1 + - reference-id: 800-161 + entries: + - reference-id: PL-4 + assessment-requirements: + - id: OSPS-LE-03.01 + text: | + While active, the license for the source code MUST be maintained in + the corresponding repository's LICENSE file, COPYING file, or + LICENSE/ directory. + applicability: + - maturity-1 + - maturity-2 + - maturity-3 + recommendation: | + Include the project's source code license in the project's LICENSE + file, COPYING file, or LICENSE/ directory to provide visibility and + clarity on the licensing terms. The filename MAY have an extension. + If the project has multiple repositories, ensure that each repository + includes the license file. + - id: OSPS-LE-03.02 + text: | + While active, the license for the released software assets MUST be + included in the released source code, or in a LICENSE file, COPYING + file, or LICENSE/ directory alongside the corresponding release + assets. + applicability: + - maturity-1 + - maturity-2 + - maturity-3 + recommendation: | + Include the project's released software assets license in the released + source code, or in a LICENSE file, COPYING file, or LICENSE/ directory + alongside the corresponding release assets to provide visibility and + clarity on the licensing terms. The filename MAY have an extension. + If the project has multiple repositories, ensure that each repository + includes the license file. diff --git a/baseline/OSPS-QA.yaml b/baseline/OSPS-QA.yaml index 14ca982f..673ba904 100644 --- a/baseline/OSPS-QA.yaml +++ b/baseline/OSPS-QA.yaml @@ -1,547 +1,549 @@ -title: Quality -description: | - Quality focuses on the processes and - practices used to ensure the quality and - reliability of the project's source code and - software assets. These controls help ensure - that the project's source code is well - maintained, secure, and reliable, reducing the - risk of defects or vulnerabilities in the - software. -controls: - - id: OSPS-QA-01 - title: | - The project's source code and change history MUST be publicly readable at - a static URL. - objective: | - Enable users to access and review the project's source code and history, - promoting transparency and collaboration within the project community. - guideline-mappings: - - reference-id: BPB - identifiers: - - CC-B-1 - - CC-B-2 - - CC-B-3 - - R-B-5 - - reference-id: CRA - identifiers: - - 1.2b - - 1.2f - - 1.2j - - reference-id: SSDF - identifiers: - - PS.1 - - PS.2 - - PS.3 - - PW.1.2 - - PW.2.1 - - reference-id: OpenCRE - identifiers: - - 486-813 - - 124-564 - - 757-271 - - reference-id: CSF - identifiers: - - ID.AM-02 - - ID.RA-01 - - ID.RA-08 - - reference-id: ISO-18974 - identifiers: - - 4.1.4 - - reference-id: SLSA - identifiers: - - Build platform - isolation strength - Isolated - - reference-id: PSSCRM - identifiers: - - P3.5 - - E2.2 - - reference-id: SAMM - identifiers: - - Implementation -Secure Build -Build Process Lvl1 - - reference-id: PCIDSS - identifiers: - - 2.1.1 - - 6.2.1 - - 6.5.1 - - 6.5.2 - - reference-id: 800-161 - identifiers: - - RA-5 - - SA-11 - - SA-15 - assessment-requirements: - - id: OSPS-QA-01.01 - text: | - While active, the project's source code repository MUST be publicly - readable at a static URL. - applicability: - - Maturity Level 1 - - Maturity Level 2 - - Maturity Level 3 - recommendation: | - Use a common VCS such as GitHub, GitLab, or Bitbucket. Ensure the - repository is publicly readable. Avoid duplication or mirroring of - repositories unless highly visible documentation clarifies the primary - source. Avoid frequent changes to the repository that would impact the - repository URL. Ensure the repository is public. - - id: OSPS-QA-01.02 - text: | - The version control system MUST contain a publicly readable record of - all changes made, who made the changes, and when the changes were - made. - applicability: - - Maturity Level 1 - - Maturity Level 2 - - Maturity Level 3 - recommendation: | - Use a common VCS such as GitHub, GitLab, or Bitbucket to maintain a - publicly readable commit history. Avoid squashing or rewriting commits - in a way that would obscure the author of any commits. +control-families: + - id: QA + title: Quality + description: | + Quality focuses on the processes and + practices used to ensure the quality and + reliability of the project's source code and + software assets. These controls help ensure + that the project's source code is well + maintained, secure, and reliable, reducing the + risk of defects or vulnerabilities in the + software. + controls: + - id: OSPS-QA-01 + title: | + The project's source code and change history MUST be publicly readable at + a static URL. + objective: | + Enable users to access and review the project's source code and history, + promoting transparency and collaboration within the project community. + guideline-mappings: + - reference-id: BPB + entries: + - reference-id: CC-B-1 + - reference-id: CC-B-2 + - reference-id: CC-B-3 + - reference-id: R-B-5 + - reference-id: CRA + entries: + - reference-id: 1.2b + - reference-id: 1.2f + - reference-id: 1.2j + - reference-id: SSDF + entries: + - reference-id: PS.1 + - reference-id: PS.2 + - reference-id: PS.3 + - reference-id: PW.1.2 + - reference-id: PW.2.1 + - reference-id: OpenCRE + entries: + - reference-id: 486-813 + - reference-id: 124-564 + - reference-id: 757-271 + - reference-id: CSF + entries: + - reference-id: ID.AM-02 + - reference-id: ID.RA-01 + - reference-id: ID.RA-08 + - reference-id: ISO-18974 + entries: + - reference-id: 4.1.4 + - reference-id: SLSA + entries: + - reference-id: Build platform - isolation strength - Isolated + - reference-id: PSSCRM + entries: + - reference-id: P3.5 + - reference-id: E2.2 + - reference-id: SAMM + entries: + - reference-id: Implementation -Secure Build -Build Process Lvl1 + - reference-id: PCIDSS + entries: + - reference-id: 2.1.1 + - reference-id: 6.2.1 + - reference-id: 6.5.1 + - reference-id: 6.5.2 + - reference-id: 800-161 + entries: + - reference-id: RA-5 + - reference-id: SA-11 + - reference-id: SA-15 + assessment-requirements: + - id: OSPS-QA-01.01 + text: | + While active, the project's source code repository MUST be publicly + readable at a static URL. + applicability: + - maturity-1 + - maturity-2 + - maturity-3 + recommendation: | + Use a common VCS such as GitHub, GitLab, or Bitbucket. Ensure the + repository is publicly readable. Avoid duplication or mirroring of + repositories unless highly visible documentation clarifies the primary + source. Avoid frequent changes to the repository that would impact the + repository URL. Ensure the repository is public. + - id: OSPS-QA-01.02 + text: | + The version control system MUST contain a publicly readable record of + all changes made, who made the changes, and when the changes were + made. + applicability: + - maturity-1 + - maturity-2 + - maturity-3 + recommendation: | + Use a common VCS such as GitHub, GitLab, or Bitbucket to maintain a + publicly readable commit history. Avoid squashing or rewriting commits + in a way that would obscure the author of any commits. - - id: OSPS-QA-02 - title: | - The project MUST provide a list of dependencies used in the software. - objective: | - Provide transparency and accountability for the project's dependencies - while enabling users and contributors to understand the software's direct - dependencies. - guideline-mappings: - - reference-id: BPB - identifiers: - - Q-S-8 - - Q-S-9 - - reference-id: CRA - identifiers: - - 2.1 - - 2.2 - - 2.3 - - reference-id: SSDF - identifiers: - - PO.3.3 - - PS.1 - - PS.2 - - PS.3.2 - - PW.4 - - reference-id: CSF - identifiers: - - ID.AM.01 - - ID.AM-02 - - reference-id: ISO-18974 - identifiers: - - 4.1.5 - - 4.3.1 - - reference-id: OpenCRE - identifiers: - - 486-813 - - 124-564 - - 673-475 - - 863-521 - - 613-286 - - reference-id: PSSCRM - identifiers: - - G1.4 - - G1.5 - - G2.5 - - P3.1 - - P3.2 - - P5.1 - - P5.2 - - E2.1 - - E2.2 - - reference-id: SAMM - identifiers: - - Implementation -Secure Build -Software Dependencies Lvl1 - - reference-id: PCIDSS - identifiers: - - 6.3.2 - - 6.4.3 - - 12.5.1 - - reference-id: UKSSCOP - identifiers: - - 1.2 - - reference-id: 800-161 - identifiers: - - CA-7 - - CM-2 - - CM-8 - - PL-8 - - RA-3(1) - - RA-5 - - SA-11 - - SA-15 - - SR-3 - - SR-4 - assessment-requirements: - - id: OSPS-QA-02.01 - text: | - When the package management system supports it, the source code - repository MUST contain a dependency list that accounts for the direct - language dependencies. - applicability: - - Maturity Level 1 - - Maturity Level 2 - - Maturity Level 3 - recommendation: | - This may take the form of a package manager or language dependency file - that enumerates all direct dependencies such as package.json, Gemfile, - or go.mod. - - id: OSPS-QA-02.02 - text: | - When the project has made a release, all compiled released software - assets MUST be delivered with a software bill of materials. - applicability: - - Maturity Level 3 - recommendation: | - It is recommended to auto-generate SBOMs at build time using a tool - that has been vetted for accuracy. This enables users to ingest this - data in a standardized approach alongside other projects in their - environment. + - id: OSPS-QA-02 + title: | + The project MUST provide a list of dependencies used in the software. + objective: | + Provide transparency and accountability for the project's dependencies + while enabling users and contributors to understand the software's direct + dependencies. + guideline-mappings: + - reference-id: BPB + entries: + - reference-id: Q-S-8 + - reference-id: Q-S-9 + - reference-id: CRA + entries: + - reference-id: 2.1 + - reference-id: 2.2 + - reference-id: 2.3 + - reference-id: SSDF + entries: + - reference-id: PO.3.3 + - reference-id: PS.1 + - reference-id: PS.2 + - reference-id: PS.3.2 + - reference-id: PW.4 + - reference-id: CSF + entries: + - reference-id: ID.AM.01 + - reference-id: ID.AM-02 + - reference-id: ISO-18974 + entries: + - reference-id: 4.1.5 + - reference-id: 4.3.1 + - reference-id: OpenCRE + entries: + - reference-id: 486-813 + - reference-id: 124-564 + - reference-id: 673-475 + - reference-id: 863-521 + - reference-id: 613-286 + - reference-id: PSSCRM + entries: + - reference-id: G1.4 + - reference-id: G1.5 + - reference-id: G2.5 + - reference-id: P3.1 + - reference-id: P3.2 + - reference-id: P5.1 + - reference-id: P5.2 + - reference-id: E2.1 + - reference-id: E2.2 + - reference-id: SAMM + entries: + - reference-id: Implementation -Secure Build -Software Dependencies Lvl1 + - reference-id: PCIDSS + entries: + - reference-id: 6.3.2 + - reference-id: 6.4.3 + - reference-id: 12.5.1 + - reference-id: UKSSCOP + entries: + - reference-id: 1.2 + - reference-id: 800-161 + entries: + - reference-id: CA-7 + - reference-id: CM-2 + - reference-id: CM-8 + - reference-id: PL-8 + - reference-id: RA-3(1) + - reference-id: RA-5 + - reference-id: SA-11 + - reference-id: SA-15 + - reference-id: SR-3 + - reference-id: SR-4 + assessment-requirements: + - id: OSPS-QA-02.01 + text: | + When the package management system supports it, the source code + repository MUST contain a dependency list that accounts for the direct + language dependencies. + applicability: + - maturity-1 + - maturity-2 + - maturity-3 + recommendation: | + This may take the form of a package manager or language dependency file + that enumerates all direct dependencies such as package.json, Gemfile, + or go.mod. + - id: OSPS-QA-02.02 + text: | + When the project has made a release, all compiled released software + assets MUST be delivered with a software bill of materials. + applicability: + - maturity-3 + recommendation: | + It is recommended to auto-generate SBOMs at build time using a tool + that has been vetted for accuracy. This enables users to ingest this + data in a standardized approach alongside other projects in their + environment. - - id: OSPS-QA-03 - title: | - Any automated status checks for commits MUST pass or require manual - acknowledgement prior to merge. - objective: | - Ensure that the project's approvers do not become accustomed to tolerating - failing status checks, even if arbitrary, because it increases the risk of - overlooking security vulnerabilities or defects identified by automated - checks. - guideline-mappings: - - reference-id: CRA - identifiers: - - 1.2f - - 1.2k - - reference-id: SSDF - identifiers: - - PO.4.1 - - PS.1 - - PS.2 - - RV.1.2 - - reference-id: CSF - identifiers: - - ID.IM-02 - - reference-id: ISO-18974 - identifiers: - - 4.1.5 - - reference-id: OpenCRE - identifiers: - - 263-184 - - 253-452 - - reference-id: PSSCRM - identifiers: - - G2.2 - - G5.3 - - G5.4 - - P3.5 - - P4.1 - - P4.2 - - reference-id: SAMM - identifiers: - - Implementation -Secure Build -Build Process Lvl3 - - Implementation -Secure Build -Software Dependencies Lvl3 - - Verification -Requirements Testing -Control Verification Lvl1 - - Verification -Requirements Testing -Control Verification Lvl2 - - Verification -Requirements Testing -Control Verification Lvl3 - - reference-id: PCIDSS - identifiers: - - 6.3.1 - - 6.3.2 - - 6.5.2 - - reference-id: 800-161 - identifiers: - - AU-6 - - CM-3 - - CM-6 - - PL-8 - - SA-11 - - SA-15 - - SR-3 - assessment-requirements: - - id: OSPS-QA-03.01 - text: | - When a commit is made to the primary branch, any automated status - checks for commits MUST pass or be manually bypassed. - applicability: - - Maturity Level 2 - - Maturity Level 3 - recommendation: | - Configure the project's version control system to require that all - automated status checks pass or require manual acknowledgement before a - commit can be merged into the primary branch. It is recommended that - any optional status checks are NOT configured as a pass or fail - requirement that approvers may be tempted to bypass. + - id: OSPS-QA-03 + title: | + Any automated status checks for commits MUST pass or require manual + acknowledgement prior to merge. + objective: | + Ensure that the project's approvers do not become accustomed to tolerating + failing status checks, even if arbitrary, because it increases the risk of + overlooking security vulnerabilities or defects identified by automated + checks. + guideline-mappings: + - reference-id: CRA + entries: + - reference-id: 1.2f + - reference-id: 1.2k + - reference-id: SSDF + entries: + - reference-id: PO.4.1 + - reference-id: PS.1 + - reference-id: PS.2 + - reference-id: RV.1.2 + - reference-id: CSF + entries: + - reference-id: ID.IM-02 + - reference-id: ISO-18974 + entries: + - reference-id: 4.1.5 + - reference-id: OpenCRE + entries: + - reference-id: 263-184 + - reference-id: 253-452 + - reference-id: PSSCRM + entries: + - reference-id: G2.2 + - reference-id: G5.3 + - reference-id: G5.4 + - reference-id: P3.5 + - reference-id: P4.1 + - reference-id: P4.2 + - reference-id: SAMM + entries: + - reference-id: Implementation -Secure Build -Build Process Lvl3 + - reference-id: Implementation -Secure Build -Software Dependencies Lvl3 + - reference-id: Verification -Requirements Testing -Control Verification Lvl1 + - reference-id: Verification -Requirements Testing -Control Verification Lvl2 + - reference-id: Verification -Requirements Testing -Control Verification Lvl3 + - reference-id: PCIDSS + entries: + - reference-id: 6.3.1 + - reference-id: 6.3.2 + - reference-id: 6.5.2 + - reference-id: 800-161 + entries: + - reference-id: AU-6 + - reference-id: CM-3 + - reference-id: CM-6 + - reference-id: PL-8 + - reference-id: SA-11 + - reference-id: SA-15 + - reference-id: SR-3 + assessment-requirements: + - id: OSPS-QA-03.01 + text: | + When a commit is made to the primary branch, any automated status + checks for commits MUST pass or be manually bypassed. + applicability: + - maturity-2 + - maturity-3 + recommendation: | + Configure the project's version control system to require that all + automated status checks pass or require manual acknowledgement before a + commit can be merged into the primary branch. It is recommended that + any optional status checks are NOT configured as a pass or fail + requirement that approvers may be tempted to bypass. - - id: OSPS-QA-04 - title: | - Any additional subproject code repositories produced by the project - and compiled into a release MUST enforce security requirements as - applicable to the status and intent of the respective codebase. - objective: | - Ensure that additional code repositories or subprojects produced by the - project are held to a standard that is clear and appropriate for that - codebase. - guideline-mappings: - - reference-id: CRA - identifiers: - - 1.2b - - 1.2f - - reference-id: SSDF - identifiers: - - PO.3.2 - - PO.4.1 - - PS.1 - - PS.2 - - RV.1.2 - - reference-id: OpenCRE - identifiers: - - 486-813 - - 124-564 - - reference-id: SLSA - identifiers: - - Build platform - isolation strength - Isolated - - reference-id: Scorecard - identifiers: - - Binary-Artifacts - - reference-id: PSSCRM - identifiers: - - G2.2 - - G5.4 - - reference-id: PCIDSS - identifiers: - - 6.4.2 - - reference-id: 800-161 - identifiers: - - PL-8 - - SA-15 - assessment-requirements: - - id: OSPS-QA-04.01 - text: | - While active, the project documentation MUST contain a list of any - codebases that are considered subprojects. - applicability: - - Maturity Level 1 - - Maturity Level 2 - - Maturity Level 3 - recommendation: | - Document any additional subproject code repositories produced by the - project and compiled into a release. This documentation should include - the status and intent of the respective codebase. - - id: OSPS-QA-04.02 - text: | - When the project has made a release comprising multiple source code - repositories, all subprojects MUST enforce security requirements that - are as strict or stricter than the primary codebase. - applicability: - - Maturity Level 3 - recommendation: | + - id: OSPS-QA-04 + title: | Any additional subproject code repositories produced by the project - and compiled into a release must enforce security requirements as + and compiled into a release MUST enforce security requirements as applicable to the status and intent of the respective codebase. - In addition to following the corresponding OSPS Baseline requirements, - this may include requiring a security review, ensuring that it is - free of vulnerabilities, and ensuring that it is free of known - security issues. + objective: | + Ensure that additional code repositories or subprojects produced by the + project are held to a standard that is clear and appropriate for that + codebase. + guideline-mappings: + - reference-id: CRA + entries: + - reference-id: 1.2b + - reference-id: 1.2f + - reference-id: SSDF + entries: + - reference-id: PO.3.2 + - reference-id: PO.4.1 + - reference-id: PS.1 + - reference-id: PS.2 + - reference-id: RV.1.2 + - reference-id: OpenCRE + entries: + - reference-id: 486-813 + - reference-id: 124-564 + - reference-id: SLSA + entries: + - reference-id: Build platform - isolation strength - Isolated + - reference-id: Scorecard + entries: + - reference-id: Binary-Artifacts + - reference-id: PSSCRM + entries: + - reference-id: G2.2 + - reference-id: G5.4 + - reference-id: PCIDSS + entries: + - reference-id: 6.4.2 + - reference-id: 800-161 + entries: + - reference-id: PL-8 + - reference-id: SA-15 + assessment-requirements: + - id: OSPS-QA-04.01 + text: | + While active, the project documentation MUST contain a list of any + codebases that are considered subprojects. + applicability: + - maturity-1 + - maturity-2 + - maturity-3 + recommendation: | + Document any additional subproject code repositories produced by the + project and compiled into a release. This documentation should include + the status and intent of the respective codebase. + - id: OSPS-QA-04.02 + text: | + When the project has made a release comprising multiple source code + repositories, all subprojects MUST enforce security requirements that + are as strict or stricter than the primary codebase. + applicability: + - maturity-3 + recommendation: | + Any additional subproject code repositories produced by the project + and compiled into a release must enforce security requirements as + applicable to the status and intent of the respective codebase. + In addition to following the corresponding OSPS Baseline requirements, + this may include requiring a security review, ensuring that it is + free of vulnerabilities, and ensuring that it is free of known + security issues. - - id: OSPS-QA-05 - title: | - The version control system MUST NOT contain generated executable - artifacts. - objective: | - Reduce the risk of including generated executable artifacts in the - project's version control system, ensuring that only source code and - necessary files are stored in the repository. - guideline-mappings: - - reference-id: CRA - identifiers: - - 1.2b - - reference-id: SSDF - identifiers: - - PS.1 - - PS.2 - - reference-id: OpenCRE - identifiers: - - 486-813 - - 124-564 - - reference-id: PCIDSS - identifiers: - - 6.4.3 - - reference-id: 800-161 - identifiers: - - PL-8 - - SA-15 - - SR-3 - assessment-requirements: - - id: OSPS-QA-05.01 - text: | - While active, the version control system MUST NOT contain generated - executable artifacts. - applicability: - - Maturity Level 1 - - Maturity Level 2 - - Maturity Level 3 - recommendation: | - Remove generated executable artifacts in the project's version control - system. It is recommended that any scenario where a generated - executable artifact appears critical to a process such as testing, it - should be instead be generated at build time or stored separately and - fetched during a specific well-documented pipeline step. - - id: OSPS-QA-05.02 - text: | - While active, the version control system MUST NOT contain unreviewable - binary artifacts. - applicability: - - Maturity Level 1 - - Maturity Level 2 - - Maturity Level 3 - recommendation: | - Do not add any unreviewable binary artifacts to the project's version - control system. This includes executable application binaries, library - files, and similar artifacts. It does not include assets such as - graphical images, sound or music files, and similar content typically - stored in a binary format. + - id: OSPS-QA-05 + title: | + The version control system MUST NOT contain generated executable + artifacts. + objective: | + Reduce the risk of including generated executable artifacts in the + project's version control system, ensuring that only source code and + necessary files are stored in the repository. + guideline-mappings: + - reference-id: CRA + entries: + - reference-id: 1.2b + - reference-id: SSDF + entries: + - reference-id: PS.1 + - reference-id: PS.2 + - reference-id: OpenCRE + entries: + - reference-id: 486-813 + - reference-id: 124-564 + - reference-id: PCIDSS + entries: + - reference-id: 6.4.3 + - reference-id: 800-161 + entries: + - reference-id: PL-8 + - reference-id: SA-15 + - reference-id: SR-3 + assessment-requirements: + - id: OSPS-QA-05.01 + text: | + While active, the version control system MUST NOT contain generated + executable artifacts. + applicability: + - maturity-1 + - maturity-2 + - maturity-3 + recommendation: | + Remove generated executable artifacts in the project's version control + system. It is recommended that any scenario where a generated + executable artifact appears critical to a process such as testing, it + should be instead be generated at build time or stored separately and + fetched during a specific well-documented pipeline step. + - id: OSPS-QA-05.02 + text: | + While active, the version control system MUST NOT contain unreviewable + binary artifacts. + applicability: + - maturity-1 + - maturity-2 + - maturity-3 + recommendation: | + Do not add any unreviewable binary artifacts to the project's version + control system. This includes executable application binaries, library + files, and similar artifacts. It does not include assets such as + graphical images, sound or music files, and similar content typically + stored in a binary format. - - id: OSPS-QA-06 - title: | - The project MUST use at least one automated test suite for the source - code repository. - objective: | - Ensure that the project uses at least one automated test suite for the - source code repository and clearly documents when and how tests are run. - guideline-mappings: - - reference-id: BPB - identifiers: - - Q-B-4 - - Q-B-8 - - Q-B-9 - - Q-B-10 - - Q-S-2 - - reference-id: CRA - identifiers: - - 2.3 - - reference-id: SSDF - identifiers: - - PW.8.2 - - reference-id: CSF - identifiers: - - ID.AM-02 - - reference-id: ISO-18974 - identifiers: - - 4.1.5 - - reference-id: OpenCRE - identifiers: - - 207-435 - - 088-377 - - reference-id: Scorecard - identifiers: - - CI-Tests - - reference-id: PSSCRM - identifiers: - - P4.1 - - P4.2 - - P4.3 - - P4.4 - - E2.4 - - E2.5 - - reference-id: SAMM - identifiers: - - Verification-Requirements -Testing -Control Verification Lvl1 - - Verification-Requirements -Testing -Control Verification Lvl2 - - Verification-Requirements -Testing -Control Verification Lvl3 - - Verification -Security Testing -Scalable Baseline Lvl3 - - reference-id: PCIDSS - identifiers: - - 6.2.3 - - 6.3.1 - - 6.3.2 - - 6.4.2 - - reference-id: 800-161 - identifiers: - - SA-11 - - SA-15 - - SR-3 - assessment-requirements: - - id: OSPS-QA-06.01 - text: | - Prior to a commit being accepted, the project's CI/CD pipelines MUST - run at least one automated test suite to ensure the changes meet - expectations. - applicability: - - Maturity Level 2 - - Maturity Level 3 - recommendation: | # give examples - Automated tests should be run prior to every merge into the primary - branch. The test suite should be run in a CI/CD pipeline and the - results should be visible to all contributors. The test suite should - be run in a consistent environment and should be run in a way that - allows contributors to run the tests locally. - Examples of test suites include unit tests, integration tests, and - end-to-end tests. - - id: OSPS-QA-06.02 - text: | - While active, project's documentation MUST clearly document when and - how tests are run. - applicability: - - Maturity Level 3 - recommendation: | - Add a section to the contributing documentation that explains how to - run the tests locally and how to run the tests in the CI/CD pipeline. - The documentation should explain what the tests are testing and how to - interpret the results. - - id: OSPS-QA-06.03 - text: | - While active, the project's documentation MUST include a policy that - all major changes to the software produced by the project should add - or update tests of the functionality in an automated test suite. - applicability: - - Maturity Level 3 - recommendation: | - Add a section to the contributing documentation that explains the - policy for adding or updating tests. The policy should explain what - constitutes a major change and what tests should be added or updated. + - id: OSPS-QA-06 + title: | + The project MUST use at least one automated test suite for the source + code repository. + objective: | + Ensure that the project uses at least one automated test suite for the + source code repository and clearly documents when and how tests are run. + guideline-mappings: + - reference-id: BPB + entries: + - reference-id: Q-B-4 + - reference-id: Q-B-8 + - reference-id: Q-B-9 + - reference-id: Q-B-10 + - reference-id: Q-S-2 + - reference-id: CRA + entries: + - reference-id: 2.3 + - reference-id: SSDF + entries: + - reference-id: PW.8.2 + - reference-id: CSF + entries: + - reference-id: ID.AM-02 + - reference-id: ISO-18974 + entries: + - reference-id: 4.1.5 + - reference-id: OpenCRE + entries: + - reference-id: 207-435 + - reference-id: 088-377 + - reference-id: Scorecard + entries: + - reference-id: CI-Tests + - reference-id: PSSCRM + entries: + - reference-id: P4.1 + - reference-id: P4.2 + - reference-id: P4.3 + - reference-id: P4.4 + - reference-id: E2.4 + - reference-id: E2.5 + - reference-id: SAMM + entries: + - reference-id: Verification-Requirements -Testing -Control Verification Lvl1 + - reference-id: Verification-Requirements -Testing -Control Verification Lvl2 + - reference-id: Verification-Requirements -Testing -Control Verification Lvl3 + - reference-id: Verification -Security Testing -Scalable Baseline Lvl3 + - reference-id: PCIDSS + entries: + - reference-id: 6.2.3 + - reference-id: 6.3.1 + - reference-id: 6.3.2 + - reference-id: 6.4.2 + - reference-id: 800-161 + entries: + - reference-id: SA-11 + - reference-id: SA-15 + - reference-id: SR-3 + assessment-requirements: + - id: OSPS-QA-06.01 + text: | + Prior to a commit being accepted, the project's CI/CD pipelines MUST + run at least one automated test suite to ensure the changes meet + expectations. + applicability: + - maturity-2 + - maturity-3 + recommendation: | # give examples + Automated tests should be run prior to every merge into the primary + branch. The test suite should be run in a CI/CD pipeline and the + results should be visible to all contributors. The test suite should + be run in a consistent environment and should be run in a way that + allows contributors to run the tests locally. + Examples of test suites include unit tests, integration tests, and + end-to-end tests. + - id: OSPS-QA-06.02 + text: | + While active, project's documentation MUST clearly document when and + how tests are run. + applicability: + - maturity-3 + recommendation: | + Add a section to the contributing documentation that explains how to + run the tests locally and how to run the tests in the CI/CD pipeline. + The documentation should explain what the tests are testing and how to + interpret the results. + - id: OSPS-QA-06.03 + text: | + While active, the project's documentation MUST include a policy that + all major changes to the software produced by the project should add + or update tests of the functionality in an automated test suite. + applicability: + - maturity-3 + recommendation: | + Add a section to the contributing documentation that explains the + policy for adding or updating tests. The policy should explain what + constitutes a major change and what tests should be added or updated. - - id: OSPS-QA-07 - title: | - The project's version control system MUST require at least one - non-author approval of changes to the primary branch. - objective: | - Ensure that the project's version control system requires at least one - non-author approval of changes before merging into the release or primary - branch. - guideline-mappings: - - reference-id: BPB - identifiers: - - B-G-3 - - reference-id: Scorecard - identifiers: - - Code-Review - - reference-id: PSSCRM - identifiers: - - G2.4 - - P3.3 - - P3.5 - - reference-id: PCIDSS - identifiers: - - 6.2.3.1 - - 6.4.2 - - 6.5.4 - - reference-id: 800-161 - identifiers: - - AC-5 - - AU-6 - - PL-8 - - SA-15 - - SR-3 - assessment-requirements: - - id: OSPS-QA-07.01 - text: | - When a commit is made to the primary branch, the project's version - control system MUST require at least one non-author approval of the - changes before merging. - applicability: - - Maturity Level 3 - recommendation: | - Configure the project's version control system to require at least one - non-author approval of changes before merging into the release or - primary branch. This can be achieved by requiring a pull request to be - reviewed and approved by at least one other contributor before it can - be merged. + - id: OSPS-QA-07 + title: | + The project's version control system MUST require at least one + non-author approval of changes to the primary branch. + objective: | + Ensure that the project's version control system requires at least one + non-author approval of changes before merging into the release or primary + branch. + guideline-mappings: + - reference-id: BPB + entries: + - reference-id: B-G-3 + - reference-id: Scorecard + entries: + - reference-id: Code-Review + - reference-id: PSSCRM + entries: + - reference-id: G2.4 + - reference-id: P3.3 + - reference-id: P3.5 + - reference-id: PCIDSS + entries: + - reference-id: 6.2.3.1 + - reference-id: 6.4.2 + - reference-id: 6.5.4 + - reference-id: 800-161 + entries: + - reference-id: AC-5 + - reference-id: AU-6 + - reference-id: PL-8 + - reference-id: SA-15 + - reference-id: SR-3 + assessment-requirements: + - id: OSPS-QA-07.01 + text: | + When a commit is made to the primary branch, the project's version + control system MUST require at least one non-author approval of the + changes before merging. + applicability: + - maturity-3 + recommendation: | + Configure the project's version control system to require at least one + non-author approval of changes before merging into the release or + primary branch. This can be achieved by requiring a pull request to be + reviewed and approved by at least one other contributor before it can + be merged. diff --git a/baseline/OSPS-SA.yaml b/baseline/OSPS-SA.yaml index e131b800..70f3b194 100644 --- a/baseline/OSPS-SA.yaml +++ b/baseline/OSPS-SA.yaml @@ -1,271 +1,273 @@ -title: Security Assessment -description: | - Security Assessment encourages practices that - help ensure that the project is well positioned - to identify and address security vulnerabilities - and threats in the software. -controls: - - id: OSPS-SA-01 - title: | - The project documentation MUST provide design documentation demonstrating - all actions and actors within the system. - objective: | - Provide an overview of the project's design and architecture, illustrating - the interactions and components of the system to help contributors and - security reviewers understand the internal logic of the released software - assets. - guideline-mappings: - - reference-id: BPB - identifiers: - - B-B-1 - - B-S-7 - - B-S-8 - - reference-id: CRA - identifiers: - - 1.2a - - 1.2b - - reference-id: SSDF - identifiers: - - PO.1 - - PO.2 - - PO.3.2 - - reference-id: CSF - identifiers: - - ID.AM-02 - - reference-id: OpenCRE - identifiers: - - 155-155 - - 326-704 - - 068-102 - - 036-275 - - 162-655 - - reference-id: PSSCRM - identifiers: - - G5.1 - - P1.1 - - E3.4 - - E3.7 - - reference-id: SAMM - identifiers: - - Operations -Operational Management -Data Protection Lvl2 - - reference-id: PCIDSS - identifiers: - - 2.2.1 - - 2.2.3 - - 2.2.4 - - 2.2.5 - - 2.2.6 - - 3.1.1 - - 4.1.1 - - 5.1.1 - - 6.1.1 - - 6.2.1 - - 7.1.1 - - 8.1.1 - - 11.1.1 - - 12.3.1 - - 12.5.3 - - reference-id: UKSSCOP - identifiers: - - 1.4 - - reference-id: 800-161 - identifiers: - - CM-2 - - PL-8 - - RA-3 - - SA-15 - assessment-requirements: - - id: OSPS-SA-01.01 - text: | - When the project has made a release, the project documentation MUST - include design documentation demonstrating all actions and actors - within the system. - applicability: - - Maturity Level 2 - - Maturity Level 3 - recommendation: | - Include designs in the project documentation that explains the actions - and actors. Actors include any subsystem or entity that can influence - another segment in the system. - Ensure this is updated for new features or breaking changes. +control-families: + - id: SA + title: Security Assessment + description: | + Security Assessment encourages practices that + help ensure that the project is well positioned + to identify and address security vulnerabilities + and threats in the software. + controls: + - id: OSPS-SA-01 + title: | + The project documentation MUST provide design documentation demonstrating + all actions and actors within the system. + objective: | + Provide an overview of the project's design and architecture, illustrating + the interactions and components of the system to help contributors and + security reviewers understand the internal logic of the released software + assets. + guideline-mappings: + - reference-id: BPB + entries: + - reference-id: B-B-1 + - reference-id: B-S-7 + - reference-id: B-S-8 + - reference-id: CRA + entries: + - reference-id: 1.2a + - reference-id: 1.2b + - reference-id: SSDF + entries: + - reference-id: PO.1 + - reference-id: PO.2 + - reference-id: PO.3.2 + - reference-id: CSF + entries: + - reference-id: ID.AM-02 + - reference-id: OpenCRE + entries: + - reference-id: 155-155 + - reference-id: 326-704 + - reference-id: 068-102 + - reference-id: 036-275 + - reference-id: 162-655 + - reference-id: PSSCRM + entries: + - reference-id: G5.1 + - reference-id: P1.1 + - reference-id: E3.4 + - reference-id: E3.7 + - reference-id: SAMM + entries: + - reference-id: Operations -Operational Management -Data Protection Lvl2 + - reference-id: PCIDSS + entries: + - reference-id: 2.2.1 + - reference-id: 2.2.3 + - reference-id: 2.2.4 + - reference-id: 2.2.5 + - reference-id: 2.2.6 + - reference-id: 3.1.1 + - reference-id: 4.1.1 + - reference-id: 5.1.1 + - reference-id: 6.1.1 + - reference-id: 6.2.1 + - reference-id: 7.1.1 + - reference-id: 8.1.1 + - reference-id: 11.1.1 + - reference-id: 12.3.1 + - reference-id: 12.5.3 + - reference-id: UKSSCOP + entries: + - reference-id: 1.4 + - reference-id: 800-161 + entries: + - reference-id: CM-2 + - reference-id: PL-8 + - reference-id: RA-3 + - reference-id: SA-15 + assessment-requirements: + - id: OSPS-SA-01.01 + text: | + When the project has made a release, the project documentation MUST + include design documentation demonstrating all actions and actors + within the system. + applicability: + - maturity-2 + - maturity-3 + recommendation: | + Include designs in the project documentation that explains the actions + and actors. Actors include any subsystem or entity that can influence + another segment in the system. + Ensure this is updated for new features or breaking changes. - - id: OSPS-SA-02 - title: | - The project documentation MUST include descriptions of all external - software interfaces of the released software assets. - objective: | - Provide users and developers with an understanding of how to interact with - the project's software and integrate it with other systems, enabling them - to use the software effectively. - guideline-mappings: - - reference-id: BPB - identifiers: - - B-B-10 - - B-S-7 - - reference-id: CRA - identifiers: - - 1.2a - - 1.2b - - reference-id: SSDF - identifiers: - - PW.1.2 - - reference-id: CSF - identifiers: - - GV.OC-05 - - ID.AM-01 - - reference-id: ISO-18974 - identifiers: - - 4.1.4 - - reference-id: OpenCRE - identifiers: - - 155-155 - - 068-102 - - 072-713 - - 820-878 - - reference-id: PSSCRM - identifiers: - - E3.4 - - E3.7 - - reference-id: PCIDSS - identifiers: - - 2.2.1 - - 2.2.3 - - 2.2.4 - - 2.2.5 - - 2.2.6 - - 6.2.1 - - 12.3.1 - - 12.8.1 - - reference-id: 800-161 - identifiers: - - CM-2 - - PL-2 - - PL-8 - - RA-3 - - SA-15 - assessment-requirements: - - id: OSPS-SA-02.01 - text: | - When the project has made a release, the project documentation MUST - include descriptions of all external software interfaces of the - released software assets. - applicability: - - Maturity Level 2 - - Maturity Level 3 - recommendation: | - Document all software interfaces (APIs) of the released software - assets, explaining how users can interact with the software and what - data is expected or produced. - Ensure this is updated for new features or breaking changes. + - id: OSPS-SA-02 + title: | + The project documentation MUST include descriptions of all external + software interfaces of the released software assets. + objective: | + Provide users and developers with an understanding of how to interact with + the project's software and integrate it with other systems, enabling them + to use the software effectively. + guideline-mappings: + - reference-id: BPB + entries: + - reference-id: B-B-10 + - reference-id: B-S-7 + - reference-id: CRA + entries: + - reference-id: 1.2a + - reference-id: 1.2b + - reference-id: SSDF + entries: + - reference-id: PW.1.2 + - reference-id: CSF + entries: + - reference-id: GV.OC-05 + - reference-id: ID.AM-01 + - reference-id: ISO-18974 + entries: + - reference-id: 4.1.4 + - reference-id: OpenCRE + entries: + - reference-id: 155-155 + - reference-id: 068-102 + - reference-id: 072-713 + - reference-id: 820-878 + - reference-id: PSSCRM + entries: + - reference-id: E3.4 + - reference-id: E3.7 + - reference-id: PCIDSS + entries: + - reference-id: 2.2.1 + - reference-id: 2.2.3 + - reference-id: 2.2.4 + - reference-id: 2.2.5 + - reference-id: 2.2.6 + - reference-id: 6.2.1 + - reference-id: 12.3.1 + - reference-id: 12.8.1 + - reference-id: 800-161 + entries: + - reference-id: CM-2 + - reference-id: PL-2 + - reference-id: PL-8 + - reference-id: RA-3 + - reference-id: SA-15 + assessment-requirements: + - id: OSPS-SA-02.01 + text: | + When the project has made a release, the project documentation MUST + include descriptions of all external software interfaces of the + released software assets. + applicability: + - maturity-2 + - maturity-3 + recommendation: | + Document all software interfaces (APIs) of the released software + assets, explaining how users can interact with the software and what + data is expected or produced. + Ensure this is updated for new features or breaking changes. - - id: OSPS-SA-03 - title: | - The project MUST assess the security posture of all software assets. - objective: | - Provide project maintainers an understanding of how the software can be - misused or broken allows them to plan mitigations to close off the potential - of those threats from occurring. - guideline-mappings: - - reference-id: BPB - identifiers: - - B-S-8 - - S-G-1 - - reference-id: CRA - identifiers: - - 1.1 - - 1.2j - - 1.2k - - 2.2 - - reference-id: SSDF - identifiers: - - PO.5.1 - - PW.1.1 - - reference-id: CSF - identifiers: - - ID.RA-01 - - ID.RA-04 - - ID.RA-05 - - DE.AE-07 - - reference-id: ISO-18974 - identifiers: - - 4.1.5 - - reference-id: OpenCRE - identifiers: - - 068-102 - - 154-031 - - 888-770 - - reference-id: PSSCRM - identifiers: - - G4.3 - - G5.2 - - P2.1 - - reference-id: SAMM - identifiers: - - Governance -Create and Promote Lvl1 - - Design -Threat Assessment -Application Risk Profile Lvl1 - - Design -Threat Assessment -Threat Modeling Lvl1 - - Verification -Architecture Assessment -Architecture Mitigation Lvl2 - - reference-id: PCIDSS - identifiers: - - 2.2.4 - - 2.2.5 - - 2.2.6 - - 6.2.1 - - 6.2.3.1 - - 6.3.2 - - 6.4.2 - - 11.3.1 - - 12.3.1 - - reference-id: UKSSCOP - identifiers: - - 1.4 - - 3.3 - - reference-id: 800-161 - identifiers: - - CA-2 - - CA-2(3) - - PM-30 - - RA-3 - - SA-11 - - SA-15 - - SA-15(3) - - SA-15(8) - - SI-3 - - SR-3 - - SR-3(3) - - SR-6 - - SR-7 - assessment-requirements: - - id: OSPS-SA-03.01 - text: | - When the project has made a release, the project MUST perform a - security assessment to understand the most likely and impactful - potential security problems that could occur within the software. - applicability: - - Maturity Level 2 - - Maturity Level 3 - recommendation: | - Performing a security assessment informs both project members as well - as downstream consumers that the project understands what problems - could arise within the software. Understanding what threats could be - realized helps the project manage and address risk. This information - is useful to downstream consumers to demonstrate the security acumen - and practices of the project. - Ensure this is updated for new features or breaking changes. - - id: OSPS-SA-03.02 - text: | - When the project has made a release, the project MUST perform a threat - modeling and attack surface analysis to understand and protect against - attacks on critical code paths, functions, and interactions within the - system. - applicability: - - Maturity Level 3 - recommendation: | - Threat modeling is an activity where the project looks at the - codebase, associated processes and infrastructure, interfaces, key - components and "thinks like a hacker" and brainstorms how the system - be be broken or compromised. Each identified threat is listed out so - the project can then think about how to proactively avoid or close off - any gaps/vulnerabilities that could arise. - Ensure this is updated for new features or breaking changes. + - id: OSPS-SA-03 + title: | + The project MUST assess the security posture of all software assets. + objective: | + Provide project maintainers an understanding of how the software can be + misused or broken allows them to plan mitigations to close off the potential + of those threats from occurring. + guideline-mappings: + - reference-id: BPB + entries: + - reference-id: B-S-8 + - reference-id: S-G-1 + - reference-id: CRA + entries: + - reference-id: 1.1 + - reference-id: 1.2j + - reference-id: 1.2k + - reference-id: 2.2 + - reference-id: SSDF + entries: + - reference-id: PO.5.1 + - reference-id: PW.1.1 + - reference-id: CSF + entries: + - reference-id: ID.RA-01 + - reference-id: ID.RA-04 + - reference-id: ID.RA-05 + - reference-id: DE.AE-07 + - reference-id: ISO-18974 + entries: + - reference-id: 4.1.5 + - reference-id: OpenCRE + entries: + - reference-id: 068-102 + - reference-id: 154-031 + - reference-id: 888-770 + - reference-id: PSSCRM + entries: + - reference-id: G4.3 + - reference-id: G5.2 + - reference-id: P2.1 + - reference-id: SAMM + entries: + - reference-id: Governance -Create and Promote Lvl1 + - reference-id: Design -Threat Assessment -Application Risk Profile Lvl1 + - reference-id: Design -Threat Assessment -Threat Modeling Lvl1 + - reference-id: Verification -Architecture Assessment -Architecture Mitigation Lvl2 + - reference-id: PCIDSS + entries: + - reference-id: 2.2.4 + - reference-id: 2.2.5 + - reference-id: 2.2.6 + - reference-id: 6.2.1 + - reference-id: 6.2.3.1 + - reference-id: 6.3.2 + - reference-id: 6.4.2 + - reference-id: 11.3.1 + - reference-id: 12.3.1 + - reference-id: UKSSCOP + entries: + - reference-id: 1.4 + - reference-id: 3.3 + - reference-id: 800-161 + entries: + - reference-id: CA-2 + - reference-id: CA-2(3) + - reference-id: PM-30 + - reference-id: RA-3 + - reference-id: SA-11 + - reference-id: SA-15 + - reference-id: SA-15(3) + - reference-id: SA-15(8) + - reference-id: SI-3 + - reference-id: SR-3 + - reference-id: SR-3(3) + - reference-id: SR-6 + - reference-id: SR-7 + assessment-requirements: + - id: OSPS-SA-03.01 + text: | + When the project has made a release, the project MUST perform a + security assessment to understand the most likely and impactful + potential security problems that could occur within the software. + applicability: + - maturity-2 + - maturity-3 + recommendation: | + Performing a security assessment informs both project members as well + as downstream consumers that the project understands what problems + could arise within the software. Understanding what threats could be + realized helps the project manage and address risk. This information + is useful to downstream consumers to demonstrate the security acumen + and practices of the project. + Ensure this is updated for new features or breaking changes. + - id: OSPS-SA-03.02 + text: | + When the project has made a release, the project MUST perform a threat + modeling and attack surface analysis to understand and protect against + attacks on critical code paths, functions, and interactions within the + system. + applicability: + - maturity-3 + recommendation: | + Threat modeling is an activity where the project looks at the + codebase, associated processes and infrastructure, interfaces, key + components and "thinks like a hacker" and brainstorms how the system + be be broken or compromised. Each identified threat is listed out so + the project can then think about how to proactively avoid or close off + any gaps/vulnerabilities that could arise. + Ensure this is updated for new features or breaking changes. diff --git a/baseline/OSPS-VM.yaml b/baseline/OSPS-VM.yaml index 1f9de896..d19d6b55 100644 --- a/baseline/OSPS-VM.yaml +++ b/baseline/OSPS-VM.yaml @@ -1,566 +1,568 @@ -title: Vulnerability Management -description: | - Vulnerability Management focuses on the - processes and practices used to identify and - address security vulnerabilities in the project's - software dependencies. These controls help ensure - that the project is well positioned to respond to - security threats and vulnerabilities in the software. -controls: - - id: OSPS-VM-01 - title: | - The project documentation MUST include a policy for coordinated - vulnerability disclosure, with a clear timeframe for response. - objective: | - Establish a process for reporting and addressing vulnerabilities in the - project, ensuring that security issues are handled promptly and - transparently. - guideline-mappings: - - reference-id: BPB - identifiers: - - R-B-6 - - R-B-8 - - R-S-2 - - S-B-14 - - S-B-15 - - reference-id: CRA - identifiers: - - 2.1 - - 2.2 - - 2.3 - - 2.6 - - 2.7 - - 2.8 - - reference-id: SSDF - identifiers: - - RV.1.3 - - reference-id: CSF - identifiers: - - GV.PO-01 - - GV.PO-02 - - ID.RA-01 - - ID.RA-08 - - reference-id: ISO-18974 - identifiers: - - 4.1.5 - - 4.2.1 - - 4.3.2 - - reference-id: OpenCRE - identifiers: - - 887-750 - - reference-id: Scorecard - identifiers: - - Security-Policy - - reference-id: PSSCRM - identifiers: - - D1.1 - - D1.2 - - D1.3 - - D1.5 - - reference-id: SAMM - identifiers: - - Governance -Create and Promote Lvl2 - - Governance -Policy & Compliance -Policy & Standards Lvl1 - - Implementation -Defect Management -Defect Tracking Lvl1 - - Implementation -Defect Management -Defect Tracking Lvl2 - - Implementation -Defect Management -Defect Tracking Lvl3 - - Operations -Incident Management -Incident Response Lvl1 - - Operations -Incident Management -Incident Response Lvl2 - - Operations -Incident Management -Incident Response Lvl3 - - reference-id: PCIDSS - identifiers: - - 2.1.1 - - 3.1.1 - - 4.1.1 - - 5.1.1 - - 6.1.1 - - 6.3.1 - - 6.3.2 - - 7.1.1 - - 8.1.1 - - 11.1.1 - - 11.2.1 - - 12.1.1 - - 12.1.3 - - reference-id: UKSSCOP - identifiers: - - 3.2 - - 3.4 - - 3.5 - - reference-id: 800-161 - identifiers: - - IR-1 - - IR-4 - - IR-6 - - IR-7(1) - - IR-8 - - SI-2 - assessment-requirements: - - id: OSPS-VM-01.01 - text: | - While active, the project documentation MUST - include a policy for coordinated vulnerability disclosure (CVD), with a clear - timeframe for response. - applicability: - - Maturity Level 2 - - Maturity Level 3 - recommendation: | - Create a SECURITY.md file at the root of the directory, outlining the - project's policy for coordinated vulnerability disclosure. Include a - method for reporting vulnerabilities. Set expectations for how the - project will respond and address reported issues. +control-families: + - id: VM + title: Vulnerability Management + description: | + Vulnerability Management focuses on the + processes and practices used to identify and + address security vulnerabilities in the project's + software dependencies. These controls help ensure + that the project is well positioned to respond to + security threats and vulnerabilities in the software. + controls: + - id: OSPS-VM-01 + title: | + The project documentation MUST include a policy for coordinated + vulnerability disclosure, with a clear timeframe for response. + objective: | + Establish a process for reporting and addressing vulnerabilities in the + project, ensuring that security issues are handled promptly and + transparently. + guideline-mappings: + - reference-id: BPB + entries: + - reference-id: R-B-6 + - reference-id: R-B-8 + - reference-id: R-S-2 + - reference-id: S-B-14 + - reference-id: S-B-15 + - reference-id: CRA + entries: + - reference-id: 2.1 + - reference-id: 2.2 + - reference-id: 2.3 + - reference-id: 2.6 + - reference-id: 2.7 + - reference-id: 2.8 + - reference-id: SSDF + entries: + - reference-id: RV.1.3 + - reference-id: CSF + entries: + - reference-id: GV.PO-01 + - reference-id: GV.PO-02 + - reference-id: ID.RA-01 + - reference-id: ID.RA-08 + - reference-id: ISO-18974 + entries: + - reference-id: 4.1.5 + - reference-id: 4.2.1 + - reference-id: 4.3.2 + - reference-id: OpenCRE + entries: + - reference-id: 887-750 + - reference-id: Scorecard + entries: + - reference-id: Security-Policy + - reference-id: PSSCRM + entries: + - reference-id: D1.1 + - reference-id: D1.2 + - reference-id: D1.3 + - reference-id: D1.5 + - reference-id: SAMM + entries: + - reference-id: Governance -Create and Promote Lvl2 + - reference-id: Governance -Policy & Compliance -Policy & Standards Lvl1 + - reference-id: Implementation -Defect Management -Defect Tracking Lvl1 + - reference-id: Implementation -Defect Management -Defect Tracking Lvl2 + - reference-id: Implementation -Defect Management -Defect Tracking Lvl3 + - reference-id: Operations -Incident Management -Incident Response Lvl1 + - reference-id: Operations -Incident Management -Incident Response Lvl2 + - reference-id: Operations -Incident Management -Incident Response Lvl3 + - reference-id: PCIDSS + entries: + - reference-id: 2.1.1 + - reference-id: 3.1.1 + - reference-id: 4.1.1 + - reference-id: 5.1.1 + - reference-id: 6.1.1 + - reference-id: 6.3.1 + - reference-id: 6.3.2 + - reference-id: 7.1.1 + - reference-id: 8.1.1 + - reference-id: 11.1.1 + - reference-id: 11.2.1 + - reference-id: 12.1.1 + - reference-id: 12.1.3 + - reference-id: UKSSCOP + entries: + - reference-id: 3.2 + - reference-id: 3.4 + - reference-id: 3.5 + - reference-id: 800-161 + entries: + - reference-id: IR-1 + - reference-id: IR-4 + - reference-id: IR-6 + - reference-id: IR-7(1) + - reference-id: IR-8 + - reference-id: SI-2 + assessment-requirements: + - id: OSPS-VM-01.01 + text: | + While active, the project documentation MUST + include a policy for coordinated vulnerability disclosure (CVD), with a clear + timeframe for response. + applicability: + - maturity-2 + - maturity-3 + recommendation: | + Create a SECURITY.md file at the root of the directory, outlining the + project's policy for coordinated vulnerability disclosure. Include a + method for reporting vulnerabilities. Set expectations for how the + project will respond and address reported issues. - - id: OSPS-VM-02 - title: | - The project MUST publish contacts and process for reporting - vulnerabilities. - objective: | - Reports from researchers and users are an important source for identifying - vulnerabilities in a project. People with vulnerabilities to report should - have a clear understanding of the process so that they can quickly submit - the report to the project. - guideline-mappings: - - reference-id: BPB - identifiers: - - B-S-8 - - reference-id: CRA - identifiers: - - 2.5 - - reference-id: SSDF - identifiers: - - RV.1.3 - - reference-id: CSF - identifiers: - - GV.PO-01 - - GV.PO-02 - - ID.RA-01 - - reference-id: ISO-18974 - identifiers: - - 4.1.1 - - 4.1.3 - - 4.1.5 - - 4.2.2 - - reference-id: OpenCRE - identifiers: - - 464-513 - - reference-id: Scorecard - identifiers: - - Security-Policy - - reference-id: SAMM - identifiers: - - Governance -Policy&Compliance -Policy&Standards Lvl2 - - reference-id: PCIDSS - identifiers: - - 6.3.3 - - 12.1.1 - - 12.10.2 - - reference-id: UKSSCOP - identifiers: - - 3.2 - - reference-id: 800-161 - identifiers: - - IR-1 - - IR-4 - - IR-6 - - IR-8 - assessment-requirements: - - id: OSPS-VM-02.01 - text: | - While active, the project documentation MUST contain - security contacts. - applicability: - - Maturity Level 1 - recommendation: | - Create a security.md (or similarly-named) file that contains security - contacts for the project. + - id: OSPS-VM-02 + title: | + The project MUST publish contacts and process for reporting + vulnerabilities. + objective: | + Reports from researchers and users are an important source for identifying + vulnerabilities in a project. People with vulnerabilities to report should + have a clear understanding of the process so that they can quickly submit + the report to the project. + guideline-mappings: + - reference-id: BPB + entries: + - reference-id: B-S-8 + - reference-id: CRA + entries: + - reference-id: 2.5 + - reference-id: SSDF + entries: + - reference-id: RV.1.3 + - reference-id: CSF + entries: + - reference-id: GV.PO-01 + - reference-id: GV.PO-02 + - reference-id: ID.RA-01 + - reference-id: ISO-18974 + entries: + - reference-id: 4.1.1 + - reference-id: 4.1.3 + - reference-id: 4.1.5 + - reference-id: 4.2.2 + - reference-id: OpenCRE + entries: + - reference-id: 464-513 + - reference-id: Scorecard + entries: + - reference-id: Security-Policy + - reference-id: SAMM + entries: + - reference-id: Governance -Policy&Compliance -Policy&Standards Lvl2 + - reference-id: PCIDSS + entries: + - reference-id: 6.3.3 + - reference-id: 12.1.1 + - reference-id: 12.10.2 + - reference-id: UKSSCOP + entries: + - reference-id: 3.2 + - reference-id: 800-161 + entries: + - reference-id: IR-1 + - reference-id: IR-4 + - reference-id: IR-6 + - reference-id: IR-8 + assessment-requirements: + - id: OSPS-VM-02.01 + text: | + While active, the project documentation MUST contain + security contacts. + applicability: + - maturity-1 + recommendation: | + Create a security.md (or similarly-named) file that contains security + contacts for the project. - - id: OSPS-VM-03 - title: | - The project MUST provide a means for reporting security - vulnerabilities privately to the security contacts within the project. - objective: | - Security vulnerabilities should not be shared with the public until such - time the project has been provided time to analyze and prepare - remediations to protect users of the project. - guideline-mappings: - - reference-id: BPB - identifiers: - - R-B-7 - - reference-id: CRA - identifiers: - - 2.5 - - 2.6 - - reference-id: OpenCRE - identifiers: - - 308-514 - - reference-id: SAMM - identifiers: - - Operations -Incident Management -Incident Response Lvl3 - - reference-id: PCIDSS - identifiers: - - 6.3.1 - - 6.3.3 - - 12.10.2 - - reference-id: UKSSCOP - identifiers: - - 3.2 - - reference-id: 800-161 - identifiers: - - IR-6 - assessment-requirements: - - id: OSPS-VM-03.01 - text: | - While active, the project documentation MUST - provide a means for private vulnerability reporting directly to - the security contacts within the project. - applicability: - - Maturity Level 2 - - Maturity Level 3 - recommendation: | - Provide a means for security researchers to report vulnerabilities - privately to the project. This may be a dedicated email address, a - web form, VCS specialized tools, email addresses for security - contacts, or other methods. + - id: OSPS-VM-03 + title: | + The project MUST provide a means for reporting security + vulnerabilities privately to the security contacts within the project. + objective: | + Security vulnerabilities should not be shared with the public until such + time the project has been provided time to analyze and prepare + remediations to protect users of the project. + guideline-mappings: + - reference-id: BPB + entries: + - reference-id: R-B-7 + - reference-id: CRA + entries: + - reference-id: 2.5 + - reference-id: 2.6 + - reference-id: OpenCRE + entries: + - reference-id: 308-514 + - reference-id: SAMM + entries: + - reference-id: Operations -Incident Management -Incident Response Lvl3 + - reference-id: PCIDSS + entries: + - reference-id: 6.3.1 + - reference-id: 6.3.3 + - reference-id: 12.10.2 + - reference-id: UKSSCOP + entries: + - reference-id: 3.2 + - reference-id: 800-161 + entries: + - reference-id: IR-6 + assessment-requirements: + - id: OSPS-VM-03.01 + text: | + While active, the project documentation MUST + provide a means for private vulnerability reporting directly to + the security contacts within the project. + applicability: + - maturity-2 + - maturity-3 + recommendation: | + Provide a means for security researchers to report vulnerabilities + privately to the project. This may be a dedicated email address, a + web form, VCS specialized tools, email addresses for security + contacts, or other methods. - - id: OSPS-VM-04 - title: | - The project MUST publicly publish data about discovered vulnerabilities. - objective: | - Consumers of the project must be informed about known vulnerabilities - found within the project. - guideline-mappings: - - reference-id: CRA - identifiers: - - 1.2a - - 1.2b - - 2.1 - - 2.4 - - 2.6 - - reference-id: SSDF - identifiers: - - PO.4.1 - - RV.2.1 - - RV.2.2 - - reference-id: CSF - identifiers: - - ID.RA-01 - - reference-id: ISO-18974 - identifiers: - - 4.1.5 - - reference-id: PSSCRM - identifiers: - - G2.2 - - D1.1 - - reference-id: PCIDSS - identifiers: - - 6.2.3 - - 6.3.1 - - 6.3.2 - - 6.3.3 - - 11.3.1 - - reference-id: UKSSCOP - identifiers: - - 3.4 - - 3.5 - - 4.3 - - reference-id: 800-161 - identifiers: - - CA-7 - - CM-3 - - CM-8 - - IR-5 - - SI-2 - - SI-4 - - SI-5 - assessment-requirements: - - id: OSPS-VM-04.01 - text: | - While active, the project documentation MUST - publicly publish data about discovered vulnerabilities. - applicability: - - Maturity Level 2 - - Maturity Level 3 - recommendation: | - Provide information about known vulnerabilities in a predictable - public channel, such as a CVE entry, blog post, or other medium. - To the degree possible, this information should include affected - version(s), how a consumer can determine if they are vulnerable, and - instructions for mitigation or remediation. - - id: OSPS-VM-04.02 - text: | - While active, any vulnerabilities in the - software components not affecting the project MUST be accounted for - in a VEX document, augmenting the vulnerability report with - non-exploitability details. - applicability: - - Maturity Level 3 - recommendation: | - Establish a VEX feed communicating the exploitability status of - known vulnerabilities, including assessment details or any - mitigations in place preventing vulnerable code from being - executed. + - id: OSPS-VM-04 + title: | + The project MUST publicly publish data about discovered vulnerabilities. + objective: | + Consumers of the project must be informed about known vulnerabilities + found within the project. + guideline-mappings: + - reference-id: CRA + entries: + - reference-id: 1.2a + - reference-id: 1.2b + - reference-id: 2.1 + - reference-id: 2.4 + - reference-id: 2.6 + - reference-id: SSDF + entries: + - reference-id: PO.4.1 + - reference-id: RV.2.1 + - reference-id: RV.2.2 + - reference-id: CSF + entries: + - reference-id: ID.RA-01 + - reference-id: ISO-18974 + entries: + - reference-id: 4.1.5 + - reference-id: PSSCRM + entries: + - reference-id: G2.2 + - reference-id: D1.1 + - reference-id: PCIDSS + entries: + - reference-id: 6.2.3 + - reference-id: 6.3.1 + - reference-id: 6.3.2 + - reference-id: 6.3.3 + - reference-id: 11.3.1 + - reference-id: UKSSCOP + entries: + - reference-id: 3.4 + - reference-id: 3.5 + - reference-id: 4.3 + - reference-id: 800-161 + entries: + - reference-id: CA-7 + - reference-id: CM-3 + - reference-id: CM-8 + - reference-id: IR-5 + - reference-id: SI-2 + - reference-id: SI-4 + - reference-id: SI-5 + assessment-requirements: + - id: OSPS-VM-04.01 + text: | + While active, the project documentation MUST + publicly publish data about discovered vulnerabilities. + applicability: + - maturity-2 + - maturity-3 + recommendation: | + Provide information about known vulnerabilities in a predictable + public channel, such as a CVE entry, blog post, or other medium. + To the degree possible, this information should include affected + version(s), how a consumer can determine if they are vulnerable, and + instructions for mitigation or remediation. + - id: OSPS-VM-04.02 + text: | + While active, any vulnerabilities in the + software components not affecting the project MUST be accounted for + in a VEX document, augmenting the vulnerability report with + non-exploitability details. + applicability: + - maturity-3 + recommendation: | + Establish a VEX feed communicating the exploitability status of + known vulnerabilities, including assessment details or any + mitigations in place preventing vulnerable code from being + executed. - - id: OSPS-VM-05 - title: | - The project MUST enforce a policy for addressing SCA findings. - objective: | - Ensure that the project clearly communicates the threshold for remediation - of SCA findings, including vulnerabilities and license issues in software - dependencies. - Ensure that violations of your SCA policy are addressed before software - is merged as well as before it releases, reducing the risk of compromised - delivery mechanisms or released software assets that are vulnerable or - malicious. - guideline-mappings: - - reference-id: BPB - identifiers: - - B-S-8 - - Q-B-12 - - Q-S-9 - - S-B-14 - - S-B-15 - - A-B-1 - - A-B-3 - - A-B-8 - - A-S-1 - - reference-id: CRA - identifiers: - - 1.2a - - 1.2b - - 1.2c - - 2.1 - - 2.2 - - 2.3 - - 2.4 - - reference-id: SSDF - identifiers: - - PO.4 - - PW.1.2 - - PW.8.1 - - RV.1.2 - - RV.1.3 - - RV.2.1 - - RV.2.2 - - reference-id: CSF - identifiers: - - GV.RM-05 - - GV.RM-06 - - GV.PO-01 - - GV.PO-02 - - ID.RA-01 - - ID.RA-08 - - ID.IM-02 - - reference-id: ISO-18974 - identifiers: - - 4.1.5 - - 4.2.1 - - 4.2.2 - - 4.3.2 - - reference-id: OpenCRE - identifiers: - - 155-155 - - 124-564 - - 757-271 - - 464-513 - - 611-158 - - 207-435 - - 088-377 - - reference-id: Scorecard - identifiers: - - Security-Policy - - Vulnerabilities - - reference-id: PSSCRM - identifiers: - - G5.4 - - P4.1 - - P4.2 - - P4.3 - - P4.4 - - P4.5 - - reference-id: SAMM - identifiers: - - Implementation -Secure Build-Build Process Lvl3 - - Implementation -Software Dependencies Lvl3 - - Verification -Security Testing -Scalable Baseline Lvl1 - - Verification -Security Testing -Scalable Baseline Lvl3 - - reference-id: PCIDSS - identifiers: - - 6.2.3 - - 6.3.1 - - 6.3.2 - - 6.4.1 - - 6.4.2 - - reference-id: UKSSCOP - identifiers: - - 1.2 - - 3.3 - - reference-id: 800-161 - identifiers: - - CA-7 - - RA-5 - - SA-11 - - SI-2 - - SI-3 - assessment-requirements: - - id: OSPS-VM-05.01 - text: | - While active, the project documentation MUST include a policy that - defines a threshold for remediation of SCA findings related to - vulnerabilities and licenses. - applicability: - - Maturity Level 3 - recommendation: | - Document a policy in the project that defines a threshold for - remediation of SCA findings related to vulnerabilities and licenses. - Include the process for identifying, prioritizing, and remediating - these findings. - - id: OSPS-VM-05.02 - text: | - While active, the project documentation MUST include a policy to - address SCA violations prior to any release. - applicability: - - Maturity Level 3 - recommendation: | - Document a policy in the project to address applicable Software - Composition Analysis results before any release, and add status checks - that verify compliance with that policy prior to release. - - id: OSPS-VM-05.03 - text: | - While active, all changes to the project's codebase MUST be - automatically evaluated against a documented policy for malicious - dependencies and known vulnerabilities in dependencies, then blocked - in the event of violations, except when declared and suppressed as - non-exploitable. - applicability: - - Maturity Level 3 - recommendation: | - Create a status check in the project's version control system that - runs a Software Composition Analysis tool on all changes - to the codebase. Require that the status check passes before changes - can be merged. + - id: OSPS-VM-05 + title: | + The project MUST enforce a policy for addressing SCA findings. + objective: | + Ensure that the project clearly communicates the threshold for remediation + of SCA findings, including vulnerabilities and license issues in software + dependencies. + Ensure that violations of your SCA policy are addressed before software + is merged as well as before it releases, reducing the risk of compromised + delivery mechanisms or released software assets that are vulnerable or + malicious. + guideline-mappings: + - reference-id: BPB + entries: + - reference-id: B-S-8 + - reference-id: Q-B-12 + - reference-id: Q-S-9 + - reference-id: S-B-14 + - reference-id: S-B-15 + - reference-id: A-B-1 + - reference-id: A-B-3 + - reference-id: A-B-8 + - reference-id: A-S-1 + - reference-id: CRA + entries: + - reference-id: 1.2a + - reference-id: 1.2b + - reference-id: 1.2c + - reference-id: 2.1 + - reference-id: 2.2 + - reference-id: 2.3 + - reference-id: 2.4 + - reference-id: SSDF + entries: + - reference-id: PO.4 + - reference-id: PW.1.2 + - reference-id: PW.8.1 + - reference-id: RV.1.2 + - reference-id: RV.1.3 + - reference-id: RV.2.1 + - reference-id: RV.2.2 + - reference-id: CSF + entries: + - reference-id: GV.RM-05 + - reference-id: GV.RM-06 + - reference-id: GV.PO-01 + - reference-id: GV.PO-02 + - reference-id: ID.RA-01 + - reference-id: ID.RA-08 + - reference-id: ID.IM-02 + - reference-id: ISO-18974 + entries: + - reference-id: 4.1.5 + - reference-id: 4.2.1 + - reference-id: 4.2.2 + - reference-id: 4.3.2 + - reference-id: OpenCRE + entries: + - reference-id: 155-155 + - reference-id: 124-564 + - reference-id: 757-271 + - reference-id: 464-513 + - reference-id: 611-158 + - reference-id: 207-435 + - reference-id: 088-377 + - reference-id: Scorecard + entries: + - reference-id: Security-Policy + - reference-id: Vulnerabilities + - reference-id: PSSCRM + entries: + - reference-id: G5.4 + - reference-id: P4.1 + - reference-id: P4.2 + - reference-id: P4.3 + - reference-id: P4.4 + - reference-id: P4.5 + - reference-id: SAMM + entries: + - reference-id: Implementation -Secure Build-Build Process Lvl3 + - reference-id: Implementation -Software Dependencies Lvl3 + - reference-id: Verification -Security Testing -Scalable Baseline Lvl1 + - reference-id: Verification -Security Testing -Scalable Baseline Lvl3 + - reference-id: PCIDSS + entries: + - reference-id: 6.2.3 + - reference-id: 6.3.1 + - reference-id: 6.3.2 + - reference-id: 6.4.1 + - reference-id: 6.4.2 + - reference-id: UKSSCOP + entries: + - reference-id: 1.2 + - reference-id: 3.3 + - reference-id: 800-161 + entries: + - reference-id: CA-7 + - reference-id: RA-5 + - reference-id: SA-11 + - reference-id: SI-2 + - reference-id: SI-3 + assessment-requirements: + - id: OSPS-VM-05.01 + text: | + While active, the project documentation MUST include a policy that + defines a threshold for remediation of SCA findings related to + vulnerabilities and licenses. + applicability: + - maturity-3 + recommendation: | + Document a policy in the project that defines a threshold for + remediation of SCA findings related to vulnerabilities and licenses. + Include the process for identifying, prioritizing, and remediating + these findings. + - id: OSPS-VM-05.02 + text: | + While active, the project documentation MUST include a policy to + address SCA violations prior to any release. + applicability: + - maturity-3 + recommendation: | + Document a policy in the project to address applicable Software + Composition Analysis results before any release, and add status checks + that verify compliance with that policy prior to release. + - id: OSPS-VM-05.03 + text: | + While active, all changes to the project's codebase MUST be + automatically evaluated against a documented policy for malicious + dependencies and known vulnerabilities in dependencies, then blocked + in the event of violations, except when declared and suppressed as + non-exploitable. + applicability: + - maturity-3 + recommendation: | + Create a status check in the project's version control system that + runs a Software Composition Analysis tool on all changes + to the codebase. Require that the status check passes before changes + can be merged. - - id: OSPS-VM-06 - title: | - The project documentation MUST enforce a policy that defines a - threshold for remediation of SAST findings. - objective: | - Identify and address defects and security weaknesses in the project's - codebase early in the development process, reducing the risk of shipping - insecure software. - guideline-mappings: - - reference-id: BPB - identifiers: - - B-S-8 - - Q-B-12 - - Q-S-9 - - S-B-14 - - S-B-15 - - A-B-1 - - A-B-3 - - A-B-8 - - A-S-1 - - reference-id: CRA - identifiers: - - 1.2a - - 1.2b - - 1.2c - - 2.1 - - 2.2 - - 2.3 - - 2.4 - - reference-id: SSDF - identifiers: - - PO.4 - - PW.1.2 - - PW.8.1 - - RV.1.2 - - RV.1.3 - - RV.2.1 - - RV 2.2 - - reference-id: CSF - identifiers: - - GV.RM-05 - - GV.RM-06 - - GV.PO-01 - - GV.PO-02 - - ID.RA-01 - - ID.RA-08 - - ID.IM-02 - - reference-id: ISO-18974 - identifiers: - - 4.1.5 - - 4.2.1 - - 4.2.2 - - 4.3.2 - - reference-id: OpenCRE - identifiers: - - 155-155 - - 124-564 - - 757-271 - - 464-513 - - 611-158 - - 207-435 - - 088-377 - - reference-id: Scorecard - identifiers: - - Security-Policy - - Vulnerabilities - - SAST - - reference-id: PSSCRM - identifiers: - - G5.4 - - P4.1 - - P4.2 - - P4.3 - - P4.4 - - P4.5 - - reference-id: SAMM - identifiers: - - Implementation -Secure Build-Build Process Lvl3 - - Implementation -Software Dependencies Lvl3 - - Verification -Security Testing -Scalable Baseline Lvl1 - - Verification -Security Testing -Scalable Baseline Lvl3 - - reference-id: PCIDSS - identifiers: - - 6.2.3 - - 6.3.1 - - 6.3.2 - - 6.4.1 - - 6.4.2 - - 6.5.2 - - reference-id: UKSSCOP - identifiers: - - 1.3 - - 1.4 - - reference-id: 800-161 - identifiers: - - CA-7 - - RA-5 - - SA-11 - - SI-2 - - SI-3 - assessment-requirements: - - id: OSPS-VM-06.01 - text: | - While active, the project documentation MUST include a policy that - defines a threshold for remediation of SAST findings. - applicability: - - Maturity Level 3 - recommendation: | - Document a policy in the project that defines a threshold for - remediation of Static Application Security Testing (SAST) findings. - Include the process for identifying, prioritizing, and remediating - these findings. - - id: OSPS-VM-06.02 - text: | - While active, all changes to the project's codebase MUST be - automatically evaluated against a documented policy for security - weaknesses and blocked in the event of violations except when declared - and suppressed as non-exploitable. - applicability: - - Maturity Level 3 - recommendation: | - Create a status check in the project's version control system that - runs a Static Application Security Testing (SAST) tool on all changes - to the codebase. Require that the status check passes before changes - can be merged. + - id: OSPS-VM-06 + title: | + The project documentation MUST enforce a policy that defines a + threshold for remediation of SAST findings. + objective: | + Identify and address defects and security weaknesses in the project's + codebase early in the development process, reducing the risk of shipping + insecure software. + guideline-mappings: + - reference-id: BPB + entries: + - reference-id: B-S-8 + - reference-id: Q-B-12 + - reference-id: Q-S-9 + - reference-id: S-B-14 + - reference-id: S-B-15 + - reference-id: A-B-1 + - reference-id: A-B-3 + - reference-id: A-B-8 + - reference-id: A-S-1 + - reference-id: CRA + entries: + - reference-id: 1.2a + - reference-id: 1.2b + - reference-id: 1.2c + - reference-id: 2.1 + - reference-id: 2.2 + - reference-id: 2.3 + - reference-id: 2.4 + - reference-id: SSDF + entries: + - reference-id: PO.4 + - reference-id: PW.1.2 + - reference-id: PW.8.1 + - reference-id: RV.1.2 + - reference-id: RV.1.3 + - reference-id: RV.2.1 + - reference-id: RV 2.2 + - reference-id: CSF + entries: + - reference-id: GV.RM-05 + - reference-id: GV.RM-06 + - reference-id: GV.PO-01 + - reference-id: GV.PO-02 + - reference-id: ID.RA-01 + - reference-id: ID.RA-08 + - reference-id: ID.IM-02 + - reference-id: ISO-18974 + entries: + - reference-id: 4.1.5 + - reference-id: 4.2.1 + - reference-id: 4.2.2 + - reference-id: 4.3.2 + - reference-id: OpenCRE + entries: + - reference-id: 155-155 + - reference-id: 124-564 + - reference-id: 757-271 + - reference-id: 464-513 + - reference-id: 611-158 + - reference-id: 207-435 + - reference-id: 088-377 + - reference-id: Scorecard + entries: + - reference-id: Security-Policy + - reference-id: Vulnerabilities + - reference-id: SAST + - reference-id: PSSCRM + entries: + - reference-id: G5.4 + - reference-id: P4.1 + - reference-id: P4.2 + - reference-id: P4.3 + - reference-id: P4.4 + - reference-id: P4.5 + - reference-id: SAMM + entries: + - reference-id: Implementation -Secure Build-Build Process Lvl3 + - reference-id: Implementation -Software Dependencies Lvl3 + - reference-id: Verification -Security Testing -Scalable Baseline Lvl1 + - reference-id: Verification -Security Testing -Scalable Baseline Lvl3 + - reference-id: PCIDSS + entries: + - reference-id: 6.2.3 + - reference-id: 6.3.1 + - reference-id: 6.3.2 + - reference-id: 6.4.1 + - reference-id: 6.4.2 + - reference-id: 6.5.2 + - reference-id: UKSSCOP + entries: + - reference-id: 1.3 + - reference-id: 1.4 + - reference-id: 800-161 + entries: + - reference-id: CA-7 + - reference-id: RA-5 + - reference-id: SA-11 + - reference-id: SI-2 + - reference-id: SI-3 + assessment-requirements: + - id: OSPS-VM-06.01 + text: | + While active, the project documentation MUST include a policy that + defines a threshold for remediation of SAST findings. + applicability: + - maturity-3 + recommendation: | + Document a policy in the project that defines a threshold for + remediation of Static Application Security Testing (SAST) findings. + Include the process for identifying, prioritizing, and remediating + these findings. + - id: OSPS-VM-06.02 + text: | + While active, all changes to the project's codebase MUST be + automatically evaluated against a documented policy for security + weaknesses and blocked in the event of violations except when declared + and suppressed as non-exploitable. + applicability: + - maturity-3 + recommendation: | + Create a status check in the project's version control system that + runs a Static Application Security Testing (SAST) tool on all changes + to the codebase. Require that the status check passes before changes + can be merged. diff --git a/baseline/frameworks.yaml b/baseline/frameworks.yaml deleted file mode 100644 index 71c93f74..00000000 --- a/baseline/frameworks.yaml +++ /dev/null @@ -1,61 +0,0 @@ -mapping-references: - - id: BPB - title: OpenSSF Best Practices Badge - version: 2024 - url: https://github.com/coreinfrastructure/best-practices-badge/blob/main/criteria/criteria.yml - description: "The Open Source Security Foundation (OpenSSF) Best Practices Badge is a way for Free/Libre and Open Source Software (FLOSS) projects to show that they follow best practices. Projects can voluntarily self-certify, at no cost, by using this web application to explain how they follow each best practice. The OpenSSF Best Practices Badge is inspired by the many badges available to projects on GitHub. Consumers of the badge can quickly assess which FLOSS projects are following best practices and, as a result, are more likely to produce higher-quality secure software." - - id: CSF - title: NIST Cybersecurity Framework - version: 2.0 - url: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf - description: "The NIST Cybersecurity Framework (CSF) 2.0 provides guidance to industry, government agencies, and other organizations to manage cybersecurity risks. It offers a taxonomy of high level cybersecurity outcomes that can be used by any organization — regardless of its size, sector, or maturity — to better understand, assess, prioritize, and communicate its cybersecurity efforts. The CSF does not prescribe how outcomes should be achieved. Rather, it links to online resources that provide additional guidance on practices and controls that could be used to achieve those outcomes." - - id: CRA - title: Cyber Resilience Act - version: 20.11.2024 - url: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#tit_1 - description: "Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act) (Text with EEA relevance)" - - id: SSDF - title: Secure Software Development Framework - version: 1.1 - url: https://csrc.nist.gov/pubs/sp/800/218/final - description: "The Secure Software Development Framework (SSDF) is a set of fundamental, sound, and secure software development practices based on established secure software development practice documents from organizations such as BSA, OWASP, and SAFECode. Few software development life cycle (SDLC) models explicitly address software security in detail, so practices like those in the SSDF need to be added to and integrated with each SDLC implementation. Following the SSDF practices should help software producers reduce the number of vulnerabilities in released software, reduce the potential impact of the exploitation of undetected or unaddressed vulnerabilities, and address the root causes of vulnerabilities to prevent recurrences. Also, because the SSDF provides a common language for describing secure software development practices, software producers and acquirers can use it to foster their communications for procurement processes and other management activities." - - id: OC - title: ISO/IEC 18974 - version: 1.0 - 2023-12 - url: https://openchainproject.org/security-assurance - description: "ISO/IEC 18974 helps organizations check open source for known security vulnerability issues like CVEs, GitHub dependency alerts or package manager alerts. ISO/IEC 18974 identifies: The key places to have security processes, How to assign roles and responsibilities, And how to ensure sustainability of the processes. ISO/IEC 18974 is lightweight, easy to read and is supported by our global community with free reference material and conformance resources." - - id: OCRE - title: Open Cybersecurity Reference Architecture - version: 2024 - url: https://github.com/OWASP/OpenCRE - description: "OpenCRE stands for Open Common Requirement enumeration. It is an interactive content linking platform for uniting security standards and guidelines. It offers easy and robust access to relevant information when designing, developing, testing and procuring secure software." - - id: SLSA - title: Supply Chain Levels for Software Artifacts - version: 1.0 - url: https://github.com/slsa-framework/slsa - description: "SLSA (pronounced \"salsa\") is a security framework from source to service, giving anyone working with software a common language for increasing levels of software security and supply chain integrity. It’s how you get from safe enough to being as resilient as possible, at any link in the chain." - - id: PSSCRM - title: Proactive Software Supply Chain Risk Management Framework - version: 1.0 - url: https://arxiv.org/pdf/2404.12300 - description: "The Proactive-Software Supply Chain Risk Management (P-SSCRM) Framework is designed to help you understand and plan a secure software supply chain risk management initiative. P-SSCRM was created through a process of understanding and analyzing real-world data from nine industry-leading software supply chain risk management initiatives as well as through the analysis and unification of ten government and industry documents, frameworks, and standards. Although individual methodologies and standards differ, many initiatives and standards share common ground. P-SSCRM describes this common ground and presents a model for understanding, quantifying, and developing a secure software supply chain risk management program and determining where your organization’s existing efforts stand when contrasted with other real-world software supply chain risk management initiatives." - - id: SAMM - title: OWASP Software Assurance Maturity Model - version: 2.0 - url: https://owaspsamm.org/model/ - description: "The mission of OWASP Software Assurance Maturity Model (SAMM) is to be the prime maturity model for software assurance that provides an effective and measurable way for all types of organizations to analyze and improve their software security posture. OWASP SAMM supports the complete software lifecycle, including development and acquisition, and is technology and process agnostic. It is intentionally built to be evolutive and risk-driven in nature." - - id: PCIDSS - title: Payment Card Industry Data Security Standard - version: 4.0.1 - url: https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0_1.pdf - description: "PCI Security Standards are technical and operational requirements set by the PCI Security Standards Council (PCI SSC) to protect cardholder data. The standards apply to all entities that store, process or transmit cardholder data – with requirements for software developers and manufacturers of applications and devices used in those transactions. The Council is responsible for managing the security standards, while compliance with the PCI set of standards is enforced by the founding members of the Council: American Express, Discover Financial Services, JCB, MasterCard and Visa Inc. The PCI Data Security Standard (PCI DSS) applies to all entities that store, process, and/or transmit cardholder data. It covers technical and operational system components included in or connected to cardholder data. If you accept or process payment cards, PCI DSS applies to you." - - id: 800-161 - title: NIST Special Publication 800-161 - Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations - version: r1-upd1 - url: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-161r1-upd1.pdf - description: "This publication provides guidance to organizations on identifying, assessing, and mitigating cybersecurity risks throughout the supply chain at all levels of their organizations. The publication integrates cybersecurity supply chain risk management (C-SCRM) into risk management activities by applying a multilevel, C-SCRM-specific approach, including guidance on the development of C-SCRM strategy implementation plans, C-SCRM policies, C-SCRM plans, and risk assessments for products and services." - - id: UKSSCOP - title: United Kingdom National Cyber Security Centre Software Security Code of Practice - version: 2025-05-07 - url: https://www.ncsc.gov.uk/guidance/software-security-code-of-practice-assurance-principles-claims - description: "The Software Code of Practice has been created by DSIT and the National Cyber Security Centre (NCSC), the UK’s technical authority for cyber security, and is co-sealed by the Canadian Centre for Cyber Security (CCCS). The Code reflects the government’s ongoing focus on codifying minimum standards for technology providers to reduce cyber risk. It is aimed at professionals who are responsible for overseeing the development of ‘commodity’ software, including technical, compliance, and risk experts. For those organisations that require a higher level of assurance in the resilience of their connected products and technology, consider using the NCSC’s Cyber Resilience Testing scheme." diff --git a/baseline/metadata.yaml b/baseline/metadata.yaml index 4ec6e65c..eaabae88 100644 --- a/baseline/metadata.yaml +++ b/baseline/metadata.yaml @@ -1,173 +1,174 @@ -id: osps-baseline -title: Open Source Project Security Baseline -version: "" -description: | - The Open Source Project Security (OSPS) Baseline is a set of security criteria - that projects should meet to demonstrate a strong security posture. -last-modified: "" +metadata: + id: osps-baseline + title: Open Source Project Security Baseline + version: "" + description: | + The Open Source Project Security (OSPS) Baseline is a set of security criteria + that projects should meet to demonstrate a strong security posture. + last-modified: "" -applicability-categories: #TODO: Update all applicability levels to use these IDs in a follow-up PR - - id: maturity-1 - title: Maturity Level 1 - description: for any code or non-code project with any number of maintainers or users - - id: maturity-2 - title: Maturity Level 2 - description: for any code project that has at least 2 maintainers and a small number of consistent users - - id: maturity-3 - title: Maturity Level 3 - description: for any code project that has a large number of consistent users + applicability-categories: #TODO: Update all applicability levels to use these IDs in a follow-up PR + - id: maturity-1 + title: Maturity Level 1 + description: for any code or non-code project with any number of maintainers or users + - id: maturity-2 + title: Maturity Level 2 + description: for any code project that has at least 2 maintainers and a small number of consistent users + - id: maturity-3 + title: Maturity Level 3 + description: for any code project that has a large number of consistent users -mapping-references: - - id: BPB - title: OpenSSF Best Practices Badge - version: "" - url: https://github.com/coreinfrastructure/best-practices-badge/blob/main/criteria/criteria.yml - description: | - The Open Source Security Foundation (OpenSSF) Best Practices Badge is a way - for Free/Libre and Open Source Software (FLOSS) projects to show that they - follow best practices. Projects can voluntarily self-certify, at no cost, - by using this web application to explain how they follow each best practice. - The OpenSSF Best Practices Badge is inspired by the many badges available - to projects on GitHub. Consumers of the badge can quickly assess which - FLOSS projects are following best practices and, as a result, are more - likely to produce higher-quality secure software. - - id: CRA - title: Cyber Resilience Act (Regulation 2024/2847) - version: "20.11.2024" - url: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847 - description: | - Regulation (EU) 2024/2847 of the European Parliament and of the - Council of 23 October 2024 on horizontal cybersecurity requirements for - products with digital elements and amending Regulations (EU) No 168/2013 and - (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act) (Text with - EEA relevance) - - id: CSF - title: NIST Cybersecurity Framework - version: "2.0" - url: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf - description: | - The NIST Cybersecurity Framework (CSF) 2.0 provides guidance to industry, - government agencies, and other organizations to manage cybersecurity risks. - It offers a taxonomy of high level cybersecurity outcomes that can be used - by any organization — regardless of its size, sector, or maturity — to - better understand, assess, prioritize, and communicate its cybersecurity - efforts. The CSF does not prescribe how outcomes should be achieved. - Rather, it links to online resources that provide additional guidance on - practices and controls that could be used to achieve those outcomes. - - id: OpenCRE - title: Open Common Requirement Enumeration - version: "" - url: https://www.opencre.org/ - description: | - An interactive content linking platform for uniting security - standards and guidelines. It offers easy and robust access to relevant - information when designing, developing, testing and procuring secure software. - - id: PCIDSS - title: Payment Card Industry Data Security Standard - version: "4.0.1" - url: https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0_1.pdf - description: | - PCI Security Standards are technical and operational requirements - set by the PCI Security Standards Council (PCI SSC) to protect cardholder - data. The standards apply to all entities that store, process or transmit - cardholder data – with requirements for software developers and manufacturers - of applications and devices used in those transactions. The Council is - responsible for managing the security standards, while compliance with the - PCI set of standards is enforced by the founding members of the Council: - American Express, Discover Financial Services, JCB, MasterCard and Visa Inc. - The PCI Data Security Standard (PCI DSS) applies to all entities that store, - process, and/or transmit cardholder data. It covers technical and operational - system components included in or connected to cardholder data. If you accept - or process payment cards, PCI DSS applies to you. - - id: SAMM - title: OWASP Software Assurance Maturity Model - version: "2" - url: https://owaspsamm.org/model/ - description: | - A maturity model for software assurance that provides an effective - and measurable way for all types of organizations to analyze and improve their - software security posture. OWASP SAMM supports the complete software lifecycle, - including development and acquisition, and is technology and process agnostic. - It is intentionally built to be evolutive and risk-driven in nature. - - id: SSDF - title: NIST Secure Software Development Framework (SP 800-218) - version: "1.1" - url: https://csrc.nist.gov/pubs/sp/800/218/final - description: | - The Secure Software Development Framework (SSDF) is a set of fundamental, - sound, and secure software development practices based on established - secure software development practice documents from organizations such as - BSA, OWASP, and SAFECode. Few software development life cycle (SDLC) models - explicitly address software security in detail, so practices like those in - the SSDF need to be added to and integrated with each SDLC implementation. - Following the SSDF practices should help software producers reduce the - number of vulnerabilities in released software, reduce the potential impact - of the exploitation of undetected or unaddressed vulnerabilities, and - address the root causes of vulnerabilities to prevent recurrences. Also, - because the SSDF provides a common language for describing secure software - development practices, software producers and acquirers can use it to foster - their communications for procurement processes and other management activities. - - id: SLSA - title: Supply-chain Levels for Software Artifacts - version: "1.0" - url: https://slsa.dev/ - description: | - SLSA (pronounced \"salsa\") is a security framework from source - to service, giving anyone working with software a common language for - increasing levels of software security and supply chain integrity. It’s how - you get from safe enough to being as resilient as possible, at any link in - the chain. - - id: ISO-18974 - title: ISO/IEC 18974 - version: "1.0 - 2023-12" - url: https://openchainproject.org/security-assurance - description: | - ISO/IEC 18974 helps organizations check open source for known security - vulnerability issues like CVEs, GitHub dependency alerts or package manager - alerts. ISO/IEC 18974 identifies: The key places to have security processes, - How to assign roles and responsibilities, And how to ensure sustainability - of the processes. ISO/IEC 18974 is lightweight, easy to read and is - supported by our global community with free reference material and - conformance resources. - - id: PSSCRM - title: Proactive Software Supply Chain Risk Management Framework - version: "" - url: https://arxiv.org/pdf/2404.12300 - description: | - The Proactive-Software Supply Chain Risk Management (P-SSCRM) Framework is - designed to help you understand and plan a secure software supply chain risk - management initiative. P-SSCRM was created through a process of understanding - and analyzing real-world data from nine industry-leading software supply chain - risk management initiatives as well as through the analysis and unification - of ten government and industry documents, frameworks, and standards. Although - individual methodologies and standards differ, many initiatives and standards - share common ground. P-SSCRM describes this common ground and presents a model - for understanding, quantifying, and developing a secure software supply chain - risk management program and determining where your organization's existing - efforts stand when contrasted with other real-world software supply chain - risk management initiatives. - - id: UKSSCOP - title: UK Secure Software Compliance or Practices - version: "7 May 2025" - url: https://www.gov.uk/government/publications/software-security-code-of-practice/software-security-code-of-practice - description: | - This voluntary Software Security Code of Practice has been developed to - improve the security and resilience of software that organisations and - businesses rely on. - The Software Security Code of Practice will support software vendors and - their customers in reducing the likelihood and impact of software supply - chain attacks and other software resilience incidents. Often, these kinds - of attacks and disruptions are caused by avoidable weaknesses in software - development and maintenance practices. The impact of these kinds of incidents - can also be exacerbated by poor communication between organisations and - their software suppliers. This Code addresses those issues. - - id: Scorecard - title: OpenSSF Scorecard - version: "v5.2.1" - url: "https://scorecard.dev/" - description: | - An OpenSSF project that helps users assesses open - source projects for security risks through a series - of automated checks. It was created by OSS developers - to help improve the health of critical projects - that the community depends on. + mapping-references: + - id: BPB + title: OpenSSF Best Practices Badge + version: "" + url: https://github.com/coreinfrastructure/best-practices-badge/blob/main/criteria/criteria.yml + description: | + The Open Source Security Foundation (OpenSSF) Best Practices Badge is a way + for Free/Libre and Open Source Software (FLOSS) projects to show that they + follow best practices. Projects can voluntarily self-certify, at no cost, + by using this web application to explain how they follow each best practice. + The OpenSSF Best Practices Badge is inspired by the many badges available + to projects on GitHub. Consumers of the badge can quickly assess which + FLOSS projects are following best practices and, as a result, are more + likely to produce higher-quality secure software. + - id: CRA + title: Cyber Resilience Act (Regulation 2024/2847) + version: "20.11.2024" + url: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847 + description: | + Regulation (EU) 2024/2847 of the European Parliament and of the + Council of 23 October 2024 on horizontal cybersecurity requirements for + products with digital elements and amending Regulations (EU) No 168/2013 and + (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act) (Text with + EEA relevance) + - id: CSF + title: NIST Cybersecurity Framework + version: "2.0" + url: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf + description: | + The NIST Cybersecurity Framework (CSF) 2.0 provides guidance to industry, + government agencies, and other organizations to manage cybersecurity risks. + It offers a taxonomy of high level cybersecurity outcomes that can be used + by any organization — regardless of its size, sector, or maturity — to + better understand, assess, prioritize, and communicate its cybersecurity + efforts. The CSF does not prescribe how outcomes should be achieved. + Rather, it links to online resources that provide additional guidance on + practices and controls that could be used to achieve those outcomes. + - id: OpenCRE + title: Open Common Requirement Enumeration + version: "" + url: https://www.opencre.org/ + description: | + An interactive content linking platform for uniting security + standards and guidelines. It offers easy and robust access to relevant + information when designing, developing, testing and procuring secure software. + - id: PCIDSS + title: Payment Card Industry Data Security Standard + version: "4.0.1" + url: https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0_1.pdf + description: | + PCI Security Standards are technical and operational requirements + set by the PCI Security Standards Council (PCI SSC) to protect cardholder + data. The standards apply to all entities that store, process or transmit + cardholder data – with requirements for software developers and manufacturers + of applications and devices used in those transactions. The Council is + responsible for managing the security standards, while compliance with the + PCI set of standards is enforced by the founding members of the Council: + American Express, Discover Financial Services, JCB, MasterCard and Visa Inc. + The PCI Data Security Standard (PCI DSS) applies to all entities that store, + process, and/or transmit cardholder data. It covers technical and operational + system components included in or connected to cardholder data. If you accept + or process payment cards, PCI DSS applies to you. + - id: SAMM + title: OWASP Software Assurance Maturity Model + version: "2" + url: https://owaspsamm.org/model/ + description: | + A maturity model for software assurance that provides an effective + and measurable way for all types of organizations to analyze and improve their + software security posture. OWASP SAMM supports the complete software lifecycle, + including development and acquisition, and is technology and process agnostic. + It is intentionally built to be evolutive and risk-driven in nature. + - id: SSDF + title: NIST Secure Software Development Framework (SP 800-218) + version: "1.1" + url: https://csrc.nist.gov/pubs/sp/800/218/final + description: | + The Secure Software Development Framework (SSDF) is a set of fundamental, + sound, and secure software development practices based on established + secure software development practice documents from organizations such as + BSA, OWASP, and SAFECode. Few software development life cycle (SDLC) models + explicitly address software security in detail, so practices like those in + the SSDF need to be added to and integrated with each SDLC implementation. + Following the SSDF practices should help software producers reduce the + number of vulnerabilities in released software, reduce the potential impact + of the exploitation of undetected or unaddressed vulnerabilities, and + address the root causes of vulnerabilities to prevent recurrences. Also, + because the SSDF provides a common language for describing secure software + development practices, software producers and acquirers can use it to foster + their communications for procurement processes and other management activities. + - id: SLSA + title: Supply-chain Levels for Software Artifacts + version: "1.0" + url: https://slsa.dev/ + description: | + SLSA (pronounced \"salsa\") is a security framework from source + to service, giving anyone working with software a common language for + increasing levels of software security and supply chain integrity. It’s how + you get from safe enough to being as resilient as possible, at any link in + the chain. + - id: ISO-18974 + title: ISO/IEC 18974 + version: "1.0 - 2023-12" + url: https://openchainproject.org/security-assurance + description: | + ISO/IEC 18974 helps organizations check open source for known security + vulnerability issues like CVEs, GitHub dependency alerts or package manager + alerts. ISO/IEC 18974 identifies: The key places to have security processes, + How to assign roles and responsibilities, And how to ensure sustainability + of the processes. ISO/IEC 18974 is lightweight, easy to read and is + supported by our global community with free reference material and + conformance resources. + - id: PSSCRM + title: Proactive Software Supply Chain Risk Management Framework + version: "" + url: https://arxiv.org/pdf/2404.12300 + description: | + The Proactive-Software Supply Chain Risk Management (P-SSCRM) Framework is + designed to help you understand and plan a secure software supply chain risk + management initiative. P-SSCRM was created through a process of understanding + and analyzing real-world data from nine industry-leading software supply chain + risk management initiatives as well as through the analysis and unification + of ten government and industry documents, frameworks, and standards. Although + individual methodologies and standards differ, many initiatives and standards + share common ground. P-SSCRM describes this common ground and presents a model + for understanding, quantifying, and developing a secure software supply chain + risk management program and determining where your organization's existing + efforts stand when contrasted with other real-world software supply chain + risk management initiatives. + - id: UKSSCOP + title: UK Secure Software Compliance or Practices + version: "7 May 2025" + url: https://www.gov.uk/government/publications/software-security-code-of-practice/software-security-code-of-practice + description: | + This voluntary Software Security Code of Practice has been developed to + improve the security and resilience of software that organisations and + businesses rely on. + The Software Security Code of Practice will support software vendors and + their customers in reducing the likelihood and impact of software supply + chain attacks and other software resilience incidents. Often, these kinds + of attacks and disruptions are caused by avoidable weaknesses in software + development and maintenance practices. The impact of these kinds of incidents + can also be exacerbated by poor communication between organisations and + their software suppliers. This Code addresses those issues. + - id: Scorecard + title: OpenSSF Scorecard + version: "v5.2.1" + url: "https://scorecard.dev/" + description: | + An OpenSSF project that helps users assesses open + source projects for security risks through a series + of automated checks. It was created by OSS developers + to help improve the health of critical projects + that the community depends on.