Skip to main content

Was können Sie mit einer angereicherten SBOM tun? Eine Schnellstartanleitung für parlay

Artikel von
blog feature parlay announcement

7. Juni 2023

0 Min. Lesezeit

Wir haben gerade parlay veröffentlicht, ein neues Open-Source-Tool, das SBOMs um zusätzliche Informationen erweitern kann. Mehr dazu erfahren Sie im Ankündigungsblogbeitrag. Darin haben wir kurz erläutert, warum dies für Entscheidungen auf Grundlage von SBOM-Daten wichtig ist. Wir dachten jedoch, dass einige kurze Beispiele interessant sein könnten.

parlay kann einer SBOM viele zusätzliche Informationen hinzufügen, die wir nutzen können, um leistungsfähigere Richtlinien zu erstellen. Auch wenn die Anzahl der JSON-Zeilen kein perfekter Maßstab ist, sehen Sie in diesem Beispiel, dass die SBOM um mehr als 400 % gewachsen ist – und damit zahlreiche Anwendungsfälle ermöglicht.

$ snyk sbom --format cyclonedx1.4+json | jq | wc -l
    262
$ snyk sbom --format cyclonedx1.4+json | parlay e enrich - | jq | wc -l
    1169

Lizenzrichtlinien

Eine SBOM mit nur den Mindestelementen enthält keine Informationen zu den Lizenzen der darin aufgeführten Pakete. Verwenden wir Parlay und die Daten von Ecosyste.ms, um diese Informationen hinzuzufügen.

snyk sbom --format cyclonedx1.4+json | parlay e enrich -

Mit der umfangreicheren SBOM können wir nun leistungsfähigere Richtlinien erstellen. In diesem Beispiel verwenden wir Open Policy Agent und die leistungsstarke Programmiersprache Rego. Hier erstellen wir zwei Richtlinienlisten: eine zum Ablehnen und eine zum Warnen.

package main

name = input.metadata.component.name

licenses_to_deny = [
  "LGPL",
]

licenses_to_warn = [
  "MIT"
]

deny[msg] {
  component := input.components[_]
  expression := component.licenses[_].expression
  startswith(expression, licenses_to_deny[_])
  msg := sprintf("%s is using %s which is licensed with an %s license", [name, component.name, expression])
}

warn[msg] {
    component := input.components[_]
    expression := component.licenses[_].expression
    startswith(expression, licenses_to_warn[_])
    msg := sprintf("%s is using %s which is licensed with an %s license", [name, component.name, expression])
}

Setzen wir unsere Begeisterung für Unix-Pipes fort und verwenden Conftest, um die Richtlinie auf die angereicherte SBOM anzuwenden.

snyk sbom --format cyclonedx1.4+json | parlay e enrich - | conftest test -

Im Beispielprojekt wurden daraufhin mehrere Warnungen zu bestimmten Paketen mit den angegebenen Lizenzen ausgegeben.

WARN - - main - snykit is using diff-lcs which is licensed with an MIT license
WARN - - main - snykit is using mustermann which is licensed with an MIT license
WARN - - main - snykit is using nio4r which is licensed with an MIT license
WARN - - main - snykit is using puma-metrics which is licensed with an MIT license
WARN - - main - snykit is using rack which is licensed with an MIT license
WARN - - main - snykit is using rack-protection which is licensed with an MIT license
WARN - - main - snykit is using rack-test which is licensed with an MIT license
WARN - - main - snykit is using rake which is licensed with an MIT license
WARN - - main - snykit is using rspec which is licensed with an MIT license
WARN - - main - snykit is using rspec-core which is licensed with an MIT license
WARN - - main - snykit is using rspec-expectations which is licensed with an MIT license
WARN - - main - snykit is using rspec-mocks which is licensed with an MIT license
WARN - - main - snykit is using rspec-support which is licensed with an MIT license
WARN - - main - snykit is using sinatra which is licensed with an MIT license
WARN - - main - snykit is using tilt which is licensed with an MIT license

16 tests, 1 passed, 15 warnings, 0 failures, 0 exceptions

Richtlinien für Sicherheitslücken

Versuchen wir etwas Komplexeres. Erstellen wir eine Richtlinie, die Sicherheitslücken in direkten Abhängigkeiten mit einem CVSS-Score über einem bestimmten Grenzwert kennzeichnet. Hierfür benötigen Sie Paket-, Abhängigkeits- und Sicherheitslückendaten.

deny[msg] {
  vulnerability := input.vulnerabilities[_]
  rating := vulnerability.ratings[_]
  rating.source.name == "Snyk"
  rating.score > max_cvss_score
  component := input.components[_]
  bom_ref = vulnerability["bom-ref"]
  component["bom-ref"] == bom_ref

  root = input.metadata.component["bom-ref"]

  dependency := input.dependencies[_]
  dependency.ref == root

  direct := dependency.dependsOn[_]
  direct == bom_ref

  msg := sprintf("%s version %s has a vulnerability with a CVSS score of %s", [component.name, component.version, round(rating.score)])
}

round(n) = f {
  f := sprintf("%.2f", [n])
  contains(f, ".") # Ensure that it was a float
}

round(n) = f {
  not contains(sprintf("%.2f", [n]), ".") # Test if it wasn't a float
  f := sprintf("%v.00", [n]) # Fudge the decimals for integer values
}

Anschließend können wir eine SBOM erstellen oder eine vorhandene verwenden, sie mit den Sicherheitslückendaten von Snyk anreichern und dann unsere Richtlinie mit Conftest anwenden.

snyk sbom --format cyclonedx1.4+json | parlay s enrich - | conftest test -
FAIL - - main - puma version 4.2.1 has a vulnerability with a CVSS score of 9.10

3 tests, 2 passed, 0 warnings, 1 failure, 0 exceptions

Hier sehen wir, dass eine Sicherheitslücke gemeldet wird, die unseren Kriterien entspricht.

Denken Sie daran: Dies ist nur ein Beispiel. Mit der von Open Policy Agent verwendeten Sprache Rego lassen sich bei Bedarf komplexe Logiken beschreiben. Wenn Sie ein anderes Richtlinien-Tool bevorzugen, sollte das ebenfalls funktionieren.

Wer ist der Autor dieser Software?

Ein letztes kurzes Beispiel. Im folgenden Beispiel verwenden wir parlay, um unsere SBOM anzureichern, und anschließend jq und awk, um einige nützliche Informationen auszugeben. In diesem Fall ermitteln wir den angegebenen Autor jedes Pakets. Auch diese Information ist in einer SBOM mit nur den Mindestelementen häufig nicht enthalten.

$ snyk sbom --format cyclonedx1.4+json | parlay e enrich - | jq -r '(.components[] | [.name, .author]) | @tsv' | awk '{print $1; $1=""; print}'
nio4r
 Socketry
puma
 Puma
prometheus-client
 Prometheus
puma-metrics

rack
 Official Rack repositories
rack-test
 Official Rack repositories
rake
 The Ruby Programming Language
rspec-support
 RSpec
rspec-core
 RSpec
diff-lcs
 Austin Ziegler
rspec-expectations
 RSpec
rspec-mocks
 RSpec
rspec
 RSpec
ruby2_keywords
 The Ruby Programming Language
mustermann
 Sinatra
rack-protection
 Sinatra
tilt
 Jeremy Evans
sinatra
 Sinatra

Mit umfangreicheren SBOM-Daten können Sie noch vieles mehr anfangen, und es gibt noch zahlreiche weitere Daten, mit denen sich SBOMs sinnvoll anreichern ließen. Teilen Sie uns mit, was Sie gerne sehen würden, und berichten Sie uns gerne von Ihren Experimenten mit parlay.

Weiterlesen

feature insights context
Blog

Autonome Angriffe sind bereits Realität. Die Verteidigung muss Schritt halten.

Autonome Angreifer verkürzen das Zeitfenster für die Verteidigung. Erfahren Sie, wie kontinuierliches Erkennen, Beheben, Validieren und Verhindern Sicherheitsteams helfen kann, Schritt zu halten.

Blog

Warum KI-Coding-Agenten immer wieder fehlerhafte Zugriffskontrollen schreiben

KI-Coding-Agenten können Autorisierungslogik erzeugen, die kompiliert und die Prüfung besteht, dabei aber die Daten eines Mandanten für einen anderen offenlegt. Erfahren Sie, warum fehlerhafte Zugriffskontrollen schwer zu erkennen sind und wie Sie sie verhindern.

Blog

Evo ADS Govern Agent Behavior ist allgemein verfügbar: MCP-Nutzung unter Kontrolle bringen

Evo ADS Govern Agent Behavior ist jetzt allgemein verfügbar und startet mit MCP Governance. Entdecken, genehmigen, überwachen, protokollieren und blockieren Sie die MCP-Server-Nutzung in führenden KI-Coding-Agenten.