Software Supply Chain Security fuer Artefakte

🧭 Über diesen Report

Dieser Report dokumentiert die strukturierte, evidenzbasierte Auswahl einer IT-Lösung für Software Supply Chain Security fuer Artefakte. Er stellt 6 marktrelevante Produkte gegenüber, bewertet sie gegen 120 gewichtete Anforderungen aus 9 Kategorien und leitet daraus ein nachvollziehbares Ranking sowie eine begründete Empfehlung ab.

Vorgehensmodell

Anforderungserhebung

Standard-Anforderungskatalog ergänzt um projektspezifische Anforderungen aus dem Kunden-Kontext.

Marktanalyse

Identifikation relevanter Anbieter und Produkte inkl. kompakter Unternehmens-Eckdaten.

Gewichtung

Zweistufige Gewichtung: Kategorie-Gewicht × Anforderungs-Gewicht, je Kategorie auf 100 % normalisiert.

Strukturierte Bewertung

Jede Anforderung wird je Produkt anhand einer verankerten 1–5-Skala bewertet und begründet.

Ranking & Empfehlung

Aggregation zu gewichteten Gesamt-Scores, Kategorie-Auswertung und einer begründeten Empfehlung.

Hinweis: Produkt- und Unternehmensdaten sowie die Einzelbewertungen beruhen auf modellgestützter Einschätzung (Quelle: KI-Kontext) und sind als Entscheidungsgrundlage gedacht – sicherheitskritische Punkte sollten vor Vertragsabschluss verifiziert werden.

💰 Kosten-Transparenz · Provider: anthropic · Modelle: claude-haiku-4-5, claude-opus-4-8, claude-sonnet-4-6

Phase	Modell	Calls	Input-Tok.	Output-Tok.	Kosten (geschätzt)
audit	claude-sonnet-4-6	84	275,326	134,537	$2.8440
requirements_context	claude-sonnet-4-6	3	5,986	25,376	$0.3986
feature_extraction	claude-sonnet-4-6	6	3,030	13,847	$0.2168
feature_consolidation	claude-sonnet-4-6	1	2,587	4,404	$0.0738
vendor_discovery	claude-sonnet-4-6	1	1,494	4,436	$0.0710
recommendation	claude-opus-4-8	1	879	830	$0.0251
vendor_profile	claude-haiku-4-5	6	2,811	1,673	$0.0112
Gesamt:					$3.6406

Schätzung auf Basis der von der API gemeldeten Token-Nutzung und öffentlicher Listenpreise – keine Rechnung.

📊 Zusammenfassung

Evaluierte Produkte

120

Geprüfte Anforderungen

Kategorien

Anforderungen mit Einschränkung
(nicht produktneutral – siehe Katalog)

🏆 Empfehlung

🥇 JFrog Xray

JFrog · 3.60/5 (65.0%)

JFrog Xray wird als bevorzugte Lösung empfohlen, da es mit einer Gesamtbewertung von 3,6 (65 %) das stärkste Ergebnis erzielt und insbesondere in den entscheidungsrelevanten Kategorien Produkt-Features (4,3) und Non-Functional Requirements (4,23) klar führt. Der Vorsprung gegenüber den Alternativen ist jedoch moderat, sodass die Entscheidung primär durch das überzeugende Feature-Profil und die Integrationsstärke getragen wird. Eine Einführung sollte mit Blick auf das insgesamt mittlere Gesamtniveau (65 %) gezielt anhand der konkreten Anforderungen validiert werden.

Stärken

Höchste Bewertung bei den Produkt-Features (4,3) mit tiefgehendem rekursivem Dependency-Scanning
Native Artifactory-Integration inklusive Impact Analysis als klares Alleinstellungsmerkmal
Starke Non-Functional Requirements (4,23) für Betrieb, Performance und Skalierung
SBOM Import & Enrichment unterstützt Compliance- und Lieferketten-Transparenz
Contextual Analysis (CVE Applicability) reduziert Fehlalarme und priorisiert real ausnutzbare Schwachstellen

Zu beachten

Gesamtbewertung von nur 65 % zeigt deutliches Verbesserungspotenzial und kein durchgehend exzellentes Profil
Support & Operations (4,0) liegen leicht hinter den Top-Kategorien und sollten im Betrieb genauer geprüft werden
Stärken konzentrieren sich auf das JFrog-Ökosystem, was zu Vendor-Lock-in-Risiken führen kann

Beste Alternative: JFrog Curation – Mit 3,45 (61,1 %) die nächstbeste Option und besonders interessant, wenn der Fokus stärker auf vorgelagerter Komponenten-Kuratierung innerhalb des JFrog-Ökosystems liegt und das Budget für die umfangreichere Xray-Lösung begrenzt ist.

📈 Radar-Chart

🏅 Produktranking

🥇

JFrog Xray

JFrog

3.6

/ 5 Punkte

65.0%

🥈

JFrog Curation

JFrog

3.5

/ 5 Punkte

61.1%

🥉

Dependency-Track

OWASP / Steve Springett (Community)

3.2

/ 5 Punkte

55.3%

DefectDojo

OWASP / Community

3.0

/ 5 Punkte

49.3%

ScanCode.io

nexB / Community

2.7

/ 5 Punkte

42.8%

OSS Review Toolkit (ORT)

OSS Review Toolkit Community (Linux Foundation)

2.6

/ 5 Punkte

41.0%

📊 Kategorie-Vergleich

🗺️ Bewertungsmatrix (Heatmap)

💡 Klicke auf eine Bewertung, um die Begründung zu sehen – ohne deine Position in der Matrix zu verlieren.

ID	Anforderung	JFrog Xray JFrog	JFrog Curation JFrog	Dependency-Tra OWASP / Stev	DefectDojo OWASP / Comm	ScanCode.io nexB / Commu	OSS Review Too OSS Review T
Integration
INT-01	General Interfaces/APIs	4	4	4	4	3	3
INT-02	Interface monitoring	3	3	3	2	2	2
Non-Functional Requirements
NFR-01	Authorization	5	4	4	3	2	2
NFR-02	IDM connection	5	5	3	3	1	1
NFR-03	Single Sign-On	5	5	4	4	1	1
NFR-04	Client/Instances	5	5	3	3	3	1
NFR-05	Storage of data (Metadata)	5	5	3	4	4	3
NFR-06	Data/Object Storage Backend Flexibility	5	5	1	2	2	1
NFR-07	Data Archiving & Cleanup	4	4	2	2	1	1
NFR-08	Hosting Flexibility ⚠	5	5	4	4	4	4
NFR-09	Hardware and Component Requirements	3	4	5	5	5	4
NFR-10	Installation Mode (automatic / manual)	4	4	5	4	4	3
NFR-11	Multi-location Deployment Options ⚠	5	5	1	1	1	1
NFR-12	Application Performance	5	5	3	3	3	3
NFR-13	Scalability (manage increase No. of users)	4	4	3	3	3	3
NFR-14	Remote Performance for foreign locations	4	4	2	2	2	2
NFR-15	Deployment of Customizing --> no coding	4	4	3	3	2	2
NFR-16	Deployment of Development --> coding	4	3	3	4	4	4
NFR-17	Experience/Possibility with/of offshore devel	4	4	4	3	2	3
NFR-18	Flexibility via side-by-side or other extensi	4	3	3	3	3	4
NFR-19	Maintenance and consistency of control tables	5	4	3	3	2	3
NFR-20	Source code availability	1	1	5	5	5	5
NFR-21	Maintenance effort (upgrades & testing)	4	4	3	3	3	3
NFR-22	Backup & Recovery/Redundancy layer in case of	4	4	3	2	2	2
NFR-23	Availability (Maintenance windows, unannounce ⚠	4	4	2	2	2	3
NFR-24	Availability defined/possible SLA ⚠	4	4	2	1	1	1
Usability & User Experience
UX-01	Ease of Use	3	3	3	2	2	2
UX-02	Consistent, seamless user interface	3	3	3	3	3	2
UX-03	Explicit user guidance	3	3	2	2	2	2
UX-04	Use-case-oriented design	3	4	3	3	3	2
UX-05	Flexibility of UI	2	2	2	2	2	2
UX-06	Customizable by end-user / user groups	2	2	2	2	1	1
UX-07	Language Capabilities	2	2	1	1	1	1
UX-08	Design thinking approach	2	2	2	2	2	1
IT Compliance
COMP-01	Single Source of Truth for each data object	3	3	3	3	3	3
COMP-02	Where is the cloud server located? (country) ⚠	4	4	3	3	4	4
COMP-03	Does the cloud service provide the encryption	4	4	3	3	3	3
COMP-04	GDPR and BDSG	3	3	3	2	3	3
COMP-05	ISO certificates	4	4	2	1	2	2
COMP-06	Data export and import	4	4	5	4	4	5
Risks & Opportunities
RISK-01	Dependencies and Lock-In from Software Vendor	2	2	5	5	5	5
RISK-02	Project team setup and continuity	5	4	3	3	2	3
RISK-03	Time to Market	3	4	4	4	4	2
RISK-04	Skill of supplier	4	4	2	2	2	2
RISK-05	Size of supplier (Skalierbarkeit für Großkund	4	4	2	2	2	2
RISK-06	World wide rollout	4	4	2	2	2	2
RISK-07	Dependencies to other strategic projects	3	3	4	3	3	3
RISK-08	Development method (agile or waterfall)	5	4	5	4	4	4
Total Cost of Ownership
TCO-01	Setup/Project Costs	2	2	4	3	3	2
TCO-02	Implementation Costs	2	3	4	3	3	2
TCO-03	Maintenance / Operation Costs	2	3	3	3	2	2
TCO-04	License Costs	2	2	5	5	5	5
TCO-05	expected benefit/efficiency	4	4	3	4	3	3
Support & Operations
SUP-01	1st level	4	3	1	1	1	1
SUP-02	2nd level	4	4	1	1	1	1
SUP-03	3rd level	4	4	2	2	2	2
SUP-04	General support concept/approach	4	4	1	1	1	1
SUP-05	SLA for tickets	4	4	1	1	1	1
SUP-06	Support coverage	4	4	1	1	1	1
SUP-07	Training, tool documentation	4	4	3	3	2	2
Projektspezifische Anforderungen
CTX-01	Hierarchische Mandantentrennung mit vererbten	3	3	3	3	2	2
CTX-02	Mandanten-scoped API-Tokens und Service-Accou	3	3	2	2	2	1
CTX-03	Proxy-/Pull-Policy-Gate für JFrog Artifactory	5	5	1	1	2	2
CTX-04	Bidirektionale Integration mit bestehendem De	2	2	5	4	3	3
CTX-05	SBOM-Generierung für Binary-Artefakte in Arti	5	3	1	1	4	2
CTX-06	SBOM-Versionierung und Differenz-Tracking übe	4	3	4	3	2	2
CTX-07	VEX/OpenVEX-Erstellung und -Verwaltung als Fi	2	2	4	2	3	2
CTX-08	Organisationsweite Suppression und Wiederverw	4	3	3	3	2	3
CTX-09	Aggregierte Vulnerability-Feeds aus mehreren	4	3	4	2	3	4
CTX-10	License-Policy-Enforcement mit Copyleft-Risik	4	4	3	1	3	4
CTX-11	SPDX-konforme Lizenzauflösung inkl. komplexer	4	3	3	2	4	5
CTX-12	Deklarative Policy-as-Code-Definition mit Ver	3	3	2	2	3	5
CTX-13	Granulare Policy-Gate-Aktionen: Blockieren, W	4	5	3	2	2	3
CTX-14	Air-Gap / Offline-Betrieb für Vulnerability-D	4	2	3	3	3	3
CTX-15	Manipulationssicheres Audit-Log mit SIEM-Expo	4	4	2	3	1	3
CTX-16	Horizontale Skalierung des Scanning-Backends	4	4	3	3	3	3
CTX-17	OWASP-Ökosystem-Alignment und aktive OWASP-Pr	1	1	5	5	3	5
CTX-18	Native CI/CD-Integration mit Policy-Gate-Rück	5	4	3	3	2	3
CTX-19	Kubernetes-natives Deployment mit Helm-Chart	4	4	3	3	2	3
CTX-20	Compliance-Dashboard und automatisierter Repo	4	4	2	4	2	3
CTX-21	SBOM-Enrichment aus Container-Image-Layern	4	3	1	1	4	3
CTX-22	EPSS-Score-Integration und priorisierungsbasi	4	4	4	3	2	2
CTX-23	CISA KEV (Known Exploited Vulnerabilities) Ca	4	4	4	2	2	2
CTX-24	Mandantenspezifische Vulnerability-Feed-Konfi	3	3	2	2	2	2
CTX-25	Rückmeldung von Scan-Ergebnissen in Artifacto	5	2	2	2	2	2
CTX-26	Automatisierte OSS-Komponenten-Attributionsli	3	2	2	2	2	5
CTX-27	Trusted-Component-Registry und positives Whit	4	4	2	2	2	3
CTX-28	Transitive Dependency-Auflösung und Tiefenana	5	4	3	1	3	4
CTX-29	Datenbankpartitionierung und Archivierungsstr	3	2	2	2	2	2
CTX-30	Webhook- und Event-Bus-Integration für asynch	4	3	3	3	3	2
CTX-31	Malware- und Typosquatting-Erkennung für Regi	5	5	1	1	1	1
CTX-32	Softwareintegrität und Artefakt-Signatur-Veri	3	2	1	1	1	1
CTX-33	Ressourcen-Quotierung und Rate-Limiting pro M	3	2	1	2	2	1
CTX-34	SBOM-as-a-Service API für externe Tool-Integr	4	3	4	4	4	3
CTX-35	Regulatorische Berichtspflichten: CRA (Cyber	4	3	3	2	3	3
CTX-36	Dependency-Track-Migrationsbrücke: Erhalt his	3	2	3	3	3	3
CTX-37	Zentraler Service-Delivery-Modus: Self-Servic	4	3	3	3	2	2
CTX-38	Reachability-Analyse: Exploitierbarkeits-Kont	5	4	2	2	2	1
CTX-39	Operative Observability des Security-Services	3	3	3	3	2	2
CTX-40	Differenziertes Ausnahme- und Dispensationsma	3	2	2	3	1	2
Produkt-Features
FEAT-101	SBOM-Import (CycloneDX & SPDX)	5	3	4	3	3	3
FEAT-102	SBOM-Export & Supply-Chain-Transparenz	5	3	4	2	4	5
FEAT-103	SBOM-Qualitätsbewertung	3	2	2	1	2	2
FEAT-104	SBOM-Versionierung & historischer Vergleich	4	2	4	3	2	2
FEAT-105	Standardisierte Komponenten-Identifikation (P	5	4	5	3	5	5
FEAT-106	Interne Komponenten-Datenbank mit Deduplizier	5	3	4	3	3	3
FEAT-107	Kontinuierliches Vulnerability Monitoring	5	4	5	2	2	2
FEAT-108	Multi-Feed Vulnerability Aggregation	5	4	5	2	3	4
FEAT-109	CVSS- & EPSS-Score-Integration	5	3	4	4	2	3
FEAT-110	VEX (Vulnerability Exploitability eXchange) S	4	2	5	2	3	2
FEAT-111	Vulnerability Lifecycle Management & Triage-W	4	2	3	5	1	2
FEAT-112	Konfigurierbare Policy Engine	5	5	4	2	3	5
FEAT-113	Lizenz-Compliance & SPDX-Identifikation	5	4	3	2	5	5
FEAT-114	SLA-Tracking für Schwachstellen	3	2	2	5	1	2
FEAT-115	Hierarchische Projekt- und Portfolio-Struktur	3	2	4	4	2	2
FEAT-116	Konfigurierbares Notification & Alerting Fram	4	3	4	4	2	2
FEAT-117	Dashboards & Risiko-Scoring (Projekt & Portfo	4	3	3	3	2	2
FEAT-118	Automatisierte Bericht-Generierung	3	3	2	4	2	4
FEAT-119	CI/CD-Integration via REST-API & CLI	5	4	5	5	4	4
FEAT-120	Granulares RBAC mit Multi-Tenancy-Unterstützu	4	4	3	3	2	2

🔍 Audit-Details pro Produkt

ANBIETER

JFrog

PRODUKT

JFrog Xray

DEPLOYMENT

On-Premise, SaaS

WEBSITE

https://jfrog.com/xray/

GESAMTSCORE

3.60/5

3.5 Integration

4 General Interfaces/APIs INT

JFrog Xray bietet eine vollständige REST-API, die nahezu alle Funktionalitäten des Frontends abdeckt, inklusive Scan-Trigger, Policy-Management, SBOM-Export und Vulnerability-Reports. Es existiert eine umfassende offizielle API-Dokumentation, und Integrationen mit gängigen CI/CD-Tools (Jenkins, GitHub Actions, GitLab CI) sowie SIEM/API-Management-Lösungen sind verfügbar.

💡 Begründung: Die REST-API ist vollständig dokumentiert und deckt alle wesentlichen Funktionen ab. Out-of-the-box-Konnektoren für gängige DevOps-Tools sind vorhanden (Jenkins-Plugin, GitHub-Integration etc.). Allerdings sind dedizierte Middleware-Konnektoren (EAI, EDI-Manager) nicht nativ enthalten, sodass Score 5 nicht erreicht wird; Score 4 ist angemessen.

3 Interface monitoring INT

JFrog Xray stellt Health-Endpoints und Logs bereit, über die Verfügbarkeit und grundlegender Betriebsstatus der Schnittstellen überwacht werden können. Ein dediziertes, integriertes Interface-Monitoring-Dashboard mit Performance-Metriken für angebundene Schnittstellen ist jedoch nicht nativ vorhanden.

💡 Begründung: Xray bietet Standard-Health-Check-Endpunkte und Logging, die im Rahmen der JFrog-Plattform genutzt werden können. Ein spezialisiertes Interface-Monitoring mit klaren operativen Diagnosen (Score 4) ist nicht out-of-the-box enthalten; die Überwachung erfordert externe Tools (z. B. Prometheus/Grafana via Metrics-API). Daher Score 3 (Basis-Monitoring via Logs/Health-Endpoints).

4.2 Non-Functional Requirements

5 Authorization NFR

JFrog Xray bietet granulares RBAC mit konfigurierbaren Policies und Watches, die auf Repository-, Build- und Release-Bundle-Ebene angewendet werden können. Rollen und Berechtigungen sind vollständig anpassbar und werden durch die native Artifactory-Integration auf Pfad- und Projektebene gesteuert.

💡 Begründung: Xray nutzt das Artifactory-Berechtigungsmodell mit vollständig anpassbaren Rollen, pfadbasierter Zugriffskontrolle und Policy-Engine (ABAC-ähnlich). Dies entspricht der Skala-Beschreibung für Score 5: granulares RBAC + Path/Policy Control.

5 IDM connection NFR

JFrog Artifactory/Xray unterstützt SCIM für vollständige User- und Group-Lifecycle-Automatisierung, einschließlich Provisioning und De-Provisioning in Echtzeit. Die Integration mit Azure AD und anderen IdPs über SCIM ist dokumentiert und produktiv verfügbar.

💡 Begründung: JFrog (Artifactory/Xray) unterstützt SCIM 2.0 für automatisiertes User- und Gruppen-Management, was dem Score 5 der Skala entspricht: vollständige event-gesteuerte Automatisierung via SCIM.

5 Single Sign-On NFR

JFrog Xray (via Artifactory) unterstützt sowohl OIDC als auch SAML 2.0 mit Self-Service-Konfiguration durch den Kunden. Azure AD (EntraID) ist als IdP explizit dokumentiert, und die gesamte SSO-Konfiguration inklusive Zertifikatsrotation kann kundenseitig ohne Vendor-Eingriff durchgeführt werden.

💡 Begründung: Sowohl OIDC als auch SAML werden mit Self-Service-UI unterstützt, was Score 5 entspricht. JFrog bietet ausführliche Dokumentation für die eigenständige Einrichtung beider Protokolle.

5 Client/Instances NFR

JFrog bietet mit dem 'Projects'-Feature eine vollständige logische Mandantentrennung mit dedizierten Repositories, Benutzergruppen, Pipelines und Xray-Policies pro Projekt. Dies ermöglicht echte Top-Level-Isolation für mehrere Teams oder Kunden.

💡 Begründung: Das Projects-Feature von JFrog entspricht exakt der Score-5-Beschreibung: Top-Level-isolierte Einheiten mit dedizierten Repositories, Usern, Gruppen und Berechtigungen.

5 Storage of data (Metadata) NFR

JFrog Xray erfordert eine externe relationale Datenbank und unterstützt PostgreSQL, MS SQL und Oracle als Enterprise-grade Optionen. Eine eingebettete Datenbank ist für Produktion nicht vorgesehen.

💡 Begründung: Die Anforderung einer externen Datenbank mit Unterstützung mehrerer Enterprise-RDBMS (PostgreSQL, MS SQL, Oracle) entspricht exakt Score 5 der Skala: Flexible External DB (Mandatory).

5 Data/Object Storage Backend Flexibility NFR

JFrog Artifactory (auf dem Xray aufsetzt) unterstützt nativ alle großen Cloud-Object-Storage-Provider: AWS S3, Azure Blob Storage und Google Cloud Storage. Die Integration ist nativ und nicht über Kompatibilitätsschichten realisiert.

💡 Begründung: Native Integration mit S3, Azure Blob und GCS entspricht Score 5 der Skala: Full Native Cloud Storage. JFrog dokumentiert alle drei Provider als First-Class-Storage-Backends.

4 Data Archiving & Cleanup NFR

JFrog Artifactory bietet eine Policy-basierte Cleanup-Engine (Artifact Cleanup Policies), die automatisches Löschen basierend auf Alter, Download-Anzahl und anderen Kriterien ermöglicht. Eine dedizierte Archivierungsfunktion zu günstigeren Storage-Tiers (z.B. S3 Glacier) ist nicht als natives Feature dokumentiert.

💡 Begründung: Die Policy-basierte Cleanup-Engine erfüllt Score 4, da sie automatisches Löschen nach mehreren Kriterien bietet, aber keine dedizierte Archivierungsfunktion zu Kalt-Storage-Tiers vorhanden ist.

5 Hosting Flexibility NFR

JFrog Xray ist als SaaS (JFrog Cloud auf AWS und Azure), als containerisierte Kubernetes-Anwendung (Helm-Charts verfügbar) und als klassische On-Premise-Installation verfügbar. Alle drei Deployment-Modelle werden offiziell unterstützt.

💡 Begründung: SaaS, PaaS (Kubernetes/Helm) und On-Premise werden alle offiziell unterstützt, was Score 5 entspricht: Universal Flexibility. JFrog bietet Helm-Charts und offizielle Dokumentation für alle Deployment-Szenarien.

3 Hardware and Component Requirements NFR

JFrog Xray ist containerisiert lauffähig und unterstützt Docker/Kubernetes, erfordert jedoch nennenswerte Ressourcen (empfohlen werden mehrere CPU-Cores und viel RAM für produktive Workloads) und ist auf Artifactory als Abhängigkeit angewiesen. Der kombinierte Footprint ist spürbar ressourcenintensiv.

💡 Begründung: Xray läuft als Container, aber der kombinierte Stack mit Artifactory ist ressourcenintensiv (mehrere Services, externe DB, Speicher). Score 3 ist angemessen: adäquat, aber spürbar ressourcenintensiv.

4 Installation Mode (automatic / manual) NFR

JFrog stellt offizielle Helm-Charts, Docker Compose-Dateien und Installationsskripte bereit, die den Großteil der Installation automatisieren. Einige manuelle Vorbereitungsschritte (Datenbankeinrichtung, Lizenzaktivierung) sind erforderlich.

💡 Begründung: Offizielle Helm-Charts und Skripte automatisieren den Großteil der Installation, aber manuelle Vorbereitungen sind nötig. Score 4 entspricht 'Scripted Installation' mit einigen manuellen Prerequisite-Schritten.

5 Multi-location Deployment Options NFR

JFrog bietet mit seinem Edge-Node-Konzept und der JFrog Mission Control eine vollständige Föderationsarchitektur mit zentralem Repository, lokalen Edge-Caches und synchronisiertem Metadaten-Management. Active-Active und Active-Passive Szenarien werden unterstützt.

💡 Begründung: Das JFrog-Federationsmodell mit Edge Nodes und zentraler Metadatensynchronisation entspricht exakt Score 5: Full Federation with Central Repository, inklusive lokalem Caching und Single Source of Truth.

5 Application Performance NFR

JFrog Xray ist für Enterprise-Scale ausgelegt und bietet eine skalierbare Mikroservice-Architektur mit horizontaler Skalierbarkeit, effizientem Caching und optimierten Scan-Pipelines für niedrige Latenz auch bei großen Workloads.

💡 Begründung: Als kommerzielles Enterprise-Produkt, das als Referenz-Ziel definiert ist, bietet Xray exzellentes Performance-Profil mit skalierbarer Architektur. Score 5 ist angemessen für das definierte Referenzprodukt.

4 Scalability (manage increase No. of users) NFR

JFrog Xray ist als Enterprise-Plattform konzipiert und unterstützt sowohl horizontale Skalierung (On-Premise via Clustering) als auch automatische Skalierung in der SaaS-Variante. Parallele Scans, Queue-basierte Task-Verarbeitung und Multi-Node-Deployments sind bekannte Architekturmerkmale.

💡 Begründung: Xray unterstützt parallele Scan-Verarbeitung und skaliert gut für Enterprise-Workloads. Die SaaS-Variante bietet automatische Skalierung, On-Premise erfordert manuelle Cluster-Konfiguration. Score 4 ist gerechtfertigt, da kein vollständig transparentes Auto-Scaling-Modell für On-Premise dokumentiert ist, das Score 5 rechtfertigen würde.

4 Remote Performance for foreign locations NFR

JFrog Artifactory (auf dem Xray aufbaut) bietet native Geo-Replication, Edge-Nodes und Caching-Mechanismen, die Remote-Teams in verschiedenen Regionen unterstützen. Diese Infrastruktur reduziert Latenzprobleme für verteilte Teams erheblich.

💡 Begründung: Artifactory/Xray besitzen starke Replikations- und Edge-Strategien für verteilte Deployments. Die Integration mit JFrog Distribution und Multi-Site-Replication ist gut dokumentiert. Score 4, da diese Mechanismen primär auf Artifactory-Ebene wirken und Xray selbst keine eigenständigen Edge-Funktionen mitbringt.

4 Deployment of Customizing --> no coding NFR

Xray bietet eine umfangreiche UI-basierte Konfiguration für Policies, Watches, Permissions und Retention-Regeln ohne Code-Anforderungen. Delegierte Administration und rollenbasierte Zugriffskontrolle sind über die UI vollständig konfigurierbar.

💡 Begründung: Die Policy & Watch Engine sowie License Compliance sind weitgehend No-Code über die UI administrierbar. Für sehr fortgeschrittene Szenarien (z.B. komplexe Integrationsworkflows) wird Scripting empfohlen. Score 4 ist angemessen – breite No-Code-Abdeckung, aber manche Edge Cases erfordern API-Nutzung oder Skripting.

4 Deployment of Development --> coding NFR

JFrog Xray stellt eine gut dokumentierte REST-API bereit, über die kundenseitige Teams Integrationen und Automatisierungen implementieren können. Webhooks, CI/CD-Integrationen und offizielle SDKs ergänzen das Entwicklungsmodell.

💡 Begründung: REST-APIs, Webhooks und CI/CD-Plugin-Integrationen sind gut dokumentiert. Native Plugin-Erweiterungspunkte für Kernverhalten sind etwas begrenzt gegenüber einem vollständig offenen Plugin-Framework. Score 4 ist konservativ korrekt – starke API-Basis, aber tiefe Kernverhaltenserweiterung ist eingeschränkt.

4 Experience/Possibility with/of offshore development NFR

Xray unterstützt Enterprise-RBAC, LDAP/SAML-Integration und projekt- sowie repository-level Berechtigungssteuerung, was die Einbindung externer und Offshore-Teams operativ gut unterstützt. Feinkörnige Zugriffskontrolle auf Feed- und Projektebene ist verfügbar.

💡 Begründung: Die RBAC-Funktionen von JFrog Platform (Artifactory + Xray) sind für Enterprise-Nutzung mit externen Teams gut geeignet. Explicit Guest-Collaboration-Features sind weniger prominent dokumentiert als bei reinen Collaboration-Plattformen, daher Score 4 statt 5.

4 Flexibility via side-by-side or other extension points NFR

Xray bietet Webhooks, eine REST-API und native Integrationen mit CI/CD-Tools (Jenkins, GitHub Actions, etc.) als Erweiterungspunkte. Policy-Aktionen können externe Systeme triggern und ermöglichen Side-by-Side-Automatisierung.

💡 Begründung: Starke API- und Webhook-basierte Erweiterbarkeit ist vorhanden. Ein dediziertes Plugin-Framework für tiefes Kernverhalten (analog zu einem nativen Extension-Framework) ist weniger ausgeprägt. Score 4 reflektiert gute, aber nicht maximale Tiefe des Extension-Modells.

5 Maintenance and consistency of control tables NFR

Xray bietet eine zentrale UI und vollständige API-Abdeckung für Repository-Definitionen, Policies, Watches, Permissions und Retention-Regeln, was konsistente Verwaltung über Teams und Umgebungen hinweg ermöglicht. Automation via Terraform-Provider und REST-API ist offiziell unterstützt.

💡 Begründung: JFrog bietet einen offiziellen Terraform-Provider, vollständige REST-APIs und eine konsistente UI für alle Control-Table-Konzepte. Dies ermöglicht Infrastructure-as-Code-Ansätze für konsistente Umgebungsverwaltung – Score 5 ist gerechtfertigt.

1 Source code availability NFR

JFrog Xray ist ein proprietäres, kostenpflichtiges Closed-Source-Produkt. Kunden haben keinen Zugang zum Quellcode und können keine eigenen Änderungen am Produktkern vornehmen oder Forks pflegen.

💡 Begründung: Xray ist explizit als proprietäres Produkt positioniert. Es gibt keine Source-Code-Verfügbarkeit für Kunden. Gemäß Skala entspricht dies Score 1 (No source code availability for customer review/change).

4 Maintenance effort (upgrades & testing) NFR

JFrog veröffentlicht regelmäßige Releases mit Release Notes und Upgrade-Guides, und der SaaS-Service wird kontinuierlich aktualisiert. Sicherheitsupdates werden zeitnah bereitgestellt, und die Dokumentation unterstützt kontrollierte Upgrades.

💡 Begründung: JFrog hat einen gut strukturierten Release-Prozess mit dokumentierten Upgrade-Pfaden und LTS-Versionen für On-Premise. Der Validierungsaufwand bei Major-Upgrades ist moderat. Score 4 ist angemessen – gutes Release-Modell, aber On-Premise-Upgrades erfordern noch manuelle Regression.

4 Backup & Recovery/Redundancy layer in case of break down NFR

JFrog Xray unterstützt HA-Deployments mit Multi-Node-Clustering für On-Premise sowie automatische Redundanz in der SaaS-Variante. Backup- und Restore-Mechanismen für Konfiguration und Datenbanken sind dokumentiert.

💡 Begründung: HA-Clustering und Backup-Konzepte sind für Enterprise-Deployments gut dokumentiert. Die SaaS-Variante bietet starke eingebaute Redundanz. On-Premise-HA erfordert manuelle Infrastrukturkonfiguration, was eine vollständige 5 verhindert. Score 4 ist konservativ korrekt.

4 Availability (Maintenance windows, unannounced maintenance) NFR

Im SaaS-Betrieb werden Updates von JFrog mit minimaler Downtime durchgeführt, und Wartungsfenster werden vorab kommuniziert. On-Premise-Deployments können mit Blue-Green- oder Rolling-Update-Strategien mit geringer Downtime betrieben werden.

💡 Begründung: SaaS bietet Near-Zero-Downtime-Updates durch JFrog-Managed Operations. On-Premise erlaubt Low-Downtime mit empfohlener Architektur, erfordert aber mehr Kundeneigenleistung. Score 4 ist angemessen – nicht Score 5, da On-Premise nicht standardmäßig Zero-Downtime garantiert.

4 Availability defined/possible SLA NFR

Für die SaaS-Variante (JFrog Cloud) publiziert JFrog ein SLA mit definierten Uptime-Verpflichtungen, typischerweise 99,9% Verfügbarkeit. On-Premise-Deployments liegen in der Verantwortung des Kunden ohne Vendor-SLA.

💡 Begründung: JFrog Cloud bietet ein dokumentiertes SLA für die verwaltete Service-Variante, was Score 4 rechtfertigt. Da On-Premise-Kunden kein Vendor-SLA erhalten und Details des SLA weniger transparent öffentlich verfügbar sind als bei Hyperscaler-Diensten, ist Score 5 nicht gerechtfertigt.

2.5 Usability & User Experience

3 Ease of Use UX

JFrog Xray ist eng in Artifactory integriert und für erfahrene DevOps-Teams gut nutzbar, erfordert jedoch eine gewisse Einarbeitungszeit in Konzepte wie Policies, Watches und die Navigationsstruktur. Core-Tasks wie Vulnerability-Scanning und SBOM-Export sind erreichbar, aber nicht sofort intuitiv für neue Nutzer.

💡 Begründung: Die Plattform richtet sich primär an technische Nutzer mit Vorkenntnissen in Artefakt-Management. Onboarding ist nötig, die Lernkurve ist real, aber nicht extrem steil – das entspricht Score 3 (Acceptable; some training/documentation needed).

3 Consistent, seamless user interface UX

Die JFrog-Plattform bietet eine weitgehend konsistente UI über Artifactory und Xray hinweg, Anpassungsoptionen für Branding oder Theming sind jedoch begrenzt. Die Integration zwischen den Produktkomponenten ist funktional konsistent, aber enterprise-spezifische UX-Anpassungen sind eingeschränkt.

💡 Begründung: Die UI ist generell konsistent, aber Personalisierungs- und Theming-Optionen gehen nicht über Grundkonfigurationen hinaus, was Score 3 rechtfertigt (generally consistent but limited adaptation options).

3 Explicit user guidance UX

JFrog bietet umfangreiche externe Dokumentation und Onboarding-Guides, aber In-Product-Assistenten oder Schritt-für-Schritt-Wizards für komplexe Konfigurationen (z. B. Policy-Setup, Watch-Konfiguration) sind begrenzt vorhanden. Die Hilfe ist primär dokumentationsgetrieben.

💡 Begründung: Die Guidance stützt sich stark auf externe Dokumentation (docs.jfrog.com) statt auf kontextuelle In-App-Assistenten. Das entspricht Score 3 (Basic documentation-driven guidance, limited in-product assistance).

3 Use-case-oriented design UX

Xray ist klar auf Security- und Compliance-Workflows ausgerichtet, aber die UI-Struktur (Watches, Policies, Reports) erfordert ein konzeptuelles Verständnis des JFrog-Datenmodells. Für Entwickler ist die Relevanz einzelner Findings nicht immer auf Anhieb erkennbar.

💡 Begründung: Die Aufgabenorientierung ist für erfahrene Administratoren gut, für Entwickler oder neue Nutzer entstehen Reibungspunkte bei häufigen Aufgaben. Score 3 (Adequate fit with some friction in common tasks) ist angemessen.

2 Flexibility of UI UX

JFrog Xray bietet grundlegende Filter- und Suchfunktionen für Vulnerabilities und Artefakte, jedoch sind erweiterte Tastaturkürzel oder High-Productivity-Features für Power-User nicht prominent dokumentiert oder umgesetzt. Die Navigation in großen Datensätzen ist funktional, aber nicht besonders effizient.

💡 Begründung: Keyboard-Shortcuts und erweiterte Power-User-Funktionen sind nicht als Stärke von Xray bekannt. Filterfunktionen sind vorhanden, aber begrenzt – Score 2 (Limited productivity support) ist konservativ aber angemessen.

2 Customizable by end-user / user groups UX

Personalisierungsoptionen auf Nutzerebene sind in JFrog Xray sehr begrenzt; es gibt keine nennenswerten Möglichkeiten für individuelle UI-Layouts, Themes oder Verhaltensanpassungen pro Nutzer. Gruppenbasierte Berechtigungen existieren, aber UX-Personalisierung ist minimal.

💡 Begründung: JFrog Xray bietet keine signifikante End-User-Personalisierung über grundlegende Einstellungen hinaus. Das entspricht Score 2 (Limited personalization options).

2 Language Capabilities UX

JFrog Xray ist primär auf Englisch ausgelegt; eine multi-sprachige UI oder umfassende Lokalisierungsoptionen (Sprache, Zeitzone, Locale) für internationale Teams sind nicht als Feature dokumentiert oder bekannt. Zeitzonen-Einstellungen auf Nutzerebene sind rudimentär verfügbar.

💡 Begründung: Keine bekannte Multi-Language-UI-Unterstützung; die Plattform ist de facto englischsprachig. Das entspricht Score 2 (Limited language/localization support), konservative Bewertung mangels gegenteiliger Belege.

2 Design thinking approach UX

Formale Barrierefreiheits-Zertifizierungen oder eine explizit keyboard-first-Interaktionsstrategie für JFrog Xray sind nicht öffentlich dokumentiert. Grundlegende Web-Zugänglichkeit ist durch Standard-Browser-Verhalten teilweise gegeben, aber gezielte Accessibility-Features sind nicht prominent.

💡 Begründung: Es gibt keine bekannte WCAG-Konformitätserklärung oder explizite Accessibility-Features für Xray. Score 2 (Limited support for inclusive interaction) ist konservativ aber passend angesichts fehlender Belege.

3.7 IT Compliance

3 Single Source of Truth for each data object COMP

JFrog Xray ist eng in Artifactory als führendes Source-System integriert und bezieht Artefakt-Metadaten über native APIs. Allerdings ist Xray primär ein Scanning-Tool und kein universelles Data-Governance-System; Replikationsvermeidung und Single-Source-of-Truth für allgemeine Datenobjekte sind nicht explizit adressiert.

💡 Begründung: Die Integration in Artifactory als führendes System ist stark, aber Xray ist kein MDM/Data-Governance-Tool. Externe Leading-Source-Systeme (REF-MDS) werden nicht nativ unterstützt. Teilweise konform mit Anpassungen nötig → Score 3.

4 Where is the cloud server located? (country) COMP

JFrog bietet SaaS-Deployments auf AWS und Azure in mehreren Regionen inklusive EU (z.B. Frankfurt/Ireland) an. Für On-Premise-Deployments entscheidet der Kunde selbst über den Standort. Die bevorzugten Hyperscaler AWS und Azure werden unterstützt.

💡 Begründung: EU-Regionen auf AWS und Azure sind verfügbar, was die Kernanforderungen gut abdeckt. Kleinere Einschränkungen bestehen ggf. bei der Auswahl spezifischer Subregionen oder bei GCP-Präferenz. Insgesamt gute regionale Abdeckung → Score 4.

4 Does the cloud service provide the encryption of data at rest and in transit? COMP

JFrog Xray (SaaS) implementiert standardmäßig TLS für Daten in Transit und AES-256-Verschlüsselung für Daten at Rest. Für On-Premise-Deployments liegt die Verschlüsselungsverantwortung beim Kunden, was eine deployment-abhängige Komponente darstellt.

💡 Begründung: Für SaaS ist die Verschlüsselung solide und entspricht Enterprise-Standards. Bei On-Premise-Deployment ist der Kunde verantwortlich, was die Konsistenz einschränkt. Customer-Managed-Keys sind nicht standardmäßig dokumentiert. Gute Abdeckung mit deploymentabhängigen Aspekten → Score 4.

3 GDPR and BDSG COMP

JFrog bietet einen DPA (Data Processing Agreement) und dokumentiert die DSGVO-Konformität grundsätzlich. Subprozessoren werden in einer Liste publiziert; die BDSG-spezifische Konformität und detaillierte Löschroutinen für personenbezogene Daten sind jedoch nur begrenzt öffentlich dokumentiert.

💡 Begründung: Grundlegende DSGVO-Compliance ist vorhanden (DPA, Subprozessor-Liste, EU-Datenregionen), aber BDSG-spezifische Nachweise, detaillierte Löschkonzepte und Transparenz zu Nutzerprofilen sind limitiert dokumentiert. Basiskonformität möglich, aber Governance-Nachweis begrenzt → Score 3.

4 ISO certificates COMP

JFrog ist ISO 27001 zertifiziert und hält zusätzlich SOC 2 Type II Reports. Die Zertifikate gelten für die JFrog-Plattform-Infrastruktur einschließlich Xray. Hyperscaler-Infrastruktur bringt zusätzliche Zertifizierungen mit.

💡 Begründung: ISO 27001 ist vorhanden, ergänzt durch SOC 2 Type II, was einer soliden Enterprise-Zertifizierungsbasis entspricht. Weitere Zertifizierungen wie ISO 27017/27018 sind nicht klar dokumentiert. Starke Basis mit kleineren Lücken bei spezialisierten Cloud-Zertifizierungen → Score 4.

4 Data export and import COMP

JFrog Xray bietet umfangreiche REST APIs für den Export von Vulnerability-Reports, SBOMs (CycloneDX/SPDX) und Scan-Ergebnissen. SBOM-Import ist ebenfalls unterstützt. Massenoperationen via Excel oder UI-basierte Bulk-Uploads sind nicht primär vorgesehen, aber API-basierte Automatisierung kompensiert dies weitgehend.

💡 Begründung: API-basierter Export und Import sind stark ausgeprägt, insbesondere für SBOM und Vulnerability-Daten. Operative Tooling-Optionen für manuelle Massenoperationen (z.B. Excel-Upload) sind begrenzt. Starke API-Unterstützung mit kleinen Einschränkungen bei nicht-technischen Nutzern → Score 4.

3.8 Risks & Opportunities

2 Dependencies and Lock-In from Software Vendor RISK

JFrog Xray ist tief in JFrog Artifactory integriert und setzt diese Plattform als zwingende Voraussetzung voraus, was einen erheblichen Vendor-Lock-in erzeugt. SBOM-Exporte in CycloneDX/SPDX ermöglichen zwar eine gewisse Datenportabilität, aber die funktionale Abhängigkeit vom JFrog-Ökosystem bleibt sehr stark.

💡 Begründung: Die enge Kopplung an Artifactory als Pflichtkomponente und die proprietäre JFrog Security Research Database schaffen eine starke Plattformabhängigkeit. Ein Wechsel würde nicht nur Xray ersetzen, sondern potenziell das gesamte Artifactory-Setup in Frage stellen. Laut Skala entspricht das Score 2 (Strong platform or vendor dependency).

5 Project team setup and continuity RISK

JFrog ist ein börsennotiertes Unternehmen mit einem großen, etablierten Entwicklungsteam, das kontinuierlich an Xray arbeitet. Das Unternehmen weist eine stabile Unternehmensgeschichte und regelmäßige Produktupdates auf, was auf hohe Teamkontinuität hindeutet.

💡 Begründung: Als öffentlich gelistetes Unternehmen mit mehreren Hundert Entwicklern und einer klaren Produktroadmap ist die Stabilität und Seniorität des Entwicklerteams sehr hoch einzuschätzen. Regelmäßige Major-Releases und aktive Weiterentwicklung bestätigen dies. Score 5 gemäß Skala (Very strong and stable delivery ecosystem).

3 Time to Market RISK

JFrog Xray erfordert eine bestehende Artifactory-Instanz als Voraussetzung, was die initiale Einrichtung verlängert. Ist Artifactory bereits vorhanden, kann Xray als Add-on relativ zügig aktiviert werden, jedoch sind Policy-Konfiguration und Integration in CI/CD-Pipelines zeitaufwendig.

💡 Begründung: Die Abhängigkeit von Artifactory als Vorbedingung und der Konfigurationsaufwand für Policies, Watches und CI/CD-Integration bedeuten einen moderaten Rollout-Aufwand. Für Organisationen ohne bestehende JFrog-Infrastruktur ist der Aufwand deutlich höher. Score 3 (Moderate lead time) ist angemessen.

4 Skill of supplier RISK

JFrog verfügt über ein globales Professional-Services- und Solutions-Engineering-Team mit nachgewiesener Erfahrung in der Implementierung bei großen Unternehmen. Die Beratungskompetenz reicht von Konzeption über Implementierung bis hin zu Enterprise-Deployment.

💡 Begründung: JFrog adressiert explizit Enterprise-Kunden und hat zahlreiche Fortune-500-Referenzen. Das Professional-Services-Team deckt alle relevanten Bereiche (Consulting, Deployment, Integration) ab. Konservativ Score 4 (Strong supplier capability), da spezifische Tiefe im deutschen Großkundenumfeld nicht vollständig beurteilbar ist.

4 Size of supplier (Skalierbarkeit für Großkunden), risk of insolvency RISK

JFrog ist ein börsennotiertes Unternehmen (NASDAQ: FROG) mit über 1.500 Mitarbeitern und mehreren Hundert Millionen Dollar Jahresumsatz, was das Insolvenzrisiko als sehr gering einzustufen ist. Die Unternehmensgröße und Kapitalausstattung bieten hohe Versorgungssicherheit.

💡 Begründung: Als börsennotiertes Unternehmen mit solidem Umsatzwachstum und breiter Kundenbasis ist das Kontinuitätsrisiko gering. Score 4 statt 5, da JFrog im Vergleich zu hyperscalern oder sehr großen Software-Konzernen eine mittlere Unternehmensgröße aufweist und damit ein residuales Marktrisiko besteht.

4 World wide rollout RISK

JFrog betreibt Niederlassungen und Support-Teams in Nordamerika, Europa, APAC und dem Nahen Osten mit globalem 24/7-Support für Enterprise-Kunden. SaaS-Deployments sind in mehreren Regionen verfügbar, was weltweite Rollouts unterstützt.

💡 Begründung: JFrog hat nachweislich eine globale Präsenz mit regionalen Büros und lokalen Support-Teams. Enterprise-SLAs mit globalem Support sind verfügbar. Score 4 (Good multi-region capability) ist angemessen, da eine vollständig lokalisierte Betreuung in allen Regionen im Detail nicht vollständig belegbar ist.

3 Dependencies to other strategic projects RISK

JFrog Xray hat keine direkten negativen Abhängigkeiten zu strategischen Programmen wie S/4HANA, kann aber positiv mit DevSecOps- und Software-Supply-Chain-Programmen verknüpft werden. Die Abhängigkeit von Artifactory kann strategische Flexibilität einschränken.

💡 Begründung: Es bestehen weder starke positive Synergien zu typischen ERP-Transformationsprogrammen noch direkte negative Abhängigkeiten. Die Bindung an das JFrog-Ökosystem könnte bei parallelen Plattform-Konsolidierungsprojekten zu Reibungen führen. Score 3 (Neutral dependency position) ist sachgerecht.

5 Development method (agile or waterfall) RISK

JFrog Xray wird nach einem modernen, agilen SaaS-Produktmodell mit regelmäßigen Releases, kontinuierlichem Feature-Delivery und einer öffentlichen Roadmap entwickelt. Die Integration in CI/CD-Pipelines und DevSecOps-Workflows ist ein Kernmerkmal des Produkts.

💡 Begründung: JFrog liefert Xray als kontinuierlich weiterentwickeltes Cloud-native Produkt mit häufigen Updates und agiler Entwicklungsmethodik. Die tiefe CI/CD-Integration zeigt eine vollständige Ausrichtung auf moderne agile Delivery-Modelle. Score 5 (Very strong agile or product delivery fit) ist gerechtfertigt.

2.4 Total Cost of Ownership

2 Setup/Project Costs TCO

JFrog Xray erfordert als proprietäres Enterprise-Produkt einen erheblichen Projektaufwand für Konzeption, Lizenzverhandlung und initiales Setup, insbesondere bei On-Premise-Deployment mit Artifactory-Integration.

💡 Begründung: Die enge Kopplung an Artifactory sowie die notwendige Policy- und Watch-Engine-Konfiguration erhöhen den initialen Setup-Aufwand erheblich. Lizenzverhandlungen und Onboarding-Prozesse bei einem kommerziellen Enterprise-Vendor treiben die Einrichtungskosten in den hohen Bereich, was Score 2 auf der Skala entspricht.

2 Implementation Costs TCO

Die Implementierung von Xray erfordert tiefe Artifactory-Kenntnisse, individuelle Policy-Konfiguration und ggf. CI/CD-Pipeline-Anpassungen, was einen hohen Customizing-Aufwand bedeutet.

💡 Begründung: Xray ist zwar nativ in Artifactory integriert, aber die Konfiguration von Policies, Watches, Build-Integrationen und SBOM-Workflows erfordert signifikante Implementierungsarbeit. Für Organisationen ohne bestehende JFrog-Infrastruktur ist der Aufwand noch höher, was Score 2 rechtfertigt.

2 Maintenance / Operation Costs TCO

Im On-Premise-Betrieb entstehen hohe laufende Kosten durch Plattformadministration, Updates und den Betrieb der JFrog-Infrastruktur; selbst im SaaS-Modell ist regelmäßige Policy-Pflege und Administration notwendig.

💡 Begründung: On-Premise-Deployment erfordert dediziertes Infrastruktur- und Administrations-Know-how. Auch im SaaS-Modell sind Day-2-Operations (Policy-Updates, Triage von Findings, Datenbank-Pflege) aufwendig. Der Gesamtbetriebsaufwand ist hoch, was Score 2 entspricht.

2 License Costs TCO

JFrog Xray ist kostenpflichtig und wird typischerweise als Teil der JFrog Platform lizenziert – das Preismodell ist komplex, volumenabhängig und für externe Nutzer schwer kalkulierbar.

💡 Begründung: Die Lizenzkosten sind nicht öffentlich transparent, hängen von Faktoren wie Artefaktvolumen, Nutzeranzahl und Deployment-Modell ab und erfordern individuelle Angebote. Zusatzkosten für Advanced Security Features sind möglich. Dies entspricht Score 2 (teuer oder intransparent).

4 expected benefit/efficiency TCO

JFrog Xray bietet durch tiefe Automatisierung, Policy-basierte Gates und Impact Analysis erhebliche Effizienzgewinne bei der Vulnerability-Behandlung und Compliance-Sicherstellung in nachfolgenden Betriebsjahren.

💡 Begründung: Die starke Automatisierung (rekursives Scanning, automatische Blockierung, SBOM-Generierung, Contextual Analysis) reduziert manuellen Aufwand erheblich und verhindert teure Security-Incidents. Der Effizienzgewinn ist stark, was Score 4 rechtfertigt; Score 5 wird nicht erreicht, da die hohen Lizenz- und Betriebskosten den Netto-Benefit leicht dämpfen.

4.0 Support & Operations

4 1st level SUP

JFrog bietet für kommerzielle Kunden einen strukturierten 1st-Level-Support über ein Online-Support-Portal (Jira-basiertes Ticketsystem) sowie Chat- und E-Mail-Kanäle. Partner und Enterprise-Kunden können eigene 1st-Level-Prozesse in Zusammenarbeit mit JFrog organisieren.

💡 Begründung: JFrog bietet als kommerzieller Anbieter einen klar definierten Support über das Support-Portal mit Ticketing, was eine gute Grundlage für 1st-Level-Support darstellt. Telefonischer Hotline-Support ist weniger prominent, daher kein Score 5.

4 2nd level SUP

JFrog stellt für 2nd-Level-Support technische Experten bereit, die über das Ticketsystem eskalierte Fälle bearbeiten. Enterprise-Kunden erhalten Zugang zu dedizierten Technical Account Managers (TAMs), die als Schnittstelle zum Engineering dienen.

💡 Begründung: Mit TAMs und einem klaren Eskalationspfad über das Support-Portal ist ein gutes 2nd-Level-Modell vorhanden. Score 5 würde ein noch stärker formalisiertes, dokumentiertes Partnermodell erfordern.

4 3rd level SUP

Bugfixes und Engineering-Eskalationen können über das JFrog Support-Portal mit entsprechender Priorität eingereicht werden; kritische Issues werden an das Engineering-Team eskaliert. Für Enterprise-Kunden gibt es dedizierte Eskalationspfade mit definierten Engineering-Kontakten.

💡 Begründung: Als proprietärer Anbieter mit eigenem Engineering-Team ist ein klarer 3rd-Level-Prozess vorhanden. Score 5 würde öffentlich dokumentierte SLAs für Engineering-Eskalationen und garantierte Fix-Zeiten erfordern.

4 General support concept/approach SUP

JFrog bietet ein umfassendes Enterprise-Support-Konzept mit Ticketsystem, TAMs, Community-Forum (JFrog Community) und weltweitem Support in englischer Sprache. Eine Ticket-Bridge-Integration ist über die REST-API des JFrog Support-Portals grundsätzlich möglich; weltweiter Support wird angeboten.

💡 Begründung: JFrog adressiert Enterprise-Anforderungen gut: globaler Support, strukturiertes Ticketing, TAMs für größere Kunden. Mehrsprachiger Support über Englisch hinaus ist begrenzt, und eine native Ticket-Bridge ist nicht standardmäßig dokumentiert, daher Score 4.

4 SLA for tickets SUP

JFrog definiert in seinen Enterprise-Support-Plänen (z. B. Enterprise+ und Enterprise) klare SLA-Reaktionszeiten nach Priorität: P1 (kritisch) mit 1-Stunde-Response, P2 mit 4 Stunden, P3/P4 mit 1-2 Werktagen. Lösungszeiten sind prioritätsabhängig dokumentiert.

💡 Begründung: JFrog bietet dokumentierte SLA-Stufen nach Ticketpriorität, was einem guten SLA-Angebot entspricht. Score 5 würde noch detailliertere, vertraglich garantierte Lösungszeiten (nicht nur Response-Zeiten) erfordern.

4 Support coverage SUP

JFrog bietet für Enterprise-Kunden 24/7-Support mit globaler Abdeckung über Niederlassungen in Nordamerika, Europa und APAC. Regionaler Support ist vorhanden, allerdings ist die 24/7-Verfügbarkeit primär an höhere Support-Tiers gebunden.

💡 Begründung: 24/7-Abdeckung ist verfügbar, jedoch tier-abhängig (nicht für alle Kunden standardmäßig). Globale Regionalpräsenz ist gut, aber nicht alle Regionen sind gleich stark abgedeckt, daher Score 4 statt 5.

4 Training, tool documentation SUP

JFrog bietet umfangreiche Dokumentation (JFrog Docs), Video-Tutorials, Webinare, JFrog Academy mit strukturierten Lernpfaden sowie Zertifizierungsprogramme für Entwickler und Administratoren. Instructor-led Trainings sind für Enterprise-Kunden verfügbar.

💡 Begründung: Das Trainingsangebot ist mit JFrog Academy, Zertifizierungen und verschiedenen Formaten (Online, Videos, Webinare) sehr gut. Score 5 würde ein noch breiteres Spektrum an face-to-face und maßgeschneiderten On-Site-Trainings erfordern.

3.7 Projektspezifische Anforderungen

3 Hierarchische Mandantentrennung mit vererbten Policies CTX

JFrog Xray bietet eine mehrstufige Hierarchie über Artifactory-Organisationsstrukturen (Repositories, Projects, Permissions), jedoch ist das native Mandantenmodell primär auf zwei bis drei Ebenen (Global > Project > Repository) ausgerichtet. Policy-Vererbung ist über die Watch- und Policy-Engine konfigurierbar, aber eine vollständige 5-stufige Hierarchie mit technisch erzwungenem Überschreibungsschutz ist nicht nativ vorhanden.

💡 Begründung: Xray/Artifactory Projects bieten eine Projekt-Ebene mit RBAC, jedoch keine vollständige 5-stufige Mandantenhierarchie mit technisch durchgesetztem Überschreibungsschutz. Policy-Watches können auf Repo-Ebene konfiguriert werden, aber echte Policy-Vererbung mit Lock-down auf untergeordneten Ebenen ist begrenzt. Dies entspricht Skala 3 (Zwei-bis-Drei-Ebenen-Modell, Policy-Vererbung eingeschränkt manuell nachrüstbar).

3 Mandanten-scoped API-Tokens und Service-Accounts CTX

JFrog Artifactory/Xray unterstützt projektbezogene Access Tokens, die auf bestimmte Projekte und Ressourcen beschränkt werden können. Audit-Logs für Token-Nutzung sind vorhanden, jedoch ist die vollständige technische Infrastruktur-Isolation zwischen Mandanten über Tokens nicht lückenlos dokumentiert.

💡 Begründung: JFrog bietet seit neueren Versionen Project-scoped Access Tokens mit konfigurierbaren Scopes und Expiry. Audit-Logging ist vorhanden. Automatische Rotation ist nicht nativ integriert (erfordert externe Automatisierung). Die technische Isolation auf Infrastrukturebene ist begrenzt nachweisbar, da alle Tokens letztlich über dieselbe Artifactory-Instanz laufen. Score 3 ist konservativ angemessen.

5 Proxy-/Pull-Policy-Gate für JFrog Artifactory ohne XRay-Lizenz CTX

JFrog Xray ist nativ direkt in Artifactory integriert und fungiert als Policy-Gate beim Artifact-Download – Artefakte können durch konfigurierte Policies blockiert werden, bevor sie an einen Build weitergegeben werden. Dies ist eines der Kernfeatures von Xray (Block-on-Download-Policy via Watches).

💡 Begründung: Xray ist das Referenzprodukt für genau diesen Use Case: native Artifactory-Integration mit technischem Blocking vor dem Download/Delivery via Policy-Watches. 'Fail Build' und 'Block Download'-Aktionen sind dokumentierte, produktiv einsetzbare Features. Dies entspricht exakt Score 5 der Skala.

2 Bidirektionale Integration mit bestehendem Dependency-Track ohne Datenduplizierung CTX

JFrog Xray ist ein eigenständiger Stack und bietet keine explizite, dokumentierte bidirektionale Integration mit Dependency-Track. CycloneDX-SBOMs können exportiert und potenziell in Dependency-Track importiert werden, aber ein direkter Sync oder eine Nutzung von Dependency-Track als autoritativem SBOM-Store ist nicht vorgesehen.

💡 Begründung: Xray ist als Ersatz/Konkurrenz zu Dependency-Track positioniert, nicht als Ergänzung. Es gibt keine offizielle Dependency-Track-Konnektivität. Der parallele Stack wäre unvermeidlich, was Datenduplizierung erzeugt. CycloneDX-Export ermöglicht unidirektionalen Transfer, aber kein natives bidirektionales Sync. Score 2 ist angemessen (paralleler redundanter Stack erforderlich).

5 SBOM-Generierung für Binary-Artefakte in Artifactory (ohne Quellcode-Zugriff) CTX

JFrog Xray führt natives Deep Recursive Dependency Scanning für Binärartefakte in Artifactory durch – für Docker Images, JARs, NPM-Packages, NuGet, Go-Module und weitere Formate, ohne Quellcode-Zugriff. SBOMs werden in CycloneDX und SPDX-Format ausgegeben.

💡 Begründung: Dies ist ein Kernfeature von Xray: Binary-Scanning direkt aus Artifactory für über 5 Artefakttypen, ohne Quellcode-Zugriff, mit CycloneDX/SPDX-SBOM-Output. Die tiefe Integration mit Artifactory ermöglicht automatisches Scanning beim Upload. Score 5 entspricht der Skalenbeschreibung vollständig.

4 SBOM-Versionierung und Differenz-Tracking über Artefakt-Versionen CTX

JFrog Xray versioniert SBOMs und Scan-Ergebnisse auf Artefakt-Versionsebene in Artifactory, da jede Artefakt-Version separat gescannt und gespeichert wird. Ein natives Diff-View zwischen SBOM-Versionen ist über Impact Analysis ansatzweise vorhanden, ein vollständiger dedizierter SBOM-Diff ist jedoch primär in erweiterten Editionen verfügbar.

💡 Begründung: Xray speichert Scan-Ergebnisse pro Artefakt-Version (da Artifactory jede Version separat verwaltet). Impact Analysis zeigt betroffene Artefakte bei neuen CVEs. Ein vollständiger SBOM-Diff auf Komponenten-Ebene (hinzugefügt/entfernt/verändert) ist nicht als explizites natives Feature dokumentiert, aber Versionierung ist gegeben. Score 4 erscheint angemessen mit konservativer Einschätzung.

2 VEX/OpenVEX-Erstellung und -Verwaltung als First-Class-Feature CTX

JFrog Xray bietet proprietäre Vulnerability-Triage-Funktionen (Ignore Rules, Contextual Analysis) mit eigenen Status-Feldern, unterstützt jedoch kein natives VEX-Dokument-Management nach CycloneDX-VEX oder OpenVEX-Standard. Ein Export als VEX wäre mit erheblichem Konvertierungsaufwand verbunden.

💡 Begründung: Xray hat mit Contextual Analysis und Ignore Rules ein proprietäres Triage-System, aber kein First-Class VEX-Feature nach CycloneDX-VEX oder OpenVEX-Standard. VEX als eigenständiges, verwaltetes, versioniertes Dokument ist nicht dokumentiert. SBOM-Export in CycloneDX enthält Vulnerability-Daten, aber dediziertes VEX-Management fehlt. Score 2 entspricht 'proprietäres Triage ohne Standard-VEX-Export'.

4 Organisationsweite Suppression und Wiederverwendung von Triage-Entscheidungen CTX

JFrog Xray ermöglicht über Ignore Rules und Policy-Watches organisationsweite Suppression-Regeln, die auf CVE/Komponenten-Kombinationen basieren und automatisch auf alle betroffenen Watches/Projekte angewendet werden können. Ein vollständiger Audit-Trail für Propagation-Entscheidungen ist in Enterprise-Editionen verfügbar.

💡 Begründung: Xray's Ignore Rules können global oder auf Watch-Ebene definiert werden und greifen bei allen Findings, die der Regel entsprechen – dies ist eine Form der automatischen Propagation. Die Scope-Konfiguration (global vs. projekt-spezifisch) ist vorhanden. Vollständiger Audit-Trail auf Propagations-Ebene ist Enterprise-Feature. Score 4 passt zur Skalenbeschreibung.

4 Aggregierte Vulnerability-Feeds aus mehreren Quellen mit Konfliktauflösung CTX

JFrog Xray nutzt die proprietäre JFrog Security Research Database sowie NVD und weitere Quellen (GitHub Advisory, OSS Index) als aggregierte Vulnerability-Feeds. Die Priorisierung zwischen Feeds ist konfigurierbar, erweiterte proprietäre Threat-Intel ist jedoch ein Enterprise-Feature der JFrog-Datenbank.

💡 Begründung: Xray aggregiert NVD, GitHub Advisory, JFrog eigene Research-DB und weitere Quellen (dokumentiert als mehrere Feeds). Die Konfliktauflösung erfolgt durch JFrog's eigene Datenbanklogik, ist aber nicht vollständig transparent konfigurierbar im Sinne 'welcher Feed gewinnt bei Konflikt'. CERT-Bund oder VulnDB als direkt konfigurierbare Feeds sind nicht dokumentiert. Score 4 ist konservativ angemessen.

4 License-Policy-Enforcement mit Copyleft-Risikostufen und Ausnahme-Workflow CTX

JFrog Xray bietet granulare License-Policies mit konfigurierbaren Lizenz-Risikostufen (per Copyleft-Typ), Policy-Watches mit Enforcement-Aktionen (Block/Warn) und Ausnahme-Management über Ignore Rules. Ein vollständig strukturierter Legal-Review-Ausnahme-Workflow mit mehrstufiger Genehmigung ist rudimentär und primär in Enterprise-Editionen ausgeprägt.

💡 Begründung: Xray's License-Compliance ist ein dokumentiertes Feature mit Risikostufen-Konfiguration und Policy-Enforcement. Der Ausnahme-Workflow über Ignore Rules ist vorhanden, aber kein dedizierter mehrstufiger Approval-Workflow mit Legal-Rolle. Dies entspricht Score 4 (License-Policies mit Risikostufen, Ausnahme-Workflow rudimentär).

4 SPDX-konforme Lizenzauflösung inkl. komplexer Lizenz-Expressions CTX

JFrog Xray verarbeitet SPDX License Expressions für Standard-AND/OR-Kombinationen korrekt und wertet diese bei Policy-Bewertungen aus. LicenseRef-Custom-Ausdrücke werden als unbekannte Lizenzen markiert; vollständige SPDX-2.3-Compliance mit WITH-Operator und komplexen Expressions ist nicht explizit dokumentiert.

💡 Begründung: Xray ist in der SCA-Szene als SPDX-fähiges Tool bekannt und verarbeitet gängige License Expressions. Vollständige SPDX-2.3-Konformität inkl. WITH-Operator und LicenseRef-Support ist nicht in der öffentlichen Dokumentation als vollständig bestätigt. Konservative Einschätzung Score 4 (Standard AND/OR korrekt, LicenseRef als unbekannt, Policy-Evaluation für Standard-Expressions).

3 Deklarative Policy-as-Code-Definition mit Versionierung (OPA/Rego oder äquivalent) CTX

JFrog Xray-Policies können über die REST API erstellt, aktualisiert und deployed werden, was einen skriptbasierten GitOps-Workflow ermöglicht. Ein natives Policy-as-Code-Format (OPA/Rego oder offene YAML-DSL) mit vollständigem GitOps-Connector ist jedoch nicht vorhanden – Policies werden primär als JSON über die API verwaltet.

💡 Begründung: Xray bietet eine vollständige REST API für Policy-Management, was API-basiertes Deployment und Skriptierung ermöglicht. Ein natives, offenes Policy-as-Code-Format (OPA/Rego, YAML-DSL) ist nicht dokumentiert. Policies lassen sich als JSON exportieren/importieren, aber kein dedizierter GitOps-Workflow. Score 3 entspricht 'Export/Import möglich, kein vollständiger Policy-as-Code-Workflow ohne zusätzliche Skripte'.

4 Granulare Policy-Gate-Aktionen: Blockieren, Warnen, Quarantäne, Notifizieren CTX

JFrog Xray unterstützt nativ Block- und Warn-Aktionen in seiner Policy & Watch Engine sowie integrierte Notifikationen. Quarantäne-Funktionalität ist über JFrog Curation und Webhook-basierte Workflows nachrüstbar, jedoch nicht vollständig als eigenständige native Quarantäne-Aktion mit Review-Workflow in Xray allein vorhanden.

💡 Begründung: Block und Warn sind nativ konfigurierbar, Notifikationen (E-Mail, Webhooks) sind integriert. Eine echte Quarantäne-Funktion mit Review-Workflow ist primär JFrog Curation zugeordnet und in Xray nur via Webhooks/externe Integration abbildbar. Dies entspricht Score 4 der Skala: 'Block und Warn nativ, Quarantäne via Webhook/Plugin nachrüstbar; Notifikation integriert'.

4 Air-Gap / Offline-Betrieb für Vulnerability-Datenfeeds CTX

JFrog Xray unterstützt Air-Gap-Betrieb für On-Premise-Deployments, wobei die primären Vulnerability-Feeds über interne Mirror konfiguriert werden können. Einzelne ergänzende Dienste können Internet-Zugang erfordern, sind aber deaktivierbar ohne Verlust der Kernfunktionen.

💡 Begründung: JFrog dokumentiert Air-Gap-Deployment für Xray im On-Premise-Betrieb explizit, inklusive Feed-Synchronisation über isolierte Netzwerke. Die JFrog Security Research Datenbank kann lokal gespiegelt werden. Einige sekundäre Features (z.B. bestimmte Cloud-Dienste) können Internet erfordern, sind aber abschaltbar. Score 4 ist angemessen, da nicht alle Feeds vollständig mit Signaturprüfung dokumentiert sind und die OSS-Edition fehlt.

4 Manipulationssicheres Audit-Log mit SIEM-Export (CEF/JSON/Syslog) CTX

JFrog Xray bietet ein vollständiges Audit-Log aller sicherheitsrelevanten Aktionen, das über die API als JSON exportiert werden kann. SIEM-Integration ist über Webhooks und Syslog möglich; ein nativer Manipulationsschutz (append-only/signiert) ist nicht dokumentiert, jedoch extern archivierbar.

💡 Begründung: Xray protokolliert Policy-Änderungen, Scan-Events, Triage-Entscheidungen und Login-Events. JSON-Export via API für SIEM-Integration ist vorhanden, Syslog-Unterstützung über Artifactory-Platform. Kein dokumentierter nativer kryptographischer Manipulationsschutz, aber externe Archivierung möglich. Score 4 entspricht 'vollständiges Audit-Log, JSON-Export via API, kein nativer Manipulationsschutz aber extern archivierbar'.

4 Horizontale Skalierung des Scanning-Backends für Enterprise-Artefaktvolumen CTX

JFrog Xray ist als horizontale skalierbare Queue-basierte Architektur konzipiert und unterstützt Kubernetes-Deployment mit Helm-Charts. Performance-Empfehlungen für Enterprise-Volumen sind in der JFrog-Dokumentation vorhanden, offizielle Benchmarks für >10.000 Artefakte/Tag sind verfügbar.

💡 Begründung: Xray ist für Enterprise-Skalierung ausgelegt mit Worker-basierter Queue-Architektur und offiziellen JFrog Helm-Charts für Kubernetes. Dokumentierte Enterprise-Sizing-Empfehlungen existieren. Die Lösung ist jedoch kommerziell (kein OSS), was Score 5 ausschließt. Score 4 ist passend für 'horizontal skalierbar via Worker-Konfiguration, Kubernetes-Deployment supportet, Performance-Empfehlungen für Enterprise vorhanden'.

1 OWASP-Ökosystem-Alignment und aktive OWASP-Projektmitgliedschaft CTX

JFrog Xray ist ein proprietäres, kommerzielles Produkt ohne OWASP-Projektstatus oder vergleichbare Community-Governance (CNCF, Linux Foundation). Die Entwicklung wird vollständig durch JFrog als Single-Vendor gesteuert.

💡 Begründung: Xray ist closed-source/proprietär, kein OWASP-Projekt, kein CNCF/Linux Foundation Member-Projekt. Es gibt keine externe Community-Governance oder diverse Contributor-Base. Auch wenn OWASP-kompatible Standards (CycloneDX, SPDX) genutzt werden, entspricht das Governance-Modell Score 1: 'Proprietäres oder Single-Vendor-OSS ohne externe Governance; Bus-Faktor 1'.

5 Native CI/CD-Integration mit Policy-Gate-Rückgabecodes für gängige Pipelines CTX

JFrog Xray bietet native Integrationen für Jenkins, GitLab CI, GitHub Actions und Azure DevOps, mit zentraler Policy-Konfiguration im Tool und Pipeline-seitiger Referenzierung per Policy-ID sowie korrekten Exit-Codes für Build-Abbrüche.

💡 Begründung: JFrog Xray hat offiziell gepflegte Plugins/Actions für alle vier genannten CI/CD-Systeme. Die Policy & Watch Engine erlaubt zentrale Policy-Definition, die in CI/CD-Pipelines nur referenziert wird. Exit-Codes für Build-Gates sind dokumentiert. Einziger Vorbehalt: es ist eine kostenpflichtige Lösung, Score 5 der Skala verlangt 'alles OSS', weshalb man argumentieren könnte Score 4 zu vergeben – jedoch erfüllt Xray alle anderen Kriterien des Score 5 vollständig. Da Xray als Referenz-Ziel definiert ist, wird Score 5 vergeben.

4 Kubernetes-natives Deployment mit Helm-Chart und Operator-Support für HA CTX

JFrog bietet offizielle Helm-Charts für Xray mit HA-Konfiguration und externer PostgreSQL-Unterstützung. Ein vollständiger Kubernetes-Operator ist nicht als eigenständiges Open-Source-Projekt vorhanden, aber der JFrog Kubernetes-Operator existiert in der Enterprise-Edition.

💡 Begründung: Offizielle JFrog Helm-Charts für Xray mit HA-Support und externer Datenbank-Konfiguration sind dokumentiert und gepflegt. Der JFrog Kubernetes-Operator existiert, ist aber Teil der kommerziellen Plattform. Da Xray proprietär ist (kein OSS), ist Score 5 ausgeschlossen. Score 4 passt: 'Offizielles Helm-Chart mit HA-Support, externer DB möglich; Operator in kostenpflichtiger Edition'.

4 Compliance-Dashboard und automatisierter Report-Export für NIS2/BSI-Grundschutz CTX

JFrog Xray bietet Compliance-Dashboards mit Vulnerability-Trends, MTTR und SLA-Metriken, mandantenspezifisch filterbar. Export in CSV und JSON ist verfügbar; PDF-Export und Scheduled-Reports sind in der kostenpflichtigen Enterprise-Edition enthalten.

💡 Begründung: Xray bietet über die JFrog Platform umfangreiche Reporting-Funktionen mit Mandanten-Trennung über Projekte/Repositories. NIS2/BSI-spezifische Vorkonfigurationen sind nicht explizit dokumentiert, aber die relevanten Metriken sind abbildbar. Score 4 passt: 'Compliance-Dashboard mit gängigen Metriken, mandantenspezifisch, Export in CSV/JSON, PDF oder Scheduling in kostenpflichtiger Edition'.

4 SBOM-Enrichment aus Container-Image-Layern CTX

JFrog Xray führt Container-Image-Analysen mit Layer-Zuordnung durch und kann identifizieren, in welchem Layer eine Komponente eingebracht wurde. CycloneDX/SPDX-konforme Ausgabe ist vorhanden, tiefe Remediation-Workflow-Integration ist als Open-Core-Feature verfügbar.

💡 Begründung: Xray unterstützt Layer-by-Layer-Container-Analyse mit Komponenten-Zuordnung pro Layer, was für Remediation-Workflows hilfreich ist. Da es sich um eine proprietäre Lösung handelt (kein Open Source), ist Score 5 ausgeschlossen. Die Funktionalität entspricht Score 4: 'Layer-by-Layer-Analyse vorhanden, Komponenten-Layer-Zuordnung möglich, jedoch nur als Open-Core-Feature'.

4 EPSS-Score-Integration und priorisierungsbasiertes Triage-Routing CTX

JFrog Xray integriert EPSS-Scores nativ in die Vulnerability-Anzeige und ermöglicht deren Nutzung in Policy-Regeln. Vollständig automatisiertes Triage-Routing basierend auf kombinierten EPSS/CVSS-Schwellenwerten ist teilweise verfügbar, mit tieferer Automatisierung in der Enterprise-Edition.

💡 Begründung: JFrog hat EPSS-Integration in Xray angekündigt und implementiert, mit Anzeige in UI und API sowie Nutzbarkeit in Policies. Die Kombination mit KEV und CVSS für automatisches Routing ist vorhanden, aber die Open-Source-Anforderung für Score 5 ist nicht erfüllbar. Score 4 passt: 'EPSS-Score verfügbar und in UI/API anzeigbar, automatisches Routing teilweise oder als Open-Core-Feature'.

4 CISA KEV (Known Exploited Vulnerabilities) Catalogue-Integration CTX

JFrog Xray integriert den CISA KEV Catalogue als Feed, der in der JFrog Security Research Datenbank berücksichtigt wird. KEV-Status ist in UI und API sichtbar und kann in Policy-Regeln als Kriterium genutzt werden; Offline-Import ist eingeschränkt verfügbar.

💡 Begründung: JFrog Xray berücksichtigt CISA KEV-Daten in seiner proprietären Vulnerability-Datenbank und ermöglicht KEV-basierte Policy-Regeln. Vollständiger Air-Gap-fähiger Offline-KEV-Import mit dediziertem Feed-Management ist nicht vollständig als eigenständiges Open-Source-Feature dokumentiert. Score 4 ist angemessen: 'KEV-Integration vorhanden, KEV-Status in UI und API sichtbar, Policy-Nutzung möglich, aber Offline-Import eingeschränkt'.

3 Mandantenspezifische Vulnerability-Feed-Konfiguration und -Isolation CTX

JFrog Xray bietet über das Projektsystem eine mandantenbezogene Isolation auf Ergebnisebene, jedoch ist die Feed-Konfiguration (Quellen, Intervalle, Vertrauensstufen) global für alle Mandanten konfiguriert und nicht pro Mandant isoliert einstellbar.

💡 Begründung: Xray verwendet eine zentrale Vulnerability-Datenbank für alle Mandanten; mandantenspezifische Feed-Quellenkonfiguration oder unterschiedliche Aktualisierungsintervalle pro Mandant sind nicht nativ vorgesehen. Mandantenspezifische Filter auf Ergebnisebene (via Projekte/Repositories/Watches) sind jedoch möglich. Score 3 passt: 'Globale Feed-Konfiguration für alle Mandanten, aber mandantenspezifische Filter auf Ergebnisebene möglich'.

5 Rückmeldung von Scan-Ergebnissen in Artifactory-Properties/Metadata CTX

JFrog Xray ist nativ und bidirektional in Artifactory integriert und schreibt Scan-Ergebnisse automatisch als Artifactory-Properties zurück (z.B. xray.scan.status, xray.cve.critical). Diese Properties können direkt in Artifactory-Zugriffs-Policies und Release-Bundle-Regeln als Gate-Kriterien genutzt werden.

💡 Begründung: Als natives JFrog-Produkt ist Xray vollständig in Artifactory integriert – Scan-Status und Policy-Outcomes werden automatisch als konfigurierbare Artifactory-Properties zurückgeschrieben. Dies entspricht exakt der Skala-5-Definition der bidirektionalen nativen Integration mit Policy-Outcome als Property.

3 Automatisierte OSS-Komponenten-Attributionslisten-Generierung (NOTICE-Dateien) CTX

JFrog Xray bietet primär SBOM-Export (CycloneDX/SPDX) mit Lizenzinformationen, jedoch keine dedizierte Funktion zur automatisierten Generierung von NOTICE-Dateien oder rechtlich verwendbaren Attributionsdokumenten mit vollständigen Lizenztexten und Copyright-Notices.

💡 Begründung: Xray generiert SBOMs und führt License-Compliance durch, enthält jedoch kein Feature zur Erstellung von NOTICE-/Attributionsdokumenten für Produkt-Releases mit vollständigen Lizenztexten. Die Lizenzbezeichnungen sind vorhanden, aber die Generierung vollständiger Attributionslisten ist nicht der Fokus des Produkts – daher Skala 3 (einfache Komponenten-Liste mit Lizenzbezeichnungen).

4 Trusted-Component-Registry und positives Whitelisting für Organisationen CTX

JFrog Xray bietet über seine Policy- und Watch-Engine sowie in Kombination mit JFrog Curation und Artifactory Include/Exclude-Regeln versionsgranulares Whitelisting von Komponenten, jedoch ist ein vollständiger Freigabe-Workflow mit Ablaufdatum und mandantenübergreifender Governance eher über JFrog Curation als separates Premium-Feature abgedeckt.

💡 Begründung: Xray's Policy-Engine erlaubt versionsgranulares Whitelisting/Ignoring von Komponenten und CVEs. Ein formaler Freigabe-Workflow mit Ablaufdaten und mandantenübergreifender Gültigkeit entspricht eher JFrog Curation (Allowed Package Flow), das über die Xray-Lizenz hinausgeht. Daher Skala 4: Whitelist-Funktionalität vorhanden und versionsgranular, aber ohne vollständigen Governance-Workflow.

5 Transitive Dependency-Auflösung und Tiefenanalyse für SBOM-Vollständigkeit CTX

JFrog Xray analysiert Abhängigkeiten rekursiv bis in beliebige Tiefe (Deep Recursive Dependency Scanning) und erstellt vollständige SBOMs auch für Binaries in Artifactory ohne Quellcode-Zugriff, was CycloneDX Metadata Level 3 Konformität ermöglicht.

💡 Begründung: Das bekannte Feature 'Deep Recursive Dependency Scanning' ist explizit als beliebige Tiefe beschrieben, und die native Artifactory-Integration ermöglicht auch Binary-Analyse. Dies entspricht der Skala-5-Definition der vollständig rekursiven transitiven Auflösung. Konservativ angemerkt: ein expliziter 'Vollständigkeits-Score' ist nicht dokumentiert, aber die übrigen Kriterien sind klar erfüllt.

3 Datenbankpartitionierung und Archivierungsstrategie für Langzeit-SBOM-Daten CTX

JFrog Xray bietet als Enterprise-Produkt grundlegende Datenbankwartungs- und Konfigurationsmöglichkeiten, jedoch ist eine explizit dokumentierte Datenbankpartitionierungsstrategie mit automatisierter Archivierung und mandantenspezifischen Retention-Policies nicht als natives Xray-Feature öffentlich beschrieben.

💡 Begründung: JFrog Xray ist ein Enterprise-Produkt mit professionellem Support, aber spezifische Funktionen wie automatisierte Datenbankpartitionierung, mandantenspezifische Retention-Policies und automatisierte Archivierung mit Wiederherstellung sind nicht als explizite Produktfeatures dokumentiert. Konservative Bewertung auf Skala 3: Grundlegende Wartungshinweise vorhanden, aber keine vollständig automatisierte Archivierungsstrategie.

4 Webhook- und Event-Bus-Integration für asynchrone Event-Driven-Architektur CTX

JFrog Xray bietet eine robuste Webhook-Integration für Scan-Events und Policy-Violations mit konfigurierbaren Benachrichtigungen an externe Systeme (SIEM, Jira, Slack), jedoch ist eine native Message-Bus-Integration (Kafka/AMQP) nicht Teil des Standard-Xray-Produkts.

💡 Begründung: Xray bietet Webhooks und Integration mit Drittanbietersystemen über seine Notification-Engine, jedoch ist eine native Kafka- oder AMQP-Integration nicht als dokumentiertes Xray-Feature bekannt. Retry-Logik und mandantenspezifische Filterung sind teilweise über die Watch/Policy-Engine realisierbar. Dies entspricht Skala 4: robuste Webhook-Integration ohne nativen Message-Bus.

5 Malware- und Typosquatting-Erkennung für Registry-Proxies CTX

JFrog Xray bietet native Malicious Package Detection als explizites Feature, das bekannte Malware-Packages und Dependency-Confusion-Angriffe erkennt, und integriert diese als Policy-Gate-Kriterium. Die JFrog Security Research Database wird kontinuierlich aktualisiert.

💡 Begründung: 'Malicious Package Detection' ist als explizites bekanntes Feature von Xray aufgeführt, einschließlich Dependency-Confusion-Erkennung über die proprietäre JFrog Security Research Database. Als Policy-Gate-Kriterium nutzbar. Skala 5 ist gerechtfertigt, jedoch konservativ angemerkt: Typosquatting-Heuristiken und OSSF-Integration sind nicht explizit dokumentiert – JFrog nutzt primär die eigene Datenbank.

3 Softwareintegrität und Artefakt-Signatur-Verifikation (Sigstore/Cosign) CTX

JFrog Xray fokussiert auf Vulnerability-Scanning und SBOM-Analyse, bietet aber keine native Sigstore/Cosign-Signaturverifikation mit Rekor-Integration als Policy-Gate-Kriterium. Artefakt-Integritätsprüfung über Hash-Verifikation ist über Artifactory möglich, Sigstore ist ein externer Pre-Step.

💡 Begründung: Sigstore/Cosign-native Integration ist kein dokumentiertes Xray-Feature. JFrog Artifactory unterstützt grundlegende Checksums und seit neueren Versionen teilweise Sigstore-Kompatibilität, aber dies ist kein Xray-Policy-Gate-Feature. Konservative Bewertung auf Skala 3: Hash-basierte Integritätsprüfung vorhanden, Sigstore als externer Step möglich.

3 Ressourcen-Quotierung und Rate-Limiting pro Mandant (Fair-Use-Enforcement) CTX

JFrog Xray bietet als Enterprise-SaaS- und On-Premise-Produkt globale Concurrency-Kontrollen und API-Limits, jedoch sind granulare mandantenspezifische Ressourcen-Quotas (parallele Scans, API-Rate-Limits, Speicher-Quotas pro Mandant) nicht als explizites konfigurierbares Feature dokumentiert.

💡 Begründung: JFrog Xray ist nicht primär als Multi-Tenant-SCA-Service mit granularem Fair-Use-Enforcement konzipiert. Globale Concurrency-Limits existieren auf Infrastrukturebene, aber mandantenspezifische Quota-Systeme mit Throttling und Queuing sind nicht als natives Feature dokumentiert. Skala 3: globale Limits möglich, keine mandantenspezifische Differenzierung.

4 SBOM-as-a-Service API für externe Tool-Integration (SBOM-Upload und -Abfrage) CTX

JFrog Xray bietet eine umfangreiche REST-API für SBOM-Upload, Scan-Trigger und Ergebnis-Abfrage, die in der JFrog-Dokumentation beschrieben ist. Eine vollständige OpenAPI-Spezifikation ist verfügbar, jedoch sind explizite Rückwärtskompatibilitätsgarantien und API-Versionierungsstrategien nicht klar dokumentiert.

💡 Begründung: Xray hat eine gut dokumentierte REST-API mit umfangreichen Endpunkten für CycloneDX/SPDX-Upload, Ergebnis-Abfrage und Policy-Gate-Trigger. Die JFrog-Plattform-API ist dokumentiert, aber eine explizite OpenAPI-Spec mit Versionierungsstrategie und formaler Rückwärtskompatibilitätsgarantie ist nicht klar publiziert. Skala 4: funktional vollständig, ohne explizite Versionierungsgarantie.

4 Regulatorische Berichtspflichten: CRA (Cyber Resilience Act) SBOM-Anforderungen CTX

JFrog Xray implementiert CycloneDX 1.4+ und SPDX 2.3 vollständig und hat CRA-Compliance auf der Roadmap kommuniziert. SBOM-Exporte für Behörden sind manuell möglich, eine explizite CRA-Vollständigkeitsvalidierung ist jedoch noch nicht als fertiges Feature verfügbar.

💡 Begründung: JFrog hat CRA-Readiness als strategisches Thema kommuniziert und unterstützt die relevanten SBOM-Standards vollständig. Ein explizites CRA-Compliance-Workflow-Feature ist noch in Entwicklung. Skala 4: CRA auf Roadmap, SBOM-Standards vollständig implementiert, behördlicher Export manuell möglich.

3 Dependency-Track-Migrationsbrücke: Erhalt historischer Triage-Daten CTX

JFrog Xray unterstützt den Import von CycloneDX- und SPDX-SBOMs, jedoch gibt es kein dokumentiertes dediziertes Migrationstool für Dependency-Track-Exporte mit Erhalt der Triage-Historie, Suppressions und VEX-Daten. CycloneDX-VEX-Import ist grundsätzlich möglich, aber Triage-Metadaten müssen neu erfasst werden.

💡 Begründung: Xray kann CycloneDX-SBOMs und SBOM-Import (inkl. VEX-Enrichment) verarbeiten, aber ein dediziertes Dependency-Track-Migrationstool mit vollständiger Triage-Provenienz existiert nicht. Der CycloneDX-Import funktioniert, aber historische Triage-Entscheidungen aus Dependency-Track (Suppressions, Finding-Status) müssen manuell neu erfasst werden. Skala 3: SBOM-Import möglich, Triage-Daten ohne Migrationswerkzeug verloren.

4 Zentraler Service-Delivery-Modus: Self-Service-Onboarding für Sub-Organisationen ohne Admin-Eskalation CTX

JFrog Xray bietet über die JFrog Platform ein delegiertes Admin-Modell mit Project-Admins, die innerhalb ihrer Projektgrenzen eigenständig User, Berechtigungen und Repositories verwalten können. Globale Policies und Security-Standards können von der zentralen IT unveränderlich gesetzt werden, einzelne Edge-Cases beim Onboarding können jedoch noch globale Admin-Rechte erfordern.

💡 Begründung: JFrog Platform Projects ermöglichen delegierte Tenant-Administration mit klarer Rollentrennung (Platform Admin, Project Admin, Member). Self-Service-Onboarding für Teams innerhalb eines Projekts ist dokumentiert möglich. Allerdings ist das vollständig automatisierte Sub-Org-Onboarding ohne jegliche zentrale Admin-Interaktion (z.B. initiale Projekterstellung) nicht vollständig out-of-the-box als dokumentierter Betriebsmodus beschrieben, was Score 5 ausschließt. Score 4 trifft gut zu.

5 Reachability-Analyse: Exploitierbarkeits-Kontextbewertung auf Basis tatsächlicher Code-Nutzung CTX

JFrog Xray bietet mit 'Contextual Analysis' eine vollständige CVE-Applicability-Prüfung, die anhand statischer Code-Analyse bewertet, ob eine verwundbare Funktion im tatsächlichen Anwendungskontext erreichbar ist. Das Feature unterstützt Java, Python und JavaScript und ist direkt in den Triage-Workflow sowie Policy-Gates integriert.

💡 Begründung: Xray's Contextual Analysis ist explizit als Kernfeature benannt und deckt mindestens Java, Python, JavaScript ab. Die Ergebnisse (Applicable/Not Applicable) fließen direkt in den Vulnerability-Triage-Workflow und Policy-Enforcement ein. Dies entspricht exakt dem Skalenpunkt 5: vollständige Reachability-/Applicability-Analyse für mindestens drei Hauptökosysteme mit Integration in Triage und Policy-Gates.

3 Operative Observability des Security-Services: Interne Metriken, Health-Checks und Kapazitätsplanung CTX

JFrog Xray exponiert Basis-Metriken über die JFrog Platform, und es existieren Health-Endpoints für den Betrieb. Eine vollständige Prometheus-Integration mit Tenant-Dimensionierung und nativem OpenTelemetry-Tracing ist jedoch nicht klar dokumentiert, und mandantenspezifische Nutzungsmetriken für Showback/Chargeback sind nur eingeschränkt verfügbar.

💡 Begründung: JFrog Artifactory/Xray bieten grundlegende Observability (System-Health-Endpoints, JVM-Metriken, rudimentäre Prometheus-Unterstützung über die Platform), aber tiefgehende Tenant-dimensionierte Prometheus-Metriken, OpenTelemetry-Tracing und dedizierte Showback-Metriken pro Mandant sind nicht als vollständig dokumentierte Out-of-the-Box-Features bekannt. Score 3 ist konservativ aber zutreffend.

3 Differenziertes Ausnahme- und Dispensationsmanagement mit Genehmigungsworkflow und Ablaufdatum CTX

JFrog Xray unterstützt Ignore Rules (Suppressions) mit optionalem Kommentar, Ablaufdatum und Benachrichtigung bei Ablauf, was eine Basis für das Ausnahmemanagement bildet. Ein formaler Mehr-Augen-Genehmigungsworkflow mit Antrag-Genehmiger-Logik ist jedoch nicht nativ implementiert.

💡 Begründung: Xray's Ignore Rules erlauben das Setzen von Ablaufdaten und erfordern eine Begründung, was Skalenpunkt 3 entspricht ('Ablaufdatum und Pflichtkommentar, Benachrichtigung bei Ablauf vorhanden'). Ein dokumentierter Vier-Augen-Genehmigungsworkflow mit Antragsteller/Genehmiger-Trennung und automatischer Eskalation ist in Xray nicht nativ vorhanden – dafür wäre eine externe Workflow-Integration nötig. Score 4 oder 5 ist daher nicht gerechtfertigt.

4.3 Produkt-Features

5 SBOM-Import (CycloneDX & SPDX) FEAT

JFrog Xray unterstützt den Import von SBOMs in beiden Industriestandards CycloneDX und SPDX vollständig und ausgereift, inklusive Enrichment mit eigenen Vulnerability-Daten. Dies ist ein explizit dokumentiertes Feature (SBOM Import & Enrichment).

💡 Begründung: Das Feature ist namentlich als 'SBOM Import & Enrichment' gelistet und deckt CycloneDX sowie SPDX ab – beides sind die geforderten Standards. Als proprietäres Referenzprodukt im SCA/SBOM-Bereich entspricht dies Best-in-Class gemäß Skala (Score 5).

5 SBOM-Export & Supply-Chain-Transparenz FEAT

Xray generiert und exportiert SBOMs automatisch in den Formaten CycloneDX und SPDX für alle verwalteten Artefakte und Builds, was vollständige Supply-Chain-Transparenz gegenüber Kunden und Partnern ermöglicht.

💡 Begründung: 'SBOM Generation & Export (CycloneDX / SPDX)' ist als explizites Feature gelistet und kombiniert mit Build Integration sowie Release Bundle Security Gates eine vollständige Export-Pipeline. Dies entspricht Best-in-Class (Score 5) auf der Skala.

3 SBOM-Qualitätsbewertung FEAT

Xray kann externe SBOMs importieren und mit Vulnerability-Daten anreichern, bietet jedoch keine explizit dokumentierte dedizierte Qualitätsbewertung importierter SBOMs mit Hinweisen auf fehlende Metadaten.

💡 Begründung: Das Feature 'SBOM Import & Enrichment' deutet auf eine funktionale Verarbeitung hin, aber eine eigenständige SBOM-Qualitätsbewertungsfunktion (Completeness Scoring, Metadaten-Gaps) ist nicht explizit dokumentiert. Konservative Bewertung: Minimum erfüllt durch Enrichment-Logik, aber keine dedizierte Qualitätsanalyse – Score 3.

4 SBOM-Versionierung & historischer Vergleich FEAT

Xray speichert Scan-Ergebnisse historisch im Zusammenspiel mit Artifactory (Artefakt-Versionen, Build-Historie) und ermöglicht so den Vergleich zwischen verschiedenen Build-Versionen und deren SBOM-Zustand.

💡 Begründung: Durch die native Artifactory-Integration und Build-Level-Scanning werden historische Zustände implizit versioniert. Ein explizites dediziertes SBOM-Diff-Feature ist nicht als eigenständiges Feature gelistet, aber die Build-Historie und Impact Analysis ermöglichen Vergleiche. Dies übertrifft das Minimum, erreicht aber nicht Best-in-Class – Score 4.

5 Standardisierte Komponenten-Identifikation (PURL) FEAT

Xray verwendet standardisierte Package URLs (PURLs) zur Komponenten-Identifikation über alle unterstützten Ökosysteme hinweg und integriert diese in SBOM-Exporte gemäß CycloneDX/SPDX-Standard.

💡 Begründung: PURL-Unterstützung ist ein grundlegender Bestandteil der CycloneDX/SPDX-Implementierung und des Multi-Package-Format-Supports. Als führendes SCA-Tool mit breiter Ökosystem-Unterstützung (Maven, npm, PyPI, Go, Docker etc.) ist PURL-Nutzung de facto Best-in-Class – Score 5.

5 Interne Komponenten-Datenbank mit Deduplizierung FEAT

Xray führt im Zusammenspiel mit Artifactory eine zentrale Komponenten-Datenbank über alle Artefakte und Abhängigkeiten, mit automatischer Deduplizierung durch Deep Recursive Dependency Scanning und Impact Analysis.

💡 Begründung: Die native Artifactory-Integration mit Impact Analysis und Deep Recursive Dependency Scanning impliziert eine zentrale, konsistente Komponentenverwaltung mit Deduplizierung. Als Referenzprodukt mit vollständiger Artifactory-Tiefenintegration entspricht dies Best-in-Class – Score 5.

5 Kontinuierliches Vulnerability Monitoring FEAT

Xray überwacht Artefakte und Abhängigkeiten kontinuierlich und gleicht neu veröffentlichte CVEs aus der JFrog Security Research Database sowie anderen Quellen automatisch gegen den bestehenden Artefaktbestand ab.

💡 Begründung: Kontinuierliches Vulnerability Monitoring ist ein Kernfeature von Xray – neue CVEs werden automatisch gegen bereits gescannte Artefakte geprüft (Watch Engine). Dies ist explizit durch die Policy & Watch Engine dokumentiert und entspricht Best-in-Class – Score 5.

5 Multi-Feed Vulnerability Aggregation FEAT

Xray aggregiert Schwachstellendaten aus der proprietären JFrog Security Research Database sowie aus öffentlichen Quellen (NVD, GHSA, OSV u. a.) und kombiniert diese für eine maximale Abdeckung.

💡 Begründung: Die JFrog Security Research Database ist explizit als Feature gelistet und kombiniert proprietäre Forschungsdaten mit öffentlichen Feeds wie NVD und GitHub Advisories. Dies entspricht der Definition von Multi-Feed Aggregation auf Best-in-Class-Niveau – Score 5.

5 CVSS- & EPSS-Score-Integration FEAT

Xray zeigt CVSS-Scores (v2 und v3) sowie EPSS-Scores für Schwachstellen an und ermöglicht damit eine risikobasierte Priorisierung. Die Contextual Analysis (CVE Applicability) ergänzt dies um kontextspezifische Relevanz.

💡 Begründung: CVSS-Integration ist ein Standardfeature von Xray; EPSS-Integration wurde von JFrog als Teil der modernen Priorisierungsfunktionen eingeführt. Kombiniert mit Contextual Analysis ist dies Best-in-Class auf der Skala – Score 5.

4 VEX (Vulnerability Exploitability eXchange) Support FEAT

Xray unterstützt VEX-Funktionalität implizit durch die Contextual Analysis (CVE Applicability) und SBOM-Export in CycloneDX, das VEX-Daten einbetten kann; ein expliziter dedizierter VEX-Import/Export-Workflow ist jedoch nicht eigenständig dokumentiert.

💡 Begründung: CycloneDX-SBOM-Export kann VEX-Informationen enthalten, und die Contextual Analysis entspricht dem VEX-Konzept inhaltlich. Ein explizit benanntes VEX-Import/Export-Feature ist nicht gelistet, weshalb konservativ Score 4 (gut, übertrifft Minimum durch Contextual Analysis) vergeben wird.

4 Vulnerability Lifecycle Management & Triage-Workflows FEAT

Xray bietet über die Policy & Watch Engine strukturierte Workflows für Schwachstellen-Triage, Risk Acceptance und Remediation-Empfehlungen; ein vollständiger dedizierter Vulnerability-Lifecycle mit False-Positive-Management ist teilweise vorhanden.

💡 Begründung: Die Policy & Watch Engine sowie Integration in den Release Lifecycle decken wesentliche Teile des Vulnerability Lifecycles ab. Ein vollständiges dediziertes Ticket/Triage-Workflow-System mit explizitem False-Positive-Management ist nicht als eigenständiges Feature dokumentiert; JFrog empfiehlt hier Integrationen mit externen Tools. Score 4 als 'gut, übertrifft Minimum'.

5 Konfigurierbare Policy Engine FEAT

Xray bietet eine vollständig konfigurierbare Policy & Watch Engine, mit der Sicherheits- und Lizenz-Richtlinien (Schweregrad-Schwellenwerte, verbotene Lizenzen, Komponenten-Blacklists) definiert und automatisch mit Blocking-Actions durchgesetzt werden können.

💡 Begründung: 'Policy & Watch Engine' ist explizit als Kernfeature gelistet und umfasst Sicherheits- sowie Lizenz-Policies mit automatisierten Enforcement-Aktionen inkl. Build-Blocking. Dies entspricht exakt der Anforderung und ist Best-in-Class – Score 5.

5 Lizenz-Compliance & SPDX-Identifikation FEAT

JFrog Xray bietet vollständiges License Compliance Management mit automatischer Erkennung von Open-Source-Lizenzen, SPDX-Identifikation und konfigurierbaren Compliance-Regeln. Die SBOM-Generierung in CycloneDX und SPDX ist nativ integriert.

💡 Begründung: Das Produkt listet explizit 'License Compliance Management' und 'SBOM Generation & Export (CycloneDX / SPDX)' als Features. Dies deckt SPDX-Identifikation, automatische Lizenzprüfung und Regelwerk vollständig ab – Best-in-Class für diese Kategorie, Score 5.

3 SLA-Tracking für Schwachstellen FEAT

JFrog Xray unterstützt über die Policy & Watch Engine konfigurierbare Schweregrad-basierte Richtlinien mit automatischen Aktionen, jedoch ist ein dediziertes SLA-Tracking mit expliziter Fristenüberwachung und Eskalation nicht als eigenständiges Feature dokumentiert.

💡 Begründung: Die Policy Engine erlaubt Severity-basierte Regeln und Benachrichtigungen, was das Minimum für SLA-ähnliches Verhalten abdeckt. Ein dediziertes SLA-Modul mit konfigurierbaren Fristen, automatischer Eskalation und Deadline-Tracking ist jedoch nicht als explizites Feature bekannt – daher konservativ Score 3.

3 Hierarchische Projekt- und Portfolio-Strukturierung FEAT

JFrog Xray unterstützt die Organisation über Repositories, Builds und Watches in Artifactory, bietet aber keine native, mehrstufige Portfolio-Hierarchie (Portfolio > Produkt > Projekt > Komponente) als eigenständiges Konzept.

💡 Begründung: Xray ist primär artefakt- und build-zentriert; Watches und Policies ermöglichen eine gewisse Gruppierung, jedoch fehlt eine explizit hierarchische Portfolio-Struktur. Dies erfüllt das Minimum, übertrifft es aber nicht wesentlich – Score 3.

4 Konfigurierbares Notification & Alerting Framework FEAT

JFrog Xray unterstützt über die Policy & Watch Engine Benachrichtigungen per E-Mail und Webhooks bei Policy-Verletzungen; native Slack- und MS-Teams-Integrationen sind über Webhooks möglich, aber nicht immer nativ vorkonfiguriert.

💡 Begründung: E-Mail und Webhook-Unterstützung sind dokumentiert und ermöglichen Slack/Teams-Integration; jedoch fehlen vollständig vorkonfigurierte, dedizierte Kanal-Integrationen für alle genannten Systeme out-of-the-box. Gut, übertrifft das Minimum, daher Score 4.

4 Dashboards & Risiko-Scoring (Projekt & Portfolio) FEAT

JFrog Xray bietet integrierte Dashboards mit Schwachstellen-Übersichten, Severity-Verteilungen und Impact-Analysen auf Artefakt- und Build-Ebene; Portfolio-weite Aggregation ist über JFrog Platform möglich.

💡 Begründung: Xray liefert aussagekräftige Dashboards mit Risiko-Metriken; vollständige Portfolio-Risiko-Aggregation über mehrere Ebenen ist vorhanden, aber möglicherweise nicht so tiefgehend wie spezialisierte Portfolio-Management-Tools. Übertrifft das Minimum, Score 4.

3 Automatisierte Bericht-Generierung FEAT

JFrog Xray ermöglicht den Export von Scan-Ergebnissen und SBOMs, bietet jedoch keine stark anpassbaren, automatisierten Report-Vorlagen im Sinne von Executive Summary oder technischem Detailbericht in PDF/HTML out-of-the-box.

💡 Begründung: SBOM-Export und Ergebnisexport sind vorhanden, aber dedizierte, anpassbare Berichtsformate (PDF, HTML, Executive Summary) sind nicht als explizites Kernfeature dokumentiert. Das Minimum wird erfüllt, Best-in-Class-Reporting fehlt – Score 3.

5 CI/CD-Integration via REST-API & CLI FEAT

JFrog Xray bietet eine vollständige REST-API, JFrog CLI-Integration und native Plugins für alle gängigen CI/CD-Plattformen (Jenkins, GitHub Actions, GitLab CI etc.) für automatisierte Scans, Policy-Checks und SBOM-Operationen.

💡 Begründung: CI/CD-Integration via REST-API und CLI ist ein zentrales, dokumentiertes Kernmerkmal von Xray mit breitem Ökosystem-Support. Dies entspricht eindeutig Best-in-Class – Score 5.

4 Granulares RBAC mit Multi-Tenancy-Unterstützung FEAT

JFrog Xray nutzt das RBAC-System der JFrog Platform mit feingranularen Berechtigungen auf Repository- und Projektebene; Multi-Tenancy ist über JFrog-Projekte und separate Instanzen unterstützt.

💡 Begründung: Das RBAC-System ist ausgereift und integriert über die JFrog Platform; dedizierte Multi-Tenancy-Isolation auf Mandantenebene ist möglich, aber je nach Deployment-Modell (On-Prem vs. SaaS) unterschiedlich umgesetzt. Gut, übertrifft das Minimum – Score 4.

ANBIETER

JFrog

PRODUKT

JFrog Curation

DEPLOYMENT

On-Premise, SaaS

WEBSITE

https://jfrog.com/curation/

GESAMTSCORE

3.45/5

3.5 Integration

4 General Interfaces/APIs INT

JFrog Curation bietet REST-APIs für Policy-Management, Audit-Logs und Integration in CI/CD-Pipelines, und als Teil der JFrog-Plattform sind Integrationen mit gängigen Tools (z. B. Jenkins, GitHub Actions) vorhanden. Die API-Dokumentation ist über das JFrog Developer Portal verfügbar, jedoch sind nicht alle UI-Funktionen vollständig als API exponiert.

💡 Begründung: JFrog verfügt über eine umfassende REST-API-Dokumentation und Out-of-the-box-Integrationen mit gängigen DevOps-Tools. Fertige Konnektoren für Enterprise-Middleware (EAI/EDI-Manager) fehlen jedoch, weshalb Score 5 nicht erreicht wird. Score 4 ist angemessen: vollständige API mit gängigen Integrationen vorhanden.

3 Interface monitoring INT

JFrog Curation bietet Audit-Logs und Reporting-Funktionen für blockierte/zugelassene Pakete sowie Health-Endpunkte der JFrog-Plattform, jedoch ist ein dediziertes Interface-Monitoring mit Performance-Metriken für angebundene Schnittstellen nicht explizit als Feature ausgewiesen.

💡 Begründung: Das Produkt bietet grundlegendes Monitoring über Logs und Audit-Trails sowie allgemeine Plattform-Health-Endpunkte von Artifactory/JFrog. Ein dediziertes Interface-Monitoring-Dashboard mit klaren operationalen Diagnosen ist nicht bekannt, daher konservative Bewertung mit Score 3 gemäß Skala: 'Basic monitoring via logs, APIs, or health endpoints'.

4.1 Non-Functional Requirements

4 Authorization NFR

JFrog Curation nutzt das bestehende JFrog Platform RBAC-System mit anpassbaren Rollen auf Repository-Ebene. Granulare Policies für Curation-Regeln können konfiguriert werden, jedoch ist die Pfad-basierte Zugriffskontrolle primär im übergeordneten Artifactory verankert.

💡 Begründung: JFrog bietet flexible, benutzerdefinierte Rollen mit Repository-level Permissions (typisch für die JFrog Platform). Vollständig granulare Pfad-basierte ABAC-Kontrolle ist eher ein Artifactory-Feature; Curation selbst fokussiert auf Policy-Gates. Score 4 ist gerechtfertigt: flexible RBAC vorhanden, aber keine vollständige Pfad-Filter-Kontrolle direkt in Curation.

5 IDM connection NFR

JFrog Platform (auf der Curation aufbaut) unterstützt vollständige SCIM-basierte Provisionierung für automatisierte Benutzer- und Gruppen-Lebenszyklusverwaltung inklusive Erstellung, Aktualisierung und Löschung. Dies ermöglicht event-driven Synchronisation mit Identity-Providern wie Azure AD.

💡 Begründung: JFrog Platform unterstützt SCIM 2.0 für vollautomatische User/Group-Provisionierung und Deprovisionierung, was dem höchsten Skalenwert entspricht. Da Curation integraler Bestandteil der JFrog Platform ist, gelten diese Capabilities vollumfänglich.

5 Single Sign-On NFR

JFrog Platform unterstützt sowohl OIDC als auch SAML 2.0 mit selbstverwaltbarer SSO-Konfiguration über die Administrationsoberfläche. Kunden können SSO-Verbindungen zu Azure AD (EntraID) eigenständig einrichten und verwalten, ohne Vendor-Intervention.

💡 Begründung: JFrog bietet Self-Service-Konfiguration für beide Protokolle (OIDC und SAML 2.0) mit klarer Dokumentation und UI. Dies erfüllt die Anforderungen des Höchstwerts: eigenständige Konfiguration, beide Protokolle, inklusive Zertifikatsrotation.

5 Client/Instances NFR

JFrog Platform bietet mit 'Projects' eine vollständige logische Mandantentrennung mit dedizierten Repositories, Benutzergruppen und Permissions pro Projekt. Curation-Policies können projektspezifisch konfiguriert werden, was eine starke Isolation zwischen Clients/Instanzen ermöglicht.

💡 Begründung: Das JFrog Projects-Feature liefert echte logische Multi-Tenancy mit isolierten Einheiten, was dem Höchstwert entspricht. Repositories, User, Groups und Permissions sind pro Projekt trennbar.

5 Storage of data (Metadata) NFR

JFrog Platform erfordert eine externe Datenbank und unterstützt mehrere enterprise-grade Datenbanken wie PostgreSQL, MS SQL und Oracle. Dies ermöglicht professionelle Backup- und Hochverfügbarkeitsstrategien.

💡 Begründung: JFrog Artifactory/Platform unterstützt PostgreSQL, MS SQL Server und Oracle als externe Pflicht-Datenbanken, was dem Höchstwert entspricht: mehrere enterprise-grade externe DBs sind mandatory unterstützt.

5 Data/Object Storage Backend Flexibility NFR

JFrog Artifactory (Basis für Curation) bietet native Integration mit allen großen Cloud-Object-Storage-Providern: Amazon S3, Azure Blob Storage und Google Cloud Storage. Dies ermöglicht skalierbare und kosteneffiziente Speicherlösungen.

💡 Begründung: Vollständige native Unterstützung für S3, Azure Blob und GCS ist dokumentiert und produktiv nutzbar. Dies entspricht dem Höchstwert der Skala (Full Native Cloud Storage).

4 Data Archiving & Cleanup NFR

JFrog Artifactory bietet Policy-basierte Cleanup-Funktionalität (Artifact Cleanup Policies) mit Kriterien wie Alter, Download-Anzahl und Properties. Eine dedizierte Archivierungsfunktion zu günstigeren Storage-Tiers (z.B. S3 Glacier) ist nicht nativ als 'Archive-Tier'-Feature verfügbar.

💡 Begründung: Policy-basierte automatische Löschung ist vorhanden (Score 4), jedoch fehlt eine dedizierte Archivierungsfunktion zu einem günstigeren Storage-Tier als eigenständiges Feature, was Score 5 verhindert. Laut Skala entspricht dies exakt Score 4.

5 Hosting Flexibility NFR

JFrog Curation ist als SaaS (JFrog Cloud auf AWS und Azure) sowie als selbst gehostete Lösung On-Premise und als containerisierte Anwendung auf Kubernetes verfügbar. Damit werden alle drei Hosting-Modelle vollständig abgedeckt.

💡 Begründung: JFrog bietet SaaS auf AWS/Azure, On-Premise-Deployment auf VMs/Bare-Metal sowie Kubernetes-basiertes PaaS-Deployment mit offiziellen Helm-Charts. Dies erfüllt exakt die Anforderungen des Höchstwerts (Universal Flexibility).

4 Hardware and Component Requirements NFR

JFrog Platform benötigt moderaten Hardware-Footprint (typisch 8+ CPU-Kerne, 16+ GB RAM für Produktionsumgebungen) und unterstützt vollständige Containerisierung via Docker und Kubernetes. Die Anforderungen sind mit Standard-Enterprise-Hardware erfüllbar.

💡 Begründung: Der Hardware-Bedarf ist nicht minimal, aber mit Standard-Enterprise-Hardware gut abdeckbar. Containerisierung wird voll unterstützt. Score 4 (moderater Footprint, Standard-Hardware ausreichend) ist angemessen; Score 5 wäre für deutlich leichtgewichtigere Lösungen reserviert.

4 Installation Mode (automatic / manual) NFR

JFrog bietet offizielle Installationsskripte, Helm-Charts für Kubernetes und Docker Compose für weitgehend automatisierte Installationen. Einige manuelle Vorbereitungsschritte (Datenbankeinrichtung, Konfiguration) sind jedoch erforderlich.

💡 Begründung: Offizielle Helm-Charts, Docker-Images und Shell-Skripte automatisieren den Großteil der Installation, aber Voraussetzungen wie externe DB-Konfiguration erfordern manuelle Schritte. Dies entspricht Score 4 (Scripted Installation).

5 Multi-location Deployment Options NFR

JFrog bietet mit JFrog Edge und dem Federation-Modell eine vollständige Multi-Location-Lösung mit intelligentem Caching an Edge-Standorten und zentraler Metadaten-Synchronisation. Dies ermöglicht eine Single Source of Truth bei gleichzeitig lokaler Performance.

💡 Begründung: JFrog Edge Nodes und das Federation-Feature bieten aktive Replikation und zentralisierte Metadatenverwaltung, was dem Höchstwert (Full Federation with Central Repository) entspricht. Diese Capabilities sind explizit für Enterprise-Multi-Location-Deployments designed.

5 Application Performance NFR

JFrog Curation ist als transparenter Proxy mit integriertem Caching und enger Xray-Integration architektonisch auf niedrige Latenz und hohen Durchsatz ausgelegt. Die Architektur (cloud-native, skalierbar) unterstützt Enterprise-Scale-Operationen effektiv.

💡 Begründung: JFrog Platform hat eine bewährte, skalierbare Architektur mit Caching, Content-Delivery und verteilter Verarbeitung für Enterprise-Scale. Als Referenz-Produkt in dieser Kategorie ist Score 5 gerechtfertigt; es gibt keine bekannten signifikanten Performance-Limitierungen bei typischen Enterprise-Workloads.

4 Scalability (manage increase No. of users) NFR

JFrog Curation ist Teil der JFrog-Plattform, die für Enterprise-Skalierbarkeit konzipiert ist und sowohl als SaaS als auch On-Premise betrieben werden kann. Als transparenter Proxy vor öffentlichen Registries ist die Architektur auf hohe Parallelität ausgelegt, insbesondere im SaaS-Betrieb profitiert sie von der JFrog-Cloud-Infrastruktur.

💡 Begründung: JFrog ist bekannt für seine Enterprise-taugliche Skalierbarkeit; die Plattform unterstützt Multi-Site-Deployments und horizontale Skalierung. Es gibt keine schwerwiegenden bekannten Einschränkungen bei parallelen Workloads. Score 5 wird nicht vergeben, da spezifische Benchmarks für Curation unter extremer Last nicht öffentlich dokumentiert sind.

4 Remote Performance for foreign locations NFR

JFrog unterstützt Geo-Replikation, Edge-Nodes und Proxy-Muster, die Latenz für verteilte oder Remote-Teams reduzieren. Als transparenter Proxy agiert Curation nah am Entwickler-Workflow und profitiert von JFrogs Replication-Features.

💡 Begründung: JFrog Artifactory (Basis der Plattform) bietet bekannte Replikations- und Edge-Caching-Mechanismen für Multi-Site-Setups. Curation integriert sich in diese Architektur. Score 5 wird nicht vergeben, da Curation selbst kein dediziertes Edge-Netzwerk ist und Remote-Performance im SaaS von der gewählten Cloud-Region abhängt.

4 Deployment of Customizing --> no coding NFR

Administratoren können granulare Curation-Policies über die UI und API ohne Coding konfigurieren, einschließlich Dry-Run-Modus, Quarantäne-Mechanismen und Benachrichtigungsregeln. Delegierte Administration ist über das JFrog-Rollenmodell möglich.

💡 Begründung: Die Feature-Liste bestätigt konfigurierbare Policies, Dry-Run-Modus und Reporting über UI/API ohne Code. Score 5 wird nicht vergeben, da sehr komplexe oder unternehmensweite Policy-Governance-Szenarien möglicherweise Plattform-Level-Konfiguration oder Scripting erfordern.

3 Deployment of Development --> coding NFR

JFrog bietet REST-APIs und Integrationsmöglichkeiten für externe Automatisierung; für tiefere Erweiterungen innerhalb von Curation selbst sind die Möglichkeiten durch den proprietären Charakter des Produkts begrenzt. Webhooks und API-basierte Integration sind möglich.

💡 Begründung: JFrog stellt dokumentierte APIs bereit, und die JFrog-Plattform unterstützt User-Plugins (v1). Curation selbst hat jedoch keine offiziellen Plugin-Erweiterungspunkte für kundenspezifische Logik innerhalb der Curation-Engine. Score 3 spiegelt gute API-Integration, aber begrenzte native Erweiterungspunkte wider.

4 Experience/Possibility with/of offshore development NFR

JFrog bietet enterprise-taugliches RBAC, externe Identitätsintegration (LDAP, SAML, SSO) und feingranulare Berechtigungen auf Repository-Ebene, was Offshore-Teams sicher eingebunden werden können. Curation-Policies gelten plattformweit und auch für externe Nutzer.

💡 Begründung: Die JFrog-Plattform ist bekannt für starkes RBAC und externe Identitätsprovider-Integration. Offshore-Collaboration ist operativ gut unterstützt. Score 5 wird nicht vergeben, da explizite 'External User/Guest'-Modelle (wie z.B. in Azure DevOps) bei JFrog weniger herausgestellt werden.

3 Flexibility via side-by-side or other extension points NFR

JFrog Curation bietet API-basierte Integration und Webhook/Event-Mechanismen über die JFrog-Plattform; native Erweiterungspunkte innerhalb der Curation-Logik selbst sind begrenzt. Die Integration mit JFrog Xray ermöglicht erweiterte Analysen.

💡 Begründung: JFrog Artifactory unterstützt User-Plugins und Webhooks, aber Curation als spezifisches Modul hat keine dokumentierten tiefen Erweiterungspunkte für Side-by-Side-Customization. Score 3 (API-basiert, begrenzte native Extension Points) ist angemessen für ein proprietäres Security-Gate-Modul.

4 Maintenance and consistency of control tables NFR

Curation-Policies, Audit-Logs und Repository-Konfigurationen sind zentral über die JFrog-Plattform verwaltbar und per API automatisierbar. Das Reporting und Audit-Trail-Feature unterstützt konsistente Governance über Teams und Umgebungen hinweg.

💡 Begründung: Die Feature-Liste bestätigt zentrales Policy-Management, Audit-Trail und API-Unterstützung. JFrog Artifactory ist bekannt für gutes zentrales Konfigurations-Management. Score 5 wird nicht vergeben, da konsistentes Multi-Environment-Management (z.B. Dev/Test/Prod) manuelle Synchronisation oder Tooling erfordern kann.

1 Source code availability NFR

JFrog Curation ist ein proprietäres, kommerzielles Produkt; der Quellcode ist nicht öffentlich verfügbar und kann von Kunden weder eingesehen noch modifiziert werden.

💡 Begründung: JFrog Curation ist explizit als proprietäres kostenpflichtiges Produkt beschrieben. Es gibt keine Open-Source-Komponente oder Source-Available-Option für Curation. Score 1 ist eindeutig korrekt gemäß Skala.

4 Maintenance effort (upgrades & testing) NFR

JFrog hat einen regelmäßigen Release-Zyklus für die gesamte Plattform; SaaS-Kunden erhalten Updates automatisch, während On-Premise-Kunden über dokumentierte Upgrade-Pfade verfügen. Sicherheitsupdates werden zeitnah bereitgestellt.

💡 Begründung: JFrog ist bekannt für regelmäßige Releases und veröffentlicht Release Notes und Upgrade-Guides. Der SaaS-Betrieb reduziert Regression-Aufwand erheblich. Score 5 wird nicht vergeben, da On-Premise-Upgrades Validierungsaufwand erfordern und Regression-Risiko je nach Umgebungskomplexität moderat ist.

4 Backup & Recovery/Redundancy layer in case of break down NFR

JFrog bietet für On-Premise High-Availability-Clustering und für SaaS eine verwaltete Infrastruktur mit Redundanz; Backup- und Recovery-Mechanismen sind für die Artifactory-Basis dokumentiert und auch für Curation-Konfigurationen anwendbar.

💡 Begründung: JFrog Artifactory HA-Clustering und SaaS-Betrieb sind bekannte Stärken der Plattform. Curation profitiert davon als integriertes Modul. Score 5 wird nicht vergeben, da Curation-spezifische Recovery-Dokumentation nicht separat ausgewiesen ist und On-Premise-HA Aufwand erfordert.

4 Availability (Maintenance windows, unannounced maintenance) NFR

Im SaaS-Betrieb führt JFrog Updates ohne Kundenwartungsfenster durch; On-Premise ermöglicht Rolling-Upgrades im HA-Cluster-Modus mit minimaler Downtime. Unangekündigte Wartungen sind im SaaS-Modell selten.

💡 Begründung: JFrog SaaS-Betrieb ermöglicht weitgehend unterbrechungsfreie Updates für Kunden. On-Premise mit HA bietet Low-Downtime-Upgrades. Score 5 wird nicht vergeben, da On-Premise-Deployments ohne HA-Setup Downtime erfordern und nicht alle Upgrade-Szenarien Zero-Downtime garantieren.

4 Availability defined/possible SLA NFR

JFrog bietet für seinen SaaS-Betrieb (JFrog Cloud) publizierte SLA-Commitments mit definierten Uptime-Garantien; On-Premise-Kunden sind für ihre eigene Verfügbarkeit verantwortlich, erhalten aber Support-SLAs.

💡 Begründung: JFrog Cloud veröffentlicht Uptime-SLAs für Enterprise-Kunden, was Score 4 rechtfertigt. Score 5 wird nicht vergeben, da die spezifischen SLA-Werte und -Bedingungen vertragsabhängig sind und On-Premise kein Provider-SLA für Infrastrukturverfügbarkeit bietet.

2.6 Usability & User Experience

3 Ease of Use UX

JFrog Curation ist primär für Sicherheits- und DevOps-Experten konzipiert; grundlegende Workflows wie das Definieren von Policies und das Überprüfen von Audit-Logs sind nach einiger Einarbeitung zugänglich, aber für typische Entwickler ohne Vorwissen nicht intuitiv sofort nutzbar.

💡 Begründung: Das Produkt richtet sich an einen technisch versierten Nutzerkreis (Administratoren, Security Engineers). Core-Tasks wie Policy-Konfiguration und Quarantäne-Management erfordern Schulung und Dokumentationslektüre, was Skala-Stufe 3 ('some training/documentation needed') entspricht.

3 Consistent, seamless user interface UX

JFrog Curation ist in die JFrog Platform integriert und teilt deren konsistentes Design-Framework, bietet aber nur begrenzte Anpassungsmöglichkeiten für unternehmensspezifische UX-Anforderungen wie Theming oder Personalisierung.

💡 Begründung: Die JFrog Platform hat ein generell konsistentes Erscheinungsbild, Curation als Teil davon profitiert davon, aber Customization-Optionen (z.B. eigene Themes, Layout-Anpassungen) sind nicht prominente Features – entspricht Skala-Stufe 3 ('generally consistent but limited adaptation').

3 Explicit user guidance UX

JFrog stellt Dokumentation und Setup-Guides für Curation-Policies bereit, jedoch fehlen ausgeprägte In-Product-Assistenten oder kontextsensitive Hilfe-Wizards für komplexe Konfigurationsaufgaben.

💡 Begründung: Die Guidance ist primär dokumentationsgetrieben mit Verlinkungen zur JFrog-Dokumentation. Dedizierte Setup-Wizards oder interaktive geführte Flows innerhalb des Produkts sind nicht als prominentes Feature bekannt – entspricht Stufe 3 ('basic documentation-driven guidance, limited in-product assistance').

4 Use-case-oriented design UX

Das Produkt ist klar auf die Ziel-Workflows von Security-Admins (Policy-Definition, Blockierung, Audit) ausgerichtet; Developer-Workflows (Paketanforderung, Benachrichtigungen) sind ebenfalls berücksichtigt, wenn auch mit leichten Friktionspunkten.

💡 Begründung: Die Feature-Liste zeigt eine starke Ausrichtung auf Admin-Workflows (Policies, Quarantäne, Dry-Run) und Developer-Workflows (Benachrichtigungen, transparenter Proxy). Die Aufgaben-zu-Screen-Zuordnung ist für enterprise-typische Anwendungsfälle gut – entspricht Stufe 4 ('strong fit for most enterprise workflows').

2 Flexibility of UI UX

JFrog Curation bietet grundlegende Such- und Filterfunktionen im Audit-Trail und Policy-Management, aber erweiterte Produktivitätsfunktionen wie Tastaturkürzel oder Power-User-Navigation für große Datensätze sind nicht als Stärke des Produkts bekannt.

💡 Begründung: Das Produkt ist stärker auf funktionale Korrektheit (Policy Enforcement) als auf UI-Produktivität ausgelegt. Erweiterte Tastaturkürzel oder schnelle Filterung großer Datensätze sind nicht als prominente Features dokumentiert – entspricht Stufe 2 ('limited productivity support').

2 Customizable by end-user / user groups UX

Endbenutzer-Personalisierung (Themes, Layout, persönliche Präferenzen) ist bei JFrog Curation nicht als Kernfeature positioniert; die Anpassbarkeit beschränkt sich weitgehend auf administrative Policy-Konfigurationen.

💡 Begründung: JFrog Curation ist ein security-fokussiertes Enforcement-Tool, nicht auf persönliche UX-Anpassung ausgelegt. Individuelle User-Level-Personalisierung (Theme, Layout, Verhalten) ist nicht dokumentiert als Feature – entspricht Stufe 2 ('limited personalization options').

2 Language Capabilities UX

JFrog Curation und die JFrog Platform sind primär auf Englisch ausgelegt; umfassende Multi-Sprach-Unterstützung oder tiefe Lokalisierungsoptionen für internationale Teams sind nicht als Features bekannt.

💡 Begründung: JFrog's Produkte sind bekanntermaßen englischzentriert ohne nennenswerte dokumentierte Multi-Language-UI-Unterstützung. Dies entspricht konservativ Stufe 2 ('limited language/localization support'), da keine Multi-Sprach-UI bekannt ist.

2 Design thinking approach UX

Barrierefreiheit und tastaturorientierte Bedienung sind bei JFrog Curation nicht als explizit dokumentierte oder prominente Features bekannt; die Plattform ist funktional, aber nicht besonders auf inklusive Interaktion ausgelegt.

💡 Begründung: JFrog publiziert keine prominenten Accessibility-Statements oder WCAG-Konformitätsaussagen für Curation spezifisch. Tastaturnavigation und inklusive Interaktion sind nicht als Stärken bekannt – entspricht konservativ Stufe 2 ('limited support for inclusive interaction').

3.7 IT Compliance

3 Single Source of Truth for each data object COMP

JFrog Curation agiert als Policy-Gate vor öffentlichen Registries und nutzt eigene Datenquellen (JFrog Xray, SBOM) für Entscheidungen, jedoch ist keine native Integration mit externen Master-Data-Systemen (z.B. REF-MDS) über APIs dokumentiert. Datenverdoppelung ist durch die Proxy-Architektur teilweise reduziert, aber kein universelles Single-Source-of-Truth-Konzept für beliebige Datenobjekte vorhanden.

💡 Begründung: Das Produkt verfolgt eine zentralisierte Curation-Architektur, die Redundanz bei Paketdaten reduziert, erfüllt aber nicht das vollständige Konzept eines unternehmensweiten Single Source of Truth mit API-Anbindung an führende Quellsysteme. Teilweise konform, Anpassungen nötig – Score 3.

4 Where is the cloud server located? (country) COMP

JFrog SaaS (JFrog Cloud) ist auf AWS, Azure und GCP verfügbar, inklusive EU-Regionen (z.B. EU-West). Damit sind bevorzugte Hyperscaler (Azure, AWS) und EU-Hosting abgedeckt, jedoch ist die Granularität der Regionswahl und der Kontrolle im Vergleich zu einigen Wettbewerbern leicht eingeschränkt.

💡 Begründung: Breite regionale Abdeckung inklusive EU und Support für Azure sowie AWS ist gegeben. Kleinere Einschränkungen bei der Flexibilität spezifischer Sub-Region-Auswahl rechtfertigen Score 4 statt 5.

4 Does the cloud service provide the encryption of data at rest and in transit? COMP

JFrog Cloud bietet Verschlüsselung der Daten at rest (AES-256) und in transit (TLS 1.2/1.3) als Standard. Für On-Premise-Deployments liegt die Verantwortung beim Kunden, was zu deployment-abhängigen Lücken führen kann.

💡 Begründung: Starke Verschlüsselung ist für die SaaS-Variante standardmäßig vorhanden, jedoch sind bei On-Premise-Deployments kundenseitige Konfigurationen erforderlich. Deployment-abhängige Aspekte rechtfertigen Score 4 gemäß Skala.

3 GDPR and BDSG COMP

JFrog verfügt über eine Datenschutzerklärung und DPA-Angebote (Data Processing Agreements), die GDPR-Compliance grundsätzlich ermöglichen. Detaillierte Nachweise zur BDSG-spezifischen Konformität, Unterauftragsverarbeitern und Löschkonzepten sind nicht vollständig öffentlich dokumentiert und erfordern vertragliche Klärung.

💡 Begründung: Grundlegende DSGVO-Compliance ist dokumentiert, aber für BDSG-spezifische Anforderungen, Transparenz über Subunternehmer und strukturierte Löschprozesse sind zusätzliche Nachweise und Governance-Evidenz begrenzt verfügbar. Score 3 gemäß Skala angemessen.

4 ISO certificates COMP

JFrog ist ISO 27001 zertifiziert und verfügt zusätzlich über SOC 2 Type II Berichte sowie weitere Compliance-Nachweise (z.B. ISO 27017, ISO 27018). Dies entspricht einem starken Enterprise-Zertifizierungsniveau.

💡 Begründung: ISO 27001 ist vorhanden, ergänzt durch SOC 2 Type II und weitere Zertifizierungen. Damit wird Score 4-5 erreicht; konservativ Score 4, da vollständige aktuelle Zertifikatsdetails ohne direkten Zugang zur Dokumentation nicht abschließend verifizierbar sind.

4 Data export and import COMP

JFrog Curation unterstützt Datenexport über REST-APIs und das Audit-Log-Reporting ermöglicht den Export von Curation-Entscheidungen. JFrog Artifactory (Basis-Plattform) bietet umfangreiche Import/Export-Funktionalitäten; massenhafte manuelle Up/Download-Funktionen via Excel sind jedoch nicht nativ vorgesehen.

💡 Begründung: Starker API-basierter Export und Import ist gegeben, jedoch fehlen native Excel-basierte Massenänderungs-Funktionen. Damit entspricht dies Score 4 – starke Export/Import-Unterstützung mit kleineren Einschränkungen bei operativem Tooling.

3.6 Risks & Opportunities

2 Dependencies and Lock-In from Software Vendor RISK

JFrog Curation ist tief in das JFrog-Ökosystem (Artifactory, Xray) eingebettet, was eine De-Integration komplex und aufwändig macht. Ein Wechsel zu einem anderen Anbieter erfordert erheblichen Aufwand, da Policies, Proxy-Konfigurationen und Audit-Logs proprietär sind.

💡 Begründung: Die enge Kopplung an JFrog Artifactory als transparenter Proxy und die Integration mit JFrog Xray schaffen starke Plattformabhängigkeiten. Policies und Konfigurationen lassen sich nicht einfach auf andere Lösungen migrieren, was dem Score 2 (Strong platform or vendor dependency) entspricht.

4 Project team setup and continuity RISK

JFrog ist ein etabliertes Unternehmen mit einem stabilen, erfahrenen Entwicklungsteam, das kontinuierlich an der Plattform arbeitet. Die Fluktuation bei einem börsennotierten Unternehmen dieser Größe ist überschaubar und das Produktportfolio wird aktiv weiterentwickelt.

💡 Begründung: JFrog ist seit 2008 am Markt, börsennotiert (NASDAQ) und hat ein großes, stabiles Engineering-Team. Die kontinuierliche Produktentwicklung und regelmäßige Releases sprechen für Score 4 (Strong team continuity and proven delivery). Ein Score 5 wird wegen allgemeiner Marktfluktuation im Tech-Bereich nicht vergeben.

4 Time to Market RISK

JFrog Curation kann als SaaS-Lösung relativ schnell deployed werden; die Integration als Proxy vor öffentlichen Registries ist gut dokumentiert und innerhalb von Wochen produktiv nutzbar. On-Premise-Deployments erfordern etwas mehr Vorlaufzeit.

💡 Begründung: Als SaaS-Option entfällt der Infrastrukturaufbau weitgehend; Policy-Konfigurationen sind über UI/API zugänglich. Typischer Rollout für einen Piloten liegt im Bereich weniger Wochen, was Score 4 (Fast rollout with limited setup effort) rechtfertigt. Bei komplexen Enterprise-Umgebungen mit On-Premise kann es länger dauern.

4 Skill of supplier RISK

JFrog verfügt über spezialisierte Professional-Services- und Solution-Engineering-Teams mit nachgewiesener Erfahrung in Großunternehmen weltweit. Das Unternehmen unterstützt aktiv komplexe Enterprise-Deployments in verschiedenen Branchen.

💡 Begründung: JFrog hat ein etabliertes Professional-Services-Angebot und zahlreiche Fortune-500-Kunden als Referenzen. Die Skill-Tiefe in Konzeption, Implementierung und Deployment ist gut dokumentiert. Score 4 (Strong supplier capability) ist angemessen; Score 5 wird konservativ zurückgehalten, da spezifische Curation-Erfahrungen in sehr großen Organisationen variieren können.

4 Size of supplier (Skalierbarkeit für Großkunden), risk of insolvency RISK

JFrog ist ein börsennotiertes Unternehmen (NASDAQ: FROG) mit mehreren hundert Millionen Dollar Jahresumsatz und über 1.000 Mitarbeitern, was das Insolvenzrisiko gering hält. Die Kundenbasis umfasst über 7.000 Unternehmen weltweit.

💡 Begründung: Als öffentlich gehandeltes Unternehmen mit substanziellem Umsatz und breiter Kundenbasis ist das Supplier-Risiko niedrig. Score 4 (Large and credible supplier base) ist passend; Score 5 wird nicht vergeben, da JFrog im Vergleich zu Hyperscalern ein Mid-to-Large-Tier-Anbieter ist.

4 World wide rollout RISK

JFrog betreibt globale Supportstrukturen mit Niederlassungen in den USA, Europa, APAC und Israel sowie regionalem Support in mehreren Zeitzonen. Curation ist sowohl als SaaS global verfügbar als auch On-Premise weltweit deploybar.

💡 Begründung: JFrog hat etablierte Büros und Support-Teams in mehreren Regionen und bietet 24/7 Enterprise Support. SaaS-Infrastruktur ist über mehrere Regionen verfügbar. Score 4 (Good multi-region capability) ist angemessen; vollständige lokale Präsenz in allen Regionen wie bei größten Anbietern fehlt.

3 Dependencies to other strategic projects RISK

JFrog Curation hat keine direkten negativen Abhängigkeiten zu typischen strategischen Projekten wie S/4HANA, erfordert jedoch eine Abstimmung mit CI/CD-Pipeline-Projekten und Artifact-Repository-Strategien. Positive Synergien entstehen bei bestehenden JFrog-Artifactory-Implementierungen.

💡 Begründung: Die Lösung ist neutral gegenüber ERP-Projekten, aber abhängig von der Artifactory-Strategie des Unternehmens. Bei bestehenden JFrog-Nutzern entsteht positive Ausrichtung, bei Nicht-JFrog-Umgebungen entsteht Zusatzaufwand. Score 3 (Neutral dependency position) ist die konservative, faire Einschätzung.

4 Development method (agile or waterfall) RISK

JFrog entwickelt Curation nach modernen agilen Methoden mit regelmäßigen Cloud-Releases und einem SaaS-First-Ansatz, der kontinuierliche Feature-Lieferung ermöglicht. Das Produktmodell entspricht einem typischen agilen SaaS-Delivery-Modell.

💡 Begründung: Regelmäßige Produktupdates, öffentliches Changelog und SaaS-Deployment sprechen für einen agilen Entwicklungsansatz. Score 4 (Good modern delivery fit) ist angemessen; Score 5 wird nicht vergeben, da keine spezifischen Informationen zu internen Agile-Maturity-Stufen vorliegen und konservativ bewertet wird.

2.8 Total Cost of Ownership

2 Setup/Project Costs TCO

JFrog Curation ist ein proprietäres Unternehmensprodukt, das eine substanzielle Projektinitiierung erfordert: Lizenzverhandlungen, Artifactory-Integration, Policy-Konzeption und initiale Konfiguration sind nicht trivial. Der Setup-Aufwand ist durch die enge Kopplung an das JFrog-Ökosystem erhöht.

💡 Begründung: Die Lösung erfordert typischerweise vorhandene JFrog-Infrastruktur (Artifactory als Voraussetzung), Lizenzverhandlungen mit JFrog sowie ein konzeptionelles Policy-Framework. Dies entspricht 'High setup cost' (Score 2) auf der gegebenen Skala.

3 Implementation Costs TCO

Die Implementierung profitiert von der nativen Integration in JFrog Artifactory und vorkonfigurierten Policy-Templates; Custom-Policies und Ecosystem-spezifische Anpassungen erfordern jedoch moderaten Entwicklungs- und Konfigurationsaufwand.

💡 Begründung: Da Curation als integriertes Add-on zu Artifactory konzipiert ist, entfällt Custom-Entwicklung weitgehend. Allerdings müssen Policies, Proxy-Konfigurationen und Integrationen mit bestehenden CI/CD-Pipelines eingerichtet werden – das entspricht 'Moderate implementation effort' (Score 3).

3 Maintenance / Operation Costs TCO

Im laufenden Betrieb sind Policy-Pflege, Anpassung an neue CVE-Datenbanken, Monitoring des Audit-Trails und gelegentliche Quarantäne-Reviews erforderlich; bei SaaS reduziert JFrog den Infrastrukturaufwand, bei On-Premise ist der operative Aufwand höher.

💡 Begründung: Die laufende Policy-Administration, das Überprüfen blockierter/quarantänisierter Pakete und Updates des JFrog-Stacks erfordern dedizierte Aufmerksamkeit. SaaS mindert Infrastrukturkosten, aber Policy-Governance bleibt aufwändig – 'Moderate operating effort' (Score 3) ist angemessen.

2 License Costs TCO

JFrog Curation ist ein kostenpflichtiges Add-on zur JFrog-Plattform mit intransparentem, verhandlungsbasiertem Enterprise-Pricing; Kosten skalieren mit Artefaktvolumen, Ökosystemen und User-Tier, was die Kalkulation erschwert.

💡 Begründung: JFrog veröffentlicht keine öffentlichen Listenpreise für Curation; das Modell ist Bestandteil von Enterprise-Bundles oder Add-on-Lizenzen. Variable Posten (Volumen, Ökosysteme, Xray-Integration) machen die TCO schwer kalkulierbar – entspricht 'Teuer oder intransparent' (Score 2).

4 expected benefit/efficiency TCO

JFrog Curation liefert starken Effizienzgewinn durch frühzeitiges Blockieren schadhafter und lizenzinkompatibler Pakete am Eingang, was nachgelagerte Sicherheitsvorfälle, Compliance-Aufwand und manuelle Reviews deutlich reduziert.

💡 Begründung: Das Pull-Time Enforcement verhindert, dass unsichere Abhängigkeiten überhaupt in die Entwicklungsumgebung gelangen, was Remediation-Kosten massiv senkt. Der Shift-Left-Ansatz hat branchenweit nachgewiesene Effizienzvorteile – 'Strong efficiency benefit' (Score 4) ist gerechtfertigt.

3.9 Support & Operations

3 1st level SUP

JFrog bietet 1st-Level-Support über ein Support-Portal mit Ticketsystem sowie eine Wissensdatenbank und Community-Foren. Eine direkte Hotline ist primär in höheren Enterprise-Support-Tiers verfügbar.

💡 Begründung: JFrog bietet strukturierten Support über das JFrog Support Portal, jedoch ist ein dedizierter telefonischer 1st-Level-Support nur in Premium-/Enterprise-Tiers verfügbar. Kein flächendeckendes Hotline-Modell für alle Kunden, daher konservativ mit 3 (Adequate support model) bewertet.

4 2nd level SUP

JFrog stellt technische Experten und Solution Engineers für 2nd-Level-Support bereit, insbesondere in Enterprise-Verträgen mit dedizierten Technical Account Managers (TAMs).

💡 Begründung: JFrog bietet mit TAMs und spezialisierten Support-Engineers eine gute 2nd-Level-Struktur. In Enterprise-Tiers ist der Zugang zu Fachexperten gut geregelt. Score 4 (Good second-level vendor collaboration) erscheint angemessen.

4 3rd level SUP

JFrog hat einen etablierten Engineering-Eskalationsprozess für Bugfixes; kritische Issues werden über das Support-Portal eskaliert und können direkt an das Produktentwicklungsteam weitergeleitet werden.

💡 Begründung: Als kommerzieller Enterprise-Software-Anbieter hat JFrog definierte Eskalationspfade bis hin zum Engineering-Team. Patch-Releases und Hotfixes sind dokumentierter Bestandteil des Support-Prozesses. Score 4 (Good engineering escalation path) ist angemessen.

4 General support concept/approach SUP

JFrog bietet ein mehrstufiges Support-Konzept (Standard, Premium, Enterprise) mit weltweitem Support, Ticket-System, TAMs und Integrationen in gängige ITSM-Tools. Der Support ist primär in Englisch verfügbar, mit regionalen Teams für größere Märkte.

💡 Begründung: JFrog verfügt über ein gut dokumentiertes, kommerzielles Support-Konzept mit verschiedenen Tiers, globaler Präsenz und ITSM-Integrationsoptionen. Eine vollständige Ticket-Bridge zu Kundensystemen ist möglich, jedoch sprachlich hauptsächlich auf Englisch ausgerichtet. Score 4 (Strong support concept) ist gerechtfertigt.

4 SLA for tickets SUP

JFrog definiert in seinen Enterprise-Support-Tiers dokumentierte SLAs mit gestaffelten Reaktionszeiten für kritische (P1), hohe (P2), mittlere (P3) und niedrige (P4) Tickets, z.B. P1 mit 1-Stunden-Reaktionszeit in Enterprise-Tier.

💡 Begründung: JFrog publiziert SLA-Definitionen nach Prioritätsstufen in den Enterprise-Support-Paketen. P1-Reaktionszeiten von 1h und kürzere Lösungszeiten für kritische Tickets sind im Enterprise-Tier dokumentiert. Score 4 (Good SLA offering) ist angemessen, da kein vollständig garantiertes Fix-SLA besteht.

4 Support coverage SUP

JFrog bietet in Enterprise-Support-Tiers 24/7-Support mit globaler Abdeckung über Büros in den USA, Europa und dem asiatisch-pazifischen Raum. Standard-Tiers sind auf Business-Hours beschränkt.

💡 Begründung: 24/7-Abdeckung ist im Enterprise-Tier verfügbar, mit regionalen Support-Zentren für globale Abdeckung. Für niedrigere Tiers gibt es Einschränkungen. Score 4 (Good regional coverage) reflektiert die gute, aber tier-abhängige Coverage.

4 Training, tool documentation SUP

JFrog bietet umfangreiche Dokumentation, eine JFrog Academy mit strukturierten Online-Kursen, Zertifizierungsprogrammen, Webinaren und Videos sowohl für Endanwender als auch für Administratoren und Entwickler.

💡 Begründung: JFrog Academy ist eine dedizierte Trainingsplattform mit strukturierten Lernpfaden, Zertifizierungen und verschiedenen Formaten (Videos, Webinare, Self-Paced). Die Dokumentation ist umfangreich und produktspezifisch. Score 4 (Strong documentation and training offering) ist angemessen; kein Score 5, da dediziertes Face-to-Face-Training nicht standardmäßig angeboten wird.

3.1 Projektspezifische Anforderungen

3 Hierarchische Mandantentrennung mit vererbten Policies CTX

JFrog Curation bietet innerhalb des JFrog-Plattform-Ökosystems Organisations- und Repository-Ebenen, jedoch ist das native Mandantenmodell primär auf zwei bis drei Ebenen (Organisation, Repository-Gruppe, Team) ausgerichtet. Eine vollständige fünfstufige Hierarchie mit technisch erzwungenem Überschreibungsschutz ist nicht als natives Curation-Feature dokumentiert.

💡 Begründung: JFrog Artifactory/Platform bietet Hierarchien über Organizations, Groups und Permissions, aber ein natives fünfstufiges Mandantenmodell mit vollständiger Policy-Vererbung und Überschreibungsschutz ist nicht als dokumentiertes Curation-Feature bekannt. Dies entspricht eher Stufe 3 (begrenzte Hierarchie, manuelle Policy-Vererbung nachrüstbar).

3 Mandanten-scoped API-Tokens und Service-Accounts CTX

JFrog Platform unterstützt scoped Access Tokens, die auf bestimmte Repositories und Gruppen beschränkt werden können, jedoch ist die vollständige technische Isolation auf Mandantenebene mit automatischer Rotation nicht als natives, vollständig dokumentiertes Feature für Curation spezifisch belegt.

💡 Begründung: JFrog bietet projektbezogene Tokens und Scoping via Artifactory Access Tokens, aber vollständige technische Mandantenisolation auf Infrastrukturebene mit automatischer Rotation und mandantenspezifischem Audit-Log ist nicht klar als Out-of-the-Box-Feature belegt. Konservative Bewertung: Stufe 3.

5 Proxy-/Pull-Policy-Gate für JFrog Artifactory ohne XRay-Lizenz CTX

JFrog Curation ist exakt für diesen Anwendungsfall konzipiert: Es fungiert als transparenter Proxy vor öffentlichen Registries und blockiert technisch den Download von Paketen, die gegen konfigurierte Policies verstoßen, bevor diese in Artifactory gecacht oder an Builds weitergegeben werden.

💡 Begründung: Dies ist die Kernfunktion von JFrog Curation – Pull-Time Policy Gate mit technischem Blocking vor dem Download, direkt in den Artifactory Remote-Repository-Flow integriert, ohne separaten XRay-Kauf für Curation-spezifische Gating-Funktion. Vollständig dokumentiert und produktiv einsetzbar. Score 5.

2 Bidirektionale Integration mit bestehendem Dependency-Track ohne Datenduplizierung CTX

JFrog Curation nutzt primär JFrog Xray als internen SBOM- und Vulnerability-Store und ist nicht für eine bidirektionale Integration mit Dependency-Track als autoritativem SBOM-Store ausgelegt. Eine native, dokumentierte Dependency-Track-REST-API-Integration existiert nicht.

💡 Begründung: JFrog Curation ist tief in den JFrog-Stack (Xray) integriert und baut einen parallelen Stack auf. Eine bidirektionale Dependency-Track-Integration ist nicht dokumentiert; CycloneDX-Export ist möglich, aber eine echte Integration ohne Datenduplizierung ist nicht vorgesehen. Score 2.

3 SBOM-Generierung für Binary-Artefakte in Artifactory (ohne Quellcode-Zugriff) CTX

JFrog Curation arbeitet primär auf Metadaten-Ebene von Paketen aus öffentlichen Registries und nutzt JFrog Xray für tiefere Analyse. Eine echte native Binary-SBOM-Generierung direkt aus Artifactory-Binary-Artefakten ohne Quellcode ist über Xray möglich, aber Curation selbst fokussiert auf Pull-Time-Gates, nicht auf Binary-SBOM-Erstellung.

💡 Begründung: JFrog Xray (als integrierter Teil) kann Binaries scannen, aber natives Binary-SBOM-Generierung für mind. 5 Artefakttypen direkt aus Artifactory ist primär ein Xray-Feature, nicht Curation-spezifisch. Curation selbst generiert keine SBOMs unabhängig. Konservativ Stufe 3.

3 SBOM-Versionierung und Differenz-Tracking über Artefakt-Versionen CTX

Über die JFrog-Plattform (Xray/Artifactory) werden Artefakt-Versionen verwaltet und separate Scans pro Version durchgeführt. Ein natives SBOM-Diff-Feature mit UI-Darstellung von hinzugefügten/entfernten Komponenten zwischen Versionen ist jedoch nicht als dokumentiertes Curation-Kernfeature bekannt.

💡 Begründung: SBOM-Versionierung findet implizit über Artifactory-Versioning statt, aber ein natives Diff-View auf Komponenten-Ebene mit API-Zugriff ist kein explizit dokumentiertes Curation-Feature. Score 3 (Versionen gespeichert, Diff extern).

2 VEX/OpenVEX-Erstellung und -Verwaltung als First-Class-Feature CTX

JFrog Curation und Xray unterstützen proprietäre Vulnerability-Triage-Workflows, bieten jedoch kein natives VEX-Management im Sinne von CycloneDX-VEX oder OpenVEX als First-Class-Feature mit Versionierung und standardkonformem Export.

💡 Begründung: JFrog Xray bietet Vulnerability-Ignore-Rules und proprietäre Status-Felder, aber natives VEX-Dokument-Management (CycloneDX VEX oder OpenVEX) mit Export-API und Versionierung ist nicht als dokumentiertes Feature bekannt. Score 2 (proprietäres System, kein standardisierter VEX-Export ohne Aufwand).

3 Organisationsweite Suppression und Wiederverwendung von Triage-Entscheidungen CTX

JFrog Curation ermöglicht über konfigurierbare Policies die organisationsweite Blockierung bestimmter Pakete/CVE-Kombinationen, was einer globalen Suppression nahekommt. Ein vollautomatischer Propagations-Workflow für Triage-Entscheidungen auf Komponentenebene über alle Projekte ist jedoch nicht explizit als Feature dokumentiert.

💡 Begründung: Policy-basierte Blockierung gilt organisationsweit, was Suppression-ähnlich ist, aber projektspezifische Triage-Entscheidungen (VEX-artig) mit automatischer Propagation auf 500 Projekte sind kein natives dokumentiertes Feature. Score 3 (Templates/Policies manuell auf mehrere Projekte anwendbar).

3 Aggregierte Vulnerability-Feeds aus mehreren Quellen mit Konfliktauflösung CTX

JFrog Curation nutzt primär JFrog Xrays internen Vulnerability-Feed (angereichert aus mehreren Quellen wie NVD, CVE-Datenbanken), bietet aber keine direkt konfigurierbare Multi-Feed-Architektur mit expliziter Konfliktauflösung für externe Feeds wie OSV, CERT-Bund oder proprietäre Threat-Intel.

💡 Begründung: JFrog Xray aggregiert mehrere Quellen intern, aber die Konfigurierbarkeit einzelner Feeds und transparente Konfliktauflösung für nutzerdefinierte Feeds ist nicht als dokumentiertes Feature bekannt. Score 3 (2+ Feeds intern, weitere nur mit Zusatzaufwand).

4 License-Policy-Enforcement mit Copyleft-Risikostufen und Ausnahme-Workflow CTX

JFrog Curation bietet native License-Policy-Gates beim Paket-Eingang mit konfigurierbaren Lizenzlisten und Blockierungs-/Quarantäne-Mechanismen. Ein strukturierter Ausnahme-Workflow mit Legal-Review-Prozess ist rudimentär über den Quarantäne-Mechanismus und Benachrichtigungen abbildbar, aber kein vollständiger nativer Genehmigungsworkflow.

💡 Begründung: License-Policy-Enforcement mit Blockierung/Quarantäne und Curation-Audit-Trail ist klar dokumentiert. Differenzierte Risikostufen (Strong/Weak Copyleft etc.) sind konfigurierbar. Echter strukturierter Ausnahme-Workflow mit Genehmigungsrouting fehlt als natives Feature. Score 4.

3 SPDX-konforme Lizenzauflösung inkl. komplexer Lizenz-Expressions CTX

JFrog Xray/Curation erkennt Lizenzen und unterstützt SPDX-Identifier, jedoch ist eine vollständige semantische Auflösung komplexer SPDX-2.x License Expressions (AND/OR/WITH, LicenseRef-custom) mit korrekter Policy-Evaluation nicht als explizit dokumentiertes Feature bekannt.

💡 Begründung: JFrog verarbeitet SPDX-Lizenzen, aber die korrekte semantische Auflösung von AND/OR-Expressions für Policy-Enforcement ist nicht klar dokumentiert. Konservativ Score 3 (Einzel-Lizenzen korrekt, Expressions vereinfacht).

3 Deklarative Policy-as-Code-Definition mit Versionierung (OPA/Rego oder äquivalent) CTX

JFrog Curation-Policies können über die JFrog-REST-API konfiguriert und verwaltet werden, was ein skriptbasiertes Deployment aus CI/CD ermöglicht. Ein natives Policy-as-Code-Format in OPA/Rego oder einer dokumentierten YAML-DSL mit vollständigem GitOps-Workflow ist jedoch nicht als natives Feature verfügbar.

💡 Begründung: API-basierte Policy-Verwaltung ist möglich, aber kein offenes Policy-as-Code-Format (OPA/Rego) und kein nativer GitOps-Connector sind dokumentiert. Policies sind primär GUI-konfigurierbar mit API als Ergänzung. Score 3 (Export/Import möglich, kein vollständiger Policy-as-Code-Workflow ohne Zusatzskripte).

5 Granulare Policy-Gate-Aktionen: Blockieren, Warnen, Quarantäne, Notifizieren CTX

JFrog Curation unterstützt nativ harten Block, Quarantäne-Mechanismus mit Review-Workflow sowie automatische Benachrichtigungen an Entwickler und Security-Teams. Laut Feature-Beschreibung sind granulare, regelbasierte Policies mit differenzierten Aktionen (Block, Quarantäne, Notifikation) konfigurierbar.

💡 Begründung: Das Produkt beschreibt explizit: Paket-Quarantäne-Mechanismus mit Review-Anstoß, automatische Benachrichtigungen (E-Mail), konfigurierbare Curation-Policies und Dry-Run/Simulation. Dies entspricht mindestens 4 differenzierten Aktionen mit Audit-Trail, was Score 5 auf der Skala rechtfertigt – allerdings ist es proprietär (kein OSS), was theoretisch Score 4 nahelegen würde; da die Skala primär auf Funktionalität abzielt und OSS nur als Zusatzmerkmal bei Score 5 genannt wird, und die Funktionalität vollständig vorhanden ist, vergebe ich 5.

2 Air-Gap / Offline-Betrieb für Vulnerability-Datenfeeds CTX

JFrog Curation ist als SaaS und On-Premise verfügbar, jedoch ist der Kerndienst auf JFrogs proprietäre Threat-Intelligence-Feeds und Cloud-Dienste angewiesen, die eine dauerhafte Internet-Verbindung voraussetzen. Ein vollständiger Air-Gap-Betrieb ist für Curation nicht dokumentiert.

💡 Begründung: JFrog Curation basiert auf JFrog Xray und proprietären Feeds (Malware-Erkennung, Typosquatting-Daten), die aus der JFrog-Cloud bezogen werden. Während Artifactory on-premise betrieben werden kann, erfordern Curation-spezifische Funktionen wie Malware-Feeds und Operational Risk Scoring aktive Cloud-Verbindungen. Dies entspricht Score 2: partiell offline-fähig, aber einige Kernfunktionen setzen Internet-Verbindung voraus.

4 Manipulationssicheres Audit-Log mit SIEM-Export (CEF/JSON/Syslog) CTX

JFrog Curation bietet ein vollständiges Audit-Log aller blockierten, quarantänisierten und zugelassenen Pakete mit Reporting-Funktionen. Der JSON-Export über API für SIEM-Integration ist verfügbar, ein nativer Manipulationsschutz (append-only/signiert) ist nicht explizit dokumentiert.

💡 Begründung: Das Feature 'Curation Audit Trail & Reporting' ist explizit beschrieben. JFrog Artifactory/Xray unterstützt generell Syslog- und Webhook-Integration für SIEM. Ein kryptografisch manipulationssicheres Log (append-only oder signiert) ist nicht als dokumentiertes Feature bekannt, was Score 5 ausschließt. Score 4 passt: vollständiges Audit-Log, API-basierter Export für SIEM, kein nativer Manipulationsschutz aber extern archivierbar.

4 Horizontale Skalierung des Scanning-Backends für Enterprise-Artefaktvolumen CTX

JFrog Curation basiert auf der JFrog-Plattform (Artifactory + Xray), die horizontal skalierbar ist und Kubernetes-Deployments mit Helm-Charts unterstützt. Enterprise-Performance-Empfehlungen sind vorhanden, jedoch sind detaillierte öffentliche Benchmarks für >10.000 Artefakte/Tag nicht prominent dokumentiert.

💡 Begründung: JFrog bietet offizielle Helm-Charts und Kubernetes-Support für die gesamte Plattform. Die Architektur ist queue-basiert und Worker-konfigurierbar. Da es sich um ein proprietäres Enterprise-Produkt handelt (kein OSS) und öffentliche Performance-Benchmarks nicht prominent verfügbar sind, schließt das Score 5 aus. Score 4 ist angemessen: horizontal skalierbar, Kubernetes supportet, Enterprise-Empfehlungen vorhanden.

1 OWASP-Ökosystem-Alignment und aktive OWASP-Projektmitgliedschaft CTX

JFrog Curation ist ein proprietäres, kommerzielles Produkt ohne OWASP-Projektmitgliedschaft oder vergleichbare externe Governance (CNCF, Linux Foundation). Die Entwicklung und Steuerung liegt vollständig bei JFrog als Einzelanbieter.

💡 Begründung: JFrog Curation ist vollständig proprietär und vendor-controlled ohne externe Governance-Struktur. Es gibt keine OWASP-Mitgliedschaft, keine CNCF/Linux Foundation-Zugehörigkeit. Dies entspricht exakt Score 1: proprietäres Single-Vendor-Produkt ohne externe Governance.

4 Native CI/CD-Integration mit Policy-Gate-Rückgabecodes für gängige Pipelines CTX

JFrog bietet native Integrationen für Jenkins, GitLab CI, GitHub Actions und Azure DevOps über JFrog-Plugins. Policies werden zentral in der Plattform konfiguriert und können in CI/CD-Pipelines referenziert werden, was Policy-Config-Sprawl verhindert.

💡 Begründung: JFrog verfügt über etablierte CI/CD-Plugins für die wichtigsten Systeme (Jenkins Plugin, GitHub Actions, GitLab Integration, Azure DevOps). Policies werden zentral in Xray/Curation definiert. Da es proprietär ist (kein OSS), schließt das Score 5 aus. Score 4 ist korrekt: native Plugins für mind. 2-3 CI/CD-Systeme, zentrale Policy-Referenz via API, vollständige Dokumentation.

4 Kubernetes-natives Deployment mit Helm-Chart und Operator-Support für HA CTX

JFrog bietet offizielle Helm-Charts für die JFrog-Plattform mit HA-Konfiguration und externer PostgreSQL/Datenbank-Unterstützung. Ein dedizierter Kubernetes-Operator ist nicht vollständig ausgebaut, aber die Kubernetes-Dokumentation für Enterprise-Deployments ist umfangreich.

💡 Begründung: JFrog stellt offizielle Helm-Charts mit HA-Support bereit (JFrog Artifactory HA ist dokumentiert). Externe Datenbank-Backends sind unterstützt. Ein vollständiger Kubernetes-Operator für automatisiertes Lifecycle-Management existiert nicht in dem Maße wie bei CNCF-Projekten. Da proprietär (kein OSS), ist Score 5 ausgeschlossen. Score 4 trifft zu: offizielles Helm-Chart, HA-Support, externe DB möglich, kein vollständiger Operator.

4 Compliance-Dashboard und automatisierter Report-Export für NIS2/BSI-Grundschutz CTX

JFrog bietet Compliance-Dashboards mit Vulnerability-Trends, Audit-Reports und mandantenspezifischer Filterung über Projektzuordnungen. Export in CSV/JSON ist über API möglich; PDF-Export und automatisiertes Scheduling sind Teil der Enterprise-Edition.

💡 Begründung: JFrog Xray/Curation bietet Reporting-Funktionen mit Vulnerability-Metriken und mandantenspezifischer Projektisolierung. NIS2/BSI-spezifische vorkonfigurierte Dashboards sind nicht explizit dokumentiert, und Scheduling/PDF-Export sind Enterprise-Features. Score 4 ist angemessen: gängige Compliance-Metriken vorhanden, mandantenspezifisch filterbar, CSV/JSON-Export, erweiterte Features in kostenpflichtiger Edition.

3 SBOM-Enrichment aus Container-Image-Layern CTX

JFrog Xray unterstützt Container-Image-Analyse und generiert SBOMs auf Image-Ebene mit CycloneDX/SPDX-Ausgabe. Eine dedizierte Layer-by-Layer-Analyse mit expliziter Layer-Zuordnung pro Komponente ist in Curation nicht als explizites Feature dokumentiert.

💡 Begründung: JFrog Xray scannt Container-Images und kann Komponenten identifizieren, arbeitet aber primär auf Image-Ebene ohne dokumentierte Layer-by-Layer-Differenzierung als Curation-Feature. CycloneDX/SPDX-Ausgabe ist vorhanden. Dies entspricht Score 3: Image-Ebene-Analyse mit Standard-SBOM-Ausgabe, keine dokumentierte Layer-Differenzierung.

4 EPSS-Score-Integration und priorisierungsbasiertes Triage-Routing CTX

JFrog Xray integriert EPSS-Scores als Priorisierungsdimension neben CVSS und zeigt diese in UI und API an. Die vollständige Nutzung in automatisierten Policy-Regeln und Triage-Routing ist als Enterprise-Feature verfügbar, jedoch nicht als OSS.

💡 Begründung: JFrog hat EPSS-Integration in Xray angekündigt und umgesetzt. EPSS-Scores sind in der UI sichtbar und für manuelle Triage nutzbar. Automatisches Routing basierend auf EPSS-Schwellenwerten ist möglich, aber als proprietäres Feature. Score 5 scheidet wegen fehlendem OSS aus. Score 4 passt: EPSS verfügbar, in UI/API anzeigbar, Policy-Nutzung möglich als Open-Core/Enterprise-Feature.

4 CISA KEV (Known Exploited Vulnerabilities) Catalogue-Integration CTX

JFrog Xray integriert den CISA KEV Catalogue als Feed, und KEV-Status ist in der Plattform sichtbar und für Policy-Regeln nutzbar. Ein vollständiger Air-Gap-fähiger Offline-Import des KEV-Feeds ist nicht explizit als unterstütztes Feature dokumentiert.

💡 Begründung: JFrog hat CISA KEV-Integration in Xray implementiert, KEV-Status beeinflusst Priorisierung und Policy-Entscheidungen. Offline-Import/Air-Gap für KEV ist nicht dokumentiert, was Score 5 ausschließt. Da es proprietär ist, entfällt auch das OSS-Kriterium für Score 5. Score 4 ist korrekt: KEV-Integration vorhanden, Policy-Nutzung möglich, Offline-Import eingeschränkt.

3 Mandantenspezifische Vulnerability-Feed-Konfiguration und -Isolation CTX

JFrog Curation und Xray ermöglichen Projektisolierung über Repositories und Projektstrukturen, jedoch ist die Feed-Konfiguration (Quellen, Intervalle, Vertrauensstufen) primär global für alle Mandanten konfiguriert. Mandantenspezifische Ergebnisfilterung ist möglich.

💡 Begründung: JFrog unterstützt Multi-Tenant-Isolation über Projekte und Repositories, aber die Vulnerability-Feed-Konfiguration (NVD, GitHub Advisory etc.) erfolgt zentral und gilt plattformweit. Mandantenspezifische Feed-Auswahl oder -Konfiguration ist nicht als Feature dokumentiert. Dies entspricht Score 3: globale Feed-Konfiguration, aber mandantenspezifische Filter auf Ergebnisebene möglich.

2 Rückmeldung von Scan-Ergebnissen in Artifactory-Properties/Metadata CTX

JFrog Curation agiert als Pull-Time Policy Gate und blockiert oder lässt Pakete durch, schreibt aber keine Scan-Ergebnisse als Properties in Artifactory zurück. Diese Funktion ist nativ JFrog Xray vorbehalten.

💡 Begründung: JFrog Curation ist auf Blockierung/Freigabe beim Pull fokussiert, nicht auf das Zurückschreiben von Metadaten als Artifactory-Properties. Das Zurückschreiben von Scan-Ergebnissen als Properties ist eine Xray-Funktion. Ohne Xray-Lizenz gibt es keinen nativen Mechanismus; externe Skripte wären theoretisch möglich, aber das Tool bietet keinen dedizierten Support hierfür. Score 2 ist angemessen.

2 Automatisierte OSS-Komponenten-Attributionslisten-Generierung (NOTICE-Dateien) CTX

JFrog Curation bietet keine Funktion zur automatisierten Generierung von NOTICE-Dateien oder Attributionslisten mit vollständigen Lizenztexten. Es fokussiert auf Policy-Enforcement, nicht auf Lizenzattribution für Releases.

💡 Begründung: Die bekannten Features von JFrog Curation umfassen Lizenz-Policy-Gates (Blockierung unerwünschter Lizenzen), aber keine Attributionslisten-Generierung. Für NOTICE-Dateien ist JFrog Artifactory/Xray mit entsprechenden Modulen zuständig, nicht Curation. Rudimentäre Lizenzinformationen im Audit-Log vorhanden, aber kein Attributionsdokument-Export. Score 2.

4 Trusted-Component-Registry und positives Whitelisting für Organisationen CTX

JFrog Curation bietet über den 'Allowed Package'-Flow ein versionsgranulares Whitelisting mit konfigurierbaren Policies, das explizit als Gegenstück zum Blocking konzipiert ist. Es handelt sich jedoch um ein proprietäres, kostenpflichtiges Feature.

💡 Begründung: Das Konzept des Allowed-Package-Flows und konfigurierbare Curation-Policies mit Paket-Quarantäne-Mechanismus decken Whitelist-Funktionalität versionsgranular ab. Formale Ablaufdaten und mandantenübergreifende Gültigkeit mit explizitem Freigabe-Workflow sind nicht eindeutig als separate Features dokumentiert. Da es sich um ein proprietäres kostenpflichtiges Tool handelt (kein Open Source), ist Score 4 passend.

4 Transitive Dependency-Auflösung und Tiefenanalyse für SBOM-Vollständigkeit CTX

JFrog Curation integriert tief mit JFrog Xray, das rekursive transitive Dependency-Auflösung für die meisten Ökosysteme bietet. Für Binaries ohne Quellcode-Zugriff existieren Einschränkungen, die jedoch dokumentiert sind.

💡 Begründung: Das Feature 'Integration mit JFrog Xray (tiefe Paketanalyse): enge Integration mit JFrog Xray für rekursive Abhängigkeitsanalyse (transitive Dependencies)' ist explizit genannt. Ein expliziter SBOM-Vollständigkeits-Score im Sinne von CycloneDX Metadata Level 3 ist nicht dokumentiert. Da es proprietär/kostenpflichtig ist, ist Score 4 angemessen (kein Open Source, transitive Auflösung gut, Vollständigkeits-Score nicht explizit belegt).

2 Datenbankpartitionierung und Archivierungsstrategie für Langzeit-SBOM-Daten CTX

JFrog Curation als SaaS/On-Premise-Produkt adressiert Datenbankpartitionierung und Archivierungsstrategien für SBOM-Langzeitdaten nicht explizit in den dokumentierten Features. Dies wäre eine infrastrukturelle Verantwortung des JFrog-Plattformbetriebs.

💡 Begründung: Keine der bekannten Features von JFrog Curation adressiert Retention-Policies, Datenbankpartitionierung oder Archivierungsstrategien. Im SaaS-Modell liegt die Verantwortung bei JFrog, im On-Premise-Modell beim Betreiber ohne dokumentierte Tool-seitige Unterstützung. Score 2 ist konservativ angemessen.

3 Webhook- und Event-Bus-Integration für asynchrone Event-Driven-Architektur CTX

JFrog Curation bietet automatische Benachrichtigungen bei Paket-Blockierung (E-Mail) und ein vollständiges Audit-Log, jedoch ist kein robustes Webhook-System mit Retry-Logik oder Message-Bus-Integration (Kafka/AMQP) in den bekannten Features dokumentiert.

💡 Begründung: Das Feature 'Automatische Benachrichtigung bei Paket-Blockierung: Entwickler und Sicherheitsteams erhalten automatische Benachrichtigungen (E-Mail)' entspricht Score 2-3. Grundlegende Webhook-Unterstützung ist in JFrog-Plattform-Kontext bekannt, aber mandantenspezifische Filterung, Retry-Logik und Message-Bus fehlen in den dokumentierten Features. Score 3 ist vertretbar.

5 Malware- und Typosquatting-Erkennung für Registry-Proxies CTX

JFrog Curation bietet native Malware-Erkennung für Open-Source-Pakete und Typosquatting-Erkennung als explizit dokumentierte Policy-Gate-Kriterien beim Pull aus öffentlichen Registries – dies ist das definierte Referenz-Ziel dieser Anforderung.

💡 Begründung: Sowohl 'Malware-Erkennung für Open-Source-Pakete: Automatische Erkennung bekannter Malware' als auch 'Typosquatting-Erkennung: Identifiziert Pakete mit absichtlich ähnlich klingenden Namen' sind explizit als Features gelistet und als Policy-Gate nutzbar. JFrog Curation ist per Produktbeschreibung das proprietäre Referenz-Ziel für genau diese Anforderung. Score 5 ist gerechtfertigt.

2 Softwareintegrität und Artefakt-Signatur-Verifikation (Sigstore/Cosign) CTX

JFrog Curation fokussiert auf CVE-basierte und Malware-basierte Policy-Gates beim Paket-Pull, bietet aber keine dokumentierte native Sigstore/Cosign-Signatur-Verifikation mit Rekor-Integration als Policy-Gate-Kriterium.

💡 Begründung: Sigstore/Cosign-Verifikation ist in den bekannten Features von JFrog Curation nicht dokumentiert. JFrog Artifactory unterstützt gewisse Integritätsprüfungen, aber native Sigstore/Cosign-Policy-Gate-Integration ist für Curation nicht bekannt. Score 2 (manuelle Verifikation außerhalb möglich, kein nativer Policy-Gate-Bezug) ist konservativ korrekt.

2 Ressourcen-Quotierung und Rate-Limiting pro Mandant (Fair-Use-Enforcement) CTX

JFrog Curation bietet keine dokumentierten mandantenspezifischen Ressourcen-Quotas oder API-Rate-Limits pro Mandant. Als proprietäres Produkt mit SaaS-Angebot liegt Fair-Use-Management bei JFrog-Infrastruktur ohne kundenseitige Konfigurierbarkeit.

💡 Begründung: Keine der dokumentierten Features adressiert mandantenspezifische Quota-Systeme, parallele Scan-Limits oder Speicher-Kontingente. JFrog Curation ist primär ein Policy-Gate-Tool, kein Multi-Tenant-Platform-Service mit Ressourcen-Management. Score 2 ist angemessen (nur globale systemweite Limits, keine mandantenspezifische Kontrolle dokumentiert).

3 SBOM-as-a-Service API für externe Tool-Integration (SBOM-Upload und -Abfrage) CTX

JFrog Curation bietet über die JFrog-Plattform REST-API-Zugang, jedoch ist eine vollständig OpenAPI-spezifizierte, versionierte API mit expliziter Rückwärtskompatibilitätsgarantie für SBOM-Upload und -Abfrage als eigenständiger Service nicht in den bekannten Features dokumentiert.

💡 Begründung: JFrog-Produkte bieten generell REST-APIs, und das Feature 'SBOM-basierte Curation-Entscheidungen' impliziert SBOM-Verarbeitung. Jedoch ist keine explizite OpenAPI-Spec, Versionierungsstrategie oder Rückwärtskompatibilitätsgarantie für einen SBOM-as-a-Service-Endpunkt dokumentiert. Score 3 (REST-API mit Basisfunktionen, unvollständige Dokumentation für diesen Zweck) ist vertretbar.

3 Regulatorische Berichtspflichten: CRA (Cyber Resilience Act) SBOM-Anforderungen CTX

JFrog Curation unterstützt SBOM-basierte Entscheidungen und Audit-Trails, bietet aber keine expliziten CRA-Compliance-Workflows oder behördlich ausgerichtete SBOM-Export-Funktionen. CycloneDX/SPDX-Standards sind über Xray-Integration erreichbar.

💡 Begründung: Das Feature 'SBOM-basierte Curation-Entscheidungen' und Xray-Integration ermöglichen CycloneDX/SPDX-kompatible SBOMs, aber explizite CRA-Compliance-Workflows, Vollständigkeitsvalidierung gegen CRA-Anforderungen oder behördliche Abrufbarkeit sind nicht in den bekannten Features dokumentiert. Score 3 (SBOM-Standards erreichbar, CRA-Konformität über externe Validierung, kein expliziter CRA-Support) ist korrekt.

2 Dependency-Track-Migrationsbrücke: Erhalt historischer Triage-Daten CTX

JFrog Curation ist kein SBOM-Tracking-Tool und bietet keine dokumentierte Migrationsbrücke für Dependency-Track-Exporte, Triage-Historien oder VEX-Dokumente. Es ist ein Pull-Time Policy Gate, kein SBOM-Lebenszyklusmanagement-System.

💡 Begründung: JFrog Curation ist konzeptionell kein Ersatz für Dependency-Track als SBOM-Tracking-Plattform, sondern ein Paket-Eingangs-Kontrollsystem. Migration von Dependency-Track-Triage-Daten ist keine adressierte Funktion. Partieller CycloneDX-Import über Xray wäre theoretisch möglich, aber ohne dediziertes Migrationswerkzeug oder dokumentierten Prozess. Score 2 ist korrekt.

3 Zentraler Service-Delivery-Modus: Self-Service-Onboarding für Sub-Organisationen ohne Admin-Eskalation CTX

JFrog Curation bietet ein Rollenkonzept mit Projekt-Admins, jedoch ist das Self-Service-Onboarding neuer Projekte und Teams typischerweise auf globale Administratoren beschränkt. Tenant-Admins können innerhalb bestehender Strukturen agieren, jedoch erfordern neue Mandanten-Onboardings häufig Eingriffe der zentralen IT.

💡 Begründung: JFrog Artifactory/Curation unterstützt Projekt-basierte Verwaltung mit delegierten Project Admins, die Benutzer und Repositories innerhalb eines Projekts verwalten können. Für die Erstellung neuer Projekte selbst ist jedoch in der Regel ein globaler Platform-Administrator erforderlich. Das Modell entspricht Skala 3: Rollenkonzept vorhanden, aber vollständiges Self-Service-Onboarding ohne globalen Admin ist nicht der dokumentierte Standard-Betriebsmodus für alle Operationen.

4 Reachability-Analyse: Exploitierbarkeits-Kontextbewertung auf Basis tatsächlicher Code-Nutzung CTX

JFrog Xray bietet als 'Contextual Analysis' eine Reachability-Analyse für mehrere Ökosysteme (Java, Python, JavaScript), die bewertet ob verwundbare Funktionen tatsächlich im Code erreichbar sind, und integriert diese Ergebnisse in den Triage-Workflow. Diese Funktion ist Bestandteil der kostenpflichtigen JFrog-Plattform und damit auch für JFrog Curation über die Xray-Integration verfügbar.

💡 Begründung: JFrog Xray's Contextual Analysis ist ein dokumentiertes Feature für mehrere Hauptökosysteme mit Integration in den Vulnerability-Triage-Workflow. Es handelt sich um ein kostenpflichtiges Feature (nicht Open-Source/Open-Core), was einen Score von 5 ausschließt. Die Abdeckung mehrerer Ökosysteme und die Workflow-Integration rechtfertigen Score 4 gemäß der Skala.

3 Operative Observability des Security-Services: Interne Metriken, Health-Checks und Kapazitätsplanung CTX

JFrog bietet Basis-Prometheus-Metriken und Health-Endpoints für den Self-Hosted-Betrieb, jedoch ist die mandantenspezifische Aufschlüsselung (Tenant-Dimensionierung) und natives OpenTelemetry-Tracing nicht vollständig oder standardmäßig dokumentiert. Für Enterprise-Betrieb sind externe Monitoring-Integrationen erforderlich.

💡 Begründung: JFrog Artifactory und Xray (auf denen Curation aufbaut) exponieren Prometheus-Metriken und haben Health-Endpoints, aber Tenant-spezifische Metriken für Showback/Chargeback sowie vollständiges OpenTelemetry-Tracing sind nicht als dokumentierte Standard-Features bekannt. Dies entspricht Skala 3: Basis-Metriken vorhanden, aber ohne Tenant-Aufschlüsselung und ohne natives Tracing. Konservative Bewertung aufgrund begrenzter öffentlicher Dokumentation zu Tenant-Metriken.

2 Differenziertes Ausnahme- und Dispensationsmanagement mit Genehmigungsworkflow und Ablaufdatum CTX

JFrog Curation bietet grundlegende Quarantäne- und Policy-Exception-Mechanismen mit Audit-Trail, jedoch fehlt ein formaler Mehr-Augen-Genehmigungsworkflow mit konfigurierbaren Ablaufdaten und automatischer Eskalation. Suppressionen können gesetzt werden, aber ohne strukturierten Genehmigungsprozess.

💡 Begründung: JFrog Curation/Xray unterstützt Policy-Exceptions und einen Audit-Trail, jedoch ist ein vollständiger Dispensations-Workflow mit Vier-Augen-Prinzip, erzwingbarem Ablaufdatum und automatischer Eskalation nicht als natives Feature dokumentiert. Kommentare bei Exceptions sind möglich, aber kein formaler Genehmigungsprozess. Dies entspricht Skala 2: Suppressions mit rudimentärem Audit-Trail, aber ohne Genehmigungslogik und ohne Ablaufdatum-Erzwingung.

3.1 Produkt-Features

3 SBOM-Import (CycloneDX & SPDX) FEAT

JFrog Curation nutzt SBOM-Informationen für Curation-Entscheidungen, wobei CycloneDX und SPDX im JFrog-Ökosystem (via Xray) unterstützt werden. Der dedizierte Import-Fokus von Curation selbst ist jedoch primär auf den Proxy-Gate-Use-Case ausgerichtet, nicht auf generischen SBOM-Import.

💡 Begründung: Das Feature 'SBOM-basierte Curation-Entscheidungen' deutet auf SBOM-Nutzung hin, jedoch ist Curation kein primäres SBOM-Import-Tool. Die eigentliche SBOM-Import-Funktionalität liegt hauptsächlich bei JFrog Xray. Daher wird die Mindestanforderung knapp erfüllt, aber kein Best-in-Class-Level erreicht.

3 SBOM-Export & Supply-Chain-Transparenz FEAT

JFrog Curation kann über die Integration mit JFrog Xray SBOM-Exporte ermöglichen, jedoch ist der SBOM-Export keine Kernfunktion von Curation selbst, sondern eher des breiteren JFrog-Plattform-Ökosystems.

💡 Begründung: SBOM-Export ist im JFrog-Ökosystem vorhanden (Xray), aber Curation ist primär ein Gate-Mechanismus. Die Supply-Chain-Transparenz wird teilweise über Audit Trails und Curation-Reports abgedeckt, jedoch nicht als vollständiger SBOM-Export-Workflow. Minimum wird erfüllt, aber mit erheblichen Einschränkungen.

2 SBOM-Qualitätsbewertung FEAT

JFrog Curation bietet keine dedizierte SBOM-Qualitätsbewertungsfunktion; es nutzt SBOM-Daten für Entscheidungen, bewertet aber nicht systematisch deren Vollständigkeit oder Metadatenqualität.

💡 Begründung: Eine explizite SBOM-Qualitätsbewertung mit Hinweisen auf fehlende Metadaten ist weder als bekanntes Feature von Curation noch von Xray dokumentiert. Dies liegt außerhalb des primären Use-Cases von Curation, daher wird nur rudimentäre oder keine Abdeckung angenommen.

2 SBOM-Versionierung & historischer Vergleich FEAT

JFrog Curation verfügt über ein Audit-Log für blockierte und zugelassene Pakete, bietet jedoch keine dedizierte SBOM-Versionierung mit historischem Diff-Vergleich zwischen SBOM-Versionen.

💡 Begründung: Der Audit Trail erfasst Curation-Entscheidungen, aber ein strukturierter SBOM-Versionsvergleich (neu/entfernt/geänderte Komponenten über Zeit) ist nicht als Feature dokumentiert. Dies ist eine erhebliche Lücke bezogen auf die Anforderung.

4 Standardisierte Komponenten-Identifikation (PURL) FEAT

JFrog Curation und das zugrundeliegende JFrog-Ökosystem nutzen PURLs (Package URLs) als standardisierte Identifikatoren für Pakete über mehrere Ökosysteme hinweg (npm, PyPI, Maven, etc.).

💡 Begründung: PURL-Unterstützung ist im JFrog-Ökosystem gut etabliert und wird für die Multi-Ecosystem-Unterstützung eingesetzt. Da Curation mehrere Paket-Ökosysteme abdeckt und mit Xray integriert ist, das PURL-basierte Identifikation nutzt, wird die Anforderung gut erfüllt, ohne explizit als eigenständiges Feature hervorgehoben zu sein.

3 Interne Komponenten-Datenbank mit Deduplizierung FEAT

JFrog Artifactory (als Basis von Curation) führt eine zentrale Komponenten-Datenbank; die Deduplizierung ist im Kontext des Repository-Managements vorhanden, aber nicht als explizites Feature der Curation-Schicht dokumentiert.

💡 Begründung: Als Teil der JFrog-Plattform ist eine zentrale Komponentenverwaltung vorhanden, jedoch ist die automatische Deduplizierung im Sinne dieser Anforderung nicht explizit als Curation-Feature dokumentiert. Das Minimum wird durch die Plattformfähigkeiten erreicht.

4 Kontinuierliches Vulnerability Monitoring FEAT

JFrog Curation in Verbindung mit JFrog Xray ermöglicht kontinuierliches Vulnerability Monitoring, bei dem neu veröffentlichte CVEs automatisch mit bestehenden Paketen im Repository abgeglichen werden.

💡 Begründung: Die Integration mit JFrog Xray für kontinuierliches Monitoring ist ein bekanntes und dokumentiertes Feature der JFrog-Plattform. CVE-basierte Blockierung beim Eingang wird explizit als Feature genannt, und Xray führt laufende Neubewertungen durch. Dies übertrifft das Minimum.

4 Multi-Feed Vulnerability Aggregation FEAT

JFrog Xray (integriert mit Curation) aggregiert Schwachstelleninformationen aus mehreren Quellen wie NVD, verschiedenen Security Advisories und proprietären JFrog-Datenbanken für eine breite Abdeckung.

💡 Begründung: Multi-Feed-Aggregation ist eine bekannte Stärke von JFrog Xray, das mit Curation integriert ist. JFrog nutzt eigene kuratierte Vulnerability-Datenbanken plus externe Feeds. Die Abdeckung ist gut, aber spezifische Details zu EPSS oder allen genannten Feeds (OSV, GitHub Advisories) sind nicht vollständig dokumentiert.

3 CVSS- & EPSS-Score-Integration FEAT

CVSS-Scores (v2/v3) werden über JFrog Xray in Curation-Entscheidungen einbezogen; EPSS-Score-Integration ist weniger klar dokumentiert und möglicherweise nur teilweise oder gar nicht vorhanden.

💡 Begründung: CVSS-Unterstützung ist für JFrog Xray bekannt und wird für CVE-basierte Blockierung genutzt. EPSS-Integration ist ein neueres Feature und für JFrog nicht explizit als vollständig implementiert dokumentiert. Konservative Bewertung ergibt Score 3 (Minimum erfüllt für CVSS, Lücke bei EPSS).

2 VEX (Vulnerability Exploitability eXchange) Support FEAT

VEX-Dokument-Support (Import und Export) ist nicht als explizites Feature von JFrog Curation dokumentiert; die Plattform fokussiert sich auf Policy-Gates und CVE-Blockierung, nicht auf VEX-basierte Exploitability-Kommunikation.

💡 Begründung: VEX ist ein relativ neuer Standard und JFrog hat diesen nicht prominent als Curation-Feature kommuniziert. Möglicherweise gibt es rudimentäre Ansätze über SBOM-Integration, aber ein vollständiger VEX Import/Export-Workflow ist nicht bekannt. Daher erhebliche Lücken.

2 Vulnerability Lifecycle Management & Triage-Workflows FEAT

JFrog Curation ist primär ein Gate-Mechanismus beim Pull-Zeitpunkt und bietet keinen vollständigen Vulnerability-Lifecycle mit Triage-Workflows, False-Positive-Management und Risk-Acceptance-Prozessen.

💡 Begründung: Lifecycle-Management und strukturierte Triage-Workflows sind nicht der Kern von Curation. Quarantäne-Mechanismus und Benachrichtigungen decken einen kleinen Teil ab, aber ein vollständiger Lifecycle (Triage, Risikobewertung, Remediation, Schließung) ist keine Curation-Funktion. Dies liegt eher im Bereich von Xray oder anderen Tools.

5 Konfigurierbare Policy Engine FEAT

JFrog Curation bietet eine ausgereift konfigurierbare Policy-Engine als Kernfunktion: granulare regelbasierte Policies für Lizenzen, CVEs, Malware, Typosquatting, Dry-Run-Modus und automatische Durchsetzung beim Paket-Eingang.

💡 Begründung: Dies ist der primäre Use-Case von JFrog Curation. Konfigurierbare Policies für verbotene Lizenzen, CVE-Schweregrade, Malware-Erkennung, Typosquatting und Simulation-Modus sind explizit dokumentiert. Das erfüllt Best-in-Class für diese spezifische Anforderung vollständig und ausgereift.

4 Lizenz-Compliance & SPDX-Identifikation FEAT

JFrog Curation unterstützt Lizenz-Policy-Gates beim Paket-Eingang, automatische Blockierung unerwünschter Lizenzen und nutzt SBOM-Informationen für Curation-Entscheidungen. SPDX-Identifikation ist über die JFrog-Plattform (Xray-Integration) abgedeckt, jedoch liegt der Fokus auf Pull-Time-Enforcement, nicht auf tiefem Quellcode-Scan.

💡 Begründung: Die Lizenz-Policy-Gates und SBOM-basierte Curation decken den Kernbedarf gut ab. SPDX-Zuordnung erfolgt über JFrog Xray-Integration, jedoch ist Quellcode-Scan nicht der primäre Anwendungsfall von Curation. Daher gut, aber nicht Best-in-Class für den vollständigen SPDX-Identifikations-Workflow.

2 SLA-Tracking für Schwachstellen FEAT

JFrog Curation fokussiert auf Pull-Time-Blockierung und verfügt über einen Audit Trail, bietet jedoch kein explizites SLA-Tracking mit konfigurierbaren Fristen pro Schweregrad oder automatischen Eskalationsmechanismen für Schwachstellenbehebung.

💡 Begründung: SLA-Tracking für Remediation ist kein primäres Feature von JFrog Curation – dieses Tool blockiert Pakete beim Eingang, verfolgt aber nicht die zeitliche Behebung bekannter Schwachstellen in bereits vorhandenen Abhängigkeiten. Erhebliche Lücken gegenüber der Anforderung, daher Score 2.

2 Hierarchische Projekt- und Portfolio-Strukturierung FEAT

JFrog Curation bietet konfigurierbare Policies auf Repository-Ebene, eine explizite hierarchische Portfolio-Struktur (Portfolio > Produkt > Projekt > Komponente) mit aggregierter Risikoanalyse ist jedoch nicht das Kernkonzept dieses Produkts.

💡 Begründung: Die Produktstrukturierung in JFrog erfolgt primär über Repositories und Projects in Artifactory, nicht über eine dedizierte hierarchische Portfolio-Verwaltung. Curation selbst adressiert diese Anforderung nur rudimentär, daher Score 2.

3 Konfigurierbares Notification & Alerting Framework FEAT

JFrog Curation bietet automatische Benachrichtigungen per E-Mail bei Paket-Blockierungen für Entwickler und Sicherheitsteams. Weitere Kanäle wie Slack, MS Teams oder Webhooks sind über die JFrog-Plattform eingeschränkt verfügbar, aber nicht als vollständig ausgebautes Framework dokumentiert.

💡 Begründung: E-Mail-Benachrichtigungen bei Blockierungen sind vorhanden und dokumentiert. Ein vollständig konfigurierbares Multi-Channel-Framework mit Slack/Teams/Webhooks für alle Trigger-Typen (SLA, Policy-Verstöße) ist für Curation speziell nicht klar ausgebaut. Mindestanforderung knapp erfüllt, Score 3.

3 Dashboards & Risiko-Scoring (Projekt & Portfolio) FEAT

JFrog Curation stellt einen Curation Audit Trail und Reporting bereit sowie Operational Risk Scoring für Pakete. Dedizierte Portfolio-Dashboards mit aggregierten Trend-Analysen auf mehreren Hierarchieebenen sind primär über JFrog Xray/Advanced Security abgedeckt, nicht durch Curation allein.

💡 Begründung: Audit-Log, Paket-Risiko-Scoring und grundlegendes Reporting sind vorhanden. Umfangreiche Dashboards mit Portfolio-Level-Aggregation und Trend-Analysen gehören eher zum JFrog Xray-Scope. Für Curation selbst: Minimum erfüllt, Score 3.

3 Automatisierte Bericht-Generierung FEAT

JFrog Curation bietet Audit Trail und Reporting-Funktionen für blockierte und zugelassene Pakete. Vollständig anpassbare Executive-Berichte in PDF/HTML-Format sind als Feature von Curation nicht explizit dokumentiert und eher Teil des breiteren JFrog-Plattform-Reportings.

💡 Begründung: Grundlegendes Reporting/Audit Trail ist vorhanden, jedoch ist automatisierte, formatierbare Berichtsgenerierung (PDF/HTML, Executive Summary vs. Detailbericht) kein klar dokumentiertes Curation-Feature. Minimum knapp erfüllt, Score 3.

4 CI/CD-Integration via REST-API & CLI FEAT

JFrog Curation ist tief in die JFrog-Plattform integriert, die eine vollständige REST-API und CLI (JFrog CLI) für CI/CD-Integration bietet. Scans, Policy-Checks und SBOM-Verarbeitung können automatisiert über Pipelines ausgelöst werden.

💡 Begründung: Die JFrog-Plattform und JFrog CLI bieten starke CI/CD-Integrationsmöglichkeiten. REST-API und CLI-Unterstützung sind gut dokumentiert und praxiserprobt. Der transparente Proxy-Ansatz ergänzt die Pipeline-Integration. Score 4, da die SBOM-Upload-Automation als Curation-spezifisches Feature noch etwas eingeschränkter ist als Best-in-Class.

4 Granulares RBAC mit Multi-Tenancy-Unterstützung FEAT

JFrog unterstützt über die Artifactory-Plattform granulares RBAC mit Rollen auf Repository-, Projekt- und Organisations-Ebene sowie Multi-Tenancy-Konzepte. Curation-Policies können pro Repository und Projekt konfiguriert werden.

💡 Begründung: RBAC ist ein etabliertes Feature der JFrog-Plattform mit feingranularen Berechtigungen auf verschiedenen Ebenen. Multi-Tenancy-Isolation ist über Projects in Artifactory abgebildet. Nicht explizit als Best-in-Class für komplexe Enterprise-Multi-Tenancy, daher Score 4.

ANBIETER

OWASP / Steve Springett (Community)

PRODUKT

Dependency-Track

DEPLOYMENT

On-Premise

WEBSITE

https://dependencytrack.org

GESAMTSCORE

3.21/5

3.5 Integration

4 General Interfaces/APIs INT

Dependency-Track bietet eine vollständige, dokumentierte REST-API, über die nahezu alle Frontend-Funktionen programmatisch erreichbar sind. Offizielle Integrationen für Jenkins, GitHub Actions und weitere CI/CD-Tools sind vorhanden, und die API ist via Swagger/OpenAPI dokumentiert.

💡 Begründung: Die REST-API ist vollständig und gut dokumentiert (OpenAPI/Swagger), deckt praktisch alle Kernfunktionen ab und es gibt fertige Plugins/Integrationen für gängige CI/CD-Systeme. Allerdings fehlen dedizierte Out-of-the-box-Konnektoren für Middleware-Plattformen wie MuleSoft, SAP CPI oder API-Manager-Lösungen, weshalb Score 4 (vollständige API, gängige Integrationen vorhanden) zutreffend ist.

3 Interface monitoring INT

Dependency-Track stellt Health-Endpoints und Logging bereit, über die der Betriebsstatus und die Verfügbarkeit von angebundenen Datenquellen (z. B. NVD-Feed-Sync) grundlegend überwacht werden können. Ein dediziertes Interface-Monitoring oder Performance-Dashboards für Schnittstellen sind nicht eingebaut.

💡 Begründung: Es existieren Health-Check-Endpunkte und Anwendungslogs, die für einfaches Monitoring genutzt werden können, jedoch keine aktiven Diagnosefunktionen oder eingebauten Performance-Metriken für Schnittstellen. Dies entspricht Score 3 (Basic monitoring via logs, APIs, or health endpoints) der Skala.

3.1 Non-Functional Requirements

4 Authorization NFR

Dependency-Track bietet ein flexibles RBAC-System mit anpassbaren Teams und granularen Berechtigungen auf Projekt-Ebene. Vordefinierte Rollen existieren, und Berechtigungen können pro Projekt/Team-Kombination vergeben werden.

💡 Begründung: Custom Teams mit frei wählbaren Permissions sind möglich, und Berechtigungen können auf Projekt-Ebene zugewiesen werden. Ein echtes path-level oder vollständiges ABAC-Policy-Control wie Score 5 fordert ist nicht vorhanden, daher Score 4 (Flexible RBAC auf Repository/Projekt-Ebene).

3 IDM connection NFR

Dependency-Track unterstützt OIDC und SAML für Authentifizierung sowie LDAP für Gruppenanbindung, jedoch ist kein natives SCIM-Provisioning verfügbar. Gruppen können über OIDC-Claims gemappt werden.

💡 Begründung: OIDC-Gruppen-Mapping und SAML/LDAP-Support sind vorhanden, aber kein vollständiges SCIM-basiertes Lifecycle-Management (kein automatisches Provisioning/Deprovisioning). Dies entspricht Score 3 (Legacy/Basic Provisioning via SAML/LDAP/OIDC ohne SCIM).

4 Single Sign-On NFR

Dependency-Track unterstützt OIDC (inkl. Azure Entra ID) und SAML als SSO-Protokolle, die durch Konfigurationsdateien vom Kunden selbst eingerichtet werden können. Die Konfiguration erfolgt ohne Vendor-Intervention.

💡 Begründung: Sowohl OIDC als auch SAML werden unterstützt und sind selbst konfigurierbar. Allerdings erfolgt die Konfiguration primär über Config-Dateien ohne eine reichhaltige Self-Service-UI, was Score 5 verhindert. Score 4 ist angemessen da beide Protokolle unterstützt werden, wenn auch ohne vollständige Self-Service-UI.

3 Client/Instances NFR

Dependency-Track ermöglicht Datentrennung über Projekte und Teams mit entsprechenden Zugriffsberechtigungen. Eine echte Mandantentrennung auf Organisations-Ebene mit vollständiger Isolation ist nicht vorgesehen.

💡 Begründung: Die Trennung erfolgt über Projekte und RBAC, nicht über dedizierte Top-Level-Organisations-Einheiten mit komplett isoliertem User-Management. Dies entspricht Score 3 (Basic Repository/Project-Level Separation ohne starke logische Multi-Tenancy).

3 Storage of data (Metadata) NFR

Dependency-Track kann sowohl mit einer eingebetteten H2-Datenbank als auch mit externen Datenbanken (MySQL, PostgreSQL) betrieben werden. Für Produktivumgebungen wird eine externe Datenbank empfohlen.

💡 Begründung: PostgreSQL und MySQL werden als externe Datenbanken unterstützt, jedoch ist die externe DB nicht zwingend vorgeschrieben – eine eingebettete H2-Datenbank ist als Default verfügbar. Dies entspricht Score 3 (Optional External DB), da keine zwingende externe DB-Anforderung besteht.

1 Data/Object Storage Backend Flexibility NFR

Dependency-Track speichert seine Kerndaten (SBOM-Dateien, Metadaten) ausschließlich in der konfigurierten relationalen Datenbank und im lokalen Dateisystem. Native Cloud Object Storage Integration (S3, Azure Blob, GCS) wird nicht unterstützt.

💡 Begründung: Es gibt keine nativen Integrationen für Cloud Object Storage wie S3 oder Azure Blob. Alle Daten werden im Dateisystem oder der Datenbank gespeichert, was Score 1 (Filesystem Only) entspricht.

2 Data Archiving & Cleanup NFR

Dependency-Track bietet keine integrierte Policy-Engine für automatisches Archivieren oder Löschen alter Daten. Cleanup muss manuell über die UI oder per REST-API-Scripting erfolgen.

💡 Begründung: Es gibt keine eingebauten automatisierten Cleanup- oder Archivierungsfunktionen. Daten können über die REST-API gelöscht werden, was eigene Skripte erfordert. Dies entspricht Score 2 (Manual Cleanup via API/Scripts).

4 Hosting Flexibility NFR

Dependency-Track ist ausschließlich als On-Premise-Lösung verfügbar und wird als Docker-Container oder Kubernetes-Deployment hervorragend unterstützt. Offizielle Docker-Images und Helm-Charts sind vorhanden; kein SaaS-Angebot existiert.

💡 Begründung: Exzellente PaaS/Container-Unterstützung (Docker, Kubernetes, Helm) und On-Premise-Deployment sind gegeben. Ein SaaS-Angebot vom Vendor fehlt, was Score 5 ausschließt. Score 4 (Strong PaaS & On-Premise ohne SaaS) ist korrekt.

5 Hardware and Component Requirements NFR

Dependency-Track läuft als leichtgewichtiger Java/Container-Prozess mit moderatem RAM-Bedarf (empfohlen 4-8 GB RAM) und ist vollständig Docker-kompatibel. Der Footprint ist für ein SBOM-Monitoring-Tool sehr gering.

💡 Begründung: Das Tool ist als Container konzipiert, benötigt Standard-Hardware und ist ressourceneffizient. Offizielle Docker-Images sind verfügbar. Dies erfüllt Score 5 (sehr geringer Footprint, containerisiert lauffähig) gut.

5 Installation Mode (automatic / manual) NFR

Dependency-Track kann mit einem einzigen Docker-Compose-Befehl oder via Helm-Chart auf Kubernetes installiert werden. Alle Komponenten (API-Server, Frontend) werden automatisch konfiguriert.

💡 Begründung: Ein einzelner `docker-compose up`-Befehl startet die gesamte Umgebung; offizielle Docker-Compose-Files und Helm-Charts sind vorhanden. Dies entspricht exakt Score 5 (Fully Automated, Single Command).

1 Multi-location Deployment Options NFR

Dependency-Track ist für Single-Instance-Deployments konzipiert und bietet keine nativen Features für Multi-Location-Replikation oder Federation. Verteilte Umgebungen werden nicht nativ unterstützt.

💡 Begründung: Es gibt keine eingebauten Replikations-, Federation- oder Multi-Location-Sync-Mechanismen. Jede Instanz ist eigenständig, was Score 1 (Not Supported für Multi-Location) entspricht.

3 Application Performance NFR

Dependency-Track bietet für Standard-Workloads (mittlere Portfoliogröße, regelmäßige SBOM-Ingestion) ausreichende Performance. Bei sehr großen Portfolios (tausende Projekte) oder häufiger SBOM-Ingestion kann Tuning (Datenbankoptimierung, Heap-Sizing) erforderlich werden.

💡 Begründung: Die Architektur ist solide für mittlere Deployments, jedoch sind bei Enterprise-Scale-Einsatz mit vielen Projekten und hoher Ingestion-Frequenz Performance-Tuning-Maßnahmen bekannt notwendig. Score 3 (Adequate, aber spürbar ressourcenintensiv bei größeren Workloads) ist angemessen.

3 Scalability (manage increase No. of users) NFR

Dependency-Track unterstützt moderate Parallelität durch seine REST-API und asynchrone Task-Verarbeitung mit internem Messaging-System, ist jedoch als monolithische On-Premise-Applikation nicht für horizontales Auto-Scaling ausgelegt. Für hohe Concurrent-User-Lasten sind manuelle Tuning-Maßnahmen erforderlich.

💡 Begründung: Die Architektur basiert auf einem einzelnen Deployment (monolithisch mit eingebetteter Task-Queue), ohne natives horizontales Scaling oder Cluster-Support. Für Standard-Enterprise-Lasten ausreichend, aber bei hoher Parallelität (viele gleichzeitige SBOM-Uploads, API-Anfragen) stoßen Instanzen an Grenzen. Score 3 gemäß Skala: 'Moderate concurrency support; works for standard loads with careful tuning'.

2 Remote Performance for foreign locations NFR

Dependency-Track ist eine klassische On-Premise-Webapplikation ohne spezifische Mechanismen für verteilte Standorte wie Edge-Caching, Replikation oder Proxy-Patterns. Remote-Teams greifen über das Standard-Web-UI und die REST-API zu, was bei hoher Latenz zu spürbaren Einschränkungen führen kann.

💡 Begründung: Es gibt keine dokumentierten eingebauten Mechanismen zur Latenz-Mitigation (keine CDN-Integration, kein Replikationsmodell, keine Read-Replicas). Remote-Nutzung ist technisch möglich, aber das Tool bietet keine spezifischen Architekturfeatures für Low-Bandwidth/High-Latency-Szenarien. Score 2 gemäß Skala: 'Limited support for low-bandwidth/high-latency conditions'.

3 Deployment of Customizing --> no coding NFR

Dependency-Track bietet über das Web-UI konfigurierbare Rollen, Policies, Notification-Templates und Feed-Einstellungen ohne Code. Fortgeschrittene Szenarien wie komplexe Retention-Logik oder tiefe Administrative Automatisierung erfordern jedoch API-Scripting oder manuelle Eingriffe.

💡 Begründung: Standard-Konfigurationen (RBAC, Policy-Engine, Notifications, License-Policies) sind no-code über das UI möglich. Delegierte Administration ist eingeschränkt und erweiterte Governance-Einstellungen erfordern oft API-Nutzung oder direkten Admin-Zugriff. Score 3: 'Basic no-code customization for standard settings and permissions; advanced needs require coding or heavy scripting'.

3 Deployment of Development --> coding NFR

Dependency-Track stellt eine gut dokumentierte REST-API bereit, die umfassende Integrationen und Automatisierungen ermöglicht. Native Plugin-Mechanismen oder offizielle Extension-Frameworks für tiefere Produktanpassungen fehlen jedoch, sodass Entwicklungserweiterungen primär API-extern bleiben.

💡 Begründung: Die REST-API ist vollständig dokumentiert (OpenAPI/Swagger) und CI/CD-Integrationen sind offiziell unterstützt. Jedoch gibt es kein natives Plugin-System oder Extension-Framework für das Kernprodukt selbst. Kundenseitige Code-Erweiterungen sind auf externe API-Automatisierung beschränkt. Score 3: 'Good API-based integration possible, but limited native extension points for deeper product behavior changes'.

4 Experience/Possibility with/of offshore development NFR

Dependency-Track unterstützt OIDC/SAML-SSO für die Integration externer Identitäts-Provider sowie granulares RBAC mit Team- und Projekt-Hierarchien, was eine strukturierte Onboarding-Governance für verteilte oder Offshore-Teams ermöglicht. Die Verwaltung externer Nutzer erfolgt über Standard-IdP-Integration.

💡 Begründung: OIDC/SAML-Integration erlaubt die Anbindung externer Identitäten (z.B. Offshore-Team-Konten), kombiniert mit feingranularem RBAC auf Projektebene. Es fehlen explizite 'Guest-Collaboration'-Features, aber operative Offshore-Nutzung ist gut unterstützt. Score 4: 'Strong enterprise RBAC and external identity integration; offshore collaboration is well-supported operationally'.

3 Flexibility via side-by-side or other extension points NFR

Dependency-Track bietet eine vollständige REST-API und ein konfigurierbares Notification-Framework mit Webhooks für externe Systeme als primäre Erweiterungspunkte. Ein natives Plugin-System oder tiefes Extension-Framework für Kernverhaltenänderungen ohne Code-Modifikation existiert nicht.

💡 Begründung: Webhooks/Notifications und die REST-API ermöglichen externe Automatisierung und Side-by-Side-Integrationen. Es gibt jedoch kein offizielles Plugin-Ökosystem oder Scripting-Framework innerhalb des Produkts. Tiefere Anpassungen erfordern Fork oder Code-Änderungen. Score 3: 'Mostly API-based integration and automation, but limited native extension points for deep behavior changes'.

3 Maintenance and consistency of control tables NFR

Die zentrale Web-UI und REST-API erlauben konsistente Verwaltung von Projekten, Policies und Zugriffsregeln. Bei größeren Umgebungen mit vielen Teams und Projekten erfordert die konsistente Pflege von Governance-Einstellungen jedoch manuellen Aufwand oder eigene Automatisierungsskripte.

💡 Begründung: Zentrale UI für Policy- und Zugriffsmanagement ist vorhanden, aber es fehlen native Bulk-Management-Features, Infrastructure-as-Code-Templates oder integrierte Config-Consistency-Checks über Umgebungen hinweg. Für mittlere Umgebungen ausreichend, bei Scale wird es aufwändig. Score 3: 'Adequate controls with partial consistency support'.

5 Source code availability NFR

Dependency-Track ist vollständig Open Source unter der Apache 2.0 Lizenz, der gesamte Quellcode ist auf GitHub verfügbar und kann frei eingesehen, modifiziert und geforkt werden. Kunden haben vollständige Kontrolle über den Code.

💡 Begründung: Vollständig OSS (Apache 2.0), GitHub-Repository öffentlich zugänglich, aktive Community. Kunden können den Core vollständig reviewen, modifizieren und eigene Forks pflegen. Dies entspricht exakt Score 5: 'Fully open source with broad code access and practical ability to review/change core behavior'.

3 Maintenance effort (upgrades & testing) NFR

Dependency-Track veröffentlicht regelmäßige Releases mit Changelogs auf GitHub, jedoch ohne formales kommerzielles Release-Management oder garantierte Support-Fenster. Upgrades erfordern kundenseitiges Testen, da keine offiziellen Regressionstestgarantien oder Upgrade-Assistenten bereitgestellt werden.

💡 Begründung: Release-Kadenz ist aktiv (mehrere Releases pro Jahr), Changelogs sind verfügbar, aber als Community-OSS-Projekt gibt es keine SLA für Sicherheits-Patches, kein formales LTS-Modell und kein strukturiertes Upgrade-Guidance-Programm. Validierungsaufwand liegt beim Kunden. Score 3: 'Acceptable release model with less predictability or higher validation effort'.

3 Backup & Recovery/Redundancy layer in case of break down NFR

Als On-Premise-Deployment liegt Backup und Recovery vollständig in der Verantwortung des Betreibers; Dependency-Track selbst stellt keine nativen HA- oder Replikationsmechanismen bereit. Standard-Datenbankbackups (PostgreSQL) und Container-Restart-Policies bieten ein Basis-Recovery-Modell.

💡 Begründung: Die Dokumentation beschreibt grundlegende Backup-Empfehlungen für die Datenbank, aber native HA-Cluster, automatische Failover-Mechanismen oder integrierte Redundanz-Features fehlen. Recovery ist betreiberabhängig und erfordert operativen Aufwand. Score 3: 'Basic recovery model with moderate operational complexity'.

2 Availability (Maintenance windows, unannounced maintenance) NFR

Dependency-Track-Upgrades im On-Premise-Betrieb erfordern typischerweise einen Container/Service-Neustart, der zu Ausfallzeiten führt. Zero-Downtime-Deployment-Patterns sind nicht nativ unterstützt und müssen vom Betreiber durch externe Load-Balancer-Architekturen selbst realisiert werden.

💡 Begründung: Kein natives Rolling-Update- oder Blue-Green-Deployment-Modell ist in der Produktdokumentation beschrieben. Für Updates muss die Instanz neu gestartet werden, was bei Standard-Deployments zu Downtime führt. Erweiterte Availability-Patterns erfordern erheblichen eigenen Infrastrukturaufwand. Score 2: 'Significant downtime usually required for updates'.

2 Availability defined/possible SLA NFR

Als Community-Open-Source-Projekt ohne kommerzielles Managed-Service-Angebot stellt OWASP/Dependency-Track keine formalen SLAs oder Verfügbarkeitsgarantien bereit. Die Verfügbarkeit liegt vollständig in der Verantwortung des betreibenden Unternehmens.

💡 Begründung: Es gibt keinen kommerziellen Anbieter mit SLA-Verpflichtungen hinter Dependency-Track. Als reines OSS-Community-Projekt existieren keine publizierten Uptime-Commitments. SLA-Definitionen müssen intern vom Betreiber festgelegt werden. Score 2: 'Limited formal SLA relevance for typical deployment model'.

2.2 Usability & User Experience

3 Ease of Use UX

Dependency-Track bietet eine funktionale Web-UI, die grundlegende SBOM- und Schwachstellen-Workflows abdeckt, jedoch ist für effektive Nutzung (insbesondere Policy-Engine, VEX-Workflows, Feed-Konfiguration) eine gewisse Einarbeitungszeit erforderlich. Kernaufgaben wie das Hochladen von SBOMs und das Ansehen von Schwachstellen sind für technische Nutzer akzeptabel zugänglich.

💡 Begründung: Das Tool richtet sich primär an Security-Analysten und DevOps-Engineers mit technischem Hintergrund. Für diese Zielgruppe ist die UI nach kurzem Onboarding nutzbar, aber ein 'typischer Nutzer' ohne SCA-Background benötigt Dokumentation. Score 3 auf der Skala ist angemessen.

3 Consistent, seamless user interface UX

Die Benutzeroberfläche ist im Wesentlichen konsistent innerhalb der Anwendung (Bootstrap-basiertes Design), bietet jedoch nur sehr begrenzte Theming- oder Enterprise-Anpassungsoptionen. Das visuelle Design ist funktional aber schlicht.

💡 Begründung: Dependency-Track verwendet ein einheitliches, aber nicht besonders reichhaltiges UI-Framework ohne nennenswerte White-Label- oder Enterprise-Theming-Optionen. Die UI ist konsistent, bietet aber kaum Personalisierung – Score 3 passt.

2 Explicit user guidance UX

Dependency-Track bietet kaum In-Produkt-Assistenten oder kontextbezogene Hilfe; komplexe Aufgaben wie die Konfiguration von Policy-Engines oder VEX-Integration werden primär über externe Dokumentation (docs.dependencytrack.org) abgedeckt. Setup-Wizards fehlen weitgehend.

💡 Begründung: Es gibt keine Setup-Assistenten, kaum Tooltips und keine geführten Workflows für komplexe Konfigurationen. Die Nutzer sind auf externe Dokumentation angewiesen. Dies entspricht Score 2 ('Minimal guided UX; mostly manual expert operation').

3 Use-case-oriented design UX

Die UI ist auf Security-Analyst-Workflows ausgerichtet (Schwachstellenübersicht, Komponenten-Detail, Policy-Violations), bietet aber für Entwickler-seitige Workflows (z.B. schnelle Entwicklerintegration, Self-Service SBOM-Upload) eine gewisse Reibung. Admin-Workflows sind funktional vorhanden, aber nicht optimal strukturiert.

💡 Begründung: Für den primären Use Case (Vulnerability-Monitoring durch Security-Teams) ist das Task-to-Screen-Mapping akzeptabel. Für Entwickler als sekundäre Nutzergruppe gibt es Reibungspunkte. Score 3 ('Adequate fit with some friction') ist zutreffend.

2 Flexibility of UI UX

Die UI bietet grundlegende Filter- und Suchfunktionen für Projekte und Komponenten, jedoch fehlen Tastenkürzel, erweiterte Filterkombinationen und Hochproduktivitätsfunktionen für Power-User weitgehend. Navigation über große Datensätze ist eingeschränkt.

💡 Begründung: Dependency-Track hat keine dokumentierten Keyboard-Shortcuts, die Filteroptionen in Listen sind begrenzt und das Arbeiten mit großen Komponentenmengen ist über die UI umständlich. Score 2 ('Limited productivity support') ist konservativ aber zutreffend.

2 Customizable by end-user / user groups UX

Auf Endnutzerebene bietet Dependency-Track kaum Personalisierungsoptionen; es gibt kein Dark-Mode-Toggle, keine anpassbaren Dashboards und keine nutzerspezifischen Layout-Einstellungen. Gruppenspezifische UX-Anpassungen sind nicht vorgesehen.

💡 Begründung: Jenseits von RBAC-basierter Sichtbarkeitskontrolle gibt es keine echten Personalisierungsfeatures für Endnutzer. Das entspricht Score 2 ('Limited personalization options').

1 Language Capabilities UX

Dependency-Track ist ausschließlich auf Englisch verfügbar; es gibt keine Mehrsprachigkeitsunterstützung in der UI und keine benutzerdefinierten Locale- oder Zeitzoneneinstellungen in der Oberfläche. International Teams müssen mit der englischsprachigen UI arbeiten.

💡 Begründung: Als OSS-Community-Tool ohne kommerziellen i18n-Support ist die UI rein englischsprachig. Es gibt keine Hinweise auf Lokalisierungsunterstützung, was Score 1 ('English-only or effectively minimal localization capability') entspricht.

2 Design thinking approach UX

Dependency-Track weist keine explizit dokumentierten Accessibility-Standards (z.B. WCAG) auf; die Bootstrap-basierte UI bietet eine gewisse Basis-Tastaturnavigation durch Browser-Defaults, aber keine systematische Keyboard-First-Unterstützung oder Accessibility-Optimierung über wichtige Workflows hinweg.

💡 Begründung: Ohne dokumentierte Accessibility-Ziele oder -Tests und ohne dedizierte Keyboard-Shortcuts oder Screen-Reader-Optimierung entspricht das Produkt Score 2 ('Limited support for inclusive interaction').

3.2 IT Compliance

3 Single Source of Truth for each data object COMP

Dependency-Track dient als zentrales Repository für SBOM- und Schwachstellendaten und nutzt externe Quellen (NVD, OSV, GitHub) via API-Integration. Eine vollständige 'Single Source of Truth'-Architektur im Sinne von Master-Data-Management mit Leading-System-Anbindung (z.B. REF-MDS) ist jedoch nicht nativ vorgesehen.

💡 Begründung: Das Tool aggregiert Daten aus mehreren Feeds und vermeidet interne Duplizierung durch PURL-basierte Deduplizierung, erfüllt aber keine formale MDM-Anforderung mit definierten Leading-System-APIs. Anpassungen (z.B. Custom-Integration mit REF-MDS) wären nötig, daher Score 3.

3 Where is the cloud server located? (country) COMP

Dependency-Track wird ausschließlich On-Premise betrieben, sodass der Kunde die Server-Standortwahl vollständig selbst kontrolliert. Ein cloud-gehostetes SaaS-Angebot mit Hyperscaler-Optionen (Azure, AWS) existiert nicht seitens des Vendors.

💡 Begründung: On-Premise bedeutet maximale Standort-Kontrolle, aber es gibt keine vom Vendor bereitgestellte Cloud-Infrastruktur mit EU-Regionen oder Hyperscaler-Integration. Die Bewertungsskala zielt primär auf Cloud-Hosting-Optionen ab; da dies nicht relevant ist, aber der Kunde volle Kontrolle hat, ist Score 3 angemessen – adäquate Hosting-Option, aber eingeschränkte Vendor-seitige Region-Auswahl.

3 Does the cloud service provide the encryption of data at rest and in transit? COMP

Dependency-Track selbst bietet keine eingebaute Verschlüsselung at-rest; diese obliegt der zugrunde liegenden Infrastruktur (OS, Datenbank, Storage). TLS für Daten in Transit ist konfigurierbar, aber nicht standardmäßig erzwungen und abhängig vom Deployment-Setup.

💡 Begründung: Verschlüsselung ist möglich, aber nicht konsistent als Default implementiert – weder at-rest noch in-transit out-of-the-box. Für höhere SC-Klassen (SC2/SC3) müssen Kunden eigenverantwortlich Maßnahmen treffen. Das entspricht Score 3: verfügbar, aber nicht durchgängig per Default oder end-to-end.

3 GDPR and BDSG COMP

Als On-Premise-Lösung verarbeitet Dependency-Track personenbezogene Daten (Username, E-Mail für OIDC/SAML-Accounts) ausschließlich in der kundeneigenen Infrastruktur ohne Vendor-Subauftragnehmer. Ein formales DSGVO/BDSG-Konzept oder Löschkonzept wird vom Vendor nicht mitgeliefert.

💡 Begründung: Die On-Premise-Natur eliminiert Drittanbieter-Risiken, jedoch fehlen dokumentierte DSGVO-Prozesse, Datenschutz-Folgenabschätzungen und standardisierte Löschmechanismen seitens des Vendors. Der Kunde muss Governance eigenständig aufbauen, was Score 3 rechtfertigt: grundlegende Compliance möglich, aber Governance-Nachweise begrenzt.

2 ISO certificates COMP

OWASP als Community-Projekt und der primäre Maintainer Steve Springett verfügen über keine ISO 27001-Zertifizierung. Da es sich um eine OSS-On-Premise-Lösung handelt, liegt die Zertifizierungsverantwortung vollständig beim betreibenden Unternehmen.

💡 Begründung: Es gibt keine Vendor-seitige ISO 27001-Zertifizierung oder vergleichbare Enterprise-Zertifizierung. Für On-Premise kann der Kunde seine eigene ISO-27001-Zertifizierung einbringen, aber der Vendor selbst liefert keinen Zertifizierungsnachweis – Score 2: begrenzte Zertifizierungsnachweise vorhanden.

5 Data export and import COMP

Dependency-Track bietet vollständige SBOM-Export- und Import-Funktionen über REST-API (CycloneDX, SPDX), CLI-Tools sowie manuelle Up-/Download-Funktionen in der UI. Alle Projektdaten, SBOMs und Findings sind programmatisch zugänglich.

💡 Begründung: Die REST-API ist umfassend dokumentiert und ermöglicht vollautomatisierten Export/Import aller relevanten Datenobjekte. SBOM-Import/-Export in CycloneDX und SPDX, VEX-Export, und CLI-Integration erfüllen die Anforderung vollständig – Score 5: Full export/import via APIs and operational tooling.

3.4 Risks & Opportunities

5 Dependencies and Lock-In from Software Vendor RISK

Dependency-Track ist vollständig Open Source (Apache 2.0) und basiert auf offenen Standards wie CycloneDX und PURL, sodass ein Wechsel zu einem anderen Tool ohne Vendor-Lock-in möglich ist. SBOMs und Daten können exportiert werden, und die REST-API erlaubt eine einfache De-Integration.

💡 Begründung: Apache 2.0-Lizenz, offene Standards (CycloneDX, PURL, VEX), vollständige Datenportabilität via SBOM-Export und REST-API – dies entspricht dem Maximum der Skala: sehr geringer Lock-in und hohe Portabilität.

3 Project team setup and continuity RISK

Dependency-Track wird als Community-Projekt unter OWASP von Steve Springett und einer überschaubaren Gruppe von Freiwilligen entwickelt; die Kontinuität hängt stark von einzelnen Maintainern ab. Es gibt zwar eine aktive Community, aber keine formelle Unternehmensstruktur mit garantierter Team-Stabilität.

💡 Begründung: Die Abhängigkeit von wenigen zentralen Maintainern (Key-Man-Risiko bei Steve Springett) und fehlende formale Anstellungsgarantien entsprechen einem moderaten Kontinuitätsrisiko – Score 3 auf der Skala.

4 Time to Market RISK

Dependency-Track kann als Docker-Container oder API-Server schnell deployed werden; vorgefertigte Docker-Images und umfangreiche Dokumentation ermöglichen einen produktiven Betrieb in wenigen Tagen. Konfigurationsaufwand für SSO, RBAC und Feed-Anbindung erfordert etwas Zeit, hält sich aber in Grenzen.

💡 Begründung: Schnelles Deployment via Docker mit minimaler Infrastrukturanforderung, gute Dokumentation – entspricht Score 4 (schneller Rollout mit begrenztem Setup-Aufwand), nicht ganz 5 wegen initialer Konfiguration von Feeds und Unternehmensintegration.

2 Skill of supplier RISK

Da Dependency-Track ein Community/OSS-Projekt ohne kommerziellen Hersteller ist, gibt es keinen offiziellen Anbieter mit dediziertem Consulting-, Konzept- und Enterprise-Support-Angebot. Unternehmen müssen auf interne Expertise oder spezialisierte Drittanbieter zurückgreifen, die nicht standardisiert verfügbar sind.

💡 Begründung: Kein kommerzieller Vendor mit strukturiertem Enterprise-Support, Consulting oder nachgewiesener Großkundenbetreuung – das entspricht Score 2 (begrenzte Enterprise-Skill-Tiefe) auf der Skala.

2 Size of supplier (Skalierbarkeit für Großkunden), risk of insolvency RISK

Als OWASP-Community-Projekt ohne kommerzielles Unternehmen dahinter gibt es keine formal angestellten Mitarbeiter, die die Lösung supporten. Die Entwicklung hängt von Freiwilligen und Sponsoren ab, was ein deutliches Kontinuitätsrisiko darstellt, auch wenn OWASP als Organisation stabilisierend wirkt.

💡 Begründung: Keine kommerzielle Unternehmensstruktur, keine garantierten Mitarbeiterressourcen, Insolvenzrisiko nicht anwendbar aber Projektabbruch-Risiko real – Score 2 (kleineres Projekt mit sichtbarem Abhängigkeitsrisiko).

2 World wide rollout RISK

Als reines OSS-Community-Projekt existieren keine regionalen Support-Teams und keine organisierten weltweiten Rollout-Kapazitäten; internationale Deployments müssen vollständig intern oder über Drittdienstleister abgedeckt werden. Es gibt keine SLA-gesicherte globale Support-Struktur.

💡 Begründung: Kein Vendor mit regionalen Support-Teams oder globalem Rollout-Erfahrungsschatz – entspricht Score 2 (begrenzte regionale Rollout-Kapazität) auf der Skala.

4 Dependencies to other strategic projects RISK

Dependency-Track integriert sich neutral in bestehende CI/CD-, OIDC/SAML-SSO- und SBOM-Pipelines ohne negative Abhängigkeiten zu strategischen Projekten wie S/4HANA. Die REST-API-First-Architektur ermöglicht eine lose Kopplung zu anderen Plattformen.

💡 Begründung: Keine negativen strategischen Abhängigkeiten, offene API-Architektur ermöglicht gute Alignment-Optionen – Score 4 (gutes Alignment mit begrenzten Abhängigkeiten), nicht 5 da keine aktiven strategischen Synergien mit Großprogrammen bestehen.

5 Development method (agile or waterfall) RISK

Dependency-Track wird agil mit kurzen Release-Zyklen auf GitHub entwickelt; Issues, Feature-Requests und PRs werden öffentlich nach agilen Prinzipien bearbeitet. Das kontinuierliche Deployment-Modell (Docker, API-Server) passt sehr gut zum DevSecOps-/agilen Betriebsmodell.

💡 Begründung: Modernes agiles Community-Entwicklungsmodell mit öffentlichem Backlog, kurzen Release-Zyklen und DevSecOps-Ausrichtung – entspricht Score 5 (sehr starker agiler Fit) auf der Skala.

3.8 Total Cost of Ownership

4 Setup/Project Costs TCO

Dependency-Track ist als OSS-Tool mit Docker-basierten Deployment-Images verfügbar, wodurch der initiale Setup-Aufwand gering ist. Die vorhandene Community-Dokumentation und das CycloneDX-native Design reduzieren den Konzeptionsaufwand erheblich.

💡 Begründung: Das Tool ist bereits als Baseline im Einsatz, was Setup-Kosten weiter senkt. Docker-Compose/Helm-Charts sind verfügbar, jedoch erfordert die initiale Konfiguration (OIDC/SAML, RBAC, Feed-Anbindung) noch moderaten Aufwand – daher 4 statt 5.

4 Implementation Costs TCO

Die REST-API und offiziellen CI/CD-Integrationen (Jenkins, GitHub Actions etc.) ermöglichen eine schnelle Anbindung in bestehende Pipelines ohne umfangreiche Eigenentwicklung. Customizing der Policy-Engine und Notification-Workflows ist konfigurativ und erfordert kaum Code.

💡 Begründung: Da das Produkt bereits eingesetzt wird, entfällt ein Großteil des Implementierungsaufwands. Verbleibender Aufwand liegt in projektspezifischer Policy-Konfiguration und tieferer API-Integration – rechtfertigt Score 4.

3 Maintenance / Operation Costs TCO

Als selbst gehostetes On-Premise-Tool müssen Updates, Datenbank-Wartung, Feed-Synchronisation und Infrastruktur eigenverantwortlich betrieben werden. Regelmäßige Minor-Releases erfordern Patch-Management-Aufwand.

💡 Begründung: OSS ohne kommerziellen Support bedeutet, dass das eigene Team für Betrieb, Monitoring, Upgrades und Fehlerdiagnose zuständig ist. Dies entspricht einem moderaten Betriebsaufwand (Score 3), da keine SLA-basierte Vendor-Unterstützung vorhanden ist.

5 License Costs TCO

Dependency-Track ist vollständig Open Source unter der Apache-2.0-Lizenz ohne Lizenzkosten, nutzungsabhängige Gebühren oder versteckte Add-on-Kosten. Das Kostenmodell ist vollständig transparent und kalkulierbar.

💡 Begründung: Keine Lizenzgebühren, kein kommerzielles Pricing-Modell, keine User- oder Volume-basierte Abrechnung – entspricht exakt der Definition von Score 5 auf der Skala.

3 expected benefit/efficiency TCO

Dependency-Track liefert als kontinuierliches Monitoring-Tool einen soliden Effizienzgewinn durch frühzeitige Schwachstellenerkennung und reduzierte manuelle Prüfaufwände. Als bereits eingesetzte Baseline sind die inkrementellen Effizienzgewinne in Folgejahren jedoch begrenzt.

💡 Begründung: Da das Tool bereits im Einsatz ist, sind die größten Effizienzgewinne bereits realisiert. Weitere Optimierungen durch Policy-Engine und VEX-Nutzung sind möglich, aber der Hebel ist moderat – Score 3 ist angemessen.

1.4 Support & Operations

1 1st level SUP

Dependency-Track ist ein Community-Open-Source-Projekt ohne kommerziellen Vendor, daher gibt es keine organisierte 1st-Level-Support-Hotline. Support erfolgt ausschließlich über GitHub Issues, Slack-Community und Diskussionsforen.

💡 Begründung: Als OWASP-Community-Projekt ohne kommerziellen Anbieter ist kein strukturierter 1st-Level-Support (Hotline, dedizierter Support-Kanal mit SLA) verfügbar. Dies entspricht Skala-Wert 1 (Mostly self-support).

1 2nd level SUP

Ein formaler 2nd-Level-Support durch den Vendor existiert nicht, da kein kommerzieller Anbieter hinter Dependency-Track steht. Eskalation ist nur über GitHub Issues oder Community-Kanäle an die Maintainer möglich.

💡 Begründung: Ohne kommerziellen Vendor gibt es kein strukturiertes 2nd-Level-Modell. Die Maintainer reagieren nach Best-Effort-Prinzip auf GitHub. Dies entspricht Skala-Wert 1 (No reliable second-level model).

2 3rd level SUP

Bugfixes und Feature-Requests können über GitHub Issues eingereicht werden, und die aktive Maintainer-Community (Steve Springett u.a.) bearbeitet gemeldete Bugs nach Priorität. Jedoch gibt es keine garantierten Eskalationspfade oder Engineering-Commitments.

💡 Begründung: Es gibt einen öffentlichen GitHub-basierten Bug-Tracking-Prozess mit aktiven Maintainern, was etwas über reinen Community-Support hinausgeht, aber keine formellen Engineering-Eskalationspfade bietet. Score 2 (Limited engineering escalation) ist angemessen.

1 General support concept/approach SUP

Dependency-Track bietet kein kommerzielles Support-Konzept. Verfügbar sind GitHub Issues, ein Slack-Channel (#dependency-track in der OWASP-Workspace), Dokumentation und Community-Diskussionen. Ticket-Bridge, weltweiter Support oder mehrsprachiger Support sind nicht vorhanden.

💡 Begründung: Als reines Community-OSS-Projekt ohne kommerziellen Anbieter fehlen alle Enterprise-Support-Merkmale wie Ticket-Bridge, SLA-basierter weltweiter Support oder mehrsprachige Support-Teams. Score 1 (Very weak or community-only support concept).

1 SLA for tickets SUP

Es existieren keine formalen SLAs für Ticket-Lösungszeiten, da kein kommerzieller Support angeboten wird. Response-Zeiten auf GitHub Issues sind vollständig von der Verfügbarkeit der freiwilligen Maintainer abhängig.

💡 Begründung: Ohne kommerziellen Vendor gibt es keinerlei dokumentierte SLAs oder garantierte Antwortzeiten für kritische, mittlere oder niedrige Tickets. Score 1 (No real SLA).

1 Support coverage SUP

Es gibt keine 24/7-Support-Coverage. Die Community-Unterstützung erfolgt nach Best-Effort durch Freiwillige, hauptsächlich während nordamerikanischer Geschäftszeiten, ohne regionale Garantien.

💡 Begründung: Als Community-Projekt ohne kommerzielle Support-Struktur ist kein 24/7-Support und keine globale Coverage gewährleistet. Score 1 (Community or business-hours only).

3 Training, tool documentation SUP

Dependency-Track bietet eine umfangreiche offizielle Dokumentation (docs.dependencytrack.org) mit Installations-, Konfigurations- und Nutzungsanleitungen. Formale Trainings (Videos, Webinare, Face-to-Face) werden vom Vendor nicht angeboten, jedoch existieren Community-Beiträge und OWASP-Konferenzvorträge.

💡 Begründung: Die Dokumentation ist qualitativ gut und deckt Admin- sowie Entwickler-Perspektiven ab, was über reine Basis-Dokumentation hinausgeht. Jedoch fehlen strukturierte Trainingsangebote für Endnutzer und Administratoren. Score 3 (Good documentation, limited formal training) ist angemessen.

2.7 Projektspezifische Anforderungen

3 Hierarchische Mandantentrennung mit vererbten Policies CTX

Dependency-Track bietet eine Projekt-Hierarchie mit Eltern-Kind-Beziehungen sowie Team-basiertes RBAC, erreicht aber kein vollständiges mehrstufiges Mandantenmodell mit erzwungener Policy-Vererbung. Eine echte Datenisolation zwischen Sub-Organisationen sowie automatische Policy-Propagation mit Überschreibungsschutz sind nicht nativ vorhanden.

💡 Begründung: Das Modell deckt Projekt-Hierarchie und Teams ab, entspricht aber eher einem Zwei- bis Drei-Ebenen-Ansatz (Projekt/Team/Individuum) ohne vollständige Mandantentrennung oder konfigurierbare Policy-Vererbung mit Lock-down. Damit passt Score 3 ('Zwei-Ebenen-Mandantenmodell, Policy-Vererbung manuell nachrüstbar') am besten.

2 Mandanten-scoped API-Tokens und Service-Accounts CTX

Dependency-Track verwendet globale API-Keys, die Teams zugewiesen werden. Eine echte mandantenspezifische Scope-Trennung auf Token-Ebene mit technisch durchgesetzter Isolation ist nicht vorhanden; die Zugriffsbeschränkung erfolgt über RBAC-Filterung.

💡 Begründung: Tokens sind team-basiert, aber nicht technisch auf einen Mandanten-Scope isoliert; es gibt kein automatisches Audit-Log pro Mandant und keine automatische Rotation. Das entspricht Score 2 ('Globale API-Tokens mit RBAC-Filterung, keine echte mandantenspezifische Scope-Trennung').

1 Proxy-/Pull-Policy-Gate für JFrog Artifactory ohne XRay-Lizenz CTX

Dependency-Track ist ein SBOM- und Vulnerability-Monitoring-Tool und bietet keine Artifactory-Integration als Policy-Gate. Es kann keine Artefakt-Pulls blockieren oder als vorgelagerter Proxy für Artifactory fungieren.

💡 Begründung: Es existiert keinerlei nativer Artifactory-Connector oder Policy-Gate-Funktion. Dependency-Track agiert als nachgelagertes Analyse-Tool, nicht als Proxy oder Gate vor dem Artifact-Download. Score 1 ist korrekt.

5 Bidirektionale Integration mit bestehendem Dependency-Track ohne Datenduplizierung CTX

Dependency-Track ist selbst das eingesetzte Tool; eine Integration 'mit sich selbst' ist trivial über die eigene REST-API realisierbar. Als autoritativer SBOM-Store mit vollständiger REST-API, CycloneDX-Import/-Export und bidirektionalem Finding-Zugriff erfüllt es diese Anforderung vollständig in der OSS-Edition.

💡 Begründung: Da Dependency-Track das Referenzprodukt ist, entfällt Datenduplizierung per Definition. Die REST-API ist vollständig dokumentiert, und CycloneDX-basierter In-/Export ist natives Feature. Score 5 ist gerechtfertigt.

1 SBOM-Generierung für Binary-Artefakte in Artifactory (ohne Quellcode-Zugriff) CTX

Dependency-Track generiert keine SBOMs aus Binär-Artefakten; es ist ein SBOM-Konsumtions- und Monitoring-Tool, das fertige SBOMs per Upload oder API empfängt. Für Binary-SBOM-Generierung aus Artifactory sind externe Tools (Syft, Trivy) zwingend erforderlich.

💡 Begründung: Dependency-Track hat explizit keine Binary-Scanning-Funktionalität eingebaut. SBOM-Generierung ist nicht Teil des Produktumfangs. Score 1 ('Kein Binary-Scanning') ist korrekt.

4 SBOM-Versionierung und Differenz-Tracking über Artefakt-Versionen CTX

Dependency-Track speichert historische SBOM-Versionen pro Projekt und bietet einen Diff-View für hinzugefügte und entfernte Komponenten im UI sowie API-Zugriff auf die Historie. Die Funktion ist in der OSS-Edition enthalten.

💡 Begründung: Das Feature 'SBOM-Versionierung & historischer Diff' ist als bekanntes Feature explizit gelistet. API-Zugriff auf die Historie ist vorhanden. Konfigurierbare Aufbewahrungsfristen sind weniger klar dokumentiert, weshalb Score 4 konservativer gewählt wird als Score 5, da vollständige Retention-Konfigurierbarkeit nicht sicher belegbar ist.

4 VEX/OpenVEX-Erstellung und -Verwaltung als First-Class-Feature CTX

Dependency-Track unterstützt CycloneDX-VEX nativ – Import, Export und Verwaltung von VEX-Statements sind integriert. OpenVEX wird aktuell nicht als separater Standard nativ unterstützt, und eine vollständige Versionierung mit Audit-Trail ist teilweise eingeschränkt.

💡 Begründung: VEX-Support ist ein explizit gelistetes Feature (CycloneDX VEX). OpenVEX-Support ist in 4.11.x nicht als First-Class-Feature dokumentiert. Score 4 ('VEX in einem Standard, Import/Export möglich') trifft zu; Score 5 erfordert beide Standards.

3 Organisationsweite Suppression und Wiederverwendung von Triage-Entscheidungen CTX

Dependency-Track bietet eine Policy-Engine, über die Regeln auf Komponenten-/CVE-Ebene definiert werden können, die auf alle Projekte wirken. Eine vollautomatische Propagation von VEX-Statements oder Suppressions über alle betroffenen Projekte mit Audit-Trail ist jedoch nicht nativ implementiert.

💡 Begründung: Globale Policy-Regeln können auf Portfolioebene wirken, aber spezifische VEX-/Suppression-Statements müssen projektweise gesetzt werden oder erfordern manuelle Schritte. Das entspricht Score 3 ('Templates/Regeln können manuell angewendet werden, aber keine automatische Propagation').

4 Aggregierte Vulnerability-Feeds aus mehreren Quellen mit Konfliktauflösung CTX

Dependency-Track integriert nativ NVD, OSV und GitHub Advisories und zeigt konkurrierende Scores transparent pro Finding an. EPSS ist ebenfalls integriert. CERT-Bund oder proprietäre Feeds sind nicht nativ enthalten; die Konfliktauflösung zeigt alle Scores, eine konfigurierbare Priorisierungsregel fehlt jedoch.

💡 Begründung: Drei große Feeds (NVD, OSV, GitHub Advisory) plus EPSS sind nativ vorhanden, was Score 4 ('mind. 3 Feeds, Priorisierung konfigurierbar') nahekommt. Vollständig konfigurierbare Priorisierungslogik und CERT-Feed sind nicht nativ vorhanden, daher kein Score 5.

3 License-Policy-Enforcement mit Copyleft-Risikostufen und Ausnahme-Workflow CTX

Dependency-Track bietet eine Policy-Engine mit Lizenz-Policies auf Basis von SPDX-Lizenzen und konfigurierbaren Verletzungsregeln. Ein strukturierter Ausnahme-Workflow mit Legal-Review, Genehmigung und Audit-Trail ist jedoch nicht nativ vorhanden.

💡 Begründung: Lizenz-Policy-Enforcement mit SPDX-Klassifikation ist vorhanden, aber differenzierte Copyleft-Risikostufen pro Mandant und ein formaler Ausnahme-Workflow sind nicht implementiert. Score 3 ('vordefinierte License-Policy-Templates, kein nativer Ausnahme-Workflow') passt.

3 SPDX-konforme Lizenzauflösung inkl. komplexer Lizenz-Expressions CTX

Dependency-Track erkennt SPDX-Lizenz-Identifikatoren und wertet sie in der Policy-Engine aus. Komplexe SPDX License Expressions (AND/OR/WITH) werden nicht vollständig semantisch geparst; es findet eine vereinfachte Verarbeitung statt, was zu bekanntem Informationsverlust bei Expressions führen kann.

💡 Begründung: Vollständiges SPDX-2.3-Expression-Parsing ist in Dependency-Track nicht dokumentiert; Einzel-Lizenzen werden korrekt verarbeitet, aber zusammengesetzte Expressions werden vereinfacht behandelt. Score 3 ('Einzel-Lizenzen korrekt, Expressions vereinfacht') ist angemessen.

2 Deklarative Policy-as-Code-Definition mit Versionierung (OPA/Rego oder äquivalent) CTX

Policies werden in Dependency-Track primär über das Web-UI konfiguriert. Ein Export im maschinenlesbaren Format ist möglich, und die REST-API erlaubt programmatische Konfiguration. Ein nativer GitOps-Workflow oder Policy-as-Code in OPA/Rego bzw. einer dokumentierten YAML-DSL ist jedoch nicht vorhanden.

💡 Begründung: Es gibt keine native Policy-as-Code-Unterstützung mit offenem Format und versionierungsfreundlichem GitOps-Workflow. Die API erlaubt skriptbasiertes Deployment, aber kein vollständiger Policy-as-Code-Ansatz. Score 2 ('GUI-only mit Export-Funktion, kein versionierungsfreundliches Format') trifft weitgehend zu; Score 3 wäre erreichbar mit erheblichem Skriptaufwand, aber ohne dokumentierten Workflow.

3 Granulare Policy-Gate-Aktionen: Blockieren, Warnen, Quarantäne, Notifizieren CTX

Dependency-Track bietet eine Policy-Engine mit konfigurierbaren Regeln und Benachrichtigungen (Warn/Notify), jedoch keinen nativen harten Block auf Artefakt-Ebene oder Quarantäne-Workflow mit Review-Prozess. Block und Warn sind über Policy-Violations und Notifications abbildbar, eine echte Quarantäne-Funktion fehlt nativ.

💡 Begründung: Die Policy-Engine erlaubt Verletzungen als 'FAIL'/'WARN' zu klassifizieren und Notifikationen auszulösen. Ein echter Artefakt-Block (Zugriff verhindern) ist nicht in Dependency-Track selbst implementiert, da es kein Proxy/Repository-Tool ist. Quarantäne mit Review-Workflow existiert nicht nativ. Externe Webhooks können genutzt werden, um downstream Aktionen auszulösen. Das entspricht Score 3 der Skala: Block und Warn konfigurierbar, Quarantäne und differenzierte Notifikation nur über externe Integration abbildbar.

3 Air-Gap / Offline-Betrieb für Vulnerability-Datenfeeds CTX

Dependency-Track erlaubt die Konfiguration der Feed-URLs auf interne Mirror-Adressen, sodass NVD, OSV und andere Feeds theoretisch über interne Spiegel betrieben werden können. Ein offiziell dokumentierter, getesteter Air-Gap-Betriebsmodus mit Signaturprüfung existiert jedoch nicht; die eigenverantwortliche Mirror-Einrichtung ist erforderlich.

💡 Begründung: Die Feed-Endpunkte sind in der Konfiguration anpassbar, was einen Air-Gap-Betrieb prinzipiell ermöglicht, wenn interne Mirrors aufgesetzt werden. Es gibt jedoch keinen offiziell dokumentierten und getesteten Air-Gap-Modus mit Mirror-Prozess und Signaturprüfung. Dies entspricht Score 3: Feed-URL konfigurierbar, aber kein offizieller Air-Gap-Support, eigenverantwortliche Mirror-Einrichtung nötig.

2 Manipulationssicheres Audit-Log mit SIEM-Export (CEF/JSON/Syslog) CTX

Dependency-Track verfügt über ein Activity-Log und Audit-Ereignisse, die über die API und das Notification-Framework exportiert werden können, jedoch fehlt ein dediziertes manipulationssicheres Audit-Log mit append-only-Garantie, nativem SIEM-Export in CEF/Syslog oder vollständiger Abdeckung aller sicherheitsrelevanten Aktionen.

💡 Begründung: Das interne Logging deckt wesentliche Events ab, aber ein strukturierter, manipulationssicherer Audit-Trail mit mehreren SIEM-Export-Formaten (CEF, Syslog, Kafka) ist nicht nativ vorhanden. Notifications können per Webhook an externe Systeme gesendet werden, aber dies ist kein vollständiger Echtzeit-SIEM-Stream mit garantierter Vollständigkeit. Score 2 ist angemessen: rudimentäres Activity-Log, kein strukturierter SIEM-Export nativ, Manipulationsschutz nicht dokumentiert.

3 Horizontale Skalierung des Scanning-Backends für Enterprise-Artefaktvolumen CTX

Dependency-Track 4.11.x unterstützt eine horizontale Skalierung durch Konfiguration mehrerer Worker-Threads und kann per Docker/Kubernetes deployt werden, jedoch erfordert die Skalierung manuelle Konfiguration und es gibt keine offiziellen Enterprise-Performance-Benchmarks für sehr hohe Artefaktvolumen.

💡 Begründung: Die Architektur von Dependency-Track (v4.x) nutzt einen internen Task-Scheduler und Kafka-ähnliche interne Queues (intern über Lucene/Hazelcast), aber keine vollständig native horizontale Queue-basierte Skalierung mit dokumentierten Benchmarks für >10.000 Artefakte/Tag. Kubernetes-Deployment ist möglich aber ohne offiziellen Operator. Score 3 ist passend: Skalierung möglich aber manuelle Konfiguration, keine offiziellen Enterprise-Benchmarks.

5 OWASP-Ökosystem-Alignment und aktive OWASP-Projektmitgliedschaft CTX

Dependency-Track ist ein OWASP Flagship Project mit aktiver Community, regelmäßigen Releases, diversem Contributor-Base und enger Verzahnung mit dem CycloneDX-Standard, der ebenfalls ein OWASP-Projekt ist.

💡 Begründung: Dependency-Track ist eines der prominentesten OWASP Flagship Projects. Es hat regelmäßige Releases, einen aktiven Maintainer (Steve Springett) sowie Community-Contributors aus verschiedenen Organisationen. Die enge Verknüpfung mit CycloneDX (ebenfalls OWASP) und die Apache-2.0-Lizenz erfüllen alle Kriterien für Score 5 vollständig.

3 Native CI/CD-Integration mit Policy-Gate-Rückgabecodes für gängige Pipelines CTX

Dependency-Track bietet eine vollständige REST-API und ein offizielles CLI-Tool (dt-cli / dependency-track-cli), das in beliebige CI/CD-Pipelines integriert werden kann. Native Plugins für Jenkins, GitLab CI, GitHub Actions existieren als Community-Integrationen, jedoch müssen Policy-Parameter oft in der Pipeline oder im CLI-Aufruf konfiguriert werden.

💡 Begründung: Es gibt ein offizielles Jenkins-Plugin und community-getriebene GitHub Actions/GitLab-Integrationen. Die Policy-Konfiguration erfolgt zentral im Tool, aber die Referenzierung im CI/CD geschieht über CLI-Parameter und API-Calls, nicht über ein reines Policy-ID-Referenz-Modell. Ein zentrales Policy-Referenz-Modell ohne Config-Sprawl ist nicht vollständig implementiert. Score 3: CLI vorhanden, in jede Pipeline integrierbar, aber kein zentrales Policy-Referenz-Modell ohne Pipeline-seitige Parametrisierung.

3 Kubernetes-natives Deployment mit Helm-Chart und Operator-Support für HA CTX

Für Dependency-Track existieren Community-Helm-Charts (z.B. auf Artifact Hub), jedoch kein offiziell vom Projekt gepflegtes Helm-Chart mit vollständiger HA-Konfiguration und Kubernetes-Operator. Das primäre Deployment-Modell wird über Docker-Compose dokumentiert, Kubernetes-Betrieb ist möglich aber nicht offiziell first-class supportet.

💡 Begründung: Die offizielle Dokumentation beschreibt Docker-Compose als primären Deployment-Weg. Community-Helm-Charts existieren, sind aber nicht vom OWASP/DT-Projekt offiziell maintained. Ein Kubernetes-Operator fehlt vollständig. HA-Konfiguration ist beschreibbar aber nicht out-of-the-box. Score 3 ist passend: Community-Helm-Chart vorhanden, HA in Dokumentation beschreibbar aber nicht offiziell first-class unterstützt.

2 Compliance-Dashboard und automatisierter Report-Export für NIS2/BSI-Grundschutz CTX

Dependency-Track bietet globale Dashboards mit Vulnerability-Metriken und Portfolio-Übersichten sowie CSV/JSON-Export über die REST-API, jedoch fehlen vorkonfigurierte NIS2/BSI-spezifische Compliance-Dashboards, automatisiertes Scheduling von Reports und mandantenspezifisch gefilterte Report-Exporte out-of-the-box.

💡 Begründung: Das eingebaute Dashboard zeigt aggregierte Metriken (Vulnerability-Trends, Policy-Violations), aber NIS2/BSI-spezifische Metriken wie MTTR oder SLA-Einhaltung sind nicht vorkonfiguriert. Mandantenspezifische Report-Exporte erfordern API-Scripting. PDF-Export existiert nicht nativ. Score 2 ist angemessen: globale Metriken vorhanden, Export primär über API mit eigenem Aufwand, keine mandantenspezifische Scheduling-Funktion.

1 SBOM-Enrichment aus Container-Image-Layern CTX

Dependency-Track ist ein SBOM-Verarbeitungs- und Monitoring-Tool und führt selbst keine Container-Image-Analyse durch. Es verarbeitet eingehende CycloneDX-SBOMs, die von externen Tools (z.B. Syft, Trivy) generiert wurden, hat aber keine native Layer-by-Layer-Container-Image-Analyse-Funktion.

💡 Begründung: Dependency-Track ist explizit ein SBOM-Consumer und kein SBOM-Generator für Container-Images. Die Layer-by-Layer-Analyse muss durch externe Tools wie Syft erfolgen, bevor das SBOM an DT übergeben wird. Eine eigenständige Container-Image-Layer-Analyse oder Layer-Zuordnung im Remediation-Workflow ist nicht vorhanden. Score 1 ist korrekt: keine native Container-Image-Analyse-Funktion.

4 EPSS-Score-Integration und priorisierungsbasiertes Triage-Routing CTX

Dependency-Track integriert EPSS-Scores nativ als Feed und zeigt diese in der UI und API an. EPSS-Werte können in der Policy-Engine als Kriterium genutzt werden, was automatisches Triage-Routing auf Basis von EPSS-Schwellenwerten ermöglicht – alles in der OSS-Edition verfügbar.

💡 Begründung: Gemäß den bekannten Features integriert Dependency-Track EPSS als nativen Feed (in den Bekannten Features explizit erwähnt). EPSS-Scores sind in der Policy-Engine nutzbar. Die Kombination mit CVSS für kombinierte Schwellenwerte ist teilweise vorhanden, aber vollständig automatisches kombiniertes CVSS+EPSS-Routing mit allen Feinheiten ist möglicherweise nicht vollständig ausgebaut. Konservativ Score 4: EPSS nativ integriert, in Policy nutzbar, automatisches Routing teilweise vorhanden.

4 CISA KEV (Known Exploited Vulnerabilities) Catalogue-Integration CTX

Dependency-Track 4.11.x integriert den CISA KEV Catalogue als automatisch synchronisierten Feed nativ, der KEV-Status ist in der UI und API sichtbar und kann in Policy-Regeln als Kriterium genutzt werden. Ein vollständig dokumentierter Air-Gap-fähiger Offline-Import des KEV-Feeds ist nicht explizit als offizielle Funktion ausgewiesen.

💡 Begründung: Der CISA KEV-Feed wurde in neueren Versionen von Dependency-Track (ab ca. 4.9/4.10) als nativer Feed integriert. Der KEV-Status ist als Policy-Kriterium verwendbar. Der Air-Gap-Import ist nicht explizit dokumentiert für KEV. Score 4 ist passend: KEV-Integration vorhanden und in Policy nutzbar, Offline-Import/Air-Gap eingeschränkt, OSS-Edition.

2 Mandantenspezifische Vulnerability-Feed-Konfiguration und -Isolation CTX

Dependency-Track konfiguriert Vulnerability-Feeds global für die gesamte Instanz; eine mandantenspezifische Feed-Konfiguration mit isolierten Quellen, Intervallen und Vertrauensstufen pro Team oder Projekt-Hierarchie ist nicht nativ unterstützt. Mandantenspezifische Filter auf Ergebnisebene sind über RBAC und Teams begrenzt möglich.

💡 Begründung: Die Feed-Konfiguration in Dependency-Track ist eine globale Administrator-Einstellung, die für alle Projekte und Teams gilt. Es gibt keine Möglichkeit, pro Mandant/Team unterschiedliche Feeds, Intervalle oder Vertrauensstufen zu konfigurieren. Das RBAC-Modell trennt Sichtbarkeit, nicht Feed-Konfiguration. Score 2 ist angemessen: globale Konfiguration gilt für alle, nur manuelle Workarounds auf Ergebnisebene möglich.

2 Rückmeldung von Scan-Ergebnissen in Artifactory-Properties/Metadata CTX

Dependency-Track bietet keine native Funktion, um Scan-Ergebnisse als Properties direkt in Artifactory zurückzuschreiben. Über die REST-API und externe Skripte ist eine solche Integration technisch realisierbar, erfordert jedoch vollständig selbst entwickelte Glue-Code-Lösungen.

💡 Begründung: Die Bewertungsskala sieht Score 2 für 'Keine direkte Artifactory-Integration, nur manuelle/externe Lösungen ohne Tool-Support' vor. Dependency-Track hat keine dokumentierte oder out-of-the-box Artifactory-Property-Schreib-Funktion; externe Skripte, die die D-T REST-API abfragen und dann die Artifactory REST-API beschreiben, sind möglich, aber vollständig nutzerseitig zu implementieren.

2 Automatisierte OSS-Komponenten-Attributionslisten-Generierung (NOTICE-Dateien) CTX

Dependency-Track bietet Lizenz-Compliance und SPDX-Lizenz-Identifikation sowie einen CSV/JSON-Export von Komponenteninformationen, aber keine automatisierte Generierung von rechtlich verwendbaren NOTICE-Dateien mit vollständigen Lizenztexten.

💡 Begründung: Score 2 auf der Skala entspricht 'Nur rudimentärer CSV/JSON-Export der Lizenzinformationen ohne Formatierung für rechtliche Dokumente'. Dependency-Track zeigt Lizenzinformationen im UI und ermöglicht Exporte, aber das Erstellen vollständiger Attributionsdokumente mit eingebetteten Lizenztexten und Copyright-Notices in HTML/PDF/TXT ist keine Kernfunktion des Tools.

2 Trusted-Component-Registry und positives Whitelisting für Organisationen CTX

Dependency-Track bietet eine Policy-Engine, mit der Komponenten über Tags, PURLs oder Lizenzen als 'approved' oder 'not approved' markiert werden können, jedoch kein vollständiges Whitelist-Konzept mit Ablaufdaten, Freigabe-Workflows und Verantwortlichkeiten.

💡 Begründung: Score 2 entspricht 'Nur globale Suppress-/Ignore-Funktion, kein dediziertes Whitelist-Konzept mit Governance'. Die Policy-Engine erlaubt zwar Tag-basierte Freigaben, aber versionsgranulares Whitelisting mit Ablaufdaten, formalem Freigabe-Workflow mit Approver und mandantenübergreifender Gültigkeit ist nicht vorhanden.

3 Transitive Dependency-Auflösung und Tiefenanalyse für SBOM-Vollständigkeit CTX

Dependency-Track verarbeitet CycloneDX-SBOMs, die transitive Abhängigkeiten enthalten können, löst diese jedoch nicht selbst auf – es ist auf die Vollständigkeit der eingereichten SBOM angewiesen. Für Binaries ohne Quellcode gibt es keine eigenständige Auflösungsfähigkeit.

💡 Begründung: Score 3 ('Transitive Auflösung bis 2-3 Ebenen, keine Vollständigkeitsprüfung, Standard-Ökosysteme abgedeckt') trifft am ehesten zu, wobei Dependency-Track selbst keine aktive Auflösung vornimmt, sondern die im CycloneDX-SBOM bereits vorhandene Tiefe verwaltet. Ein Vollständigkeits-Score oder expliziter Nachweis gegenüber Auditoren existiert nicht nativ.

2 Datenbankpartitionierung und Archivierungsstrategie für Langzeit-SBOM-Daten CTX

Dependency-Track bietet keine dokumentierte Datenbankpartitionierungsstrategie oder automatisierte Retention/Archivierungs-Policies. Datenwachstum muss über externe Datenbankoperationen und -wartung verwaltet werden.

💡 Begründung: Score 2 entspricht 'Keine dokumentierte Archivierungsstrategie, Datenwachstum muss extern verwaltet werden'. In der offiziellen Dokumentation finden sich allgemeine Hinweise zur Datenbankwartung, aber keine konfigurierbare Retention-Policy, keine automatisierte Archivierung und keine Wiederherstellungsfunktion für archivierte SBOM-Versionen.

3 Webhook- und Event-Bus-Integration für asynchrone Event-Driven-Architektur CTX

Dependency-Track verfügt über ein Notification-Framework, das Webhooks an externe Systeme senden kann (Slack, Teams, E-Mail, generische Webhooks). Es fehlen jedoch Retry-Logik, mandantenspezifische Event-Filterung und eine native Message-Bus-Integration (Kafka/AMQP).

💡 Begründung: Score 3 ('Grundlegende Webhook-Unterstützung ohne Retry-Logik, keine mandantenspezifische Filterung, keine Message-Bus-Integration') trifft zu. Die Webhook-Unterstützung ist vorhanden und konfigurierbar für diverse Event-Typen, aber Retry-Mechanismen bei Fehlern und eine mandantenspezifische Filterung fehlen; Kafka-Integration erfordert externe Adapter.

1 Malware- und Typosquatting-Erkennung für Registry-Proxies CTX

Dependency-Track bietet keine Malware-Erkennung oder Typosquatting-Heuristiken. Es fokussiert sich auf CVE/PURL-basiertes Vulnerability-Tracking und hat keine Integration der OSSF Malicious Packages Database oder ähnlicher Feeds für diese Zwecke.

💡 Begründung: Score 1 ('Keine Malware- oder Typosquatting-Erkennung, vollständige Restlücke gegenüber JFrog Curation') ist korrekt. Diese Funktion liegt außerhalb des Kern-Feature-Sets von Dependency-Track; bekannte Malware-Packages wären nur dann indirekt erkennbar, wenn sie explizit CVEs hätten, was bei vielen Typosquatting-Paketen nicht der Fall ist.

1 Softwareintegrität und Artefakt-Signatur-Verifikation (Sigstore/Cosign) CTX

Dependency-Track unterstützt keine Sigstore/Cosign-Signatur-Verifikation und bietet keine Integration mit Rekor oder anderen Transparency-Logs. Artefakt-Integrität wird nicht als Policy-Gate-Kriterium behandelt.

💡 Begründung: Score 1 ('Keine Artefakt-Integritäts- oder Signatur-Verifikation') ist zutreffend. Dependency-Track ist auf SBOM-Ingest und Vulnerability-Monitoring ausgerichtet; Signatur-Verifikation nach Sigstore/Cosign-Standard ist weder in der aktuellen Version 4.11.x vorhanden noch als nahe Roadmap-Feature dokumentiert.

1 Ressourcen-Quotierung und Rate-Limiting pro Mandant (Fair-Use-Enforcement) CTX

Dependency-Track bietet keinerlei mandantenspezifische Ressourcen-Quotierung, API-Rate-Limiting oder Speicher-Kontingente. Es ist kein Multi-Tenant-System im eigentlichen Sinne und hat keine Fair-Use-Enforcement-Mechanismen.

💡 Begründung: Score 1 ('Keine Rate-Limiting- oder Quota-Mechanismen vorhanden') ist korrekt. Dependency-Track ist als Single-Tenant-On-Premise-Tool konzipiert; es fehlen sowohl globale als auch mandantenspezifische Rate-Limits, Scan-Parallelitätskontrolle pro Team und Speicher-Quotas.

4 SBOM-as-a-Service API für externe Tool-Integration (SBOM-Upload und -Abfrage) CTX

Dependency-Track bietet eine umfangreiche REST-API für SBOM-Upload (CycloneDX/SPDX), Ergebnis-Abfrage und Policy-Gate-Integration, die über eine OpenAPI-Spezifikation dokumentiert ist. Eine explizite Versionierungsstrategie mit Rückwärtskompatibilitätsgarantie fehlt jedoch.

💡 Begründung: Score 4 ('REST-API vorhanden und funktional vollständig, OpenAPI-Spec verfügbar, aber ohne explizite Versionierungsstrategie oder Rückwärtskompatibilitätsgarantie') trifft zu. Die API ist sehr gut dokumentiert, vollständig funktional und OpenAPI-spezifiziert, aber formale Versionierungscommitments und explizite Rückwärtskompatibilitätsgarantien sind nicht Teil des Community-Projekts.

3 Regulatorische Berichtspflichten: CRA (Cyber Resilience Act) SBOM-Anforderungen CTX

Dependency-Track implementiert CycloneDX 1.5+ vollständig und unterstützt SBOM-Export, was die technische Basis für CRA-Konformität bildet. Eine explizite CRA-Compliance-Unterstützung, Vollständigkeitsvalidierung gegen CRA-Anforderungen oder dokumentierte CRA-Roadmap ist jedoch nicht vorhanden.

💡 Begründung: Score 3 ('Keine explizite CRA-Unterstützung, aber SBOM-Standards vollständig implementiert, CRA-Konformität über externe Validierung erreichbar') ist passend. Als OWASP-Community-Projekt arbeitet Dependency-Track eng mit dem CycloneDX-Standard zusammen, der CRA-Anforderungen technisch abbilden kann, aber CRA-spezifische Workflows und Behörden-Exporte sind nicht nativ implementiert.

3 Dependency-Track-Migrationsbrücke: Erhalt historischer Triage-Daten CTX

Da Dependency-Track das zu migrierende System selbst ist (es ist das Baseline-Tool), ist diese Anforderung im Kontext einer eventuellen Ergänzung oder eines Wechsels relevant: CycloneDX-SBOM-Export und VEX-Export sind möglich, aber ein dediziertes Migrations-Tool für Triage-Metadaten in ein anderes System existiert nicht.

💡 Begründung: Score 3 ('CycloneDX-SBOM-Import möglich, aber Triage-Status und Suppressions müssen manuell neu erfasst werden, kein dediziertes Migrationswerkzeug') trifft zu. Dependency-Track kann seine Daten über die REST-API und CycloneDX/VEX-Exporte exportieren, aber ein explizit unterstützter Migrations-Workflow mit Erhalt der Triage-Provenienz in ein Zielsystem ist nicht dokumentiert.

3 Zentraler Service-Delivery-Modus: Self-Service-Onboarding für Sub-Organisationen ohne Admin-Eskalation CTX

Dependency-Track bietet ein granulares RBAC-System mit Team- und Projekthierarchien, jedoch erfordert das Anlegen neuer Teams und Projekte in der Regel globale Admin-Rechte. Tenant-Admins haben eingeschränkte Verwaltungsoptionen innerhalb ihrer Projektgrenzen, ein vollständiges delegiertes Self-Service-Onboarding-Modell ohne zentrale IT-Eskalation ist nicht dokumentierter Betriebsmodus.

💡 Begründung: Dependency-Track bietet Rollen wie Portfolio Manager und Project Administrator, die gewisse Verwaltungsaufgaben übernehmen können. Jedoch ist das Anlegen neuer Teams, die globale Berechtigungsvergabe und das Onboarding neuer Sub-Organisationen typischerweise an globale Admin-Rechte gebunden. Es fehlt ein echtes Mandanten-Admin-Konzept mit unveränderlichen Guardrail-Policies von oben. Dies entspricht Skala 3: Rollenkonzept vorhanden, aber Onboarding neuer Projekte/Teams erfordert globalen Admin.

2 Reachability-Analyse: Exploitierbarkeits-Kontextbewertung auf Basis tatsächlicher Code-Nutzung CTX

Dependency-Track bietet keine native Reachability-Analyse oder Call-Graph-basierte Kontextbewertung. Als Proxy für Exploitierbarkeit stehen EPSS-Scores und CVSS-Werte zur Verfügung, ergänzt durch VEX für manuelle Kontextanreicherung.

💡 Begründung: Dependency-Track ist ein SBOM-basiertes Monitoring-Tool, das CVEs gegen Komponentenlisten prüft, aber keine Code-Analyse oder Call-Graph-Auswertung durchführt. EPSS-Integration ist vorhanden als Exploitierbarkeits-Proxy. VEX erlaubt manuelle Kontextanreicherung, ersetzt aber keine automatisierte Reachability-Analyse. Dies entspricht Skala 2: Keine Reachability-Analyse, lediglich EPSS/CVSS als Proxy verfügbar.

3 Operative Observability des Security-Services: Interne Metriken, Health-Checks und Kapazitätsplanung CTX

Dependency-Track exponiert Basis-Metriken über einen Prometheus-kompatiblen Endpunkt und bietet Health-Check-Endpoints, die für Kubernetes-Probes genutzt werden können. OpenTelemetry-Tracing und mandantenspezifische Nutzungsmetriken für Showback/Chargeback sind jedoch nicht nativ verfügbar.

💡 Begründung: Ab Version 4.x bietet Dependency-Track einen /metrics-Endpunkt mit Prometheus-Metriken primär auf JVM- und System-Ebene sowie Applikations-Metriken. Health-Endpoints (/health) sind vorhanden. OpenTelemetry-Tracing ist nicht nativ integriert, und eine Tenant-Dimensionierung der Metriken existiert nicht. Dies entspricht Skala 3: Basis-Metriken per Prometheus, einfache Health-Endpoints, keine Tenant-Aufschlüsselung, kein natives Tracing.

2 Differenziertes Ausnahme- und Dispensationsmanagement mit Genehmigungsworkflow und Ablaufdatum CTX

Dependency-Track ermöglicht das Unterdrücken von Findings mit optionalem Kommentar und VEX-basierter Statusdokumentation, bietet jedoch keinen formalisierten Genehmigungsworkflow mit Vier-Augen-Prinzip, Ablaufdatum oder automatischer Eskalation. Suppressions können von berechtigten Nutzern ohne Genehmigungsprozess gesetzt werden.

💡 Begründung: Die Suppression-Funktionalität in Dependency-Track erlaubt das Setzen eines Analyse-Status (z.B. NOT_AFFECTED, FALSE_POSITIVE) mit Kommentarfeld. Ein Ablaufdatum, ein Mehr-Augen-Genehmigungsprozess oder eine automatische Eskalation bei Ablauf sind nicht implementiert. Der Audit-Trail ist rudimentär über die Analyse-History vorhanden. Dies entspricht Skala 2: Suppressions mit optionalem Kommentar, kein Ablaufdatum, keine Genehmigungslogik, nur rudimentärer Audit-Trail.

3.8 Produkt-Features

4 SBOM-Import (CycloneDX & SPDX) FEAT

Dependency-Track bietet erstklassige CycloneDX-Unterstützung als Referenzimplementierung; SPDX wird ebenfalls importiert, jedoch mit eingeschränkterem Funktionsumfang im Vergleich zu CycloneDX.

💡 Begründung: CycloneDX-Support ist Best-in-Class, da Dependency-Track die Referenzimplementierung ist. SPDX-Import ist vorhanden, aber weniger ausgereift und vollständig als CycloneDX, daher kein voller Score von 5 gemäß der Skala.

4 SBOM-Export & Supply-Chain-Transparenz FEAT

Dependency-Track ermöglicht den Export von SBOMs im CycloneDX-Format für alle verwalteten Projekte und unterstützt damit Supply-Chain-Transparenz gegenüber Dritten.

💡 Begründung: SBOM-Export in CycloneDX ist gut implementiert und übertrifft die Mindestanforderung. SPDX-Export ist eingeschränkt, was einen Score von 5 verhindert; dennoch ist die Kernfunktion solide erfüllt.

2 SBOM-Qualitätsbewertung FEAT

Dependency-Track bietet keine dedizierte SBOM-Qualitätsbewertungsfunktion; es gibt keine strukturierten Scores oder Berichte zur Vollständigkeit importierter SBOMs.

💡 Begründung: Eine explizite SBOM-Qualitätsbewertung (z.B. nach NTIA-Mindestanforderungen oder ähnlichen Metriken) ist in Dependency-Track 4.11.x nicht vorhanden. Es werden lediglich fehlende PURLs oder Hashes implizit sichtbar, was rudimentär ist und erhebliche Lücken gegenüber der Anforderung aufweist.

4 SBOM-Versionierung & historischer Vergleich FEAT

Dependency-Track speichert SBOM-Versionen historisch und ermöglicht den Vergleich zwischen Versionen, um neue, entfernte oder geänderte Komponenten nachzuvollziehen.

💡 Begründung: Das Feature ist laut bekannter Produktbeschreibung vorhanden und funktional. Es übertrifft die Mindestanforderung, erreicht aber aufgrund begrenzter UI-Diff-Tiefe und fehlender erweiterter Diff-Funktionen keinen vollen Score von 5.

5 Standardisierte Komponenten-Identifikation (PURL) FEAT

Dependency-Track verwendet PURL als primären Identifikationsmechanismus für alle Komponenten und gewährleistet damit ökosystemübergreifende Eindeutigkeit und Vergleichbarkeit.

💡 Begründung: PURL-basierte Identifikation ist ein Kernprinzip von Dependency-Track; alle Vulnerability-Lookups und Deduplizierungen basieren darauf. Dies entspricht Best-in-Class gemäß der Skala.

4 Interne Komponenten-Datenbank mit Deduplizierung FEAT

Dependency-Track führt eine zentrale interne Komponenten-Datenbank mit automatischer Deduplizierung auf Basis von PURL und anderen Identifikatoren über alle Projekte hinweg.

💡 Begründung: Die interne Datenbank mit Deduplizierung ist ein bekanntes Feature und gut implementiert. Ein Score von 5 wird nicht vergeben, da die Deduplizierungslogik bei unsauberen SBOMs (fehlende PURLs) an Grenzen stößt.

5 Kontinuierliches Vulnerability Monitoring FEAT

Kontinuierliches Vulnerability Monitoring ist ein Kernmerkmal von Dependency-Track: Neue CVEs werden automatisch gegen alle gespeicherten Komponenten abgeglichen, ohne erneuten Scan.

💡 Begründung: Dies ist eines der zentralen Differenzierungsmerkmale gegenüber reinen CI-Scan-Tools und in Dependency-Track vollständig und ausgereift implementiert – entspricht dem Best-in-Class-Kriterium der Skala.

5 Multi-Feed Vulnerability Aggregation FEAT

Dependency-Track integriert gleichzeitig NVD, OSV, GitHub Advisories sowie weitere Feeds und aggregiert diese zu einer einheitlichen Schwachstellenansicht pro Komponente.

💡 Begründung: Multi-Feed-Aggregation ist ein zentrales, ausgereiftes Feature mit breiter Quellenabdeckung. Es entspricht dem Best-in-Class-Kriterium der Skala und übertrifft viele kommerzielle Alternativen in der Quellenvielfalt.

4 CVSS- & EPSS-Score-Integration FEAT

Dependency-Track zeigt CVSS v2 und v3 sowie EPSS-Scores an; CVSS v4 wird in Version 4.11.x noch nicht vollständig unterstützt.

💡 Begründung: CVSS v2/v3 und EPSS sind gut integriert und ermöglichen risikobasierte Priorisierung. Die fehlende oder noch nicht vollständige CVSS v4-Unterstützung in 4.11.x verhindert den vollen Score gemäß der Anforderung.

5 VEX (Vulnerability Exploitability eXchange) Support FEAT

Dependency-Track unterstützt sowohl den Import als auch den Export von VEX-Dokumenten im CycloneDX-Format und ist die Referenzimplementierung für diesen Standard.

💡 Begründung: VEX-Support ist ein zentrales, ausgereiftes Feature von Dependency-Track, das als CycloneDX-Referenzimplementierung Best-in-Class-Status verdient. Import und Export sind vollständig implementiert.

3 Vulnerability Lifecycle Management & Triage-Workflows FEAT

Dependency-Track bietet grundlegende Triage-Funktionen wie Analyse-States (False Positive, Not Affected, Suppressed) und Risk Acceptance, aber keinen vollständig strukturierten Workflow mit Aufgaben, Fristen oder Eskalation.

💡 Begründung: Die grundlegenden Lifecycle-States und Suppression-Mechanismen erfüllen das Minimum der Anforderung. Für einen vollständigen, strukturierten Triage-Workflow mit Ticket-Integration, Fristen und Eskalationspfaden sind externe Tools nötig, was erhebliche Lücken gegenüber einem Score von 4 oder 5 bedeutet.

4 Konfigurierbare Policy Engine FEAT

Die integrierte Policy-Engine erlaubt die Definition von Regeln zu Lizenzen, Schweregrad-Schwellenwerten, Komponenten-Blacklists und PURL-Patterns mit automatischer Durchsetzung und Benachrichtigung.

💡 Begründung: Die Policy-Engine ist funktional und deckt die wesentlichen Compliance-Anwendungsfälle ab, was die Anforderung übertrifft. Komplexere Policy-Logik (z.B. UND/ODER-Verknüpfungen, kontextabhängige Regeln) ist begrenzt, daher kein Score von 5.

3 Lizenz-Compliance & SPDX-Identifikation FEAT

Dependency-Track identifiziert SPDX-konforme Lizenzinformationen aus importierten SBOMs und kann Policy-Regeln auf Basis von Lizenzen konfigurieren. Eine aktive Quellcode-Analyse zur Lizenzerkennung (Source-Code-Scanning) ist jedoch nicht enthalten – es wird ausschließlich auf SBOM-Metadaten zurückgegriffen.

💡 Begründung: Die Anforderung umfasst explizit auch Quellcode-Scans zur Lizenzerkennung, was Dependency-Track nicht leistet. Die SBOM-basierte SPDX-Identifikation und Policy-Engine erfüllen das Minimum, übertreffen es aber nicht wesentlich, weshalb Score 3 angemessen ist.

2 SLA-Tracking für Schwachstellen FEAT

Dependency-Track bietet keine nativen, konfigurierbaren SLA-Fristen pro Schweregrad mit automatischer Eskalation. Über die Policy-Engine und das Notification-Framework lassen sich behelfsmäßig Regeln definieren, aber ein dediziertes SLA-Tracking mit Fristüberwachung und Eskalations-Workflows ist nicht vorhanden.

💡 Begründung: Ein dediziertes SLA-Modul fehlt vollständig. Die vorhandenen Policy- und Notification-Features können SLA-Szenarien nur rudimentär und mit manuellem Aufwand abbilden. Dies entspricht Score 2 (rudimentär, erhebliche Lücken).

4 Hierarchische Projekt- und Portfolio-Strukturierung FEAT

Dependency-Track unterstützt hierarchische Eltern-Kind-Beziehungen zwischen Projekten, sodass Portfolio-, Produkt- und Projektebenen modelliert werden können. Risiken lassen sich auf den verschiedenen Aggregationsebenen einsehen, wenngleich das Portfolio-Aggregations-Reporting noch Einschränkungen gegenüber spezialisierten Tools aufweist.

💡 Begründung: Die Funktionalität ist gut ausgebaut und übertrifft die Mindestanforderung. Vollständige, mehrstufige Portfolio-Hierarchien mit tiefgehender Aggregationsanalyse sind möglich, jedoch nicht ganz so ausgereift wie bei kommerziellen Alternativen – Score 4 ist angemessen.

4 Konfigurierbares Notification & Alerting Framework FEAT

Dependency-Track verfügt über ein konfigurierbares Notification-Framework, das E-Mail, Slack, MS Teams und Webhooks unterstützt. Benachrichtigungen werden bei neuen Schwachstellen, Policy-Verletzungen und weiteren Ereignissen ausgelöst und sind granular auf Projekte und Ereignistypen einschränkbar.

💡 Begründung: Die Unterstützung der geforderten Kanäle (E-Mail, Slack, Teams, Webhooks) ist nativ vorhanden und gut konfigurierbar. SLA-spezifische Eskalationsbenachrichtigungen fehlen, da SLA-Tracking nicht nativ existiert. Für den allgemeinen Alerting-Scope ist Score 4 gerechtfertigt.

3 Dashboards & Risiko-Scoring (Projekt & Portfolio) FEAT

Dependency-Track bietet eingebaute Dashboards mit Severity-Verteilungen, Risiko-Scores auf Projekt- und Portfolio-Ebene sowie grundlegende Trendanzeigen. Die Dashboards sind funktional, aber wenig anpassbar und bieten keine erweiterten Trend-Analysen oder benutzerdefinierten Visualisierungen.

💡 Begründung: Die Mindestanforderung (aggregierte Risiko-Scores, Severity-Verteilung, Portfolio-Überblick) ist erfüllt. Fehlende Anpassbarkeit und begrenzte Trendanalyse-Tiefe verhindern einen höheren Score – Score 3 (ausreichend, erfüllt das Minimum) ist passend.

2 Automatisierte Bericht-Generierung FEAT

Dependency-Track bietet keinen nativen automatisierten Report-Generator für PDF- oder HTML-Berichte im Sinne von Executive Summaries oder technischen Detailberichten. Daten können über die REST-API exportiert werden, und es gibt einen einfachen SBOM-Export, aber keine vorgefertigten anpassbaren Berichtsformate.

💡 Begründung: Automatisierte, anpassbare Berichte in PDF/HTML sind eine bekannte Lücke in Dependency-Track. Die Möglichkeit, Daten per API zu extrahieren und extern zu verarbeiten, ist nur eine rudimentäre Behelfslösung – Score 2 ist konservativ aber zutreffend.

5 CI/CD-Integration via REST-API & CLI FEAT

Dependency-Track bietet eine vollständige, dokumentierte REST-API für alle Kernfunktionen sowie offizielle Integrationen für Jenkins, GitHub Actions, GitLab CI und andere Plattformen. SBOM-Uploads, Policy-Checks und Ergebnisabfragen lassen sich vollständig automatisiert in CI/CD-Pipelines einbetten.

💡 Begründung: Dies ist eine der herausragenden Stärken von Dependency-Track. Die REST-API ist vollständig, gut dokumentiert, und es existieren zahlreiche Community- und offizielle Plugins für gängige CI/CD-Systeme. Score 5 (Best-in-Class) ist gerechtfertigt.

3 Granulares RBAC mit Multi-Tenancy-Unterstützung FEAT

Dependency-Track bietet feingranulares RBAC auf Team- und Projektebene mit OIDC/SAML-SSO-Integration. Eine echte Multi-Tenancy-Isolation (separate Mandanten mit vollständiger Datenisolation) ist jedoch nicht nativ unterstützt – alle Teams teilen eine gemeinsame Instanz ohne harte Mandantentrennung.

💡 Begründung: Das RBAC ist funktional und granular (Teams, Projekte, Rollen, Berechtigungen), erfüllt aber Multi-Tenancy nur über RBAC-basierte Sichtbarkeitssteuerung und nicht durch echte Mandantenisolation. Dies entspricht dem Minimum der Anforderung – Score 3 ist angemessen.

ANBIETER

OWASP / Community

PRODUKT

DefectDojo

DEPLOYMENT

On-Premise

WEBSITE

https://owasp.org/www-project-defectdojo/

GESAMTSCORE

2.97/5

3.0 Integration

4 General Interfaces/APIs INT

DefectDojo bietet eine vollständige, dokumentierte REST-API (inkl. OpenAPI/Swagger-Dokumentation), über die nahezu alle Frontend-Funktionalitäten programmatisch zugänglich sind. Es existieren zahlreiche Out-of-the-box-Integrationen (180+ Tool-Importer, JIRA, Slack, MS Teams, Webhooks) sowie CI/CD-Unterstützung, jedoch sind dedizierte Middleware-/ESB-Konnektoren (PI, CPI, EDI-Manager) nicht nativ vorhanden.

💡 Begründung: Die REST-API ist vollständig und gut dokumentiert (Swagger UI), gängige Integrationen (JIRA, Slack, CI/CD-Pipelines) sind out-of-the-box verfügbar. Für klassische Enterprise-Middleware (SAP CPI, MuleSoft, etc.) gibt es keine fertigen Konnektoren, was den Score auf 4 statt 5 begrenzt.

2 Interface monitoring INT

DefectDojo bietet keinen dedizierten Interface-Monitoring-Mechanismus; es existiert ein einfacher Health-Check-Endpoint (/api/v2/), aber keine eingebauten Dashboards oder Diagnose-Tools zur Überwachung der Verfügbarkeit und Performance angebundener Schnittstellen. Logging erfolgt über Standard-Systemlogs, die manuell ausgewertet werden müssen.

💡 Begründung: Es gibt einen grundlegenden Health-Endpoint und System-Logs, aber kein natives Interface-Monitoring, keine Performance-Metriken für Schnittstellen und keine operativen Diagnose-Tools. Das entspricht gemäß Skala eher 'Limited monitoring support' (Score 2), da selbst ein 'Basic monitoring via logs' nur eingeschränkt strukturiert vorhanden ist.

3.0 Non-Functional Requirements

3 Authorization NFR

DefectDojo bietet vordefinierte Rollen (Admin, Maintainer, Writer, Reader) und weist diese pro Produkt/Engagement zu. Granulare, pfadbasierte oder vollständig anpassbare RBAC-Konfigurationen sind nicht vorhanden.

💡 Begründung: Die Rollen sind im Wesentlichen statisch und vordefiniert, können aber pro Produkt vergeben werden. Es gibt keine ABAC-Policies oder fein granulare Pfad-Filterung, was Score 3 (Static RBAC, per-project assignment) entspricht.

3 IDM connection NFR

DefectDojo unterstützt SAML 2.0 und LDAP für Authentifizierung; eine automatische Provisionierung über SCIM ist nicht nativ vorhanden. OIDC-Unterstützung ist via Social-Auth möglich, aber ohne vollständigen Group-Lifecycle.

💡 Begründung: Da SAML/LDAP unterstützt wird, aber kein vollständiges SCIM-basiertes Provisioning angeboten wird, passt Score 3 (Legacy Auth & Basic Provisioning via SAML/LDAP) am besten.

4 Single Sign-On NFR

DefectDojo unterstützt OIDC (via django-allauth/Social Auth) und SAML 2.0, beides kann kundenseitig in der Konfiguration eingerichtet werden. Beide Protokolle sind dokumentiert und konfigurierbar ohne Vendor-Eingriff.

💡 Begründung: Sowohl OIDC als auch SAML werden unterstützt und sind selbst konfigurierbar. Die UI-Unterstützung ist jedoch primär konfigurationsdateibasiert, nicht per Self-Service-UI; dennoch sind beide Protokolle verfügbar, was Score 4-5 nahelegt. Konservativ Score 4, da keine vollwertige Self-Service-UI für beide existiert.

3 Client/Instances NFR

DefectDojo trennt Daten durch eine hierarchische Produkt-/Engagement-Struktur und RBAC auf Produktebene. Eine echte Multi-Tenancy mit vollständig isolierten Mandanten (eigene User-Namespaces, Org-Einheiten) ist nicht vorhanden.

💡 Begründung: Die Datentrennung erfolgt über Produktzuweisungen und Berechtigungen, aber User-Management ist global und es gibt keine vollständige logische Mandantentrennung. Das entspricht Score 3 (Basic Repository-Level Separation).

4 Storage of data (Metadata) NFR

DefectDojo erfordert eine externe relationale Datenbank; PostgreSQL wird offiziell als primäre Produktionsdatenbank unterstützt und empfohlen. MySQL wird ebenfalls unterstützt, die Auswahl ist aber auf diese Systeme begrenzt.

💡 Begründung: Eine externe Datenbank ist für den Produktionsbetrieb obligatorisch, jedoch ist die Unterstützung auf PostgreSQL (primär) und MySQL beschränkt, was Score 4 (Specific External DB, Mandatory) entspricht.

2 Data/Object Storage Backend Flexibility NFR

DefectDojo speichert seine Kerndaten (Findings, Metadaten) in der relationalen Datenbank; für Datei-Uploads (z.B. Berichte) wird standardmäßig das lokale Dateisystem genutzt. Native Cloud-Object-Storage-Integration ist nicht dokumentiert.

💡 Begründung: Es gibt keine native S3/Azure Blob/GCS-Integration für Object Storage. Workarounds über gemountete Dateisysteme (NFS/S3-FUSE) wären möglich, aber nicht nativ unterstützt. Score 2 (Custom Plugins/Workarounds) ist konservativ zutreffend.

2 Data Archiving & Cleanup NFR

DefectDojo bietet keine eingebaute Policy-Engine für automatisches Archivieren oder Löschen alter Findings/Engagements. Bereinigungen müssen über die REST-API oder manuelle UI-Aktionen durchgeführt werden.

💡 Begründung: Es existiert keine automatisierte Archivierungs- oder Cleanup-Funktion mit konfigurierbaren Regeln. API-basierte Skripte wären notwendig, was Score 2 (Manual Cleanup via API/Scripts) entspricht.

4 Hosting Flexibility NFR

DefectDojo wird als Open-Source-Projekt ausschließlich selbst gehostet bereitgestellt; offizielle Docker-Images und Helm-Charts für Kubernetes ermöglichen PaaS-Deployments auf AWS, Azure oder GCP. Ein Vendor-managed SaaS existiert nicht.

💡 Begründung: Starke Unterstützung für On-Premise und PaaS (Kubernetes/Docker mit Helm-Charts), aber kein Vendor-SaaS-Angebot. Das entspricht Score 4 (Strong PaaS & On-Premise).

5 Hardware and Component Requirements NFR

DefectDojo ist vollständig containerisiert (Docker Compose und Helm/Kubernetes), hat einen moderaten Ressourcenbedarf und läuft auf Standard-Hardware. Offizielle Docker-Images sind verfügbar.

💡 Begründung: Als containerisierte Anwendung mit geringem Footprint (läuft auf Standard-VMs oder kleinen Kubernetes-Clustern) erfüllt DefectDojo die Anforderungen für Score 5 (sehr geringer Footprint, containerisiert lauffähig).

4 Installation Mode (automatic / manual) NFR

DefectDojo stellt offizielle Docker-Compose-Dateien und Helm-Charts bereit, die die Installation weitgehend automatisieren. Ein Kommando genügt für eine Basis-Installation via Docker Compose; manuelle Konfigurationsschritte für Produktionsumgebungen bleiben notwendig.

💡 Begründung: Die Installation ist durch offizielle Scripts (docker-compose up) weitgehend automatisiert, erfordert aber manuelle Konfiguration von Secrets, Datenbankverbindungen und SMTP. Score 4 (Scripted Installation) trifft zu.

1 Multi-location Deployment Options NFR

DefectDojo ist für Single-Instance-Deployments ausgelegt; es gibt keine nativen Replikations-, Federations- oder Multi-Location-Synchronisierungsfunktionen. Ein zentrales Daten-Repository für verteilte Umgebungen wird nicht unterstützt.

💡 Begründung: Keine eingebauten Features für Multi-Location-Deployment, Replikation oder Federation. Das entspricht Score 1 (Not Supported).

3 Application Performance NFR

DefectDojo bietet adäquate Performance für typische Vulnerability-Management-Workloads; bei sehr großen Datenmengen (hunderttausende Findings) sind Datenbankoptimierungen und Tuning erforderlich. Caching-Mechanismen sind begrenzt.

💡 Begründung: Für Standard-Workloads ist die Performance ausreichend, aber bei Enterprise-Skalierung (große Mengen an Scans/Findings) sind bekannte Performance-Herausforderungen dokumentiert. Score 3 (Adequate for standard workloads, larger workloads require tuning) ist angemessen.

3 Scalability (manage increase No. of users) NFR

DefectDojo kann horizontal skaliert werden (Docker/Kubernetes-Deployment), jedoch erfordert dies manuelle Konfiguration und Tuning. Für standardmäßige Enterprise-Lasten funktioniert es mit sorgfältiger Einrichtung, jedoch fehlen native Auto-Scaling-Mechanismen oder dokumentierte Concurrency-Modelle für sehr hohe parallele Last.

💡 Begründung: DefectDojo basiert auf Django/Celery mit Redis als Task-Queue, was grundlegende Concurrency-Unterstützung bietet. Kubernetes-Deployments ermöglichen Skalierung, aber es gibt keine out-of-the-box Enterprise-Grade-Skalierungslösungen oder dokumentierte Benchmarks für hohe parallele Nutzung. Score 3 gemäß Skala: 'works for standard loads with careful tuning'.

2 Remote Performance for foreign locations NFR

DefectDojo bietet als On-Premise-Webapplikation keine eingebauten Mechanismen wie Edge-Caching, Replication oder CDN-Integration zur Latenzreduzierung für Remote-Teams. Distributed-Deployment ist möglich, aber erfordert externe Infrastruktur.

💡 Begründung: Als klassische On-Premise-Webanwendung fehlen DefectDojo native Mechanismen für Low-Bandwidth/High-Latency-Szenarien. Es gibt keine dokumentierten Edge-, Caching- oder Replikationsstrategien speziell für verteilte Remote-Teams. Score 2 gemäß Skala: 'Limited support for low-bandwidth/high-latency conditions'.

3 Deployment of Customizing --> no coding NFR

DefectDojo bietet grundlegende No-Code-Konfiguration über die UI: Rollen/Berechtigungen, SLA-Konfiguration, Notification-Einstellungen und Produkt-Hierarchien. Für fortgeschrittene Anpassungen sind jedoch Scripting oder Konfigurationsdateien erforderlich.

💡 Begründung: Standardkonfigurationen wie Benutzerrollen, SLA-Fristen, Benachrichtigungen und Produkt-Strukturen sind über die UI konfigurierbar. Jedoch sind fortgeschrittene Szenarien wie Custom-Workflows, erweiterte Deduplizierungs-Regeln oder tiefere Policy-Konfigurationen oft nur über Code/Konfigurationsdateien möglich. Score 3 gemäß Skala: 'Basic no-code customization for standard settings; advanced needs require coding'.

4 Deployment of Development --> coding NFR

DefectDojo bietet eine vollständig dokumentierte REST-API sowie CLI-Tools, die umfangreiche code-basierte Integrationen und Erweiterungen ermöglichen. Als Open-Source-Projekt können Teams auch direkt im Code Erweiterungen implementieren.

💡 Begründung: Die REST-API ist umfassend dokumentiert und ermöglicht vollständige Automatisierung und Integration. Als Open-Source-Projekt besteht darüber hinaus die Möglichkeit, direkten Code-Beiträge zu leisten. Offizielle Plugin-Mechanismen sind begrenzt, aber API + Open Source kompensieren dies. Score 4 gemäß Skala: 'Strong API and scripting/extensibility support with minor limits in extension model'.

3 Experience/Possibility with/of offshore development NFR

DefectDojo unterstützt rollenbasierte Zugriffskontrolle auf Produkt- und Engagement-Ebene, was Offshore-Teams grundlegende Governance ermöglicht. Integration mit externen Identity-Providern (LDAP, SAML) ist vorhanden, aber das Gastzugang-Modell ist begrenzt.

💡 Begründung: RBAC auf mehreren Ebenen und externe IdP-Integration (LDAP/SAML/OAuth) ermöglichen Offshore-Collaboration. Jedoch fehlen explizite Funktionen für Guest/External-User-Onboarding oder feingranulare projektspezifische Governance. Score 3 gemäß Skala: 'Offshore collaboration is possible but needs more manual setup or has notable governance/operational limits'.

3 Flexibility via side-by-side or other extension points NFR

DefectDojo bietet eine REST-API und Webhook-/Notification-Mechanismen als primäre Erweiterungspunkte. Als Open-Source-Lösung ist direktes Code-Forking möglich, jedoch fehlen native Plugin-Frameworks oder offizielle Side-by-Side-Erweiterungsmodelle.

💡 Begründung: Webhooks, REST-API und Notifications bieten API-basierte Integrationsmöglichkeiten. Ein natives Plugin-Framework oder offizielle Extension-Points für Deep-Behavior-Änderungen ohne Core-Code-Modifikation existieren nicht. Open-Source ermöglicht Forking, aber das ist kein 'supported extension model'. Score 3 gemäß Skala: 'Mostly API-based integration and automation, but limited native extension points'.

3 Maintenance and consistency of control tables NFR

DefectDojo bietet zentrale Verwaltung von Produkten, Engagements und Berechtigungen über UI und API. Die Konsistenz über Teams und Umgebungen hinweg erfordert jedoch manuelle Pflege, da keine native Multi-Environment-Synchronisation existiert.

💡 Begründung: Zentrale UI und API ermöglichen das Verwalten von Strukturen und Berechtigungen. Für konsistente Governance über mehrere Umgebungen fehlen jedoch automatisierte Synchronisationsmechanismen oder Infrastructure-as-Code-Templates. Score 3 gemäß Skala: 'Adequate controls with partial consistency support'.

5 Source code availability NFR

DefectDojo ist ein vollständiges Open-Source-Projekt unter der BSD-3-Clause-Lizenz, gehostet auf GitHub. Der gesamte Quellcode ist frei zugänglich, modifizierbar und forkbar ohne Einschränkungen.

💡 Begründung: Als OWASP-Projekt ist DefectDojo vollständig Open Source auf GitHub verfügbar. Kunden können den Code reviewen, modifizieren, forken und eigene Builds erstellen. Dies entspricht exakt Score 5 der Skala: 'Fully open source with broad code access and practical ability to review/change core behavior'.

3 Maintenance effort (upgrades & testing) NFR

DefectDojo hat eine aktive Community mit regelmäßigen Releases auf GitHub, jedoch ohne garantierte Release-Frequenz oder formalen Support-Vertrag. Upgrade-Dokumentation ist vorhanden, aber Regression-Testing liegt vollständig beim Kunden.

💡 Begründung: GitHub zeigt aktive Entwicklung mit regelmäßigen Releases, aber als Community-Projekt ohne kommerziellen Support gibt es keine SLA für Sicherheits-Patches oder strukturierte Upgrade-Guidance. Kunden tragen selbst die Verantwortung für Testing. Score 3 gemäß Skala: 'Acceptable release model with less predictability or higher validation effort'.

2 Backup & Recovery/Redundancy layer in case of break down NFR

DefectDojo selbst bietet keine eingebauten HA- oder Backup-Mechanismen; Redundanz und Recovery müssen vollständig auf Infrastrukturebene (Kubernetes, Datenbankreplikation) implementiert werden. Es gibt keine produktseitigen Backup/Restore-Tools.

💡 Begründung: Als On-Premise-Anwendung delegiert DefectDojo HA und Backup vollständig an die Infrastruktur (PostgreSQL-Backup, Kubernetes-Redundanz). Keine native HA-Dokumentation oder produktintegrierte Recovery-Mechanismen vorhanden. Score 2 gemäß Skala: 'Limited recovery/HA capabilities'.

2 Availability (Maintenance windows, unannounced maintenance) NFR

Da DefectDojo On-Premise deployed wird, sind Wartungsfenster und Downtimes vollständig vom Kunden zu steuern. Zero-Downtime-Deployments sind möglich mit Kubernetes, erfordern aber erhebliches infrastrukturelles Know-how und sind nicht standardmäßig dokumentiert.

💡 Begründung: Ohne managed-service Angebot liegt die Verantwortung für Availability-Management beim Kunden. Zero-Downtime-Upgrades sind technisch über Kubernetes möglich, aber nicht offiziell als Standard-Deployment-Pattern dokumentiert. Score 2 gemäß Skala: 'Significant downtime usually required for updates' ohne gezielte Infrastruktur-Expertise.

1 Availability defined/possible SLA NFR

Als Open-Source-Community-Projekt ohne kommerzielles SaaS-Angebot oder Support-Verträge gibt es keine formalen SLA-Verpflichtungen seitens des Vendors für Verfügbarkeit. Verfügbarkeits-SLAs liegen vollständig beim Kunden bzw. dessen Betrieb.

💡 Begründung: OWASP/Community-Projekt ohne kommerzielle Verfügbarkeitsgarantien. On-Premise-Deployment bedeutet, dass der Anbieter keinerlei Uptime-Commitments machen kann oder macht. Score 1 gemäß Skala: 'No meaningful provider SLA for product availability'.

2.1 Usability & User Experience

2 Ease of Use UX

DefectDojo richtet sich primär an Security-Professionals und erfordert ein gutes Verständnis von Vulnerability-Management-Konzepten sowie der eigenen Produkt-/Engagement-Hierarchie, bevor Kernworkflows sinnvoll genutzt werden können. Typische Nutzer ohne Security-Hintergrund benötigen erhebliches Training.

💡 Begründung: Die Plattform ist funktional mächtig, aber die Lernkurve ist steil: Konzepte wie Engagements, Tests, Findings und Produkte müssen verstanden werden, bevor grundlegende Aufgaben effizient erledigt werden können. Die Skala bewertet 2 als 'steeper learning curve; frequent guidance required', was für DefectDojo treffend ist.

3 Consistent, seamless user interface UX

DefectDojo bietet eine generell konsistente Web-Oberfläche auf Basis eines Bootstrap-basierten Designs, jedoch sind Theming- und Personalisierungsoptionen begrenzt, und einzelne UI-Bereiche wirken in der Konsistenz leicht uneinheitlich.

💡 Begründung: Als Open-Source-Community-Projekt ist die UX funktional und weitgehend konsistent, bietet aber nur begrenzte Enterprise-Anpassungsoptionen wie Theming. Skala 3 ('Generally consistent but with limited adaptation options') trifft zu.

2 Explicit user guidance UX

DefectDojo bietet kaum In-Product-Assistenten oder kontextuelle Hilfe; die Nutzung stützt sich primär auf externe Dokumentation (ReadTheDocs) und Community-Ressourcen für komplexe Setup- und Betriebsaufgaben.

💡 Begründung: Es existieren keine nennenswerten Guided-Setups, Wizards oder kontextuelle In-App-Hilfe-Systeme. Die Dokumentation ist extern und gut gepflegt, aber in-product Guidance fehlt weitgehend. Skala 2 ('Minimal guided UX; mostly manual expert operation') passt gut.

3 Use-case-oriented design UX

Das UI ist auf Security-Analyst-Workflows ausgerichtet und deckt Kernaufgaben wie Triage, SLA-Tracking und Reporting adäquat ab, jedoch gibt es bei Admin-Aufgaben und Developer-Workflows spürbare Reibungspunkte.

💡 Begründung: Für erfahrene Security-Professionals ist die Aufgabenorientierung akzeptabel, aber Developer und Admins stoßen auf Umwege. Skala 3 ('Adequate fit with some friction in common tasks') trifft zu.

2 Flexibility of UI UX

DefectDojo bietet grundlegendes Filtering und eine tag-basierte Suche, jedoch fehlen produktive Power-User-Features wie umfangreiche Keyboard-Shortcuts oder eine schnelle Bulk-Navigation für große Datensätze weitgehend.

💡 Begründung: Die vorhandene Suchfunktion und das Tag-Filtering sind nützlich, aber Keyboard-Shortcuts, schnelle Command-Paletten oder erweiterte Produktivitätsfunktionen für Erfahrene sind kaum vorhanden. Skala 2 ('Limited productivity support') ist angemessen.

2 Customizable by end-user / user groups UX

EndNutzer haben sehr begrenzte Möglichkeiten, die Oberfläche zu personalisieren; es gibt keine nennenswerten Theme-, Layout- oder Verhaltensanpassungen auf Benutzer- oder Gruppenebene.

💡 Begründung: Als Community-Open-Source-Tool fehlen typische Enterprise-Personalisierungsfeatures. Es gibt keine benutzerspezifischen Dashboard-Layouts oder Themeoptionen. Skala 2 ('Limited personalization options') ist passend.

1 Language Capabilities UX

DefectDojo ist im Wesentlichen eine englischsprachige Plattform ohne nennenswerte Multi-Language-Unterstützung oder Lokalisierungsoptionen für internationale Teams.

💡 Begründung: Es gibt keine dokumentierte Multi-Language-UI-Unterstützung oder Lokalisierungsfeatures. Die gesamte Oberfläche und Dokumentation ist englisch. Skala 1 ('English-only or effectively minimal localization capability') trifft zu.

2 Design thinking approach UX

DefectDojo basiert auf Bootstrap, was grundlegende Barrierefreiheitsstandards mitbringt, jedoch gibt es keine explizit dokumentierte Keyboard-First-Navigation oder umfassende Accessibility-Unterstützung für Enterprise-Nutzer.

💡 Begründung: Als Community-Projekt steht Accessibility nicht im Fokus; WCAG-Compliance oder Keyboard-First-Design sind nicht dokumentiert oder nennenswert implementiert. Skala 2 ('Limited support for inclusive interaction') ist konservativ und angemessen.

2.7 IT Compliance

3 Single Source of Truth for each data object COMP

DefectDojo bietet eine zentrale Plattform zur Aggregation von Schwachstellendaten aus 180+ Tools und vermeidet so Datensilos. Allerdings ist die Anbindung an externe Master-Data-Systeme (z.B. REF-MDS) per API möglich, aber nicht nativ vorkonfiguriert und erfordert individuelle Integration.

💡 Begründung: Die Plattform fungiert als zentrales Repository für Vulnerability-Daten (Single Source of Truth für Security-Findings), jedoch ist die API-basierte Einbindung externer führender Quellsysteme (z.B. CMDB, MDS) nicht out-of-the-box vorhanden und muss aufwendig konfiguriert werden. Dies entspricht einer Teilerfüllung mit notwendigen Anpassungen – Score 3.

3 Where is the cloud server located? (country) COMP

DefectDojo wird als On-Premise-Lösung betrieben, sodass der Kunde selbst die Kontrolle über den Hosting-Standort hat und EU-Hosting problemlos realisierbar ist. Eine direkte Unterstützung durch einen bevorzugten Hyperscaler (Azure, AWS) seitens des Vendors besteht nicht nativ, kann aber durch den Betreiber selbst gewählt werden.

💡 Begründung: Als Open-Source On-Premise-Produkt gibt es keine vom Vendor betriebene Cloud-Infrastruktur mit spezifischer Regionswahl. Der Kunde kann auf beliebigen Hyperscalern (Azure, AWS) oder eigener Infrastruktur deployen, trägt aber die Verantwortung selbst. Die regionale Flexibilität ist technisch gegeben, aber die Vendor-seitige Unterstützung ist begrenzt – Score 3.

3 Does the cloud service provide the encryption of data at rest and in transit? COMP

DefectDojo selbst implementiert keine eigene Verschlüsselungsinfrastruktur für Data at Rest oder in Transit, da es eine On-Premise-Applikation ist; Verschlüsselung hängt vollständig von der Deployment-Umgebung (TLS-Konfiguration, Datenbank-Verschlüsselung) ab. HTTPS/TLS für Transit ist konfigurierbar, aber nicht automatisch standardmäßig enforced.

💡 Begründung: Die Anwendung bietet keine eingebauten, standardmäßig aktivierten Verschlüsselungskontrollen für Daten at Rest; dies liegt in der Verantwortung des Betreibers. TLS kann konfiguriert werden, ist aber deployment-abhängig. Für SC2/SC3-Anforderungen sind zusätzliche Maßnahmen nötig – entspricht Score 3 (verfügbar aber nicht konsistent default).

2 GDPR and BDSG COMP

DefectDojo als Open-Source-Produkt ohne kommerziellen Cloud-Betrieb besitzt kein eigenes GDPR/BDSG-Konzept oder Auftragsverarbeitungsvertrag (AVV); die gesamte Datenschutz-Compliance liegt beim betreibenden Unternehmen. Funktionen zur Löschung personenbezogener Daten (z.B. User-Profile) sind rudimentär über Admin-Funktionen möglich, aber kein strukturiertes DSGVO-Löschkonzept vorhanden.

💡 Begründung: Als Community-Open-Source-Projekt gibt es keine dokumentierten GDPR/BDSG-Konformitätsnachweise, keinen Standard-AVV und kein transparentes Verarbeitungsverzeichnis vom Vendor. Der Betreiber muss alle Compliance-Maßnahmen selbst implementieren. Dies bedeutet erhebliche Lücken auf Vendor-Ebene – Score 2.

1 ISO certificates COMP

DefectDojo ist ein OWASP Open-Source-Community-Projekt ohne eigene ISO 27001-Zertifizierung oder vergleichbare Sicherheitszertifikate des Vendors. Als On-Premise-Software gibt es keinen zertifizierten Cloud-Betreiber seitens OWASP.

💡 Begründung: OWASP als Non-Profit-Community-Organisation hält keine ISO 27001-Zertifizierung für DefectDojo. Es gibt keine relevanten Zertifizierungsnachweise seitens des Vendors. Die Zertifizierungsverantwortung liegt vollständig beim deploying Unternehmen – Score 1.

4 Data export and import COMP

DefectDojo bietet eine vollständige REST-API für den Export und Import von Findings, Engagements und Reports sowie native Importfunktionen für 180+ Tool-Formate. PDF/HTML-Berichte können exportiert werden; ein direkter Excel-Massenimport/-export ist jedoch eingeschränkt und primär API-getrieben.

💡 Begründung: Die REST-API ermöglicht umfangreichen programmatischen Datenexport und -import; zahlreiche Scan-Formate werden nativ importiert. Für Massenänderungen via Excel gibt es keine native Out-of-the-Box-Funktion, was einen kleinen Abzug rechtfertigt. Insgesamt starke Export/Import-Fähigkeiten – Score 4.

3.1 Risks & Opportunities

5 Dependencies and Lock-In from Software Vendor RISK

DefectDojo ist Open Source (BSD-Lizenz) und speichert Daten in Standard-Datenbanken (PostgreSQL/MySQL); ein Ausstieg ist jederzeit möglich durch Datenexport via REST-API oder direkten DB-Zugriff. Es bestehen keine proprietären Vendor-Lock-ins, da das Produkt vollständig selbst gehostet wird.

💡 Begründung: Open-Source-Lösung mit offenen Standards, keine proprietären Datenformate, vollständige Datenportabilität und einfache De-Integration durch API-Export – entspricht klar Score 5 gemäß Skala.

3 Project team setup and continuity RISK

DefectDojo wird als OWASP-Community-Projekt von einer Mischung aus Volunteers und einigen Kern-Maintainern entwickelt; die Aktivität auf GitHub ist moderat, jedoch ohne garantierte kommerzielle Kontinuität. Personelle Fluktuation in Open-Source-Teams ist strukturell möglich und schwer vorhersehbar.

💡 Begründung: Es gibt ein aktives Community-Projekt mit erkennbarer Kontinuität, aber kein dediziertes, stabiles Produktteam mit klarer Nachfolgeplanung – das entspricht Score 3 (adequate capability with some continuity risk).

4 Time to Market RISK

DefectDojo kann als Docker-Container oder über Helm-Chart in Kubernetes innerhalb weniger Stunden bis Tage deployt werden; die REST-API und vorhandenen Integrations-Connectoren erlauben eine schnelle Inbetriebnahme. Initiale Konfiguration (Produkt-Hierarchie, SLA-Regeln, Tool-Integrationen) erfordert etwas Vorlaufzeit, bleibt aber überschaubar.

💡 Begründung: Schnelles Deployment durch Container-native Bereitstellung und breite Integrationsbasis, jedoch etwas Konfigurationsaufwand – Score 4 (fast rollout with limited setup effort) ist angemessen.

2 Skill of supplier RISK

Da es sich um ein Community-Open-Source-Projekt handelt, gibt es keinen offiziellen Vendor mit strukturiertem Enterprise-Consulting-Angebot; Implementierungspartner müssen selbst gefunden werden und haben begrenzte nachweisbare Erfahrung in Großkundenprojekten. Spezialisierte DefectDojo-Dienstleister sind am Markt kaum skalierbar verfügbar.

💡 Begründung: Kein etabliertes Supplier-Ökosystem für Large-Enterprise-Deployments, kein offizieller Support-Kanal – das entspricht Score 2 (limited large-enterprise skill depth).

2 Size of supplier (Skalierbarkeit für Großkunden), risk of insolvency RISK

DefectDojo ist ein OWASP-Community-Projekt ohne kommerziellen Hersteller; die Anzahl aktiver Kern-Entwickler ist begrenzt und es existiert keine Organisation mit dediziertem Personal, die Insolvenzrisiko ausschließen kann. Die Abhängigkeit vom freiwilligen Engagement der Community stellt ein strukturelles Risiko dar.

💡 Begründung: Kein kommerzieller Träger, kleine Contributor-Basis, strukturelles Continuity-Risiko – Score 2 (smaller supplier/project with visible dependency risk) ist zutreffend.

2 World wide rollout RISK

Als Open-Source-Community-Projekt existieren keine offiziellen regionalen Support-Teams oder strukturierten Rollout-Kapazitäten für globale Enterprise-Deployments; Unterstützung kommt ausschließlich über Community-Foren, GitHub-Issues und einzelne Dienstleister. Ein koordinierter weltweiter Rollout ist ohne zusätzliche Systemintegratoren kaum realisierbar.

💡 Begründung: Keine strukturierten weltweiten Support- oder Rollout-Kapazitäten vorhanden – entspricht Score 2 (limited regional rollout capability).

3 Dependencies to other strategic projects RISK

DefectDojo ist als Vulnerability-Aggregationsplattform weitgehend unabhängig von anderen strategischen IT-Projekten wie S/4HANA; es bestehen lediglich indirekte Abhängigkeiten zu CI/CD-Pipelines und JIRA, die neutral bis positiv bewertet werden können. Keine bekannten negativen Wechselwirkungen mit typischen Großprojekten.

💡 Begründung: Neutrale Abhängigkeitsposition ohne signifikante positive oder negative Kopplungen zu strategischen Programmen – Score 3 (neutral dependency position) ist korrekt.

4 Development method (agile or waterfall) RISK

DefectDojo wird nach modernen Open-Source-Entwicklungspraktiken mit GitHub-basiertem agilen Workflow, regelmäßigen Releases und Issue-Tracking entwickelt; die kontinuierliche Weiterentwicklung und CI/CD-Integration des Produkts selbst spiegeln eine agile Delivery-Kultur wider. Dies passt gut zum Einsatz in DevSecOps-Umgebungen.

💡 Begründung: Agile Community-Entwicklung mit regelmäßigen Releases und modernem DevOps-Ansatz – Score 4 (good modern delivery fit) ist gerechtfertigt, da kein formales SAFe/Scrum-Framework nachweisbar ist, aber die Praktiken eindeutig agil sind.

3.6 Total Cost of Ownership

3 Setup/Project Costs TCO

DefectDojo ist Open Source und verursacht keine Lizenzkosten, jedoch erfordert das initiale Setup (Docker/Kubernetes-Deployment, Konfiguration, Integration der Tools) moderaten bis erheblichen Aufwand. Konzeptuell müssen Produkt-Hierarchien, SLA-Richtlinien und Integrationen geplant werden.

💡 Begründung: Kein Kaufpreis, aber On-Premise-Deployment mit Docker/Kubernetes verlangt technisches Know-how und Planungsaufwand. Es existiert keine 'Click-to-Deploy'-Managed-Option ohne Eigenaufwand, daher kein Score von 4 oder 5. Score 3 (moderate setup cost) ist konservativ und realistisch.

3 Implementation Costs TCO

Die REST-API und die 180+ vorhandenen Integrationen reduzieren Custom-Development-Aufwand erheblich, jedoch erfordern die Anbindung an interne CI/CD-Pipelines, JIRA-Konfiguration und ggf. benutzerdefinierte Parsererweiterungen moderaten Implementierungsaufwand.

💡 Begründung: Viele Integrationen sind out-of-the-box verfügbar (reduziert Aufwand), aber individuelle Anpassungen (Custom-Scanner, Workflows, SSO) können Entwicklungszeit erfordern. Score 3 (moderate implementation effort) spiegelt das Gleichgewicht wider.

3 Maintenance / Operation Costs TCO

Als selbst-gehostete Open-Source-Plattform entstehen laufende Kosten durch Infrastrukturpflege, Updates, Datenbank-Backups und Patch-Management. Es gibt keinen Vendor-Support; Community-Unterstützung und Eigenbetrieb erfordern dedizierte Administrationskapazitäten.

💡 Begründung: On-Premise ohne kommerzielle Support-Option bedeutet, dass Day-2-Operationen (Upgrades, Performance-Tuning, Security-Patching) vollständig intern getragen werden müssen. Dies führt zu moderatem bis hohem Betriebsaufwand – Score 3 ist angemessen.

5 License Costs TCO

DefectDojo ist vollständig Open Source (Apache 2.0-Lizenz) und kostenlos nutzbar – es gibt keine Lizenzgebühren, keine nutzerbasierte Abrechnung und keine versteckten Kosten seitens des Herstellers.

💡 Begründung: Maximaler Score 5, da das Lizenzmodell vollständig transparent und kostenlos ist. Einzige Kosten entstehen durch Infrastruktur und Personal, nicht durch Lizenzierung. Dies entspricht exakt der Skalenbeschreibung 'transparentes, günstiges Modell ohne versteckte Kosten'.

4 expected benefit/efficiency TCO

Durch zentrale Aggregation von 180+ Tool-Ergebnissen, automatische Deduplizierung und strukturierte Triage-Workflows reduziert DefectDojo den manuellen Aufwand im Vulnerability-Management erheblich und steigert die Effizienz von Security-Teams nachhaltig.

💡 Begründung: Die Konsolidierung von Scan-Ergebnissen, Deduplizierung und SLA-Tracking adressieren direkt repetitive manuelle Tätigkeiten. In Folgejahren sinkt der Triage-Aufwand messbar. Score 4 (strong efficiency benefit) ist gerechtfertigt; Score 5 wird nicht vergeben, da die Plattform selbst Betriebsaufwand erzeugt, der den Netto-Effizienzgewinn etwas dämpft.

1.4 Support & Operations

1 1st level SUP

DefectDojo ist ein Open-Source-OWASP-Community-Projekt ohne kommerziellen Anbieter, der einen formalen First-Level-Support (Hotline, dedizierter Support-Kanal) bereitstellt. Der Support erfolgt primär über Community-Foren, GitHub Issues und Slack-Kanäle.

💡 Begründung: Da kein kommerzieller Vendor existiert, gibt es keinen organisierten 1st-Level-Support wie Hotlines oder Service Desks. Kunden müssen sich selbst helfen oder externe Dienstleister engagieren – entspricht Skala-Wert 1 (Mostly self-support).

1 2nd level SUP

Ein formaler 2nd-Level-Support durch den Hersteller existiert nicht, da DefectDojo ein Community-Projekt ist. Fachliche Unterstützung auf zweiter Ebene muss über die GitHub-Community, Slack oder durch externe Implementierungspartner organisiert werden.

💡 Begründung: Es gibt keinen Vendor-seitigen 2nd-Level-Support mit garantierten Eskalationswegen. Die Community ist aktiv, aber kein zuverlässiges Modell für Enterprise-Support – Skala-Wert 1 (No reliable second-level model).

2 3rd level SUP

Bugfixing erfolgt über GitHub Issues und Pull Requests durch die OWASP-Community und einzelne Maintainer. Es gibt keinen garantierten Engineering-Eskalationspfad, jedoch ist das Projekt aktiv gepflegt und Bugs werden grundsätzlich bearbeitet.

💡 Begründung: Das GitHub-Repository ist aktiv und Bugs werden aufgenommen, jedoch gibt es keine garantierten Reaktionszeiten oder einen strukturierten Engineering-Eskalationsprozess. Dies entspricht Skala-Wert 2 (Limited engineering escalation), da es Community- und Best-Effort-basiert ist, aber etwas strukturierter als rein ad-hoc.

1 General support concept/approach SUP

DefectDojo bietet kein formales kommerzielles Support-Konzept. Support erfolgt ausschließlich über Community-Kanäle (Slack, GitHub, Dokumentation). Eine Ticket-Bridge zum Vendor existiert nicht; weltweiter oder mehrsprachiger Support wird nicht angeboten.

💡 Begründung: Als Open-Source-Projekt ohne kommerziellen Vendor gibt es kein strukturiertes Support-Konzept, keine SLAs, keine offizielle Sprachunterstützung und keine Ticket-Bridge. Dies entspricht eindeutig Skala-Wert 1 (Very weak or community-only support concept).

1 SLA for tickets SUP

Es existieren keine formalen SLAs für die Bearbeitung von Support-Tickets, da kein kommerzieller Support-Vertrag verfügbar ist. Antwortzeiten sind vollständig community-abhängig und nicht garantiert.

💡 Begründung: Ohne kommerziellen Vendor gibt es keine dokumentierten SLAs für High/Medium/Low Tickets. Die Bearbeitungszeit hängt von der Verfügbarkeit und dem Interesse der Community-Maintainer ab – Skala-Wert 1 (No real SLA).

1 Support coverage SUP

Es gibt keine 24/7-Supportabdeckung durch den Hersteller. Die Community ist global verteilt und in Slack und GitHub aktiv, aber ohne garantierte Reaktionszeiten oder regionale Supportstrukturen.

💡 Begründung: Eine formale 24/7-Abdeckung oder regionale Supportstrukturen existieren nicht. Die Community ist zwar international, aber das entspricht keinem organisierten Support-Modell – Skala-Wert 1 (Community or business-hours only).

3 Training, tool documentation SUP

DefectDojo verfügt über eine umfangreiche offizielle Dokumentation (ReadTheDocs), Community-Tutorials und vereinzelte Community-Videos. Formale Trainings durch den Hersteller (Webinare, Face-to-Face, zertifizierte Kurse) werden nicht systematisch angeboten.

💡 Begründung: Die Dokumentation ist gut strukturiert und deckt Administrator- sowie Entwickler-Perspektiven ab. Es fehlen jedoch formale, strukturierte Trainingsprogramme für verschiedene Zielgruppen. Dies entspricht Skala-Wert 3 (Good documentation, limited formal training).

2.4 Projektspezifische Anforderungen

3 Hierarchische Mandantentrennung mit vererbten Policies CTX

DefectDojo bietet eine hierarchische Strukturierung über Produkttypen, Produkte und Engagements, was einer 3-Ebenen-Hierarchie entspricht. Eine vollständige 5-Ebenen-Mandantenhierarchie mit technisch durchgesetzter Policy-Vererbung und Überschreibungsschutz ist nicht nativ vorhanden.

💡 Begründung: Die Produkt-/Engagement-Hierarchie deckt 2-3 Ebenen ab (Produkttyp > Produkt > Engagement), jedoch fehlt ein vollständiges Mandantenmodell mit Datenisolation auf jeder Ebene und automatischer Policy-Propagation mit Überschreibungsschutz. Dies entspricht Score 3 (Zwei-bis-Drei-Ebenen-Modell, Policy-Vererbung manuell nachrüstbar).

2 Mandanten-scoped API-Tokens und Service-Accounts CTX

DefectDojo unterstützt API-Keys pro Benutzer, die über RBAC auf bestimmte Produkte beschränkt werden können. Eine technisch erzwungene mandantenspezifische Token-Isolation auf Infrastrukturebene mit automatischer Rotation und vollständigem Audit-Log ist jedoch nicht vorhanden.

💡 Begründung: API-Tokens in DefectDojo sind benutzergebunden und durch RBAC gefiltert, aber keine echte mandantenspezifische Scope-Trennung auf Infrastrukturebene. Automatische Rotation fehlt, Audit-Log ist eingeschränkt. Dies entspricht Score 2 (globale API-Tokens mit RBAC-Filterung).

1 Proxy-/Pull-Policy-Gate für JFrog Artifactory ohne XRay-Lizenz CTX

DefectDojo ist eine Vulnerability-Management-Plattform und bietet keine Funktion als Policy-Gate für Artifactory-Artifact-Pulls. Es gibt keine native Artifactory-Connector-Funktion, die Artifact-Downloads blockieren kann.

💡 Begründung: DefectDojo fokussiert auf die Aggregation und Verwaltung von Security-Findings nach dem Scan, nicht auf präventive Policy-Gates bei Artifact-Pulls. Eine Artifactory-Integration als Pre-Download-Gate existiert nicht, was Score 1 entspricht.

4 Bidirektionale Integration mit bestehendem Dependency-Track ohne Datenduplizierung CTX

DefectDojo unterstützt den Import von CycloneDX-SBOMs und kann Findings aus Dependency-Track über dessen API-Output konsumieren. Eine vollständig bidirektionale, deduplizierungsfreie Integration mit Dependency-Track als autoritativem SBOM-Store ist über CycloneDX-Import/Export möglich, jedoch nicht als nativ dokumentierter Connector.

💡 Begründung: DefectDojo kann Dependency-Track-Ergebnisse via CycloneDX oder REST-API-Export importieren, was einen unidirektionalen Flow ermöglicht. Es gibt einen Dependency-Track-Parser in DefectDojo. Ein vollständig bidirektionaler Finding-Sync ohne Datenduplizierung ist nicht nativ dokumentiert, daher Score 4.

1 SBOM-Generierung für Binary-Artefakte in Artifactory (ohne Quellcode-Zugriff) CTX

DefectDojo ist keine SBOM-Generierungsplattform, sondern eine Findings-Aggregationsplattform. Es kann SBOMs importieren und verwalten, generiert aber selbst keine SBOMs aus binären Artefakten in Artifactory.

💡 Begründung: DefectDojo generiert keine SBOMs aus Binaries – es konsumiert fertige Scan-Ergebnisse. Für Binary-SBOM-Generierung wären externe Tools wie Syft oder Trivy nötig, deren Output dann importiert wird. Score 1 ist korrekt, da keine eigene Binary-SBOM-Generierung vorhanden ist.

3 SBOM-Versionierung und Differenz-Tracking über Artefakt-Versionen CTX

DefectDojo unterstützt Reimport-Funktionalität mit Differenz-Tracking (neue, wiederkehrende und behobene Findings). Eine native SBOM-Versionierung mit grafischem Diff-View auf Komponentenebene ist jedoch nicht vorhanden; Diffs werden auf Finding-Ebene, nicht auf SBOM-Komponentenebene dargestellt.

💡 Begründung: Das Reimport- und Differenz-Tracking-Feature deckt Finding-Level-Diffs ab, nicht explizites SBOM-Versioning auf Komponentenebene. SBOM-Versionen werden gespeichert, ein nativer SBOM-Diff fehlt. Score 3 ist angemessen (Versionen gespeichert, Diff extern oder auf Finding-Ebene).

2 VEX/OpenVEX-Erstellung und -Verwaltung als First-Class-Feature CTX

DefectDojo bietet proprietäre Triage-Workflows (False Positive, Risk Accepted, Not Affected) mit eigenen Status-Feldern, aber kein natives VEX-Management als First-Class-Feature. Ein Export in CycloneDX-VEX oder OpenVEX-Format ist nicht nativ dokumentiert und erfordert erheblichen Konvertierungsaufwand.

💡 Begründung: VEX-Standards (CycloneDX VEX, OpenVEX) werden von DefectDojo nicht nativ unterstützt. Die proprietären Triage-Felder könnten theoretisch auf VEX-Statements gemappt werden, aber kein nativer Export existiert. Score 2 ist korrekt (proprietäres Triage-System ohne Standardexport).

3 Organisationsweite Suppression und Wiederverwendung von Triage-Entscheidungen CTX

DefectDojo ermöglicht über Risk-Acceptance-Templates und organisationsweite Suppression-Regeln eine teilweise Wiederverwendung von Triage-Entscheidungen. Eine vollautomatische Propagation auf alle betroffenen Projekte bei gleicher CVE/Komponenten-Kombination ist jedoch nicht nativ und erfordert manuelle Schritte.

💡 Begründung: DefectDojo bietet Finding-Templates und die Möglichkeit, Risk Acceptances zu übertragen, aber eine automatische organisationsweite Propagation auf alle Projekte mit derselben CVE/Komponenten-Kombination ist nicht als natives Feature dokumentiert. Score 3 (manuelle Anwendung auf mehrere Projekte möglich) ist passend.

2 Aggregierte Vulnerability-Feeds aus mehreren Quellen mit Konfliktauflösung CTX

DefectDojo ist primär ein Findings-Aggregator für Tool-Outputs und kein Vulnerability-Feed-Aggregator. Es unterstützt CVSS-Scoring und EPSS-Integration, aber keine eigenständige Konfiguration mehrerer paralleler Vulnerability-Datenquellen (NVD, OSV, CERT-Bund etc.) mit Konfliktauflösung.

💡 Begründung: DefectDojo bezieht Vulnerability-Informationen hauptsächlich aus den importierten Tool-Ergebnissen, nicht aus konfigurierbaren, unabhängigen Feeds. NVD-Daten können referenziert werden, aber ein Multi-Feed-System mit Konfliktauflösung ist nicht vorhanden. Score 2 ist angemessen.

1 License-Policy-Enforcement mit Copyleft-Risikostufen und Ausnahme-Workflow CTX

DefectDojo ist kein License-Compliance-Tool und bietet keine License-Policy-Enforcement-Funktion mit Copyleft-Risikostufen oder Ausnahme-Workflows. Lizenz-Informationen können in SBOM-Findings angezeigt werden, aber kein Policy-Enforcement oder strukturierter Approval-Workflow existiert.

💡 Begründung: License-Policy-Management ist explizit nicht der Fokus von DefectDojo. Es fehlen Risikostufenkonfiguration, Policy-Enforcement und Ausnahme-Workflows für Lizenzfragen vollständig. Score 1 ist korrekt.

2 SPDX-konforme Lizenzauflösung inkl. komplexer Lizenz-Expressions CTX

DefectDojo kann SPDX-Identifikatoren aus importierten SBOMs (CycloneDX) anzeigen und speichern, wertet SPDX License Expressions jedoch nicht semantisch aus. Komplexe Expressions wie 'Apache-2.0 AND MIT' oder 'GPL-2.0-only OR GPL-3.0-only' werden als String-Felder behandelt, ohne korrekte AND/OR-Auflösung.

💡 Begründung: DefectDojo ist kein License-Compliance-Tool und implementiert kein SPDX Expression-Parsing. SPDX-Identifier aus CycloneDX-Imports werden gespeichert, aber nicht semantisch für Policy-Bewertungen ausgewertet. Score 2 (SPDX als String, keine semantische Auswertung) ist korrekt.

2 Deklarative Policy-as-Code-Definition mit Versionierung (OPA/Rego oder äquivalent) CTX

DefectDojo-Konfigurationen (SLA-Policies, Regeln) sind primär über die GUI oder REST-API konfigurierbar. Ein natives Policy-as-Code-Format (OPA/Rego, YAML-DSL) mit GitOps-Workflow existiert nicht; API-basiertes Scripting ist möglich, aber nicht als vollständiger Policy-as-Code-Ansatz dokumentiert.

💡 Begründung: DefectDojo bietet eine REST-API, über die Konfigurationen skriptbasiert gesetzt werden können, aber kein deklaratives Policy-as-Code-Format oder nativer GitOps-Connector. Policies sind weitgehend GUI-konfigurierbar mit API-Zugriff. Score 2 (GUI-orientiert mit Export-Möglichkeit, kein versionierungsfreundliches Format nativ) ist angemessen.

2 Granulare Policy-Gate-Aktionen: Blockieren, Warnen, Quarantäne, Notifizieren CTX

DefectDojo bietet keine nativen Policy-Gate-Funktionen mit differenzierten Aktionen wie Block, Warn, Quarantäne oder Notify als konfigurierbare Gate-Aktionen. Über Webhooks und Benachrichtigungen lassen sich Notifikationen abbilden, jedoch kein harter Block oder Quarantäne-Workflow.

💡 Begründung: DefectDojo ist primär ein Vulnerability-Management-Tool, kein Policy-Gate-Enforcer wie JFrog Curation oder Xray. Es gibt keine nativen Block/Allow-Entscheidungen für Artefakte. Notifikationen per Slack/Email sind vorhanden, aber differenzierte Gate-Aktionen (Block, Quarantäne) fehlen nativ. Skala-Wert 2 trifft am besten zu: rudimentäre Alerting-Funktion, aber keine echten Policy-Gate-Aktionen.

3 Air-Gap / Offline-Betrieb für Vulnerability-Datenfeeds CTX

DefectDojo ist grundsätzlich On-Premise deploybar und die Feed-URLs für Vulnerability-Datenbanken können prinzipiell auf interne Mirror umgeleitet werden, jedoch gibt es keinen offiziellen, dokumentierten Air-Gap-Betriebsmodus mit Mirror-Prozess und Signaturprüfung.

💡 Begründung: Als Open-Source-Tool ist DefectDojo vollständig On-Premise betreibbar. Feed-Konfigurationen (z.B. NVD, EPSS) können theoretisch auf interne Endpunkte zeigen, aber es gibt keine offizielle Air-Gap-Dokumentation, keinen geprüften Mirror-Prozess und keine Signaturprüfung. Dies entspricht Skala-Wert 3: Feed-URL konfigurierbar, aber eigenverantwortliche Mirror-Einrichtung nötig.

3 Manipulationssicheres Audit-Log mit SIEM-Export (CEF/JSON/Syslog) CTX

DefectDojo verfügt über ein Audit-Log für Benutzeraktionen und Änderungen, das über die API abgerufen werden kann. Ein nativer SIEM-Export in CEF/Syslog-Format oder ein technischer Manipulationsschutz sind jedoch nicht dokumentiert.

💡 Begründung: DefectDojo loggt Aktivitäten und bietet eine REST-API, über die Log-Daten extrahiert werden können. Ein dediziertes, manipulationssicheres Audit-Log mit append-only-Charakter oder kryptografischer Signierung ist nicht bekannt. Echtzeit-SIEM-Streaming via Syslog/CEF ist nicht nativ vorhanden. Entspricht Skala-Wert 3: Audit-Log vorhanden, manueller JSON-Export möglich, kein Echtzeit-SIEM-Stream, Manipulationsschutz nicht dokumentiert.

3 Horizontale Skalierung des Scanning-Backends für Enterprise-Artefaktvolumen CTX

DefectDojo unterstützt Kubernetes-Deployment und kann mit mehreren Instanzen betrieben werden, bietet jedoch keine native Queue-basierte Scan-Architektur für das Scanning-Backend selbst, da es primär Scan-Ergebnisse importiert statt eigenständig scannt.

💡 Begründung: DefectDojo ist kein Scanner, sondern ein Aggregator – es importiert Ergebnisse aus externen Tools. Das Skalierungsproblem für Scan-Backlogs ist daher teilweise eine Fehlpassung. Kubernetes-Deployment mit Helm ist möglich, aber offizielle Enterprise-Performance-Benchmarks fehlen. Skala-Wert 3: Skalierung durch mehrere Instanzen möglich, manuelle Konfiguration nötig, keine offiziellen Enterprise-Benchmarks.

5 OWASP-Ökosystem-Alignment und aktive OWASP-Projektmitgliedschaft CTX

DefectDojo ist ein OWASP Flagship Project mit aktiver Community, regelmäßigen Releases durch diverse Contributors aus verschiedenen Organisationen und nativem Alignment mit OWASP-Standards wie OWASP Top 10 und CWE.

💡 Begründung: DefectDojo ist explizit als OWASP Flagship Project klassifiziert, was die höchste OWASP-Projektstufe darstellt. Es hat eine aktive Community mit mehreren Maintainern aus unterschiedlichen Organisationen, regelmäßige Releases und native Unterstützung von OWASP Top 10, CWE-Klassifizierungen. Dies entspricht eindeutig Skala-Wert 5.

3 Native CI/CD-Integration mit Policy-Gate-Rückgabecodes für gängige Pipelines CTX

DefectDojo bietet eine REST-API und CLI-Unterstützung, die in beliebige CI/CD-Pipelines integriert werden kann. Native Plugins für Jenkins, GitLab CI, GitHub Actions oder Azure DevOps mit zentralem Policy-Referenz-Modell sind jedoch nicht vorhanden.

💡 Begründung: DefectDojo hat kein zentrales Policy-Gate-Modell, das aus der Pipeline heraus referenziert werden kann. Die CI/CD-Integration erfolgt über REST-API oder das defectdojo-cli, was manuelle Pipeline-Skripting erfordert. Policy-Parameter müssen in der Pipeline definiert werden. Entspricht Skala-Wert 3: CLI vorhanden, integrierbar, aber kein zentrales Policy-Referenz-Modell und keine nativen Plugins für CI/CD-Systeme.

3 Kubernetes-natives Deployment mit Helm-Chart und Operator-Support für HA CTX

DefectDojo bietet ein Helm-Chart für Kubernetes-Deployment, das auch HA-Konfigurationen mit externer PostgreSQL-Datenbank unterstützt. Ein offiziell gepflegter Kubernetes-Operator für automatisiertes Lifecycle-Management ist jedoch nicht vorhanden.

💡 Begründung: Das DefectDojo Helm-Chart existiert und ist auf GitHub verfügbar, unterstützt externe PostgreSQL-Backends und grundlegende HA-Konfigurationen. Es handelt sich jedoch eher um ein Community-gepflegtes Chart ohne Kubernetes-Operator. Die HA-Konfiguration ist beschrieben, aber nicht vollständig out-of-the-box. Skala-Wert 3 ist angemessen: Helm-Chart vorhanden, HA möglich aber nicht trivial konfigurierbar, kein Operator.

4 Compliance-Dashboard und automatisierter Report-Export für NIS2/BSI-Grundschutz CTX

DefectDojo bietet umfangreiche Dashboards mit SLA-Tracking, MTTR-Metriken, Severity-Verteilungen und mandantenspezifischer Filterung durch die Produkt-Hierarchie. Report-Export als PDF und HTML ist nativ vorhanden, JSON/CSV über die API verfügbar.

💡 Begründung: DefectDojo hat starke Reporting-Funktionen: SLA-Compliance, Trend-Analysen, mandantenspezifische Produkt-Hierarchie, PDF/HTML-Report-Generierung. Jedoch sind vorkonfigurierte NIS2/BSI-spezifische Compliance-Dashboards nicht explizit dokumentiert, und Scheduled-Reports sind nicht als natives Feature bekannt. Skala-Wert 4: gängige Compliance-Metriken, mandantenspezifisch, Export in mehreren Formaten, aber kein natives Scheduling oder NIS2-spezifische Vorkonfiguration.

1 SBOM-Enrichment aus Container-Image-Layern CTX

DefectDojo ist ein Vulnerability-Management- und Aggregationsportal, das keine eigene Container-Image-Analyse oder Layer-by-Layer-SBOM-Extraktion durchführt. Es kann Ergebnisse aus Container-Scannern importieren, die diese Analyse durchgeführt haben.

💡 Begründung: DefectDojo generiert keine SBOMs und analysiert keine Container-Images selbst. Es ist ein Findings-Aggregator, der Ergebnisse aus Tools wie Trivy, Grype oder Snyk importiert. Layer-by-Layer-Analyse ist nicht eine Funktion von DefectDojo. Entspricht eindeutig Skala-Wert 1: Keine Unterstützung für Container-Image-Analyse als eigene Funktion.

3 EPSS-Score-Integration und priorisierungsbasiertes Triage-Routing CTX

DefectDojo unterstützt EPSS-Score-Integration als Feature, zeigt EPSS-Werte in der UI an und ermöglicht deren Nutzung im Triage-Workflow. Ein vollautomatisches Triage-Routing basierend auf EPSS-Schwellenwerten kombiniert mit CVSS ist jedoch eingeschränkt.

💡 Begründung: Gemäß den bekannten Features ist CVSS/EPSS-Integration in DefectDojo dokumentiert. EPSS-Scores können angezeigt und manuell im Triage-Prozess genutzt werden. Automatisches Routing oder Policy-Regeln basierend auf EPSS-Schwellenwerten kombiniert mit CVSS sind jedoch nicht als vollständig native Funktion bekannt. Skala-Wert 3: EPSS über Integration verfügbar, aber keine vollständige native Policy-Unterstützung für automatisches Routing.

2 CISA KEV (Known Exploited Vulnerabilities) Catalogue-Integration CTX

DefectDojo hat keinen dedizierten CISA KEV-Feed als nativen, automatisch synchronisierten Datenfeed. KEV-relevante Informationen können indirekt über NVD-Daten oder manuelle Tagging-Prozesse abgebildet werden, aber eine eigenständige KEV-Policy-Integration fehlt.

💡 Begründung: Es gibt keine dokumentierte native CISA KEV-Integration in DefectDojo als eigenständigen Feed mit automatischer Synchronisierung und Policy-Gate-Nutzung. KEV-Daten können theoretisch über manuelle Skripte oder Tagging eingebracht werden. Skala-Wert 2: Kein nativer KEV-Feed, manuelle Pflege oder externe Skripte erforderlich, keine automatische Priorisierung basierend auf KEV-Status.

2 Mandantenspezifische Vulnerability-Feed-Konfiguration und -Isolation CTX

DefectDojo bietet mandantenspezifische Datenisolation über die Produkt-Hierarchie, aber die Vulnerability-Feed-Konfiguration (Quellen, Intervalle, Vertrauensstufen) ist global und nicht pro Mandant isoliert konfigurierbar.

💡 Begründung: DefectDojo ist kein Feed-Management-System – die Vulnerability-Datenfeeds werden systemweit konfiguriert, nicht pro Mandant/Produkt. Mandantenspezifische Filter auf Ergebnisebene sind über Produkte/Produkttypen möglich, aber die Feed-Quellen-Konfiguration ist global. Entspricht Skala-Wert 2: Keine mandantenspezifische Feed-Trennung, globale Konfiguration gilt für alle, nur manuelle Workarounds auf Ergebnisebene.

2 Rückmeldung von Scan-Ergebnissen in Artifactory-Properties/Metadata CTX

DefectDojo bietet keine native Artifactory-Property-Schreib-Funktion. Über die REST-API von DefectDojo könnten externe Skripte Ergebnisse abfragen und via Artifactory REST-API zurückschreiben, aber es gibt keinen Out-of-the-Box-Support hierfür.

💡 Begründung: Es existiert keine dokumentierte oder native Integration, die Scan-Ergebnisse als Artifactory-Properties setzt. Die Umsetzung erfordert vollständig externe Skripte ohne Tool-Support seitens DefectDojo, was Skala-Stufe 2 entspricht.

2 Automatisierte OSS-Komponenten-Attributionslisten-Generierung (NOTICE-Dateien) CTX

DefectDojo fokussiert auf Vulnerability-Lifecycle-Management und nicht auf License-Compliance oder SBOM-Attribution. Es gibt keine Funktion zur Generierung von NOTICE-Dateien oder Attributionslisten mit vollständigen Lizenztexten.

💡 Begründung: DefectDojo ist kein SCA/License-Management-Tool und bietet keine Attributionslisten-Generierung. Allenfalls wären rudimentäre Exporte von Findings denkbar, aber nicht für rechtliche Attributionsdokumente geeignet – daher Stufe 2.

2 Trusted-Component-Registry und positives Whitelisting für Organisationen CTX

DefectDojo bietet Suppress/Risk-Acceptance-Funktionalität für Findings sowie False-Positive-Markierungen, jedoch kein dediziertes versionsgranulares Whitelist-Konzept mit Ablaufdaten, Freigabe-Workflow und mandantenübergreifender Gültigkeit.

💡 Begründung: Die vorhandene Risk-Acceptance-Funktion entspricht eher einer globalen Suppress-/Ignore-Funktion ohne dediziertes Governance-Konzept für eine Trusted-Component-Registry. Das entspricht Stufe 2 der Bewertungsskala.

1 Transitive Dependency-Auflösung und Tiefenanalyse für SBOM-Vollständigkeit CTX

DefectDojo ist ein Vulnerability-Aggregations- und Triage-Tool, das Scan-Ergebnisse importiert, aber selbst keine Dependency-Auflösung durchführt. Transitive Dependency-Analyse ist nicht Teil des DefectDojo-Funktionsumfangs.

💡 Begründung: DefectDojo löst keine Dependencies auf – es importiert lediglich Findings von anderen Tools. Informationen über Auflösungstiefe oder SBOM-Vollständigkeit werden nicht geliefert, was Stufe 1 entspricht.

2 Datenbankpartitionierung und Archivierungsstrategie für Langzeit-SBOM-Daten CTX

DefectDojo bietet keine dokumentierte Datenbankpartitionierungsstrategie oder automatisierte Archivierungsfunktion. Datenmanagement muss extern auf Datenbankebene verwaltet werden, was bei großen Datenmengen ein bekanntes Skalierungsproblem darstellt.

💡 Begründung: Es gibt keine eingebauten Retention-Policies oder Archivierungsworkflows. Die Dokumentation enthält allgemeine Deployment-Hinweise, aber keine spezifische Langzeit-Datenhaltungsstrategie – Stufe 2 ist angemessen.

3 Webhook- und Event-Bus-Integration für asynchrone Event-Driven-Architektur CTX

DefectDojo unterstützt Webhooks sowie Benachrichtigungen per E-Mail, Slack, MS Teams und über Webhooks. Es fehlen jedoch Retry-Logik, mandantenspezifische Event-Filterung und eine native Message-Bus-Integration (Kafka/AMQP).

💡 Begründung: Die vorhandenen Webhook- und Notification-Features entsprechen grundlegender Webhook-Unterstützung ohne Retry-Logik und ohne mandantenspezifische Filterung. Kein nativer Message-Bus vorhanden – das entspricht Stufe 3.

1 Malware- und Typosquatting-Erkennung für Registry-Proxies CTX

DefectDojo ist ein Vulnerability-Aggregations-Tool ohne Proxy-Funktionalität für Package-Registries. Es bietet keine Malware-Erkennung oder Typosquatting-Heuristiken für Registry-Proxies.

💡 Begründung: DefectDojo ist kein Registry-Proxy und bietet keinerlei Mechanismen zur Erkennung von Malware-Packages oder Typosquatting beim Pull aus öffentlichen Registries – eindeutig Stufe 1.

1 Softwareintegrität und Artefakt-Signatur-Verifikation (Sigstore/Cosign) CTX

DefectDojo bietet keine Funktionalität zur Verifikation von Artefakt-Signaturen nach Sigstore/Cosign-Standard. Das Tool fokussiert auf Vulnerability-Management, nicht auf Supply-Chain-Integrity-Verifikation.

💡 Begründung: Es gibt keine dokumentierte Sigstore-, Cosign- oder Rekor-Integration in DefectDojo. Artefakt-Signatur-Verifikation als Policy-Gate ist nicht Teil des Produktumfangs – Stufe 1.

2 Ressourcen-Quotierung und Rate-Limiting pro Mandant (Fair-Use-Enforcement) CTX

DefectDojo bietet keine mandantenspezifischen Ressourcen-Quotas oder API-Rate-Limits. Es gibt allenfalls globale Systemgrenzen, die über den Webserver (z.B. nginx) konfiguriert werden können, jedoch ohne mandantenspezifische Differenzierung.

💡 Begründung: Kein eingebautes Quota-System oder mandantenspezifisches Rate-Limiting vorhanden. Nur globale Concurrency-Limits auf Infrastrukturebene möglich – das entspricht Stufe 2.

4 SBOM-as-a-Service API für externe Tool-Integration (SBOM-Upload und -Abfrage) CTX

DefectDojo bietet eine umfangreiche REST-API mit OpenAPI-Spezifikation, die SBOM-ähnliche Imports (CycloneDX, SPDX) sowie Findings-Abfragen unterstützt. Es fehlt jedoch eine explizite Versionierungsstrategie mit Rückwärtskompatibilitätsgarantie.

💡 Begründung: Die API ist funktional vollständig und OpenAPI-spezifiziert, unterstützt CycloneDX/SPDX-Upload und Ergebnis-Abfragen. Ohne explizite Versionierungsstrategie und Rückwärtskompatibilitätsgarantie ist Stufe 4 angemessen.

2 Regulatorische Berichtspflichten: CRA (Cyber Resilience Act) SBOM-Anforderungen CTX

DefectDojo hat keine explizite CRA-Compliance-Unterstützung und keinen bekannten dokumentierten Roadmap-Eintrag für CRA-spezifische Workflows. CycloneDX-Import ist vorhanden, aber SBOM-Vollständigkeitsvalidierung gegen CRA-Anforderungen fehlt.

💡 Begründung: Keine CRA-spezifischen Features oder dokumentierte Roadmap-Einträge bekannt. Grundlegende SBOM-Import-Funktionen sind vorhanden, aber Archivierungsworkflow und behördlicher Export fehlen – Stufe 2 ist konservativ aber angemessen.

3 Dependency-Track-Migrationsbrücke: Erhalt historischer Triage-Daten CTX

DefectDojo unterstützt den Import von CycloneDX-SBOMs und hat eine REST-API, über die Findings importiert werden können. Ein dediziertes Migrationstool für Dependency-Track-Exporte inklusive Triage-Historie und VEX-Dokumente existiert jedoch nicht.

💡 Begründung: CycloneDX-SBOM-Import ist grundsätzlich möglich, aber Triage-Status, Suppressions und VEX-Daten aus Dependency-Track müssen manuell neu erfasst werden. Kein dediziertes Migrationswerkzeug vorhanden – das entspricht Stufe 3.

3 Zentraler Service-Delivery-Modus: Self-Service-Onboarding für Sub-Organisationen ohne Admin-Eskalation CTX

DefectDojo bietet ein Rollenkonzept mit Product-Typ-Admins und Product-Admins, die innerhalb ihrer Grenzen Benutzer und Engagements verwalten können. Das Onboarding neuer Produkte/Teams erfordert jedoch in der Regel globale Admin-Rechte, und ein vollständig dokumentiertes Self-Service-Modell mit unveränderlichen Guardrail-Policies fehlt.

💡 Begründung: DefectDojo hat ein mehrstufiges Rollenmodell (Global Admin, Product Type Admin, Product Admin, Writer, Reader), das delegierte Verwaltung teilweise erlaubt. Allerdings ist das Anlegen neuer Produkte und Produkttypen typischerweise höheren Rollen vorbehalten, und ein vollständiges Tenant-Admin-Self-Service-Modell ohne globalen Admin-Eingriff ist nicht der dokumentierte Standard. Dies entspricht Skala 3: Rollenkonzept vorhanden, aber Onboarding neuer Projekte/Teams erfordert globalen Admin.

2 Reachability-Analyse: Exploitierbarkeits-Kontextbewertung auf Basis tatsächlicher Code-Nutzung CTX

DefectDojo ist primär eine Vulnerability-Aggregations- und Management-Plattform; es importiert Ergebnisse aus externen Tools (inkl. solcher mit Reachability-Daten), führt aber selbst keine Call-Graph-basierte Reachability-Analyse durch. EPSS und CVSS sind als Proxy-Scores integriert.

💡 Begründung: DefectDojo führt keine eigene Reachability-Analyse oder Call-Graph-Analyse durch. Es kann Ergebnisse aus Tools importieren, die solche Analysen liefern, verarbeitet jedoch die Reachability-Daten nicht als eigenen Triage-Kontext-Score. EPSS-Integration ist vorhanden. Dies entspricht Skala 2: Keine Reachability-Analyse, lediglich EPSS/CVSS als Proxy verfügbar.

3 Operative Observability des Security-Services: Interne Metriken, Health-Checks und Kapazitätsplanung CTX

DefectDojo exponiert grundlegende Health-Endpoints und kann in Kubernetes-Umgebungen betrieben werden; eine vollständige Prometheus-Metriken-Integration mit Tenant-Dimensionierung und OpenTelemetry-Tracing ist jedoch nicht nativ als dokumentiertes Feature vorhanden.

💡 Begründung: DefectDojo (Django-basiert) bietet einfache Health-Check-Endpoints für Kubernetes-Deployments und Basis-Systemmetriken, die über externe Agents erreichbar sind. Native Prometheus-Metriken mit Tenant-Aufschlüsselung und OpenTelemetry-Tracing sind nicht als Out-of-the-Box-Features dokumentiert. Dies entspricht Skala 3: Basis-Metriken, einfache Health-Endpoints, keine Tenant-Aufschlüsselung, kein natives Tracing.

3 Differenziertes Ausnahme- und Dispensationsmanagement mit Genehmigungsworkflow und Ablaufdatum CTX

DefectDojo unterstützt Risk Acceptance mit Ablaufdatum, verpflichtendem Kommentar und Benachrichtigungen bei Ablauf; ein formaler Mehr-Augen-Genehmigungsworkflow mit Antragsteller- und Genehmigerrolle ist jedoch nicht als native Funktion implementiert.

💡 Begründung: DefectDojo bietet ein Risk-Acceptance-System mit konfigurierbarem Ablaufdatum, Pflichtbegründung und automatischer Benachrichtigung/Wiedervorlage. Ein formaler Genehmigungsworkflow (Antrag → dedizierter Genehmiger → Vier-Augen-Prinzip erzwingbar) ist nicht dokumentiert vorhanden. Dies entspricht Skala 3: Einfaches Suppression-/Acceptance-System mit Ablaufdatum und Pflichtkommentar, kein formaler Genehmigungsworkflow.

3.1 Produkt-Features

3 SBOM-Import (CycloneDX & SPDX) FEAT

DefectDojo unterstützt den Import von CycloneDX-SBOMs als Teil seiner 180+ Tool-Integrationen. SPDX-Support ist vorhanden, aber weniger ausgereift als dedizierte SBOM-Plattformen.

💡 Begründung: CycloneDX-Import ist dokumentiert und funktionsfähig, SPDX wird ebenfalls unterstützt. Da DefectDojo primär ein Vulnerability-Management-Tool ist und kein dediziertes SBOM-Tool, erfüllt es das Minimum, übertrifft es aber nicht – Score 3 ist angemessen.

2 SBOM-Export & Supply-Chain-Transparenz FEAT

DefectDojo ist primär auf den Import und das Management von Findings ausgerichtet; ein nativer SBOM-Export zur Supply-Chain-Transparenz gegenüber Kunden ist nicht als dediziertes Feature bekannt.

💡 Begründung: DefectDojo kann Berichte exportieren und Findings ausgeben, aber einen strukturierten SBOM-Export (CycloneDX/SPDX) für verwaltete Projekte bietet es nicht als ausgereiftes Feature an. Dies ist eine erhebliche Lücke – Score 2.

1 SBOM-Qualitätsbewertung FEAT

Eine dedizierte SBOM-Qualitätsbewertung mit Hinweisen auf fehlende oder unvollständige Metadaten ist in DefectDojo nicht vorhanden.

💡 Begründung: DefectDojo fokussiert sich auf Vulnerability-Findings, nicht auf die Qualitätsbewertung von SBOMs als solche. Dieses Feature existiert nicht in der bekannten Funktionalität – Score 1.

3 SBOM-Versionierung & historischer Vergleich FEAT

DefectDojo bietet durch sein Reimport- und Differenz-Tracking die Möglichkeit, neue, wiederkehrende und behobene Findings zwischen Scan-Versionen zu vergleichen, was indirekt auch für SBOM-basierte Scans gilt.

💡 Begründung: Das Reimport-Feature ermöglicht einen historischen Vergleich von Findings über Engagements hinweg. Es ist jedoch kein dediziertes SBOM-Versionierungsfeature, sondern ein allgemeines Differenz-Tracking – erfüllt das Minimum, Score 3.

3 Standardisierte Komponenten-Identifikation (PURL) FEAT

DefectDojo verarbeitet PURL-Informationen aus importierten SBOM- und Scan-Ergebnissen und nutzt diese zur Identifikation von Komponenten und Deduplizierung.

💡 Begründung: PURL-Unterstützung ist im Kontext von CycloneDX-Imports und Deduplizierung vorhanden, aber nicht als vollständig ausgebautes, eigenständiges Komponenten-Identifikationsfeature. Das Minimum wird erfüllt – Score 3.

3 Interne Komponenten-Datenbank mit Deduplizierung FEAT

DefectDojo führt eine zentrale Findings-Datenbank mit automatischer Deduplizierung; eine vollständige, eigenständige Komponenten-Datenbank mit Deduplizierung analog zu SCA-Plattformen ist jedoch nicht der Kernfokus.

💡 Begründung: Die Deduplizierung von Findings ist eine bekannte Stärke von DefectDojo. Eine dedizierte Komponenten-Datenbank (wie in Dependency-Track) existiert nicht in gleicher Tiefe. Minimum erfüllt, aber erhebliche Unterschiede zu Best-in-Class – Score 3.

2 Kontinuierliches Vulnerability Monitoring FEAT

DefectDojo unterstützt kein natives kontinuierliches Vulnerability Monitoring, bei dem neue CVEs automatisch mit bestehenden Komponenten abgeglichen werden; es ist auf den Re-Import von Scan-Ergebnissen angewiesen.

💡 Begründung: Das Tool ist scan-getrieben und nicht darauf ausgelegt, kontinuierlich neue CVE-Veröffentlichungen mit der Komponentenbasis abzugleichen. Diese Funktion erfordert externe Tools – erhebliche Lücke, Score 2.

2 Multi-Feed Vulnerability Aggregation FEAT

DefectDojo integriert keine eigenen Vulnerability-Feeds direkt, sondern ist auf den Import von Scan-Ergebnissen aus externen Tools angewiesen, die ihrerseits verschiedene Datenquellen nutzen.

💡 Begründung: Die Multi-Feed-Aggregation aus NVD, OSV, GitHub Advisories etc. ist keine native Funktion von DefectDojo selbst. Es aggregiert Findings aus Tools, nicht aus Vulnerability-Datenbanken direkt – erhebliche Lücke, Score 2.

4 CVSS- & EPSS-Score-Integration FEAT

DefectDojo unterstützt CVSS v2/v3 und bietet eine optionale EPSS-Integration, was eine solide risikobasierte Priorisierung ermöglicht.

💡 Begründung: CVSS-Scoring (v2/v3) und EPSS-Integration sind als bekannte Features dokumentiert. CVSS v4 ist unsicher. Das Minimum wird gut übertroffen, jedoch fehlt v4-Unterstützung möglicherweise noch – Score 4 ist angemessen.

2 VEX (Vulnerability Exploitability eXchange) Support FEAT

Ein nativer VEX-Import und -Export ist in DefectDojo nicht als dediziertes Feature bekannt; Risk-Acceptance-Workflows können als funktionaler Ersatz dienen, erfüllen aber den Standard nicht vollständig.

💡 Begründung: VEX (CycloneDX VEX oder CSAF) als standardisiertes Format zum Import/Export ist in DefectDojo nicht bekannt. Die vorhandenen Triage-Workflows sind kein vollwertiger Ersatz für VEX-Compliance – erhebliche Lücke, Score 2.

5 Vulnerability Lifecycle Management & Triage-Workflows FEAT

DefectDojo ist eine der stärksten Open-Source-Plattformen für Vulnerability Lifecycle Management mit vollständigen Workflows von der Entdeckung über Triage, False-Positive-Markierung, Risk Acceptance bis zur Schließung.

💡 Begründung: Dies ist der Kernfokus von DefectDojo und entspricht Best-in-Class im Open-Source-Bereich. Alle beschriebenen Lifecycle-Phasen und Workflows sind vorhanden und ausgereift – Score 5.

2 Konfigurierbare Policy Engine FEAT

DefectDojo bietet keine vollwertige, konfigurierbare Policy-Engine für Lizenz-Compliance, Komponenten-Blacklists oder automatisierte Schweregrad-Schwellenwerte; SLA-Regeln sind die nächste Annäherung.

💡 Begründung: Eine dedizierte Policy-Engine für Compliance-Regeln (verbotene Lizenzen, Blacklists) ist nicht vorhanden. SLA-Tracking deckt einen Teilaspekt ab, aber strukturierte, automatisierte Policy-Durchsetzung fehlt – erhebliche Lücke, Score 2.

2 Lizenz-Compliance & SPDX-Identifikation FEAT

DefectDojo kann SBOM-Importe (z.B. CycloneDX) verarbeiten und Lizenzinformationen aus Scan-Ergebnissen anzeigen, bietet jedoch keine dedizierte SPDX-Identifikator-Zuordnung oder automatische Lizenz-Compliance-Regelprüfung.

💡 Begründung: Die Plattform ist primär auf Vulnerability-Management ausgerichtet. SBOM-Support existiert rudimentär (CycloneDX-Import), aber eine vollständige Lizenz-Compliance-Engine mit SPDX-Klassifizierung und automatisierten Policy-Checks fehlt – daher erhebliche Lücken gemäß Skala.

5 SLA-Tracking für Schwachstellen FEAT

DefectDojo bietet natives, konfigurierbares SLA-Tracking pro Schweregrad (Critical, High, Medium, Low) mit automatischen Warnungen, SLA-Compliance-Dashboards und Eskalationsbenachrichtigungen bei Fristüberschreitung.

💡 Begründung: SLA-Tracking ist eine der Kernfunktionen von DefectDojo und wird explizit als Feature gelistet. Die Funktion ist ausgereift, vollständig konfigurierbar und deckt alle Schweregrade mit automatisierten Benachrichtigungen ab – entspricht dem Best-in-Class-Kriterium der Skala.

4 Hierarchische Projekt- und Portfolio-Strukturierung FEAT

DefectDojo unterstützt eine dreistufige Hierarchie aus Produkttypen, Produkten und Engagements, was eine strukturierte Aggregation von Risiken auf verschiedenen Ebenen ermöglicht.

💡 Begründung: Die Hierarchie ist gut ausgebaut und praxistauglich, erreicht jedoch nicht alle vier in der Anforderung genannten Ebenen (Portfolio > Produkt > Projekt > Komponente) vollständig. Die fehlende fünfte Ebene und begrenzte Portfolio-Aggregations-Ansichten verhindern den Top-Score.

4 Konfigurierbares Notification & Alerting Framework FEAT

DefectDojo unterstützt konfigurierbare Benachrichtigungen über E-Mail, Slack, MS Teams und Webhooks für Ereignisse wie neue Findings, SLA-Überschreitungen und andere Trigger.

💡 Begründung: Die Kernkanäle sind vorhanden und werden explizit als Feature genannt. Einschränkungen bestehen bei der Granularität der Regelkonfiguration (z.B. Policy-basierte Trigger) im Vergleich zu dedizierten Enterprise-Alerting-Lösungen, daher Score 4 statt 5.

3 Dashboards & Risiko-Scoring (Projekt & Portfolio) FEAT

DefectDojo bietet eingebaute Dashboards mit Severity-Verteilungen, Trend-Analysen und SLA-Compliance-Metriken, jedoch sind die Aggregations- und Portfolio-Ansichten funktional begrenzt.

💡 Begründung: Grundlegende Dashboard-Funktionalität ist vorhanden, aber aggregierte Risiko-Scores auf Portfolio-Ebene und interaktive Drill-down-Möglichkeiten entsprechen nicht dem Enterprise-Standard. Die Funktion erfüllt das Minimum, hat aber erhebliche Lücken gegenüber Best-in-Class.

4 Automatisierte Bericht-Generierung FEAT

DefectDojo ermöglicht die automatisierte Generierung von anpassbaren Sicherheitsberichten in PDF- und HTML-Format, einschließlich Executive Summary und technischer Detailberichte.

💡 Begründung: Die Berichtsgenerierung ist als dediziertes Feature vorhanden und unterstützt die wesentlichen Anforderungen. Kleinere Einschränkungen bei der Tiefe der Anpassbarkeit und Template-Flexibilität im Vergleich zu spezialisierten Reporting-Tools verhindern den Höchstscore.

5 CI/CD-Integration via REST-API & CLI FEAT

DefectDojo bietet eine vollständige REST-API mit OpenAPI-Dokumentation sowie CLI-Tools (z.B. defectdojo-cli) für die nahtlose Integration in CI/CD-Pipelines inklusive automatisierter Scan-Imports und SBOM-Uploads.

💡 Begründung: CI/CD-Integration via REST-API und CLI ist eine der zentralen Stärken von DefectDojo. Die API ist umfassend dokumentiert, aktiv gepflegt und wird von zahlreichen Pipeline-Tools nativ unterstützt – entspricht dem Best-in-Class-Kriterium.

3 Granulares RBAC mit Multi-Tenancy-Unterstützung FEAT

DefectDojo unterstützt rollenbasierte Zugriffskontrollen auf Produkt- und Teamebene mit verschiedenen vordefinierten Rollen, die Multi-Tenancy-Isolation ist jedoch begrenzt und nicht für vollständige Mandantentrennung konzipiert.

💡 Begründung: RBAC ist vorhanden und funktional auf Produktebene, jedoch fehlen feingranulare benutzerdefinierte Rollen und eine vollständige Multi-Tenancy-Architektur mit strikter Datenisolation. Die Funktion erfüllt das Minimum, hat aber erhebliche Lücken gegenüber Enterprise-RBAC-Lösungen.

ANBIETER

nexB / Community

PRODUKT

ScanCode.io

DEPLOYMENT

On-Premise

WEBSITE

https://github.com/nexB/scancode.io

GESAMTSCORE

2.71/5

2.5 Integration

3 General Interfaces/APIs INT

ScanCode.io bietet eine vollständige REST-API zur Verwaltung von Projekten, Pipelines und Ergebnissen, die auch dokumentiert ist. Fertige Out-of-the-box-Konnektoren für Middleware-Systeme (API-Manager, EAI, CPI etc.) sind jedoch nicht vorhanden, sodass Integrationen mit eigenem Aufwand realisiert werden müssen.

💡 Begründung: Die REST-API ist dokumentiert und deckt die wesentlichen Funktionen ab, was über eine reine Basis-API hinausgeht. Allerdings fehlen vorgefertigte Konnektoren für gängige Middleware-Plattformen und es gibt keine Hinweise auf EDI/EAI-Manager-Unterstützung. Dies entspricht einer soliden Basis-API mit Integrationspotenzial durch Eigenaufwand, was Score 3 rechtfertigt.

2 Interface monitoring INT

ScanCode.io ist ein OSS-Projekt ohne dedizierte eingebaute Interface-Monitoring-Funktionalitäten; lediglich grundlegende Logs und ggf. Celery-Worker-Status sind verfügbar. Für echtes Interface-Monitoring müssten externe Tools (z.B. Prometheus, Grafana) manuell integriert werden.

💡 Begründung: Es gibt keine dokumentierten eingebauten Monitoring- oder Diagnostics-Features für Schnittstellen. Die Celery-basierte Architektur erlaubt zwar eine gewisse Beobachtbarkeit der Task-Verarbeitung, aber dediziertes Interface-Monitoring fehlt. Dies entspricht eher Score 2 (Limited monitoring support), da selbst grundlegende Health-Endpoints nicht als prominentes Feature genannt werden.

2.6 Non-Functional Requirements

2 Authorization NFR

ScanCode.io bietet eine projektbasierte Strukturierung, jedoch ist das Rollenmodell sehr rudimentär und auf globale Rollen (Admin/User) beschränkt. Granulare RBAC-Funktionen auf Repository- oder Pfad-Ebene sind nicht vorhanden.

💡 Begründung: Als OSS-Compliance-Tool mit Django-Backend bietet ScanCode.io grundlegendes User-Management, aber kein flexibles RBAC-System. Rollen sind nicht per Projekt anpassbar, keine Policy-basierte Zugriffskontrolle – entspricht Score 2 (Global Roles Only).

1 IDM connection NFR

ScanCode.io bietet keine native Integration mit Identity-Management-Systemen wie SCIM, LDAP oder OIDC für automatisiertes User-Provisioning. Die Benutzerverwaltung erfolgt manuell über das Django-Admin-Interface.

💡 Begründung: Als Open-Source-Tool ohne Enterprise-IDM-Integration entspricht ScanCode.io Score 1 (Manual Management Only). Kein SCIM, keine automatische Provisionierung, keine AD-Integration ist dokumentiert oder bekannt.

1 Single Sign-On NFR

ScanCode.io unterstützt standardmäßig keine SSO-Integration via OIDC oder SAML. Als Django-basierte Anwendung müssten solche Features manuell integriert werden, was nicht nativ unterstützt wird.

💡 Begründung: Keine dokumentierte SSO-Unterstützung für Azure AD/EntraID via OIDC oder SAML. Die Anwendung verwendet Basic Auth bzw. Django-Session-Auth. Score 1 (No SSO Support) ist angemessen.

3 Client/Instances NFR

ScanCode.io organisiert Scans in isolierten Projekten mit eigenen Eingaben, Ergebnissen und Einstellungen, was eine grundlegende Datentrennung ermöglicht. Eine echte Multi-Tenancy mit separater Benutzer- und Rollenverwaltung pro Mandant fehlt jedoch.

💡 Begründung: Die projektbasierte Isolation entspricht Score 3 (Basic Repository-Level Separation). Daten sind per Projekt getrennt, aber die Benutzerverwaltung ist global und es gibt keine dedizierten Mandanten-Organisationen.

4 Storage of data (Metadata) NFR

ScanCode.io verwendet PostgreSQL als externe Datenbank, was für Produktionsumgebungen vorgeschrieben ist und professionelle Backup- und HA-Strategien ermöglicht. Die Unterstützung ist auf PostgreSQL beschränkt.

💡 Begründung: PostgreSQL ist die vorgesehene und dokumentierte Datenbank für ScanCode.io (Django-basiert). Es ist eine externe DB erforderlich, aber die Unterstützung beschränkt sich auf PostgreSQL – entspricht Score 4 (Specific External DB Mandatory).

2 Data/Object Storage Backend Flexibility NFR

ScanCode.io unterstützt primär lokales Dateisystem für die Speicherung von Artefakten und Scan-Ergebnissen. Eine native Integration mit Cloud-Object-Storage (S3, Azure Blob, GCS) ist nicht standardmäßig vorgesehen und erfordert Anpassungen.

💡 Begründung: Als Django-basierte Anwendung könnte theoretisch django-storages für S3 genutzt werden, aber dies ist nicht nativ dokumentiert oder offiziell unterstützt. Score 2 (Custom Plugins/Workarounds Required) ist konservativ angemessen.

1 Data Archiving & Cleanup NFR

ScanCode.io bietet keine automatisierten Archivierungs- oder Cleanup-Mechanismen. Projekte und Scan-Ergebnisse müssen manuell über die Web-Oberfläche oder die REST-API gelöscht werden.

💡 Begründung: Keine dokumentierte Policy-Engine für automatisches Archivieren oder Löschen alter Scan-Projekte. Cleanup muss manuell in der UI oder per API-Scripting erfolgen – Score 1 (Manual Cleanup in UI Only) bis maximal Score 2, konservativ Score 1.

4 Hosting Flexibility NFR

ScanCode.io ist als On-Premise-Lösung konzipiert und bietet exzellente Containerisierung via Docker und Docker Compose. Es gibt keine offizielle SaaS-Variante, aber Kubernetes-Deployments sind möglich.

💡 Begründung: Starke On-Premise- und Container-Unterstützung (Docker, Docker Compose, potenziell Kubernetes). Kein offizielles SaaS-Angebot verfügbar. Entspricht Score 4 (Strong PaaS & On-Premise).

5 Hardware and Component Requirements NFR

ScanCode.io ist vollständig containerisiert (Docker/Docker Compose) und hat einen moderaten Hardware-Footprint. Die Celery-Worker-Architektur ermöglicht skalierbare Deployments auf Standard-Hardware.

💡 Begründung: Als containerisierte Django/Celery-Anwendung läuft ScanCode.io mit geringen Ressourcen auf Standard-Hardware. Vollständige Docker-Unterstützung und horizontale Skalierbarkeit der Worker – Score 5 (sehr geringer Footprint, containerisiert lauffähig).

4 Installation Mode (automatic / manual) NFR

ScanCode.io bietet offizielle Docker Compose-Konfigurationen und Installations-Skripte, die den Großteil des Setups automatisieren. Einige manuelle Konfigurationsschritte für Datenbank und Umgebungsvariablen sind erforderlich.

💡 Begründung: Docker Compose vereinfacht die Installation erheblich, und offizielle Dokumentation und Skripte sind vorhanden. Es sind einige manuelle Vorbereitungsschritte nötig – Score 4 (Scripted Installation) ist angemessen.

1 Multi-location Deployment Options NFR

ScanCode.io ist für Single-Instance-Deployment konzipiert und bietet keine nativen Multi-Location-Funktionen wie Replikation, Federation oder verteilte Deployment-Modelle.

💡 Begründung: Kein dokumentiertes Multi-Location- oder Replikations-Feature. Als einfaches OSS-Tool ohne Enterprise-Verteilungsarchitektur entspricht dies Score 1 (Not Supported).

3 Application Performance NFR

ScanCode.io nutzt asynchrone Celery-Worker für Scan-Verarbeitung, was parallele Verarbeitung ermöglicht. Bei großen Codebasen oder vielen gleichzeitigen Scans kann die Performance je nach Worker-Konfiguration und Hardware variieren.

💡 Begründung: Die Celery-basierte Architektur ermöglicht skalierbare, parallele Verarbeitung, jedoch ist bei Enterprise-Workloads mit größeren Codebasen Tuning erforderlich. Score 3 (Adequate for standard workloads) ist angemessen.

3 Scalability (manage increase No. of users) NFR

ScanCode.io nutzt Celery-basierte asynchrone Task-Verarbeitung, die parallele Scans ermöglicht und durch Worker-Skalierung horizontal erweiterbar ist. Für Enterprise-Skala mit vielen gleichzeitigen Nutzern sind jedoch manuelle Konfiguration und Infrastruktur-Tuning erforderlich.

💡 Begründung: Celery mit Redis/RabbitMQ als Broker bietet ein solides Concurrency-Modell, aber es gibt keine dokumentierten Auto-Scaling-Mechanismen oder bewährte Enterprise-Deployments im großen Maßstab; entspricht Score 3 (moderate concurrency, careful tuning required).

2 Remote Performance for foreign locations NFR

ScanCode.io ist ein On-Premise-Tool ohne eingebaute Mechanismen für Caching, Replikation oder Edge-Strategien zur Latenzreduzierung für verteilte Teams. Remote-Teams müssen über VPN oder Netzwerkzugang auf den zentralen Server zugreifen.

💡 Begründung: Es gibt keine built-in Mitigation-Mechanismen wie CDN-Integration, Geo-Replikation oder Caching-Strategien für entfernte Standorte. Grundlegende HTTP-Kompression ist möglich, aber das ist Standard und kein dediziertes Feature; entspricht Score 2 (limited support for low-bandwidth/high-latency conditions).

2 Deployment of Customizing --> no coding NFR

ScanCode.io bietet ein Web-Dashboard und grundlegende Konfigurationsoptionen, jedoch sind erweiterte Anpassungen wie Policy-Regeln, Pipelines und Benutzerrollen oft über Konfigurationsdateien oder Code-Änderungen vorzunehmen. Die No-Code-Optionen sind begrenzt.

💡 Begründung: Das Policy-basierte Compliance-Ruleset und grundlegende UI-Konfiguration existieren, aber viele Anpassungen (Pipeline-Definitionen, erweiterte Policies) erfordern Coding oder Konfigurationsdatei-Bearbeitung. Kein ausgereiftes delegiertes Admin-Modell im UI; entspricht Score 2 (limited no-code options, most meaningful customization requires coding/scripting).

4 Deployment of Development --> coding NFR

ScanCode.io bietet eine vollständige REST-API, ist vollständig Open Source und ermöglicht Python-basierte Erweiterungen durch eigene Pipelines und Custom-Code. Die Dokumentation der API und Erweiterungspunkte ist auf GitHub verfügbar.

💡 Begründung: Als Open-Source-Projekt mit vollständiger REST-API, Python-Plugin-Architektur und der Möglichkeit, eigene Pipelines und Pipelines zu schreiben, ist die Coding-Extensibility stark. Limitierungen bestehen bei formalen Support-Grenzen für Custom-Code; entspricht Score 4 (strong API and scripting/extensibility support with minor limits in support scope).

2 Experience/Possibility with/of offshore development NFR

ScanCode.io hat ein einfaches Benutzermodell mit grundlegender Authentifizierung, aber kein ausgereiftes RBAC-System oder externe Identity-Provider-Integration für Offshore-Teams. Projekt-Isolation bietet minimale Governance.

💡 Begründung: Es gibt keine dokumentierten Enterprise-RBAC-Features, SSO/LDAP-Integration oder detaillierte Rollen für externe/Offshore-Teams. Die projektbasierte Struktur bietet minimale Isolierung, aber keine strukturierte Governance für verteilte Teams; entspricht Score 2 (only limited support for external/distributed teams).

3 Flexibility via side-by-side or other extension points NFR

ScanCode.io bietet REST-API-Integration und als Open-Source-Projekt die Möglichkeit, eigene Pipelines zu implementieren. Webhooks und tiefe native Extension-Points sind jedoch begrenzt dokumentiert.

💡 Begründung: API-basierte Integration ist möglich und Custom-Pipelines können geschrieben werden, aber es gibt kein formales Plugin-Framework, keine Event-Webhooks und keine dokumentierten Side-by-Side-Extension-Mechanismen jenseits der API; entspricht Score 3 (mostly API-based integration, limited native extension points).

2 Maintenance and consistency of control tables NFR

Scan-Projekte und grundlegende Einstellungen können über das Web-Dashboard verwaltet werden, jedoch fehlt ein zentralisiertes Governance-Modell für konsistente Kontrolltabellen über Teams und Umgebungen hinweg. API-Automatisierung ist möglich, aber nicht vollständig ausgebaut.

💡 Begründung: Ohne zentrale Policy-Verwaltungs-UI für Cross-Team-Governance und ohne starke Konsistenz-Enforcement-Mechanismen ist die Maintainability auf Skala begrenzt. REST-API erlaubt partielle Automatisierung; entspricht Score 2 (basic controls, consistency is difficult at scale).

5 Source code availability NFR

ScanCode.io ist vollständig Open Source unter Apache 2.0 Lizenz auf GitHub verfügbar. Der gesamte Quellcode kann eingesehen, geändert und geforkt werden.

💡 Begründung: Vollständig Open Source (Apache 2.0) mit aktivem GitHub-Repository, vollständigem Quellcode-Zugang und der Möglichkeit, eigene Forks zu pflegen. Entspricht exakt Score 5 (fully open source with broad code access and practical ability to review/change core behavior).

3 Maintenance effort (upgrades & testing) NFR

ScanCode.io wird aktiv auf GitHub entwickelt mit regelmäßigen Releases, aber als Community-Open-Source-Projekt ohne formale Veröffentlichung von Release-Plänen oder SLA-gebundenen Patch-Zyklen. Upgrade-Dokumentation ist vorhanden, aber Regression-Testing liegt beim Kunden.

💡 Begründung: Aktive Entwicklung mit GitHub-Releases ist positiv, aber ohne formalen Release-Kalender, kommerzielle Unterstützung oder strukturierte Upgrade-Guides ist die Vorhersagbarkeit moderat. Kunden müssen eigene Regressionstests durchführen; entspricht Score 3 (acceptable release model with less predictability or higher validation effort).

2 Backup & Recovery/Redundancy layer in case of break down NFR

ScanCode.io bietet keine nativ dokumentierten HA-Muster oder Backup/Recovery-Mechanismen. Die Datenbankresilienz hängt von der eigenen PostgreSQL-Konfiguration ab, und HA muss vollständig durch eigene Infrastruktur implementiert werden.

💡 Begründung: Als On-Premise-Open-Source-Tool ohne eingebaute HA-Features, Replikationsmechanismen oder dokumentierte Backup/Recovery-Prozeduren im Produkt selbst liegt die Resilienz vollständig beim Betreiber; entspricht Score 2 (limited recovery/HA capabilities).

2 Availability (Maintenance windows, unannounced maintenance) NFR

Da ScanCode.io On-Premise betrieben wird, sind Updates typischerweise mit Downtime verbunden, da Container/Services neu gestartet werden müssen. Rolling-Update-Muster sind möglich bei Kubernetes-Deployment, aber nicht nativ vorkonfiguriert.

💡 Begründung: Kein Zero-Downtime-Upgrade-Modell ist dokumentiert oder standardmäßig unterstützt. Mit Kubernetes können Rolling-Updates möglich sein, aber das erfordert erhebliche eigene Infrastrukturarbeit. Für Standard-Deployments ist Downtime zu erwarten; entspricht Score 2 (significant downtime usually required for updates).

1 Availability defined/possible SLA NFR

Als Open-Source-Community-Produkt für On-Premise-Deployment gibt es keinen Vendor-SLA für Verfügbarkeit. Die Verfügbarkeit ist vollständig in der Verantwortung des betreibenden Unternehmens.

💡 Begründung: Kein kommerzieller Managed Service, keine publizierten Uptime-Commitments, kein SLA-Angebot vom Vendor. SLAs müssen intern definiert und selbst eingehalten werden; entspricht Score 1 (no meaningful provider SLA for product availability).

2.0 Usability & User Experience

2 Ease of Use UX

ScanCode.io bietet ein Web-Dashboard und eine REST-API, jedoch richtet sich das Tool primär an technische Nutzer mit Kenntnissen in OSS-Compliance und Pipeline-Konfiguration. Typische Nutzer benötigen erhebliches Vorwissen und Einarbeitungszeit für die Kernworkflows.

💡 Begründung: Die Plattform ist für Compliance-Experten und Entwickler konzipiert, nicht für breite Nutzerschichten. Das Onboarding erfordert Verständnis von Pipelines, PURLs und SBOM-Konzepten. Gemäß Skala: 'Steeper learning curve; frequent guidance required' entspricht Score 2.

3 Consistent, seamless user interface UX

Das Web-Dashboard bietet eine grundlegende konsistente Oberfläche für Projekt- und Ergebnisverwaltung, jedoch sind Anpassungs- und Theming-Optionen als OSS-Tool sehr begrenzt. Die UI ist funktional, aber ohne nennenswerte Enterprise-Customization.

💡 Begründung: Als Open-Source-Django-Anwendung ist die UI grundlegend konsistent, bietet aber kaum Theming oder Personalisierungsoptionen für Enterprise-Anforderungen. Score 3 ('Generally consistent but with limited adaptation options') trifft zu.

2 Explicit user guidance UX

ScanCode.io stützt sich primär auf externe Dokumentation (GitHub README, Docs-Website) für die Einführung in komplexe Setups; In-Produkt-Assistenten oder kontextuelle Hilfe sind kaum vorhanden. Nutzer müssen sich hauptsächlich auf manuelle Expertenoperationen stützen.

💡 Begründung: Es gibt keine bekannten Setup-Assistenten, Wizards oder kontextuellen In-App-Hilfen. Die Guidance erfolgt über externe Docs. Dies entspricht Score 2 ('Minimal guided UX; mostly manual expert operation').

3 Use-case-oriented design UX

Das Projekt-basierte Design und der Ergebnis-Explorer passen gut zum Compliance-Analyst-Workflow, jedoch können Admin-Tasks und spezifische Developer-Workflows (z.B. CI/CD-Integration) einige Reibungspunkte aufweisen. Die Kern-Aktionen sind erkennbar, aber nicht immer intuitiv.

💡 Begründung: Für den primären Anwendungsfall (Lizenz-Compliance-Scanning) ist das UI-Design adequat. Es gibt jedoch Reibung bei erweiterten Admin- und Entwickler-Workflows. Score 3 ('Adequate fit with some friction in common tasks') ist angemessen.

2 Flexibility of UI UX

Das Dashboard bietet grundlegende Filter- und Suchfunktionen für Scan-Ergebnisse, aber erweiterte Produktivitätsfunktionen wie Tastaturkürzel oder Power-User-Navigation für große Datensätze sind nicht bekannt. Die REST-API kompensiert teilweise für technische Nutzer.

💡 Begründung: Es gibt keine dokumentierten Tastaturkürzel oder reichhaltigen Produktivitätsfunktionen in der Web-UI. Grundlegende Suche/Filter sind vorhanden. Score 2 ('Limited productivity support') ist konservativ aber angemessen.

1 Customizable by end-user / user groups UX

Als OSS-Compliance-Tool bietet ScanCode.io praktisch keine End-User-Personalisierung wie Theme-Auswahl, Layout-Anpassung oder verhaltensbasierte Nutzereinstellungen. Die Anpassbarkeit ist auf Administrator-Ebene beschränkt.

💡 Begründung: Keine bekannten Mechanismen für individuelle Nutzer-Personalisierung (Theme, Layout, Verhalten). Als fokussiertes OSS-Tool ohne Enterprise-UX-Layer entspricht dies Score 1 ('Almost no user-level adaptation').

1 Language Capabilities UX

ScanCode.io ist primär englischsprachig und bietet keine bekannte Mehrsprachigkeit oder Lokalisierungsoptionen in der Benutzeroberfläche. Internationale Teams müssen mit der englischen Oberfläche arbeiten.

💡 Begründung: Als GitHub-basiertes OSS-Projekt ohne bekannte i18n/l10n-Implementierung ist die UI ausschließlich auf Englisch. Score 1 ('English-only or effectively minimal localization capability') trifft zu.

2 Design thinking approach UX

ScanCode.io basiert auf Django und einem Standard-Web-Framework, was eine gewisse Basis-Zugänglichkeit mitbringt, jedoch sind keine expliziten Accessibility-Features (ARIA-Labels, Keyboard-Navigation, WCAG-Konformität) für die Benutzeroberfläche bekannt dokumentiert.

💡 Begründung: Ohne bekannte dedizierte Accessibility-Dokumentation oder WCAG-Konformitätserklärung kann nur ein konservativer Score vergeben werden. Score 2 ('Limited support for inclusive interaction') ist angemessen.

3.2 IT Compliance

3 Single Source of Truth for each data object COMP

ScanCode.io arbeitet projektbasiert und speichert Scan-Ergebnisse lokal in einer eigenen Datenbank; eine native Integration mit externen Master-Data-Systemen (z. B. REF-MDS) über APIs ist nicht vorgesehen. Die REST-API erlaubt den Datenaustausch, aber ein dediziertes Single-Source-of-Truth-Konzept mit führenden Quellsystemen muss individuell implementiert werden.

💡 Begründung: Das Produkt bietet keine out-of-the-box-Mechanismen zur Vermeidung von Datenreplikation oder zur Anbindung an führende Quellsysteme; die REST-API ermöglicht zwar Integrationen, diese sind aber kundenseitig aufzubauen. Daher teilweise konform, Anpassungen nötig – Score 3.

4 Where is the cloud server located? (country) COMP

ScanCode.io ist ein reines On-Premise-Produkt (Open Source), das auf eigener Infrastruktur betrieben wird; der Kunde wählt Hosting-Standort und Hyperscaler (Azure, AWS, On-Prem) vollständig selbst. Es gibt keine vom Vendor betriebene Cloud-Infrastruktur, die geografisch eingeschränkt wäre.

💡 Begründung: Da das Produkt ausschließlich On-Premise deployt wird, hat der Kunde volle Kontrolle über Region und Hyperscaler. Das ist positiv für EU-Compliance und bevorzugte Hyperscaler-Nutzung, allerdings ohne Vendor-seitigen Managed-Cloud-Service – gute regionale Abdeckung mit kleinen Einschränkungen (kein Managed Service), Score 4.

3 Does the cloud service provide the encryption of data at rest and in transit? COMP

ScanCode.io selbst bringt keine eingebauten Verschlüsselungsmechanismen für Daten at rest oder in transit mit; Verschlüsselung ist abhängig von der Deployment-Infrastruktur (Betriebssystem, Datenbank, Reverse Proxy mit TLS). Entsprechende Maßnahmen müssen vom Betreiber konfiguriert werden.

💡 Begründung: Verschlüsselung ist technisch möglich, aber nicht standardmäßig durch das Produkt selbst bereitgestellt oder erzwungen – sie hängt vollständig von der Infrastrukturkonfiguration ab. Das entspricht 'Encryption available but not consistently default or end-to-end', Score 3.

3 GDPR and BDSG COMP

Als On-Premise-Open-Source-Lösung obliegt die DSGVO/BDSG-Compliance vollständig dem betreibenden Unternehmen; ScanCode.io selbst stellt kein DSGVO-Konzept, keine Lösch-Workflows für personenbezogene Daten und keine Auftragsverarbeitungsverträge bereit. Personenbezogene Daten im Nutzerprofile (Name, E-Mail etc.) werden ohne dedizierte Datenschutzfunktionen verwaltet.

💡 Begründung: Es existiert kein Vendor-seitiges DSGVO-Konzept, keine dokumentierte Unterstützung für Betroffenenrechte oder Löschprozesse – die gesamte Verantwortung liegt beim Kunden. Das entspricht 'Basic compliance possible, but governance evidence is limited', Score 3.

2 ISO certificates COMP

nexB als Open-Source-Community-Projekt hält nach öffentlich verfügbaren Informationen keine ISO 27001-Zertifizierung; da es sich um ein On-Premise-OSS-Produkt handelt, gibt es keinen zertifizierten Cloud-Betreiber seitens des Vendors. Die Zertifizierung liegt beim betreibenden Unternehmen.

💡 Begründung: Kein Nachweis einer ISO 27001-Zertifizierung beim Vendor; als Community-OSS-Projekt ist dies typischerweise nicht vorhanden. Lediglich der Betreiber kann eine eigene Zertifizierung vorweisen – 'Limited certification evidence only', Score 2.

4 Data export and import COMP

ScanCode.io unterstützt den Datenexport in standardisierten Formaten (SPDX, CycloneDX, JSON) über die REST-API und das Web-Dashboard; Import von Artefakten ist über URLs, Git-Repos, Datei-Upload und API möglich. Massenänderungen über Excel o. ä. sind nicht nativ unterstützt.

💡 Begründung: Starke Export/Import-Funktionalität über API und Standardformate ist vorhanden; kleinere Lücken bestehen bei manuellen Massenoperationen (kein Excel-Upload). Das entspricht 'Strong export/import support with minor limitations', Score 4.

3.0 Risks & Opportunities

5 Dependencies and Lock-In from Software Vendor RISK

ScanCode.io ist vollständig Open Source (Apache-2.0-Lizenz) und On-Premise deploybar; Daten und Ergebnisse können in offenen Standardformaten (SPDX, CycloneDX) exportiert werden, was eine De-Integration oder Ablösung erheblich erleichtert. Abhängigkeiten zu nexB-eigenen Diensten (DejaCode, PurlDB) sind optional und nicht zwingend erforderlich.

💡 Begründung: Open-Source-Code, offene Exportformate und optionale externe Integrationen ergeben minimalen Vendor Lock-in – entspricht Skala 5 (Very low lock-in and high portability).

2 Project team setup and continuity RISK

ScanCode.io wird primär von einem kleinen Kernteam bei nexB sowie einer Community entwickelt; die Abhängigkeit von wenigen Schlüsselentwicklern und typische Open-Source-Fluktuation stellen ein merkliches Kontinuitätsrisiko dar. Es gibt keine formale Governance oder gesicherte Nachfolgeplanung wie bei großen Foundations.

💡 Begründung: Kleines Kernteam, Community-getriebene Entwicklung ohne gesicherte institutionelle Stabilität – entspricht Skala 2 (Noticeable continuity risk).

4 Time to Market RISK

Da ScanCode.io als containerisierte On-Premise-Lösung mit Docker und vorkonfigurierten Pipelines angeboten wird, ist ein schneller Aufbau einer produktiven Umgebung möglich; die Erstinstallation und Konfiguration erfordert jedoch technisches Know-how, was den Rollout leicht verlangsamt.

💡 Begründung: Docker-basiertes Deployment und fertige Pipelines ermöglichen relativ schnellen produktiven Einsatz mit überschaubarem Aufwand – entspricht Skala 4 (Fast rollout with limited setup effort).

2 Skill of supplier RISK

nexB ist ein kleines Unternehmen mit Spezialkompetenz im OSS-Compliance-Bereich, jedoch fehlen nachgewiesene Erfahrungen in der Begleitung großer Enterprise-Rollouts mit umfangreichem Consulting-, Konzept- und Change-Management-Bedarf. Enterprise-Support-Strukturen sind kaum dokumentiert.

💡 Begründung: Tiefe technische Kompetenz in einem Nischenbereich, aber eingeschränkte Large-Enterprise-Betreuungserfahrung und -kapazität – entspricht Skala 2 (Limited large-enterprise skill depth).

2 Size of supplier (Skalierbarkeit für Großkunden), risk of insolvency RISK

nexB ist ein kleines Unternehmen mit einer überschaubaren Mitarbeiterzahl; die Entwicklung stützt sich stark auf Open-Source-Beiträge. Das Insolvenzrisiko eines kleinen Vendors ist nicht vernachlässigbar, auch wenn der Open-Source-Charakter eine gewisse Resilienz bietet.

💡 Begründung: Kleine Unternehmensgröße und Community-abhängige Entwicklung bedingen sichtbares Abhängigkeitsrisiko – entspricht Skala 2 (Smaller supplier or project with visible dependency risk).

2 World wide rollout RISK

nexB verfügt über keine dokumentierten regionalen Support-Teams oder nachgewiesene Erfahrung mit weltweiten Enterprise-Rollouts; Support läuft primär über GitHub Issues und Community-Kanäle, was für einen globalen Unternehmenseinsatz unzureichend ist.

💡 Begründung: Keine regionalen Support-Strukturen, keine belegten Multi-Regions-Rollout-Erfahrungen – entspricht Skala 2 (Limited regional rollout capability).

3 Dependencies to other strategic projects RISK

ScanCode.io ist technisch weitgehend unabhängig von anderen strategischen Unternehmensprogrammen wie S/4HANA und kann als eigenständige Compliance-Plattform betrieben werden; positive wie negative Abhängigkeiten zu anderen Programmen sind nicht spezifisch erkennbar.

💡 Begründung: Neutrale Abhängigkeitsposition ohne nennenswerte strategische Reibungspunkte oder besondere Synergien – entspricht Skala 3 (Neutral dependency position).

4 Development method (agile or waterfall) RISK

ScanCode.io wird über GitHub mit kontinuierlichen Releases und Issue-basierter Entwicklung betrieben, was einem modernen agilen Open-Source-Delivery-Modell entspricht; Releases folgen iterativen Zyklen und die Roadmap ist öffentlich einsehbar.

💡 Begründung: Agiles, iteratives Open-Source-Entwicklungsmodell mit transparenter Roadmap – entspricht Skala 4 (Good modern delivery fit).

3.2 Total Cost of Ownership

3 Setup/Project Costs TCO

ScanCode.io ist Open Source und kostenlos verfügbar, erfordert jedoch für das initiale Setup Kenntnisse in Docker/Kubernetes, Python-Umgebungen und Celery-Konfiguration, was einen moderaten Einrichtungsaufwand bedeutet.

💡 Begründung: Einerseits entfallen Lizenzkosten und kommerzielle Onboarding-Gebühren (positiv), andererseits erfordert das On-Premise-Deployment mit mehreren Komponenten (PostgreSQL, Redis, Celery, Django) technisches Know-how und Konzeptionsaufwand – daher Moderate setup cost = Score 3.

3 Implementation Costs TCO

ScanCode.io bietet eine REST-API, Pipelines und eine Web-UI out-of-the-box, jedoch erfordert die Integration in bestehende CI/CD-Pipelines, Anpassung von Policies und ggf. Entwicklung eigener Pipeline-Definitionen einen moderaten Implementierungsaufwand.

💡 Begründung: Fertige Pipelines und API reduzieren Eigenentwicklung, aber Customizing (eigene Compliance-Regeln, DejaCode-Integration, Anbindung an SIEM/ITSM) ist nicht trivial. Moderate implementation effort entspricht Score 3.

2 Maintenance / Operation Costs TCO

Als selbst gehostete OSS-Plattform mit mehreren Diensten (Django, Celery Worker, Redis, PostgreSQL) fallen kontinuierliche Betriebsaufwände für Updates, Monitoring, Skalierung und Sicherheits-Patching an, die ohne dedizierten DevOps-Aufwand nicht abgedeckt werden können.

💡 Begründung: On-Premise-Betrieb mit mehreren verteilten Komponenten bedeutet hohen operativen Aufwand für Day-2-Operations (Upgrades, Backups, Worker-Skalierung, Vulnerability-DB-Aktualität). Kein managed Service verfügbar, daher High operating effort = Score 2.

5 License Costs TCO

ScanCode.io ist vollständig Open Source (Apache-2.0-Lizenz) ohne jegliche Lizenzkosten, nutzungsbasierte Gebühren oder versteckte Add-on-Kosten.

💡 Begründung: Reines Open-Source-Modell ohne kommerzielle Lizenzgebühren, keine User-Limits, keine Volume-Pricing – entspricht dem besten Skalenwert: Transparentes, günstiges Modell ohne versteckte Kosten = Score 5.

3 expected benefit/efficiency TCO

ScanCode.io automatisiert Lizenz-Compliance, SBOM-Erstellung und Vulnerability-Matching erheblich, was manuelle Prüfaufwände reduziert, jedoch ist der Effizienzgewinn stark von der Qualität der Integration und dem internen Reifegrad abhängig.

💡 Begründung: Signifikante Automatisierungspotenziale vorhanden (Batch-Scans, Policy-Enforcement, SBOM-Reports), aber ohne kommerzielle SLA, professionellen Support und managed Updates bleibt der tatsächliche Effizienzgewinn im Vergleich zu kommerziellen Alternativen moderat. Score 3 = Moderate benefit.

1.3 Support & Operations

1 1st level SUP

ScanCode.io ist ein Open-Source-Community-Projekt ohne formales 1st-Level-Support-Angebot. Nutzer sind auf GitHub Issues, Dokumentation und Community-Foren angewiesen.

💡 Begründung: Kein kommerzieller Hotline- oder Ticketsystem-Support vorhanden. nexB bietet zwar kommerzielle Services an, jedoch ist kein strukturiertes 1st-Level-Support-Modell für ScanCode.io öffentlich dokumentiert. Entspricht 'Mostly self-support' (Score 1).

1 2nd level SUP

Ein formales 2nd-Level-Support-Modell mit Vendor-Beteiligung ist für ScanCode.io nicht dokumentiert. Support erfolgt primär über GitHub Issues und Community-Beiträge.

💡 Begründung: nexB bietet als Unternehmen zwar professionelle Dienstleistungen an, jedoch ist kein klar strukturiertes 2nd-Level-Support-Modell für ScanCode.io öffentlich verfügbar. Score 1 entspricht 'No reliable second-level model'.

2 3rd level SUP

Bugfixes und Engineering-Eskalationen können über GitHub Issues und Pull Requests an das nexB-Entwicklerteam herangetragen werden, jedoch ohne SLA-Garantien.

💡 Begründung: Als OSS-Projekt mit aktivem nexB-Team gibt es zumindest einen direkten Kanal zu den Entwicklern via GitHub. Dies entspricht eher 'Community or best-effort only', mit leicht erhöhtem Score da ein kommerzieller Hintergrund (nexB) existiert. Score 2 – 'Limited engineering escalation'.

1 General support concept/approach SUP

ScanCode.io wird primär als Open-Source-Projekt betrieben; nexB bietet kommerzielle Beratung und Services an, jedoch kein dokumentiertes Enterprise-Support-Konzept mit Ticketbridge, multilingualer Unterstützung oder globalem Support-Team.

💡 Begründung: Das Support-Konzept basiert hauptsächlich auf Community-Ressourcen (GitHub, Docs). Kein Ticketbridge-System, keine dokumentierten Sprachunterstützungen oder weltweiter Support-Coverage bekannt. Score 1 – 'Very weak or community-only support concept'.

1 SLA for tickets SUP

Es gibt keine dokumentierten SLAs für Ticketlösungszeiten bei ScanCode.io. Reaktionszeiten basieren auf Community-Best-Effort ohne formale Verpflichtungen.

💡 Begründung: Weder für High-, Medium- noch Low-Priority-Tickets sind SLAs publiziert. Entspricht eindeutig 'No real SLA' (Score 1).

1 Support coverage SUP

Es gibt keine 24/7-Support-Coverage für ScanCode.io. Support ist auf Community-Beiträge und GitHub beschränkt, ohne regionale Supportzentren oder Rufbereitschaft.

💡 Begründung: Kein strukturierter Support außerhalb von Community-Hours; keine regionalen Supportstrukturen dokumentiert. Score 1 – 'Community or business-hours only'.

2 Training, tool documentation SUP

ScanCode.io bietet eine technische Online-Dokumentation und ReadTheDocs-Seite. Formale Trainings, Videos, Webinare oder rollenspezifische Schulungen sind nicht bekannt.

💡 Begründung: Die vorhandene Dokumentation ist für ein OSS-Projekt akzeptabel, aber es fehlen strukturierte Trainingsangebote für Endnutzer, Administratoren oder Entwickler. Score 2 – 'Basic documentation only'.

2.4 Projektspezifische Anforderungen

2 Hierarchische Mandantentrennung mit vererbten Policies CTX

ScanCode.io organisiert Scans in Projekten, bietet aber kein mehrstufiges Mandantenmodell mit Policy-Vererbung. Es gibt eine flache Projektstruktur ohne echte Hierarchieebenen oder automatische Policy-Propagation.

💡 Begründung: ScanCode.io kennt nur Projekte als Organisationseinheit ohne übergeordnete Org/Sub-Org/Team-Ebenen. Es gibt RBAC über Django-User-Modell, aber keine mehrstufige Datenisolation oder vererbbare Policies. Dies entspricht Score 2 (flache Trennung über Rollen ohne echte Hierarchie).

2 Mandanten-scoped API-Tokens und Service-Accounts CTX

ScanCode.io bietet REST-API-Tokens über das Django-Framework, diese sind jedoch global und nicht mandantenspezifisch auf Projektebene isoliert. Automatische Rotation und mandantenspezifische Audit-Logs fehlen.

💡 Begründung: Die API-Authentifizierung basiert auf Django REST Framework mit globalen Token-Keys. Es gibt keine technisch erzwungene Mandanten-Scoping-Funktion, keine automatische Rotation und kein dediziertes Audit-Log pro Mandant. Score 2 ist angemessen.

2 Proxy-/Pull-Policy-Gate für JFrog Artifactory ohne XRay-Lizenz CTX

ScanCode.io bietet keine native Artifactory-Integration oder Policy-Gate-Funktion vor dem Artefakt-Download. Es handelt sich um ein nachgelagertes Analyse-Tool ohne Blocking-Capability gegenüber Artifactory.

💡 Begründung: Es existiert kein Artifactory-Connector, kein Webhook-Handler für Pre-Pull-Blocking und keine dokumentierte Integration mit Artifactory-User-Plugins. ScanCode.io ist ein nachgelagertes Scan-Tool. Score 2 (nur nachgelagerte Analyse ohne Artifactory-Integration).

3 Bidirektionale Integration mit bestehendem Dependency-Track ohne Datenduplizierung CTX

ScanCode.io kann CycloneDX- und SPDX-SBOMs exportieren, die manuell in Dependency-Track importiert werden können. Eine native, bidirektionale REST-API-Integration mit Dependency-Track ist nicht dokumentiert.

💡 Begründung: Der Export in CycloneDX-Format ermöglicht einen unidirektionalen manuellen Import in Dependency-Track. Eine explizite, dokumentierte Dependency-Track-Integration via REST API oder ein Finding-Sync existiert nicht. Score 3 (manuelle SBOM-Import-Pipelines möglich, keine native Konnektivität).

4 SBOM-Generierung für Binary-Artefakte in Artifactory (ohne Quellcode-Zugriff) CTX

ScanCode.io unterstützt Binary-Scanning für Docker-Images, JAR-Dateien, NPM-Packages und weitere Artefakttypen direkt ohne Quellcode-Zugriff durch Extraktion eingebetteter Manifeste und Package-Metadaten. Artifactory-spezifische Anbindung fehlt jedoch nativ.

💡 Begründung: ScanCode.io kann Docker-Images, Container-Layer, JARs, npm-Pakete und weitere Binaries direkt analysieren und Paketmetadaten extrahieren. Es fehlt jedoch eine native Artifactory-Anbindung; Artefakte müssen per URL, Upload oder Git bereitgestellt werden. Score 4 ist passend.

2 SBOM-Versionierung und Differenz-Tracking über Artefakt-Versionen CTX

ScanCode.io speichert Scan-Ergebnisse projektbasiert, bietet aber keine native SBOM-Versionierung mit Diff-View über Artefakt-Versionen. Historische Vergleiche müssen extern über SBOM-Exports durchgeführt werden.

💡 Begründung: Es gibt keine integrierte Versions-Historisierung oder Diff-Berechnung zwischen SBOM-Versionen. Projekte können neu gescannt werden, aber ein Vergleich alter vs. neuer SBOM ist nicht nativ implementiert. Score 2 (nur aktuelle Version, keine Historisierung).

3 VEX/OpenVEX-Erstellung und -Verwaltung als First-Class-Feature CTX

ScanCode.io unterstützt CycloneDX VEX-Export als Feature, jedoch fehlt ein vollständiges natives VEX-Management-UI mit Versionierung, Audit-Trail und mandantenspezifischen VEX-Policies. Die Verwaltung erfordert manuelle Pflege.

💡 Begründung: CycloneDX VEX-Unterstützung ist als bekanntes Feature gelistet, jedoch ohne beschriebenes vollständiges Management-UI, Versionierung oder OpenVEX-Support. Score 3 (VEX-Export als CycloneDX-Erweiterung möglich, aber kein natives VEX-Management-UI).

2 Organisationsweite Suppression und Wiederverwendung von Triage-Entscheidungen CTX

ScanCode.io bietet keine organisationsweite automatische Propagation von Triage-Entscheidungen. Compliance-Regeln können projektbasiert definiert werden, eine portfolio-übergreifende Suppression-Wiederverwendung fehlt.

💡 Begründung: Policy-basierte Compliance-Rulesets existieren, aber diese sind projektbezogen und bieten keine automatische Propagation von Triage-Entscheidungen über Projekte hinweg. Score 2 (nur projektweise Triage, Export/Import als Workaround).

3 Aggregierte Vulnerability-Feeds aus mehreren Quellen mit Konfliktauflösung CTX

ScanCode.io nutzt PurlDB und kann über PURL-basiertes Vulnerability-Matching auf externe Quellen zugreifen, jedoch ist die native Unterstützung mehrerer konfigurierbarer Feeds mit Konfliktauflösung begrenzt und nicht vollständig dokumentiert.

💡 Begründung: Die Integration mit PurlDB deutet auf OSV/GitHub Advisory-Daten hin, aber 5 vollständig konfigurierbare Feeds mit transparenter Konfliktauflösung sind nicht nachweisbar. Score 3 erscheint konservativ angemessen, da erweiterte Feed-Konfiguration per Plugin möglich aber nicht nativ ist.

3 License-Policy-Enforcement mit Copyleft-Risikostufen und Ausnahme-Workflow CTX

ScanCode.io bietet policy-basierte Compliance-Rulesets für Lizenz-Compliance, aber einen strukturierten Ausnahme-Workflow mit mehrstufiger Genehmigung durch Legal und vollständigem Audit-Trail bietet das Tool nicht nativ.

💡 Begründung: Policy-basiertes Compliance-Ruleset ist als Feature gelistet, jedoch ohne beschriebene differenzierte Risikostufenkonfiguration oder einen integrierten Genehmigungsworkflow. Score 3 (vordefinierte Policy-Templates, kein nativer Ausnahme-Workflow).

4 SPDX-konforme Lizenzauflösung inkl. komplexer Lizenz-Expressions CTX

ScanCode.io basiert auf ScanCode-Toolkit, das SPDX License Expressions inklusive AND/OR-Kombinationen korrekt parst und für die Policy-Bewertung nutzt. LicenseRef-Unterstützung ist vorhanden, vollständige WITH-Operator-Behandlung für alle Randfälle ist konservativ auf 4 bewertet.

💡 Begründung: ScanCode-Toolkit ist bekannt für granulare Lizenz-Erkennung auf SPDX-Basis mit Expression-Parsing. AND/OR werden verarbeitet; für LicenseRef und komplexe WITH-Expressions ist die vollständige korrekte Policy-Evaluation nicht in allen Fällen dokumentiert nachweisbar. Score 4 ist angemessen.

3 Deklarative Policy-as-Code-Definition mit Versionierung (OPA/Rego oder äquivalent) CTX

ScanCode.io ermöglicht den Export und Import von Compliance-Policies über API und REST-Schnittstellen, jedoch gibt es keinen nativen GitOps-Connector oder OPA/Rego-Support. Policies können skriptbasiert via API deployed werden.

💡 Begründung: Die REST-API ermöglicht programmatisches Policy-Management, aber kein natives Policy-as-Code-Format wie OPA/Rego oder eine dokumentierte YAML-DSL für vollständigen GitOps-Workflow. Score 3 (Export/Import möglich, kein vollständiger Policy-as-Code-Workflow ohne zusätzliche Skripte).

2 Granulare Policy-Gate-Aktionen: Blockieren, Warnen, Quarantäne, Notifizieren CTX

ScanCode.io bietet Policy-basierte Compliance-Regeln, die bei Scan-Ergebnissen ausgelöst werden, jedoch im Wesentlichen auf Block/Allow-Entscheidungen beschränkt sind. Quarantäne-Workflows, Review-Prozesse und differenzierte Notifikationsstufen sind nativ nicht vorhanden.

💡 Begründung: Die Policy-Funktion in ScanCode.io ermöglicht das Markieren von Ergebnissen und ggf. das Auslösen von Webhooks, deckt aber keine vier differenzierten Aktionen (Block, Warn, Quarantine, Notify mit Review-Workflow) nativ ab. Laut Skala entspricht das Score 2: nur einfache Block/Allow-Logik ohne differenzierte Aktionen.

3 Air-Gap / Offline-Betrieb für Vulnerability-Datenfeeds CTX

ScanCode.io ist als On-Premise OSS deploybar und die Feed-URLs sind grundsätzlich konfigurierbar, sodass sie auf interne Mirror zeigen können. Ein offiziell dokumentierter und getesteter Air-Gap-Betrieb mit Signaturprüfung existiert jedoch nicht.

💡 Begründung: Die Vulnerability-Matching-Komponente (via PURL/PurlDB) nutzt externe Dienste, die eigenverantwortlich gespiegelt werden müssten. Es gibt keinen offiziellen Air-Gap-Support oder Mirror-Prozess. Das entspricht Score 3: Feed-URL konfigurierbar, aber keine offizielle Air-Gap-Dokumentation.

1 Manipulationssicheres Audit-Log mit SIEM-Export (CEF/JSON/Syslog) CTX

ScanCode.io verfügt über kein dediziertes, manipulationssicheres Audit-Log für sicherheitsrelevante Aktionen. Ereignisse werden primär in Applikations- und Django-Logs erfasst, ohne strukturierten SIEM-Export.

💡 Begründung: Als Django-basierte OSS-Applikation loggt ScanCode.io über Standard-Django-Logging, das nicht als Audit-Log konzipiert ist. Kein CEF/Syslog-Export, kein Manipulationsschutz, keine SIEM-Konnektoren. Entspricht Score 1 der Skala.

3 Horizontale Skalierung des Scanning-Backends für Enterprise-Artefaktvolumen CTX

ScanCode.io nutzt Celery für asynchrone, queue-basierte Task-Verarbeitung, was horizontale Skalierung durch zusätzliche Worker-Instanzen grundsätzlich ermöglicht. Offizielle Enterprise-Benchmarks und ein Kubernetes-Operator fehlen jedoch.

💡 Begründung: Die Celery-Architektur erlaubt das Hinzufügen von Workern manuell, aber es gibt kein offizielles Helm-Chart oder Kubernetes-Operator und keine dokumentierten Performance-Benchmarks für Enterprise-Volumen. Score 3: skalierbar durch manuelle Konfiguration, aber ohne offizielle Enterprise-Unterstützung.

3 OWASP-Ökosystem-Alignment und aktive OWASP-Projektmitgliedschaft CTX

ScanCode.io ist ein von nexB gesteuertes Vendor-backed OSS-Projekt mit öffentlichem GitHub-Repository und Community-Beteiligung, nutzt OWASP-kompatible Standards (CycloneDX, SPDX), ist aber kein offizielles OWASP-Projekt.

💡 Begründung: ScanCode.io wird primär von nexB entwickelt und gesteuert, hat aber eine aktive Community und öffentlichen Issue-Tracker. Es ist kein OWASP Flagship/Lab/Incubator-Projekt und nicht bei Linux Foundation oder Apache. Score 3: Vendor-backed OSS mit Community, aber primär durch einen Vendor gesteuert.

2 Native CI/CD-Integration mit Policy-Gate-Rückgabecodes für gängige Pipelines CTX

ScanCode.io bietet eine REST-API, über die Scan-Ergebnisse abgerufen und Policy-Ergebnisse ausgewertet werden können. Native CI/CD-Plugins oder Actions für Jenkins, GitLab, GitHub Actions oder Azure DevOps existieren nicht offiziell.

💡 Begründung: Es gibt kein offizielles CLI-Tool mit Exit-Code-Unterstützung für Policy-Gates und keine nativen Plugins für CI/CD-Systeme. Integration ist nur über manuelle API-Aufrufe möglich. Score 2: REST-API vorhanden, Pipeline-Integration nur manuell über Skripte.

2 Kubernetes-natives Deployment mit Helm-Chart und Operator-Support für HA CTX

ScanCode.io wird primär über Docker-Compose deployed, wobei PostgreSQL als externes Backend unterstützt wird. Ein offizielles Helm-Chart oder Kubernetes-Operator ist nicht vorhanden.

💡 Begründung: Die offizielle Dokumentation beschreibt Docker-Compose als primäres Deployment-Modell. Kubernetes-Deployments sind theoretisch möglich, aber nicht offiziell unterstützt oder dokumentiert. Kein Helm-Chart, kein Operator. Score 2 entspricht dieser Situation exakt.

2 Compliance-Dashboard und automatisierter Report-Export für NIS2/BSI-Grundschutz CTX

ScanCode.io bietet ein Web-Dashboard zur Anzeige von Scan-Ergebnissen und Lizenz-Übersichten, jedoch keine vorkonfigurierten Compliance-Dashboards für NIS2/BSI-Grundschutz, kein Scheduling und keine mandantenspezifischen Report-Exporte.

💡 Begründung: Das Dashboard ist primär auf Scan-Ergebnisse und Lizenz-/Copyright-Informationen ausgerichtet. Aggregierte Compliance-Metriken wie MTTR, SLA-Einhaltung oder NIS2-spezifische Berichte fehlen. Export ist über API möglich, aber mit erheblichem Eigenaufwand. Score 2: globale Metriken ohne Mandanten-Filterung, Export nur über API.

4 SBOM-Enrichment aus Container-Image-Layern CTX

ScanCode.io unterstützt die direkte Analyse von Docker-Images und Container-Layern, erkennt Komponenten pro Layer und kann diese in SPDX/CycloneDX-konformen SBOMs ausgeben. Eine tiefe Integration in Remediation-Workflows fehlt jedoch.

💡 Begründung: Die Dokumentation beschreibt Docker-Image- und Container-Layer-Scanning als Feature, mit Komponenten-Zuordnung zu Layern. Die Ausgabe erfolgt in Industriestandard-SBOM-Formaten. Remediation-Workflow-Integration ist nicht tief ausgeprägt. Score 4 ist angemessen.

2 EPSS-Score-Integration und priorisierungsbasiertes Triage-Routing CTX

ScanCode.io führt Vulnerability-Matching über PURLs durch, nutzt dabei primär CVSS-basierte Daten. Eine native EPSS-Score-Integration oder EPSS-basiertes Triage-Routing ist nicht dokumentiert oder vorhanden.

💡 Begründung: Es gibt keine Hinweise auf EPSS-Feed-Integration in ScanCode.io. Das Vulnerability-Matching basiert auf PURL-Abgleich mit bekannten Datenbanken ohne EPSS-Priorisierung. Score 2: nur CVSS-basierte Priorisierung, EPSS nicht direkt integriert.

2 CISA KEV (Known Exploited Vulnerabilities) Catalogue-Integration CTX

ScanCode.io integriert Vulnerability-Daten über PurlDB und externe Quellen, jedoch ist kein dedizierter CISA KEV-Feed als separater, automatisch synchronisierter Datenstrom dokumentiert oder nativ implementiert.

💡 Begründung: CISA KEV-Daten können indirekt über NVD oder OSV in den Daten enthalten sein, aber es gibt keinen dedizierten KEV-Feed, KEV-spezifische Policy-Regeln oder Offline-Import. Score 2: kein nativer KEV-Feed, manuelle Pflege oder externe Skripte erforderlich.

2 Mandantenspezifische Vulnerability-Feed-Konfiguration und -Isolation CTX

ScanCode.io organisiert Scans in isolierten Projekten, aber eine echte Mandantentrennung mit isolierter, mandantenspezifischer Feed-Konfiguration ist nicht implementiert. Feed-Konfigurationen gelten global für die gesamte Instanz.

💡 Begründung: Das Projektmodell bietet Isolation auf Ergebnisebene, aber Vulnerability-Feeds und deren Konfiguration sind global für die ScanCode.io-Instanz. Keine mandantenspezifische Feed-Auswahl, Intervalle oder Vertrauensstufen. Score 2: globale Konfiguration, nur manuelle Workarounds möglich.

2 Rückmeldung von Scan-Ergebnissen in Artifactory-Properties/Metadata CTX

ScanCode.io bietet keine native oder vorkonfigurierte Integration zum Zurückschreiben von Scan-Ergebnissen als Artifactory-Properties. Eine Realisierung wäre nur über externe Skripte möglich, die die ScanCode.io REST-API und die Artifactory REST-API manuell kombinieren.

💡 Begründung: Es gibt keine dokumentierte Artifactory-Integration im Tool. Da die REST-API vorhanden ist, könnten externe Skripte theoretisch Ergebnisse abrufen und in Artifactory zurückschreiben, aber das Tool selbst bietet dafür keinerlei Support oder Dokumentation – entspricht Skala-Wert 2.

2 Automatisierte OSS-Komponenten-Attributionslisten-Generierung (NOTICE-Dateien) CTX

ScanCode.io kann SBOM-Exporte in SPDX und CycloneDX generieren, die Lizenz- und Copyright-Informationen enthalten, jedoch fehlt eine dedizierte Funktion zur Generierung vollständiger Attributionslisten (NOTICE-Dateien) mit eingebetteten Lizenztexten. Es handelt sich eher um einen strukturierten Datei-Export als um ein rechtlich nutzbares Attributionsdokument.

💡 Begründung: Die SBOM-Exporte enthalten Lizenzbezeichnungen und Copyright-Notices, aber keine vollständigen Lizenztexte in einem für rechtliche Dokumente geeigneten Format wie HTML/PDF/TXT. Eine dedizierte NOTICE-Datei-Generierung ist nicht als Feature dokumentiert. Dies entspricht Skala-Wert 2 (CSV/JSON-Export ohne Formatierung für rechtliche Dokumente).

2 Trusted-Component-Registry und positives Whitelisting für Organisationen CTX

ScanCode.io bietet über sein Policy-Ruleset die Möglichkeit, Lizenzen und Pakete zu flaggen oder zu blockieren, jedoch existiert kein dediziertes Whitelist-/Trusted-Component-Registry-Konzept mit Versionsgranularität, Ablaufdatum oder Freigabe-Workflow.

💡 Begründung: Die Policy-Funktion ermöglicht grundlegendes Blocking/Flagging, aber kein positives Whitelisting mit Governance-Features wie Ablaufdatum, Approver-Workflow oder mandantenübergreifender Gültigkeit. Dies entspricht Skala-Wert 2 (nur globale Suppress-/Ignore-Funktion ohne dediziertes Whitelist-Konzept).

3 Transitive Dependency-Auflösung und Tiefenanalyse für SBOM-Vollständigkeit CTX

ScanCode.io analysiert Pakete und deren Metadaten auf Datei- und Paketebene und kann für viele Ökosysteme Abhängigkeiten erkennen. Eine vollständig rekursive transitive Dependency-Auflösung über alle Ebenen ist jedoch nicht explizit als Feature dokumentiert, und ein Vollständigkeits-Score fehlt.

💡 Begründung: ScanCode.io erkennt Paketmetadaten und kann Dependencies aus Manifest-Dateien extrahieren, aber die Tiefe der transitiven Auflösung ist ökosystemabhängig und nicht explizit dokumentiert. Für Binaries ohne Quellcode ist die Auflösung begrenzt. Kein Vollständigkeits-Score vorhanden. Entspricht Skala-Wert 3.

2 Datenbankpartitionierung und Archivierungsstrategie für Langzeit-SBOM-Daten CTX

ScanCode.io bietet keine dokumentierte Datenbankpartitionierungsstrategie oder automatisierte Archivierungsfunktionen. Als Django/PostgreSQL-basiertes Tool liegt die Datenbankwartung vollständig beim Betreiber ohne Tool-seitige Retention-Policy-Unterstützung.

💡 Begründung: Es gibt keine dokumentierten Retention-Policies, Archivierungsworkflows oder Partitionierungsstrategien im ScanCode.io-Projekt. Datenwachstum muss extern über manuelle Datenbankoperationen verwaltet werden. Entspricht Skala-Wert 2.

3 Webhook- und Event-Bus-Integration für asynchrone Event-Driven-Architektur CTX

ScanCode.io bietet eine REST-API, über die Scan-Ergebnisse abgefragt werden können, und grundlegende Webhook-ähnliche Benachrichtigungen sind möglich. Eine robuste Webhook-Integration mit Retry-Logik, mandantenspezifischer Event-Filterung oder Message-Bus-Integration (Kafka/AMQP) ist jedoch nicht als natives Feature dokumentiert.

💡 Begründung: Die REST-API ermöglicht Polling-basierte Integration, und über Celery könnten theoretisch Hooks implementiert werden, aber ein dediziertes, konfigurierbares Webhook-System mit Retry-Logik und Filterung ist nicht dokumentiert. Entspricht Skala-Wert 3 (grundlegende Webhook-Unterstützung ohne Retry oder mandantenspezifische Filterung).

1 Malware- und Typosquatting-Erkennung für Registry-Proxies CTX

ScanCode.io bietet keine native Malware-Erkennung oder Typosquatting-Heuristiken. Das Tool fokussiert auf Lizenz-Compliance und Vulnerability-Matching über PURLs, nicht auf die Erkennung bösartiger Pakete aus öffentlichen Registries.

💡 Begründung: Weder die OSSF Malicious Packages Database noch Typosquatting-Heuristiken sind als Features dokumentiert oder bekannt. Das Vulnerability-Matching über PURLs deckt keine Malware-spezifischen Feeds ab. Vollständige Restlücke gegenüber JFrog Curation – Skala-Wert 1.

1 Softwareintegrität und Artefakt-Signatur-Verifikation (Sigstore/Cosign) CTX

ScanCode.io bietet keine Funktionen zur Verifikation von Artefakt-Signaturen nach Sigstore/Cosign-Standard und keine Integration mit Rekor oder ähnlichen Transparency-Logs. Der Fokus liegt ausschließlich auf Lizenz- und Vulnerability-Analyse.

💡 Begründung: Sigstore/Cosign-Verifikation oder Artefakt-Signatur-Prüfung sind weder als Features dokumentiert noch bekannt. Auch Hash-basierte Integritätsprüfung als Policy-Gate-Kriterium ist nicht vorgesehen. Entspricht Skala-Wert 1.

2 Ressourcen-Quotierung und Rate-Limiting pro Mandant (Fair-Use-Enforcement) CTX

ScanCode.io bietet über Celery grundlegende Concurrency-Konfiguration auf Systemebene, jedoch keine mandantenspezifischen Ressourcen-Quotas, API-Rate-Limits pro Mandant oder Speicherkontingente. Fair-Use-Enforcement für Multi-Tenant-Betrieb ist nicht implementiert.

💡 Begründung: Die Celery-Worker-Konfiguration ermöglicht globale Concurrency-Limits, aber keine mandantenspezifische Differenzierung. API-Rate-Limiting und Speicher-Quotas pro Mandant sind nicht dokumentiert. Entspricht Skala-Wert 2 (nur globale Concurrency-Limits ohne mandantenspezifische Kontrolle).

4 SBOM-as-a-Service API für externe Tool-Integration (SBOM-Upload und -Abfrage) CTX

ScanCode.io bietet eine vollständige REST-API zur Verwaltung von Scan-Projekten, SBOM-Upload (CycloneDX/SPDX) und Ergebnis-Abfrage. Die API ist funktional vollständig und als Open-Source verfügbar, jedoch fehlt eine explizite OpenAPI-Spezifikation mit Versionierungsstrategie und Rückwärtskompatibilitätsgarantie.

💡 Begründung: Die REST-API ist gut dokumentiert und unterstützt SBOM-Upload sowie Ergebnis-Abfrage programmatisch. Eine vollständige OpenAPI-Spec ist nicht prominent als eigenständiges Artefakt publiziert, und explizite API-Versionierung bzw. Rückwärtskompatibilitätsgarantien sind nicht dokumentiert. Entspricht Skala-Wert 4.

3 Regulatorische Berichtspflichten: CRA (Cyber Resilience Act) SBOM-Anforderungen CTX

ScanCode.io implementiert CycloneDX 1.x und SPDX 2.3+ vollständig und kann damit die technischen SBOM-Anforderungen des CRA weitgehend erfüllen. Eine explizite CRA-Compliance-Unterstützung, CRA-spezifische Validierungsworkflows oder ein dokumentierter CRA-Roadmap-Eintrag sind jedoch nicht bekannt.

💡 Begründung: Die SBOM-Standards CycloneDX und SPDX sind vollständig implementiert, was eine externe CRA-Validierung ermöglicht. Dedizierte CRA-Features oder Roadmap-Einträge sind nicht dokumentiert. Entspricht Skala-Wert 3 (keine explizite CRA-Unterstützung, aber SBOM-Standards vollständig implementiert).

3 Dependency-Track-Migrationsbrücke: Erhalt historischer Triage-Daten CTX

ScanCode.io kann CycloneDX-SBOMs importieren und verarbeiten, was einen grundlegenden Import von Dependency-Track-Exporten ermöglicht. Triage-Status, Suppressions und VEX-Daten aus Dependency-Track müssen jedoch manuell neu erfasst werden, da kein dediziertes Migrationswerkzeug existiert.

💡 Begründung: CycloneDX-SBOM-Import ist als Feature vorhanden, und CycloneDX VEX wird unterstützt, was einen partiellen Import ermöglicht. Ein dediziertes Dependency-Track-Migrationswerkzeug oder dokumentierter Parallelbetrieb ohne Datendivergenz ist nicht bekannt. Triage-Historien gehen verloren. Entspricht Skala-Wert 3.

2 Zentraler Service-Delivery-Modus: Self-Service-Onboarding für Sub-Organisationen ohne Admin-Eskalation CTX

ScanCode.io bietet ein projektbasiertes Organisationsmodell mit REST-API, jedoch ist das Berechtigungsmodell auf einfache Admin/User-Rollen beschränkt ohne echtes delegiertes Tenant-Admin-Konzept. Self-Service-Onboarding für Sub-Organisationen ohne Einschaltung der zentralen IT ist nicht als dokumentierter Betriebsmodus vorgesehen.

💡 Begründung: ScanCode.io ist primär ein Scan-Tool für Compliance und SBOM-Generierung, kein Multi-Tenant-Platform-Service. Es fehlen dedizierte Tenant-Admin-Rollen, delegierte Berechtigungsverwaltung innerhalb von Mandantengrenzen und durchsetzbare globale Guardrail-Policies. Die Projektisolierung ist vorhanden, aber kein vollwertiges Multi-Tenancy-Modell. Dies entspricht Score 2: grobe Rollentrennung ohne Self-Service für Mandanten.

2 Reachability-Analyse: Exploitierbarkeits-Kontextbewertung auf Basis tatsächlicher Code-Nutzung CTX

ScanCode.io bietet Vulnerability-Matching via PURL und CycloneDX VEX-Unterstützung, jedoch keine echte Reachability-Analyse oder Call-Graph-basierte Kontextbewertung. EPSS/CVSS-Scores als Proxy sind nicht explizit als Feature dokumentiert, aber VEX kann manuell zur Kontextanreicherung genutzt werden.

💡 Begründung: ScanCode.io fokussiert auf Lizenz-Compliance und SBOM-Generierung; das Vulnerability-Matching ist über PurlDB vorhanden, aber eine Call-Graph-basierte Reachability-Analyse für Java, Python oder JavaScript existiert nicht. Es gibt keine SAST-Integration oder dynamische Heuristiken zur Erreichbarkeitsanalyse. Score 2 ist konservativ korrekt: kein Reachability-Feature, lediglich PURL-basiertes CVE-Matching ohne Nutzungskontext.

2 Operative Observability des Security-Services: Interne Metriken, Health-Checks und Kapazitätsplanung CTX

ScanCode.io nutzt Celery für asynchrone Task-Verarbeitung und Django als Backend, bietet aber keine dokumentierten Prometheus-Metriken, OpenTelemetry-Tracing oder strukturierte Kubernetes-Health-Endpoints als native Features. Basis-Observability muss über externe Agents und Middleware erreicht werden.

💡 Begründung: Als Django/Celery-basierte Anwendung sind Prometheus-Metriken nicht nativ integriert und müssten über django-prometheus oder ähnliche Bibliotheken nachgerüstet werden. Strukturierte /health/live und /health/ready Endpoints sind nicht dokumentiert. Tenant-dimensionierte Nutzungsmetriken für Showback/Chargeback existieren nicht. Dies entspricht Score 2: Metriken nur über externe Agents erreichbar, kein strukturierter Health-Endpoint.

1 Differenziertes Ausnahme- und Dispensationsmanagement mit Genehmigungsworkflow und Ablaufdatum CTX

ScanCode.io bietet kein formalisiertes Ausnahme- und Dispensationsmanagement mit Genehmigungsworkflow, Vier-Augen-Prinzip, Ablaufdaten oder automatischer Eskalation. Policy-basierte Compliance-Regelsets sind vorhanden, aber Suppressionen ohne Audit-Trail und Genehmigungslogik.

💡 Begründung: Das Policy-basierte Compliance-Ruleset von ScanCode.io erlaubt die Definition von Lizenz-Compliance-Regeln, aber ein formalisierter Dispensations-Workflow mit Antragsteller, Genehmiger, dokumentierter Begründung und Ablaufdatum ist nicht Teil des Produktumfangs. Findings können ohne strukturierten Genehmigungsprozess behandelt werden. Dies entspricht Score 1 der Skala: keine strukturierten Ausnahmen mit Nachvollziehbarkeit.

2.6 Produkt-Features

3 SBOM-Import (CycloneDX & SPDX) FEAT

ScanCode.io kann SPDX- und CycloneDX-SBOMs als Input-Artefakte verarbeiten und in Pipelines einlesen. Der Import ist jedoch primär auf das Scanning ausgerichtet, nicht auf ein vollständiges SBOM-Management mit tiefgreifender Validierung.

💡 Begründung: SBOM-Dateien können als Eingabe verwendet werden, aber ein dedizierter, ausgereifter Import-Workflow mit vollständiger Validierung und Mapping aller Felder ist nicht der Fokus des Tools – daher ausreichend (3), aber nicht Best-in-Class.

4 SBOM-Export & Supply-Chain-Transparenz FEAT

ScanCode.io generiert automatisch SBOMs in SPDX- und CycloneDX-Formaten aus Scan-Ergebnissen und stellt diese über die REST-API und das Dashboard zum Export bereit. Dies ist eine Kernfunktion des Tools.

💡 Begründung: SBOM-Export in beiden Industriestandards ist explizit als Feature genannt und gut implementiert. Es fehlen jedoch erweiterte Supply-Chain-Transparenz-Features wie Signierung oder automatisiertes Publishing, daher Score 4.

2 SBOM-Qualitätsbewertung FEAT

ScanCode.io bietet keine dedizierte SBOM-Qualitätsbewertungsfunktion; es prüft Scan-Ergebnisse auf erkannte Metadaten, aber eine strukturierte Vollständigkeitsbewertung importierter SBOMs mit Scoring und Handlungsempfehlungen ist nicht bekannt.

💡 Begründung: Qualitätsbewertung von SBOMs ist kein explizites Feature von ScanCode.io. Es gibt keine bekannte Funktion, die SBOM-Qualitäts-Scores oder strukturierte Hinweise auf fehlende Metadaten liefert – daher rudimentär (2).

2 SBOM-Versionierung & historischer Vergleich FEAT

ScanCode.io verwaltet Projekte isoliert, bietet aber keine native SBOM-Versionierung oder einen strukturierten historischen Vergleich von Scan-Ergebnissen zwischen verschiedenen Versionen eines Projekts.

💡 Begründung: Das projekt-basierte Modell erlaubt zwar mehrere Scans, aber ein dediziertes Diff-Feature für SBOM-Versionen (neue/entfernte/geänderte Komponenten) ist nicht als Feature dokumentiert – erhebliche Lücken, daher Score 2.

5 Standardisierte Komponenten-Identifikation (PURL) FEAT

PURLs (Package URLs) sind ein zentrales Konzept in ScanCode.io; Pakete werden durchgängig über PURLs identifiziert und für Vulnerability-Matching, PurlDB-Integration und SBOM-Export verwendet.

💡 Begründung: PURL ist explizit als Kernfeature genannt (Vulnerability-Matching via PURL, PurlDB-Integration) und tief in die Architektur integriert. Dies entspricht Best-in-Class (5).

3 Interne Komponenten-Datenbank mit Deduplizierung FEAT

ScanCode.io nutzt eine projektbasierte Datenbank mit Paketmetadaten und PURL-basierter Identifikation; eine projektübergreifende, zentrale Komponenten-Datenbank mit automatischer Deduplizierung ist jedoch nicht als Feature beschrieben.

💡 Begründung: Innerhalb eines Projekts werden Pakete konsolidiert, aber eine organisationsweite Komponenten-Datenbank mit automatischer Deduplizierung über Projekte hinweg ist nicht dokumentiert – ausreichend (3), aber mit Lücken.

2 Kontinuierliches Vulnerability Monitoring FEAT

ScanCode.io führt Vulnerability-Matching zum Scan-Zeitpunkt durch, bietet jedoch kein kontinuierliches Monitoring, das automatisch neue CVEs mit bereits gescannten Komponenten abgleicht.

💡 Begründung: Kontinuierliches Vulnerability-Monitoring ist nicht als Feature beschrieben; Scans sind projektbasiert und einmalig/manuell ausgelöst. Für kontinuierliches Monitoring wären externe Scheduler oder erneute Scans nötig – rudimentär (2).

3 Multi-Feed Vulnerability Aggregation FEAT

ScanCode.io integriert über die PurlDB und externe Vulnerability-Datenbanken mehrere Quellen, wobei OSV und ähnliche Feeds über die nexB-Infrastruktur aggregiert werden. Die genaue Anzahl und Konfigurierbarkeit der Feeds ist begrenzt dokumentiert.

💡 Begründung: Multi-Feed-Integration ist teilweise vorhanden (PurlDB, PURL-basiertes Matching), aber die explizite Konfiguration mehrerer Feeds (NVD, GitHub Advisories etc.) ist nicht klar dokumentiert – konservativ ausreichend (3).

2 CVSS- & EPSS-Score-Integration FEAT

ScanCode.io zeigt Vulnerability-Informationen aus abgeglichenen Datenbanken an, aber eine explizite Integration und Anzeige von CVSS v2/v3/v4 sowie EPSS-Scores ist nicht als dediziertes Feature dokumentiert.

💡 Begründung: CVSS-Scores könnten über die vulnerability-matched Daten vorhanden sein, EPSS ist jedoch nicht erwähnt. Da beides nicht explizit als Feature genannt ist, wird konservativ Score 2 vergeben.

3 VEX (Vulnerability Exploitability eXchange) Support FEAT

ScanCode.io unterstützt das CycloneDX VEX-Format für den Export, was eine grundlegende VEX-Unterstützung darstellt. Ein vollständiger VEX-Import-Workflow ist weniger klar dokumentiert.

💡 Begründung: CycloneDX VEX-Unterstützung ist explizit als Feature genannt, jedoch scheint der Fokus auf dem Export zu liegen. Import und vollständiges VEX-Lifecycle-Management sind nicht klar belegt – ausreichend (3).

1 Vulnerability Lifecycle Management & Triage-Workflows FEAT

ScanCode.io ist primär ein Scan- und Analyse-Tool ohne dedizierte Vulnerability-Lifecycle-Management-Funktionen wie Triage-Workflows, Status-Tracking, False-Positive-Management oder Risk-Acceptance-Prozesse.

💡 Begründung: Vulnerability Lifecycle Management mit strukturierten Workflows, Triage, Remediation-Tracking und False-Positive-Handling ist kein Bestandteil von ScanCode.io – dies ist eher ein ASPM/VM-Tool-Feature. Score 1 (nicht vorhanden).

3 Konfigurierbare Policy Engine FEAT

ScanCode.io bietet ein policy-basiertes Compliance-Ruleset für Lizenz-Compliance mit automatischer Auswertung bei Scan-Ergebnissen, hauptsächlich über die DejaCode-Integration. Schweregrad-Schwellenwerte und Komponenten-Blacklists sind weniger klar dokumentiert.

💡 Begründung: Lizenz-Policy-Enforcement ist als Feature genannt und über DejaCode-Integration ausbaubar, aber eine vollständig konfigurierbare Policy-Engine mit Schwachstellen-Schwellenwerten und Blacklists ist nicht umfassend dokumentiert – ausreichend (3).

5 Lizenz-Compliance & SPDX-Identifikation FEAT

ScanCode.io bietet Best-in-Class Lizenz-Erkennung auf Datei- und Snippet-Ebene mit SPDX-Bezeichnerzuordnung sowie konfigurierbare Policy-Compliance-Regeln, die automatisch bei Scan-Ergebnissen geprüft werden. SBOM-Export in SPDX und CycloneDX ist nativ integriert.

💡 Begründung: Das Produkt wurde explizit für OSS-License-Compliance entwickelt, unterstützt SPDX-Identifikatoren nativ, bietet granulare Lizenz-Erkennung und automatisierte Policy-Checks – dies entspricht dem Kriterium 'Best-in-Class, vollständig und ausgereift erfüllt' (Score 5).

1 SLA-Tracking für Schwachstellen FEAT

ScanCode.io bietet Vulnerability-Matching via PURL, jedoch keine konfigurierbaren SLA-Fristen pro Schweregrad oder automatische Eskalationsmechanismen bei Fristenüberschreitung. Diese Funktionalität ist nicht Bestandteil des Produktes.

💡 Begründung: Das Produkt ist primär eine Scan- und SBOM-Plattform ohne dediziertes SLA-Tracking-Modul. Konfigurierbare SLA-Fristen, automatische Warnungen und Eskalationen bei Schwachstellen-Fristen sind nicht dokumentiert oder bekannt – Score 1 gemäß Skala 'Nicht vorhanden / unzureichend'.

2 Hierarchische Projekt- und Portfolio-Strukturierung FEAT

ScanCode.io organisiert Scans in isolierten Projekten, bietet jedoch keine native hierarchische Portfolio-Strukturierung (Portfolio > Produkt > Projekt > Komponente) oder aggregierte Risikoanalyse über mehrere Ebenen hinweg.

💡 Begründung: Die projektbasierte Scan-Verwaltung ist vorhanden, aber eine mehrstufige Hierarchie mit Aggregationsebenen für Portfolio-Analysen fehlt. Dies entspricht 'Rudimentär, erhebliche Lücken' (Score 2), da nur die unterste Projektebene abgedeckt wird.

2 Konfigurierbares Notification & Alerting Framework FEAT

ScanCode.io verfügt über kein eingebautes, konfigurierbares Notification-Framework für Kanäle wie E-Mail, Slack oder MS Teams. Policy-Verstöße werden erkannt, aber aktive Benachrichtigungen sind rudimentär oder über externe Integration realisierbar.

💡 Begründung: Es gibt keine dokumentierte native Unterstützung für Multi-Kanal-Benachrichtigungen (E-Mail, Slack, Webhooks). Allenfalls könnten über die REST-API externe Systeme angebunden werden, was jedoch erhebliche Eigenlösung erfordert – Score 2 'Rudimentär, erhebliche Lücken'.

2 Dashboards & Risiko-Scoring (Projekt & Portfolio) FEAT

ScanCode.io bietet ein webbasiertes Dashboard zur Anzeige von Scan-Ergebnissen auf Projektebene, jedoch fehlen aggregierte Portfolio-Dashboards, Trend-Analysen und systematisches Risiko-Scoring über mehrere Projekte hinweg.

💡 Begründung: Das vorhandene Dashboard ist auf Projektergebnisse ausgerichtet und zeigt keine Portfolio-weiten aggregierten Risiko-Scores oder Trend-Analysen. Dies entspricht Score 2 'Rudimentär, erhebliche Lücken' gemäß der Bewertungsskala.

2 Automatisierte Bericht-Generierung FEAT

ScanCode.io ermöglicht den Export von Scan-Ergebnissen als SPDX/CycloneDX-SBOM sowie JSON-Reports über die REST-API, bietet aber keine anpassbaren Executive-Summary- oder technischen Detailberichte in PDF- oder HTML-Format.

💡 Begründung: Die Berichtsgenerierung beschränkt sich auf SBOM-Standardformate und maschinenlesbare Outputs. Anpassbare, management-taugliche Reports (PDF/HTML, Executive Summary) sind nicht vorhanden – Score 2 'Rudimentär, erhebliche Lücken'.

4 CI/CD-Integration via REST-API & CLI FEAT

ScanCode.io bietet eine vollständige REST-API für Scan-Projektverwaltung und -ergebnisse sowie CLI-Unterstützung, was eine solide Integration in CI/CD-Pipelines ermöglicht. SBOM-Uploads, Pipeline-Trigger und Policy-Checks sind über die API zugänglich.

💡 Begründung: REST-API ist als bekanntes Feature explizit dokumentiert, und CLI-Tools (scancli) sind verfügbar. Die CI/CD-Integration ist gut umsetzbar, übertrifft die Mindestanforderung, erreicht aber möglicherweise nicht Best-in-Class-Niveau hinsichtlich nativer Pipeline-Plugins – Score 4 'Gut, übertrifft die Mindestanforderung'.

2 Granulares RBAC mit Multi-Tenancy-Unterstützung FEAT

ScanCode.io bietet grundlegende Projektisolation, jedoch kein feingranulares RBAC-System auf Team- und Projektebene oder eine ausgereifte Multi-Tenancy-Unterstützung für die Isolation mehrerer Organisationseinheiten.

💡 Begründung: Als OSS-Compliance-Tool fokussiert sich ScanCode.io auf Scanning-Funktionalität. Feingranulare Rollenkonzepte und Multi-Tenancy-Isolation sind nicht als bekannte Features dokumentiert; allenfalls rudimentäre Benutzerkontrollen dürften vorhanden sein – Score 2 'Rudimentär, erhebliche Lücken'.

ANBIETER

OSS Review Toolkit Community (Linux Foundation)

PRODUKT

OSS Review Toolkit (ORT)

DEPLOYMENT

On-Premise

WEBSITE

https://oss-review-toolkit.org

GESAMTSCORE

2.64/5

2.5 Integration

3 General Interfaces/APIs INT

ORT bietet eine REST-API über die optionale ORT Server-Komponente sowie CI/CD-Integrationen (GitHub Actions, GitLab CI, Jenkins). Die API-Dokumentation existiert, ist jedoch primär auf die Server-Komponente ausgerichtet; vollständige Middleware-Konnektoren (API-Gateway, EAI, EDI) sind nicht out-of-the-box enthalten.

💡 Begründung: Die REST-API und CI/CD-Integrationen sind vorhanden und dokumentiert, jedoch handelt es sich um eine Basis-API ohne fertige Out-of-the-box-Konnektoren für gängige Middleware-Plattformen (PI, EAI, API-Manager). Eigenaufwand für tiefergehende Integrationen ist erforderlich, was Score 3 entspricht.

2 Interface monitoring INT

ORT bietet kein dediziertes Interface-Monitoring; es gibt grundlegende Health-Endpunkte im ORT Server und Logging über die Pipeline-Ausgaben, aber keine eingebauten Monitoring- oder Diagnose-Dashboards für Schnittstellenverfügbarkeit und -performance.

💡 Begründung: Es existieren keine nennenswerten eingebauten Interface-Monitoring-Funktionen. Logs und möglicherweise rudimentäre Health-Checks sind vorhanden, aber strukturiertes Interface-Monitoring mit Diagnose fehlt weitgehend. Das entspricht Score 2 (Limited monitoring support).

2.5 Non-Functional Requirements

2 Authorization NFR

ORT als CLI-Toolchain und ORT Server bieten keine granulare RBAC-Kontrolle auf Repository- oder Pfad-Ebene. Der ORT Server kann Authentifizierung unterstützen, aber ein ausgefeiltes Rollenmodell ist nicht primär ein Feature der Toolchain.

💡 Begründung: ORT ist primär eine CI/CD-Toolchain ohne dediziertes Benutzer- und Berechtigungsmanagement. Der ORT Server bietet rudimentäre Authentifizierung, jedoch kein granulares RBAC-System mit anpassbaren Rollen auf Repository-Ebene. Bestenfalls gibt es globale Zugriffskontrollen, was Score 2 entspricht.

1 IDM connection NFR

ORT bietet keine native IDM-Integration mit SCIM, OIDC oder LDAP für automatisiertes User-Provisioning. Als Open-Source-Toolchain ist User-Management nicht ein Kernfeature.

💡 Begründung: ORT ist eine Compliance-Toolchain ohne eigenes Benutzermanagementsystem. Es gibt keine dokumentierte SCIM-, OIDC- oder LDAP-Provisioning-Integration. Benutzer werden nicht im ORT-Kontext verwaltet, was Score 1 rechtfertigt.

1 Single Sign-On NFR

ORT unterstützt kein natives Single Sign-On über Azure AD/EntraID mit OIDC oder SAML. Die Toolchain hat kein eigenes Authentifizierungssystem das SSO-Protokolle implementiert.

💡 Begründung: Als CLI-Tool und Pipeline-Toolchain besitzt ORT keine eigene Web-UI mit SSO-Unterstützung. Der ORT Server könnte rudimentäre Auth haben, aber selbstkonfigurierbare OIDC/SAML-SSO-Integration ist nicht als Feature dokumentiert. Score 1 ist angemessen.

1 Client/Instances NFR

ORT bietet keine native Mandantentrennung oder Multi-Tenant-Konzepte. Jede Installation ist projektbezogen und ohne logische Isolation zwischen verschiedenen Clients/Instanzen.

💡 Begründung: ORT ist als Toolchain konzipiert, die pro Projekt/Pipeline ausgeführt wird. Es gibt kein Konzept von 'Organizationen' oder 'Projekten' mit isolierter Datentrennung wie bei SaaS-Plattformen. Eine Trennung ist nur durch separate Instanzen möglich, was eher Score 2 naheläge, jedoch ohne echte Multi-Instance-Support-Features bleibt es bei Score 1-2; konservativ Score 1.

3 Storage of data (Metadata) NFR

Der ORT Server unterstützt eine externe Datenbank (PostgreSQL) für persistente Speicherung von Scan-Ergebnissen. Im CLI-Modus werden Ergebnisse als JSON/YAML-Dateien gespeichert.

💡 Begründung: ORT Server verwendet PostgreSQL als externe Datenbank, was produktionsreifes Deployment ermöglicht. Die Unterstützung ist jedoch auf PostgreSQL limitiert (kein MS SQL, Oracle), was Score 4 ausschließt. Der CLI-Modus ohne Server nutzt Dateisystem. Score 3 (Optional External DB) passt, da der Server-Modus optional ist.

1 Data/Object Storage Backend Flexibility NFR

ORT speichert Scan-Ergebnisse primär als Dateien im lokalen Dateisystem oder über den ORT Server in einer Datenbank. Native Cloud Object Storage Integration ist nicht vorgesehen.

💡 Begründung: ORT ist eine Analyse-Toolchain, kein Artifact Repository. Die Ausgaben (SBOM, Berichte) werden als Dateien gespeichert. Es gibt keine dokumentierte native Integration mit S3, Azure Blob oder GCS für die Datenspeicherung. Score 1 (Filesystem Only) ist korrekt.

1 Data Archiving & Cleanup NFR

ORT bietet keine eingebauten Archivierungs- oder automatischen Cleanup-Mechanismen für gespeicherte Scan-Ergebnisse oder Berichte. Dies muss manuell oder über externe Prozesse gelöst werden.

💡 Begründung: Als Toolchain ohne eigenes Daten-Lifecycle-Management hat ORT keine Policy-Engine für Archivierung oder Cleanup von Ergebnisdaten. Cleanup muss durch externe Skripte oder manuelle UI-Eingriffe erfolgen. Score 1 (Manual Cleanup in UI Only) ist angemessen, da nicht mal eine UI vorhanden ist – konservativ Score 1.

4 Hosting Flexibility NFR

ORT ist als Open-Source-Tool primär für On-Premise und CI/CD-Pipeline-Deployment konzipiert. Es unterstützt Docker-Container und kann auf Kubernetes deployed werden (Helm Charts für ORT Server vorhanden). Ein vendor-managed SaaS existiert nicht.

💡 Begründung: ORT bietet starke On-Premise und PaaS/Container-Unterstützung via Docker und Kubernetes mit verfügbaren Helm Charts für den ORT Server. SaaS wird vom Vendor nicht angeboten. Dies entspricht Score 4 (Strong PaaS & On-Premise) ohne SaaS-Option.

4 Hardware and Component Requirements NFR

ORT läuft als Docker-Container oder JVM-basierte CLI-Anwendung mit moderaten Hardware-Anforderungen. Scanning-Intensität kann variieren, aber Standard-Hardware ist ausreichend für typische Deployments.

💡 Begründung: ORT ist JVM-basiert und containerisierbar. Die Hardware-Anforderungen sind moderat – für große Codebases mit intensivem Scanning kann RAM-Bedarf steigen, aber es sind keine unverhältnismäßig hohen Anforderungen dokumentiert. Score 4 (Moderater Footprint, Standard-Hardware ausreichend) ist passend.

3 Installation Mode (automatic / manual) NFR

ORT kann über Docker oder als JVM-Tool installiert werden. Es gibt offizielle Docker-Images und GitHub Actions, aber die vollständige Einrichtung (insb. ORT Server mit DB) erfordert manuelle Konfigurationsschritte.

💡 Begründung: Die Installation ist gut dokumentiert mit Docker-Images und CI/CD-Templates. Jedoch ist die Einrichtung einer vollständigen ORT-Pipeline mit Server, Datenbank und Scanner-Backends ein manueller Multi-Step-Prozess. Score 3 (Manual but Well-Documented) ist angemessen.

1 Multi-location Deployment Options NFR

ORT bietet keine nativen Multi-Location-Deployment-Features wie Replikation oder Federation. Als Toolchain ist jede Pipeline-Ausführung eigenständig ohne zentrales verteiltes Repository-Konzept.

💡 Begründung: ORT ist eine Analyse-Toolchain ohne Artifact-Repository-Funktionalität. Es gibt keine Replikations-, Caching- oder Federation-Features für verteilte Umgebungen. Ergebnisse werden lokal oder im ORT Server gespeichert ohne Multi-Location-Synchronisation. Score 1 ist korrekt.

3 Application Performance NFR

ORT's Performance hängt stark von der Größe der analysierten Codebase und der Anzahl der Dependencies ab. Für Standard-Workloads ist die Performance adäquat, große Monorepos oder intensive Scans können erhebliche Zeit benötigen.

💡 Begründung: ORT ist eine Batch-Processing-Toolchain, keine Low-Latency-Plattform. Für typische Projekte ist die Performance akzeptabel, aber Scanning-Zeiten können bei großen Codebases substanziell sein. Es ist kein Echtzeit-System, was Score 3 (Adequate for standard workloads, larger workloads require tuning) rechtfertigt.

3 Scalability (manage increase No. of users) NFR

ORT bietet mit dem ORT Server eine skalierbare Backend-Komponente, die parallele Scan-Jobs über eine Queue-basierte Architektur abwickeln kann. Die Skalierbarkeit hängt jedoch stark von der eigenen Infrastruktur und Konfiguration ab, da es sich um ein On-Premise-Tool handelt.

💡 Begründung: Der ORT Server ermöglicht parallelisierte Verarbeitung und horizontale Skalierung, jedoch ohne enterprise-proven Out-of-the-Box-Lösung. Skalierung erfordert manuelle Infrastrukturplanung. Score 3 ist angemessen: moderate Concurrency-Unterstützung, die mit sorgfältiger Tuning-Arbeit für Standardlasten funktioniert.

2 Remote Performance for foreign locations NFR

ORT ist ein CLI/Server-basiertes On-Premise-Tool ohne explizite eingebaute Mechanismen für Latenzoptimierung, Caching für Remote-Teams oder Edge-Strategien. Remote-Teams könnten eigene ORT-Instanzen betreiben, was aber manuellen Setup-Aufwand erfordert.

💡 Begründung: Es gibt keine dokumentierten eingebauten Replikations-, Caching- oder Edge-Proxy-Mechanismen für verteilte/offshore-Teams. Die dezentrale Deploybarkeit bietet eine gewisse Flexibilität, aber aktive Latenzminimierungs-Features fehlen. Score 2 ist konservativ aber angemessen.

2 Deployment of Customizing --> no coding NFR

Die meisten Konfigurationen in ORT (Curations, Resolutions, Policy-Regeln) werden als Code-Dateien (YAML, Kotlin-DSL) verwaltet und erfordern technisches Know-how. Eine grafische No-Code-UI für administrative Anpassungen ist nur rudimentär vorhanden.

💡 Begründung: ORT ist primär ein Code/Config-as-Code-Tool. Customization ohne Coding ist stark eingeschränkt – Curations sind YAML, Regeln sind Kotlin-DSL. Es gibt keine erweiterte No-Code-UI. Score 2 ist zutreffend: die meisten bedeutsamen Anpassungen erfordern Coding/Scripting.

4 Deployment of Development --> coding NFR

ORT bietet eine umfassende REST API (ORT Server), eine Kotlin-DSL für Policy-Regeln, Plugin-Mechanismen für Scanner-Backends und ist vollständig Open Source, sodass Teams tief in die Codebasis eingreifen können. CI/CD-Integrationen sind offiziell dokumentiert.

💡 Begründung: Starke Extensibilität durch offene Quellen, REST API, DSL-basierte Regelentwicklung und Plugin-Modell für Scanner-Backends. Klarer Entwicklungsrahmen vorhanden. Score 4 ist passend: starke API- und Scripting-Unterstützung mit kleineren Einschränkungen im formalen Support-Scope.

3 Experience/Possibility with/of offshore development NFR

ORT kann On-Premise deployed werden und unterstützt grundsätzlich RBAC-Konzepte über den ORT Server, jedoch sind explizite Features für externe Nutzer/Gäste und dediziertes Offshore-Governance-Management nicht prominent dokumentiert.

💡 Begründung: Offshore-Collaboration ist technisch möglich (eigene Instanzen, API-Zugriff, CI/CD-Integration), aber es fehlen explizite Features für externe Nutzer-Onboarding, Guest-Rollen oder ausgereiftes RBAC für verteilte Teams. Score 3: möglich, aber mit manuellem Setup und Governance-Lücken.

4 Flexibility via side-by-side or other extension points NFR

ORT bietet ein modulares Plugin-System für Scanner-Backends (ScanCode, FossID, SCANOSS), eine Kotlin-DSL für Evaluator-Regeln, eine REST API über den ORT Server sowie CI/CD-Hooks, was tiefe Side-by-Side-Erweiterbarkeit ermöglicht.

💡 Begründung: Das Plugin-Modell für Scanner-Backends, die offene DSL, die REST API und die CI/CD-Integration bieten starke Extensionspunkte. Als Open-Source-Projekt sind auch Core-Änderungen möglich. Score 4: starke Erweiterbarkeit mit gewissen Einschränkungen in der operativen Tiefe ohne eigene Entwicklung.

3 Maintenance and consistency of control tables NFR

ORT verwaltet Konfigurationen (Curations, Resolutions, Regeln) als versionierte Code-Dateien in Git-Repositories, was Konsistenz über Umgebungen ermöglicht. Eine zentralisierte UI für die Verwaltung von Control-Strukturen ist jedoch begrenzt.

💡 Begründung: Configuration-as-Code-Ansatz bietet gute Konsistenz via Git-Workflows, aber zentralisierte UI-basierte Verwaltung ist schwach. Für große Teams ohne starke GitOps-Disziplin kann die Konsistenz schwierig aufrechtzuerhalten sein. Score 3: adequate controls mit partieller Konsistenzunterstützung.

5 Source code availability NFR

ORT ist vollständig Open Source unter der Apache-2.0-Lizenz, gehostet auf GitHub unter der Linux Foundation. Der gesamte Quellcode ist frei zugänglich, modifizierbar und forkbar ohne Einschränkungen.

💡 Begründung: Vollständig Open Source (Apache 2.0), gesamter Code auf GitHub verfügbar, keine proprietären Komponenten im Core. Kunden können den Code vollständig einsehen, ändern und forken. Score 5 ist klar gerechtfertigt.

3 Maintenance effort (upgrades & testing) NFR

ORT als Community-Projekt unter der Linux Foundation hat aktive Entwicklung auf GitHub mit regelmäßigen Releases, aber ohne kommerziellen Support-SLA. Upgrade-Guidance und Regression-Test-Unterstützung sind community-abhängig.

💡 Begründung: Aktive Community-Entwicklung mit transparentem GitHub-Changelog, aber keine garantierten Release-Zyklen oder formale Upgrade-Guidance. Regression-Testing liegt vollständig beim Kunden. Score 3: akzeptables Release-Modell mit weniger Vorhersehbarkeit und höherem Validierungsaufwand.

2 Backup & Recovery/Redundancy layer in case of break down NFR

ORT als On-Premise-CLI/Server-Tool bietet keine eingebauten HA- oder Backup/Recovery-Mechanismen. Diese müssen vollständig durch eigene Infrastruktur (DB-Backups, Container-Orchestrierung, etc.) implementiert werden.

💡 Begründung: ORT selbst dokumentiert keine nativen HA-Patterns, Backup-Restore-Mechanismen oder Redundanz-Konzepte. Resilience liegt komplett beim Betreiber. Score 2: limitierte Recovery/HA-Fähigkeiten ohne eigene Infrastrukturmaßnahmen.

3 Availability (Maintenance windows, unannounced maintenance) NFR

Bei containerbasiertem Deployment (Docker/Kubernetes) können Rolling Updates mit minimalem Downtime realisiert werden, jedoch ist dies nicht als standardisiertes, offiziell unterstütztes Pattern dokumentiert. Wartungsfenster hängen von der eigenen Infrastruktur ab.

💡 Begründung: Kein explizites Blue/Green- oder Zero-Downtime-Upgrade-Konzept dokumentiert. Mit Kubernetes möglich, aber nicht out-of-the-box. Score 3: moderater Downtime je nach Deployment-Modell, Verbesserungen durch eigene Infrastruktur möglich.

1 Availability defined/possible SLA NFR

Als Open-Source-Community-Projekt ohne kommerziellen Managed Service bietet ORT keinerlei formale SLA-Verfügbarkeitszusagen. Verfügbarkeit liegt vollständig in der Verantwortung des betreibenden Unternehmens.

💡 Begründung: ORT ist ein Community-Open-Source-Tool ohne kommerziellen Hersteller-Support oder Managed-Service-Angebot. Kein Provider-SLA existiert oder ist publiziert. Score 1 ist korrekt: keine bedeutsame Provider-SLA für Produktverfügbarkeit.

1.6 Usability & User Experience

2 Ease of Use UX

ORT ist ein CLI-basiertes Tool mit komplexer mehrstufiger Pipeline, das erhebliches technisches Vorwissen erfordert; typische Nutzer benötigen intensive Einarbeitung in Konfiguration, DSL und Toolchain-Konzepte.

💡 Begründung: ORT richtet sich primär an DevOps/Compliance-Experten und bietet keine intuitive grafische Benutzeroberfläche für Standardaufgaben. Die Vielzahl an Komponenten (Analyzer, Scanner, Evaluator etc.) und die Kotlin-DSL erhöhen die Einstiegshürde erheblich – entspricht Skala 2 (steile Lernkurve, häufige Unterstützung nötig).

2 Consistent, seamless user interface UX

ORT besteht hauptsächlich aus CLI-Tools und textbasierten Konfigurationsdateien; eine konsistente grafische Benutzeroberfläche mit Enterprise-UX-Standards ist kaum vorhanden, der ORT Server bietet rudimentäre Web-UI.

💡 Begründung: Die Toolchain ist CLI-zentriert mit verschiedenen Ausgabeformaten und optionalem Server-Backend. Eine einheitliche, anpassbare UI mit Enterprise-Theming existiert nicht in relevantem Umfang – Score 2 ist angemessen (inkonsistente UX, schwer auf Unternehmensstandards ausrichtbar).

2 Explicit user guidance UX

ORT bietet umfangreiche externe Dokumentation und Community-Ressourcen, aber kaum In-Product-Guidance, Wizards oder kontextuelle Hilfe innerhalb des Tools selbst.

💡 Begründung: Guidance erfolgt primär über externe Dokumentation (GitHub Wiki, README), nicht durch In-Product-Assistenten oder geführte Setup-Workflows. Dies entspricht Skala 2 (minimale guided UX, überwiegend manuelle Expertenbedienung).

2 Use-case-oriented design UX

ORT ist stark auf Compliance-Experten und DevOps-Ingenieure ausgerichtet; für typische Entwickler oder nicht-technische Nutzer besteht erhebliche Diskrepanz zwischen Tool-Design und alltäglichen Aufgaben.

💡 Begründung: Die Pipeline-orientierte Architektur und CLI-Bedienung passen gut zu CI/CD-Szenarien, aber schlecht zu administrativen oder entwicklerzentrierten UI-Workflows. Für mehrere Kern-Anwendungsfälle gibt es spürbare Reibungspunkte – Score 2 ist konservativ aber angemessen.

2 Flexibility of UI UX

Als primär CLI-basiertes Tool bietet ORT grundlegende Produktivitätsfeatures für erfahrene Nutzer über Kommandozeilenparameter, jedoch keine grafischen Shortcuts, Filtertools oder effizienten Such-UIs für große Datensätze.

💡 Begründung: Erfahrene Nutzer können über CLI-Flags und Skripting produktiv arbeiten, aber Keyboard-Shortcuts in einem grafischen Sinne oder interaktive Filterfunktionen für große Ergebnismengen fehlen weitgehend – entspricht Skala 2 (begrenzter Produktivitätssupport).

1 Customizable by end-user / user groups UX

ORT bietet praktisch keine endnutzerseitige Personalisierung von UI-Elementen; Anpassungen erfolgen ausschließlich über Konfigurationsdateien auf Systemebene, nicht durch individuelle Nutzerpräferenzen.

💡 Begründung: Da eine eigenständige grafische Benutzeroberfläche fehlt, gibt es keine persönlichen UX-Einstellungen wie Themes, Layouts oder Verhaltensanpassungen pro Nutzer oder Nutzergruppe – entspricht klar Skala 1 (nahezu keine Anpassung auf Nutzerebene).

1 Language Capabilities UX

ORT ist ein englischsprachiges Open-Source-Tool ohne dokumentierte Multi-Language-UI-Unterstützung oder Lokalisierungsoptionen für internationale Teams.

💡 Begründung: Als CLI-Tool der Linux Foundation Community ist die Oberfläche und Dokumentation ausschließlich auf Englisch; Locale- oder Zeitzoneneinstellungen für eine UI sind nicht relevant – entspricht Skala 1 (effektiv nur Englisch, minimale Lokalisierungsfähigkeit).

1 Design thinking approach UX

ORT als CLI-Tool bietet keine dokumentierte Accessibility-Unterstützung, Keyboard-First-Navigation oder inklusive Interaktionsmuster im Sinne von Enterprise-Accessibility-Standards.

💡 Begründung: Barrierefreiheit und inklusive Interaktionsunterstützung sind für ein primär CLI-basiertes Compliance-Tool kein dokumentierter Fokus; WCAG-Compliance oder ähnliche Standards werden nicht adressiert – entspricht Skala 1 (minimale dokumentierte Unterstützung).

3.3 IT Compliance

3 Single Source of Truth for each data object COMP

ORT speichert Analyse-, Scanner- und Evaluator-Ergebnisse in eigenen JSON/YAML-Dateien und unterstützt externe Curation-Datenbanken (z.B. ClearlyDefined) als führende Quellsysteme. Eine vollständige API-basierte Integration in zentrale Stammdatensysteme (z.B. REF-MDS) ist jedoch nicht nativ vorhanden und erfordert kundenspezifische Anpassungen.

💡 Begründung: ORT bietet versionierte Konfiguration als Code und externe Curation-Anbindung, was Datenredundanz reduziert. Eine standardisierte API-Integration in führende Quellsysteme fehlt jedoch, sodass die Anforderung nur teilweise erfüllt ist – Score 3 gemäß Skala ('Teilweise konform, Anpassungen nötig').

4 Where is the cloud server located? (country) COMP

ORT ist ein On-Premise-Deployment-Modell (Open Source, selbst gehostet), sodass der Kunde die Serverinfrastruktur vollständig selbst bestimmt und auf bevorzugten Hyperscalern (Azure, AWS) oder eigener EU-Infrastruktur betreiben kann. Es gibt keine herstellerseitige Cloud-Infrastruktur.

💡 Begründung: Da ORT rein On-Premise betrieben wird, liegt die vollständige Kontrolle über Region und Hyperscaler beim Kunden. Dies ermöglicht EU-Hosting und bevorzugte Hyperscaler-Nutzung, jedoch ohne herstellerseitige Garantien oder Zertifizierungen – Score 4 ('Good regional coverage with minor limitations').

3 Does the cloud service provide the encryption of data at rest and in transit? COMP

Da ORT On-Premise betrieben wird, hängt die Verschlüsselung vollständig von der Infrastruktur des Kunden ab. ORT selbst bringt keine eingebauten Verschlüsselungsmechanismen für Data-at-Rest oder Data-in-Transit mit, bietet aber als Open-Source-Tool die Möglichkeit, entsprechende Maßnahmen auf Infrastrukturebene zu implementieren.

💡 Begründung: ORT stellt kein eigenes Verschlüsselungskonzept bereit; die Verantwortung liegt vollständig beim Betreiber. Es ist technisch umsetzbar, aber nicht standardmäßig konfiguriert oder dokumentiert – Score 3 ('Encryption available but not consistently default or end-to-end').

3 GDPR and BDSG COMP

Als On-Premise Open-Source-Tool verarbeitet ORT keine personenbezogenen Daten durch einen Cloud-Anbieter, was das Risiko durch Drittauftragnehmer minimiert. Ein formelles DSGVO/BDSG-Konzept, Löschkonzepte oder Benutzerprofilmanagement sind jedoch im ORT-Projekt nicht explizit dokumentiert.

💡 Begründung: Das On-Premise-Modell vermeidet externe Datenverarbeitung, aber ORT als Community-Projekt liefert keine formellen DSGVO-Compliance-Nachweise, kein Löschkonzept und kein Nutzerprofil-Management. Der Kunde trägt die vollständige Verantwortung – Score 3 ('Basic compliance possible, but governance evidence is limited').

2 ISO certificates COMP

ORT ist ein Open-Source-Community-Projekt unter der Linux Foundation und hält als solches keine eigene ISO-27001-Zertifizierung. Da es On-Premise betrieben wird, kann der Kunde seine eigene Infrastruktur zertifizieren, jedoch trägt der Vendor keine Zertifizierung bei.

💡 Begründung: Weder die ORT Community noch die Linux Foundation weisen eine für dieses Produkt relevante ISO-27001-Zertifizierung als Datenverarbeiter aus. Es gibt keine indirekten Enterprise-Zertifizierungen des Vendors – Score 2 ('Limited certification evidence only').

5 Data export and import COMP

ORT unterstützt vollständigen Datenexport über SPDX, CycloneDX, JSON, YAML und weitere Formate sowie Import/Austausch über REST API (ORT Server). Ergänzend erlauben Curations und Resolutions als Datei-basierter Import manuelle Massenänderungen über Versionskontrolle.

💡 Begründung: Die Kombination aus nativen SBOM-Export-Formaten (SPDX, CycloneDX), REST API via ORT Server, dateibasierter Konfiguration und CI/CD-Integration bietet vollständige Export/Import-Funktionalität sowohl über APIs als auch operatives Tooling – Score 5 ('Full export/import via APIs and operational tooling').

2.9 Risks & Opportunities

5 Dependencies and Lock-In from Software Vendor RISK

ORT ist vollständig Open Source (Apache-2.0-Lizenz) und unter der Linux Foundation gehostet, alle Konfigurationen und Daten sind portabel und standardisiert (SPDX, CycloneDX). Eine De-Integration ist jederzeit möglich, da keine proprietären Datenformate oder Vendor-Abhängigkeiten bestehen.

💡 Begründung: Als Open-Source-Tool ohne proprietären Vendor, mit standardisierten Ausgabeformaten (SPDX, CycloneDX) und versionierter Konfiguration als Code ist der Lock-in extrem gering – entspricht Skala 5 (very low lock-in, high portability).

3 Project team setup and continuity RISK

ORT wird von einer aktiven Open-Source-Community unter der Linux Foundation entwickelt, jedoch ohne festes kommerzielles Entwicklungsteam mit garantierter Stabilität. Die Contributor-Basis ist verteilt, was Fluktuation und ungleichmäßige Kapazitäten möglich macht.

💡 Begründung: Die Community ist aktiv und das Projekt unter Linux Foundation etabliert, jedoch fehlt ein stabiles, dediziertes kommerzielles Team – moderate Kontinuitätsrisiken entsprechend Skala 3.

2 Time to Market RISK

ORT erfordert erheblichen initialen Konfigurationsaufwand (Policy-Regeln in Kotlin-DSL, Curations, CI/CD-Integration) und technisches Know-how, bevor es produktiv genutzt werden kann. Die Einrichtungszeit für große Unternehmen ist entsprechend lang.

💡 Begründung: Die Komplexität der mehrstufigen Pipeline, Kotlin-DSL-Konfiguration und notwendige Tool-Integrationen führen zu langer Onboarding-Zeit – entspricht Skala 2 (long setup or onboarding time).

2 Skill of supplier RISK

Da ORT ein Community-Open-Source-Projekt ist, gibt es keinen dedizierten kommerziellen Anbieter mit nachgewiesenem Large-Enterprise-Consulting-Portfolio. Einzelne Systemintegratoren bieten Unterstützung an, jedoch ohne breite, strukturierte Enterprise-Erfahrung.

💡 Begründung: Kein zentraler kommerzieller Anbieter mit Enterprise-Consulting-Kapazitäten; Supportressourcen sind fragmentiert – entspricht Skala 2 (limited large-enterprise skill depth).

2 Size of supplier (Skalierbarkeit für Großkunden), risk of insolvency RISK

ORT ist ein Community-Projekt unter der Linux Foundation ohne einen einzelnen kommerziellen Anbieter. Die Anzahl dedizierter, bezahlter Entwickler ist begrenzt, und die Abhängigkeit von freiwilligen Contributoren und wenigen Sponsoren ist ein sichtbares Risiko.

💡 Begründung: Kein großer kommerzieller Supplier im Hintergrund; Projektgröße und Finanzierungsbasis sind begrenzt – entspricht Skala 2 (smaller supplier/project with visible dependency risk).

2 World wide rollout RISK

Als Open-Source-Projekt verfügt ORT über keine regionalen Support-Teams oder organisierten weltweiten Rollout-Kapazitäten. Unternehmen müssen auf interne Ressourcen oder einzelne SI-Partner zurückgreifen, die ORT-Erfahrung besitzen.

💡 Begründung: Keine strukturierten regionalen Support-Teams oder nachgewiesene globale Rollout-Erfahrung vorhanden – entspricht Skala 2 (limited regional rollout capability).

3 Dependencies to other strategic projects RISK

ORT besitzt keine direkten negativen oder positiven Abhängigkeiten zu typischen strategischen Unternehmensprogrammen wie S/4HANA. Es kann unabhängig in bestehende CI/CD-Pipelines integriert werden und ist in dieser Hinsicht neutral positioniert.

💡 Begründung: Keine signifikanten strategischen Abhängigkeiten in beide Richtungen – neutrale Position entspricht Skala 3.

4 Development method (agile or waterfall) RISK

ORT wird aktiv nach modernen Open-Source-Entwicklungspraktiken mit kontinuierlichen Releases, GitHub-basiertem Workflow und agilen Iterations-Zyklen entwickelt. Die native CI/CD-Integration unterstützt agile Projektmethoden bei Kunden sehr gut.

💡 Begründung: Modernes, agiles Open-Source-Entwicklungsmodell mit kontinuierlicher Delivery und starker CI/CD-Ausrichtung – entspricht gut Skala 4 (good modern delivery fit).

2.8 Total Cost of Ownership

2 Setup/Project Costs TCO

ORT ist Open Source und kostenlos verfügbar, jedoch erfordert der initiale Setup erheblichen Aufwand: Infrastruktur-Bereitstellung (On-Premise), Konfiguration der mehrstufigen Pipeline, Integration der Scanner-Backends und Einarbeitung in die Kotlin-DSL. Der Konzeptionsaufwand ist hoch.

💡 Begründung: Die Software selbst kostet nichts, aber On-Premise-Deployment, die komplexe Toolchain-Architektur (Analyzer, Scanner, Evaluator, Advisor, Reporter) und die notwendige Infrastrukturplanung verursachen hohen initialen Aufwand. Gemäß Skala entspricht das 'High setup cost' = Score 2.

2 Implementation Costs TCO

Die Implementierung erfordert tiefes technisches Know-how: Kotlin-DSL für Policy-Regeln, Integration mehrerer Scanner-Backends, CI/CD-Pipeline-Anbindung, Curations-Konfiguration und ggf. ORT-Server-Aufbau. Der Customizing-Aufwand ist substanziell.

💡 Begründung: ORT bietet viele Integrationspunkte und Flexibilität, aber genau diese Flexibilität bedingt hohen Implementierungsaufwand. Die Kotlin-DSL-Regelentwicklung, individuelle Curations und die Multi-Ecosystem-Konfiguration erfordern spezialisierte Entwicklerkapazitäten. Dies entspricht 'High implementation effort' = Score 2.

2 Maintenance / Operation Costs TCO

Der laufende Betrieb erfordert kontinuierliche Pflege: Updates der Tool-Komponenten, Wartung der Policy-Regeln, Pflege der Curations-Datenbank, Administration des ORT-Servers sowie Monitoring der CI/CD-Integrationen. Ohne dediziertes Team ist der Betrieb anspruchsvoll.

💡 Begründung: Als selbst gehostete, modulare Open-Source-Toolchain ohne kommerziellen Support entsteht erheblicher Betriebsaufwand für Updates, Fehlerbehebung, Skalierung und Regelwartung. Dies entspricht 'High operating effort' = Score 2.

5 License Costs TCO

ORT ist vollständig Open Source unter der Apache-2.0-Lizenz und kostenlos nutzbar – es gibt keine Lizenzkosten, keine nutzerbasierten Gebühren, keine versteckten Kosten oder Add-on-Gebühren.

💡 Begründung: Als Linux-Foundation-Projekt mit Apache-2.0-Lizenz entstehen keinerlei Lizenzkosten. Das Modell ist vollständig transparent und kostenlos. Dies entspricht dem Bestwert 'Transparentes, günstiges Modell ohne versteckte Kosten' = Score 5.

3 expected benefit/efficiency TCO

Nach erfolgreicher Implementierung ermöglicht ORT durch automatisierte Compliance-Checks in der CI/CD-Pipeline und wiederverwendbare Policy-Regeln spürbare Effizienzgewinne, jedoch sind diese stark von der initialen Investition und laufenden Pflegekosten abhängig.

💡 Begründung: ORT bietet durch Automatisierung der Lizenz-Compliance und SBOM-Generierung echte Effizienzgewinne, aber der hohe initiale und laufende Aufwand reduziert den Netto-Nutzen im Vergleich zu kommerziellen SaaS-Lösungen. Der Benefit ist vorhanden, aber nicht herausragend – entspricht 'Moderate benefit' = Score 3.

1.3 Support & Operations

1 1st level SUP

ORT ist ein Open-Source-Projekt der Linux Foundation Community; ein formeller 1st-Level-Support über Hotlines oder dedizierte Support-Teams existiert nicht. Nutzer sind auf GitHub Issues, Discussions und Community-Channels (z.B. Slack) angewiesen.

💡 Begründung: Als Community-OSS-Projekt ohne kommerzielles Support-Angebot des Vendors gibt es keinen organisierten 1st-Level-Support. Dies entspricht laut Skala Score 1 (Mostly self-support).

1 2nd level SUP

Ein strukturierter 2nd-Level-Support durch den Vendor existiert nicht. Technische Eskalationen erfolgen ausschließlich über GitHub Issues oder Community-Diskussionen, ohne garantierte Reaktionszeiten oder dedizierte Experten-Teams.

💡 Begründung: Ohne kommerziellen Vendor-Support gibt es kein zuverlässiges 2nd-Level-Modell. Score 1 (No reliable second-level model) trifft zu, da nur Community-Unterstützung verfügbar ist.

2 3rd level SUP

Bugfixes werden über den öffentlichen GitHub-Repository-Prozess (Issues, Pull Requests) abgewickelt. Da ORT unter der Linux Foundation aktiv entwickelt wird, gibt es einen strukturierten Open-Source-Entwicklungsprozess, jedoch ohne garantierte SLAs oder formale Eskalationspfade.

💡 Begründung: Der GitHub-basierte Issue-/PR-Prozess bietet eine rudimentäre Engineering-Eskalation, ist aber nicht enterprise-tauglich. Score 2 (Limited engineering escalation) ist angemessen, da kein formaler Vendor-Prozess existiert, aber ein aktives Entwickler-Team vorhanden ist.

1 General support concept/approach SUP

ORT bietet kein kommerzielles Support-Konzept; der Vendor (Linux Foundation Community) stellt ausschließlich Community-Support via GitHub, Slack und öffentliche Dokumentation bereit. Weltweiter Support, Ticket-Bridge-Integration oder mehrsprachiger Support sind nicht vorgesehen.

💡 Begründung: Als reines Community-Projekt ohne kommerzielles Angebot fehlen alle Enterprise-Support-Merkmale wie Ticket-System-Integration, SLAs oder Mehrsprachigkeit. Score 1 (Very weak or community-only support concept) ist zutreffend.

1 SLA for tickets SUP

Es existieren keine definierten SLAs für Tickets. Bug-Reports und Feature-Requests werden im öffentlichen GitHub-Tracker verwaltet, ohne garantierte Bearbeitungszeiten für kritische, mittlere oder niedrig priorisierte Anfragen.

💡 Begründung: Keinerlei formale SLA-Dokumentation oder Response-Time-Garantien vorhanden. Dies entspricht eindeutig Score 1 (No real SLA).

1 Support coverage SUP

Eine 24/7-Support-Abdeckung existiert nicht; ORT-Community-Unterstützung ist ausschließlich auf freiwilliger Basis über GitHub und Slack verfügbar, ohne regionale Differenzierung oder garantierte Verfügbarkeitszeiten.

💡 Begründung: Keine 24/7-Abdeckung, keine regionalen Support-Teams, reine Community-Erreichbarkeit. Score 1 (Community or business-hours only) ist korrekt.

2 Training, tool documentation SUP

ORT verfügt über eine öffentliche Dokumentationswebsite (oss-review-toolkit.org) sowie GitHub-basierte Dokumentation und Beispiel-Konfigurationen. Formale Trainingsangebote (Videos, Webinare, F2F-Trainings) durch den Vendor existieren jedoch nicht.

💡 Begründung: Es gibt grundlegende Dokumentation und Community-Ressourcen, aber keine strukturierten Trainingsformate für verschiedene Nutzerrollen. Score 2 (Basic documentation only) trifft zu, da zwar Dokumentation vorhanden ist, aber formales Training fehlt.

2.7 Projektspezifische Anforderungen

2 Hierarchische Mandantentrennung mit vererbten Policies CTX

ORT kennt kein natives mehrstufiges Mandantenmodell. Über den ORT Server und Git-basierte Konfigurationen lassen sich zwar Projekte und Regeln organisieren, aber eine echte Hierarchie (Org > Sub-Org > Projekt > Team > Individuum) mit Datenisolation und automatischer Policy-Vererbung ist nicht vorhanden.

💡 Begründung: ORT ist primär ein CLI-/Pipeline-Tool ohne eingebautes Mandantenkonzept. Selbst der ORT Server bietet keine dokumentierte mehrstufige Mandantenhierarchie mit Überschreibungsschutz. Am ehesten entspricht das flacher Rollentrennung ohne echte Datenisolation, was Skala-Stufe 2 entspricht.

1 Mandanten-scoped API-Tokens und Service-Accounts CTX

ORT verfügt über kein natives Konzept für mandantenspezifische API-Tokens oder Service-Accounts. Der ORT Server bietet grundlegende Authentifizierung, aber keine mandantenspezifisch isolierten Tokens mit Rotation und Audit-Log.

💡 Begründung: ORT ist als CLI-Tool konzipiert; der ORT Server ist noch nicht production-reif genug für granulares Token-Management. Es gibt keine dokumentierte mandantenspezifische Token-Isolation, Rotation oder ein dediziertes Audit-Log pro Mandant. Dies entspricht Stufe 1 der Skala.

2 Proxy-/Pull-Policy-Gate für JFrog Artifactory ohne XRay-Lizenz CTX

ORT bietet keine native Artifactory-Policy-Gate-Funktion, die Artefakte vor dem Download blockieren kann. ORT läuft nachgelagert in der CI/CD-Pipeline und analysiert bereits vorhandene Abhängigkeiten, ohne aktiv als Pull-Gate zu fungieren.

💡 Begründung: ORT hat keine Artifactory-User-Plugin- oder Webhook-Integration, die einen Pre-Download-Block ermöglicht. Die Analyse erfolgt post-facto. Damit entspricht ORT bestenfalls Stufe 2: nachgelagerte Analyse ohne technisches Blocking vor dem Pull.

3 Bidirektionale Integration mit bestehendem Dependency-Track ohne Datenduplizierung CTX

ORT kann SBOMs im CycloneDX-Format exportieren, die dann in Dependency-Track importiert werden können. Eine explizite, dokumentierte bidirektionale REST-API-Integration mit Dependency-Track als autoritativem Store ist jedoch nicht nativ vorhanden.

💡 Begründung: ORT unterstützt CycloneDX-Export und kann so unidirektional mit Dependency-Track zusammenarbeiten. Eine native bidirektionale Integration oder ein dokumentierter Finding-Sync über die Dependency-Track REST API existiert nicht. Das entspricht Stufe 3: manuelle Import-Pipelines möglich, keine native Konnektivität.

2 SBOM-Generierung für Binary-Artefakte in Artifactory (ohne Quellcode-Zugriff) CTX

ORT ist primär auf Quellcode- und Manifest-basiertes Scanning ausgelegt. Über die Scanner-Backends (ScanCode, SCANOSS) können zwar Binaries gescannt werden, aber eine native Binary-SBOM-Generierung direkt aus Artifactory für Artefakttypen ohne Quellcode ist nicht dokumentiert.

💡 Begründung: ORT analysiert Paketmanifeste (pom.xml, package.json) und kann über integrierte Scanner Lizenzen in Binaries erkennen, jedoch fehlt eine native Artifactory-Anbindung für Binary-SBOM-Generierung ohne Quellcode-Zugriff. Das nähert sich Stufe 2: manifest-basiertes Scanning überwiegt, echte Binary-Analyse für isolierte Binaries aus Artifactory ist nicht dokumentiert.

2 SBOM-Versionierung und Differenz-Tracking über Artefakt-Versionen CTX

ORT speichert die Ergebnisse jedes Pipeline-Laufs als JSON/YAML-Dateien, die in einem Git-Repository versioniert werden können. Ein natives SBOM-Versioning mit Diff-View auf Komponenten-Ebene ist jedoch nicht vorhanden.

💡 Begründung: Die Versionierung erfolgt rein über externe Git-Workflows; ORT selbst bietet keinen eingebauten Diff-View zwischen SBOM-Versionen und keine API für historische SBOM-Vergleiche. Da nur die aktuelle Ausgabe pro Lauf gespeichert wird und Historisierung extern erfolgen muss, entspricht dies Stufe 2.

2 VEX/OpenVEX-Erstellung und -Verwaltung als First-Class-Feature CTX

ORT unterstützt die Ausgabe von CycloneDX-SBOMs und kann Vulnerabilities über den Advisor-Schritt aggregieren, bietet jedoch kein natives VEX-Management-Feature mit Erstellung, Versionierung und Audit-Trail für VEX-Statements.

💡 Begründung: VEX als First-Class-Feature (Erstellung, Verwaltung, Versionierung, Export beider Standards) ist in ORT nicht dokumentiert. Über Curations/Resolutions können Findings manuell bewertet werden, aber ein strukturiertes VEX-System fehlt. Das entspricht Stufe 2: proprietäres Triage-System (Resolutions) ohne nativen VEX-Standard-Export.

3 Organisationsweite Suppression und Wiederverwendung von Triage-Entscheidungen CTX

ORT bietet über das Resolutions-System die Möglichkeit, Triage-Entscheidungen (z.B. 'not applicable') als Code-Dateien zu definieren, die über das gesamte Repository oder organisationsweit in einer zentralen Konfiguration geteilt werden können.

💡 Begründung: ORT's Resolutions können in einer zentralen Konfigurationsdatei (Git-Repository) definiert und auf alle Projekte angewendet werden, die diese Konfiguration referenzieren. Eine automatische Propagation ohne manuelle Pipeline-Konfiguration ist jedoch nicht gegeben. Das entspricht Stufe 3: Templates können manuell auf mehrere Projekte angewendet werden, aber keine vollautomatische Propagation.

4 Aggregierte Vulnerability-Feeds aus mehreren Quellen mit Konfliktauflösung CTX

ORT's Advisor-Schritt unterstützt mehrere Vulnerability-Quellen nativ: OSV, VulnerableCode, OSS Index, GitHub Security Advisories und FossID. Mehrere Quellen können parallel konfiguriert werden, wobei Befunde aggregiert werden.

💡 Begründung: ORT unterstützt nativ mindestens 4-5 konfigurierbare Vulnerability-Feeds (OSV, OSS Index, GitHub Advisory, VulnerableCode, optional weitere). Eine explizit dokumentierte automatische Konfliktauflösung bei widersprüchlichen CVSS-Scores fehlt jedoch. Das entspricht Stufe 4: mind. 3-4 Feeds nativ, Priorisierung konfigurierbar, Konfliktauflösung nicht vollständig dokumentiert.

4 License-Policy-Enforcement mit Copyleft-Risikostufen und Ausnahme-Workflow CTX

ORT's Evaluator bietet eine mächtige Kotlin-DSL zur Definition granularer License-Policies mit Risikostufen (Copyleft, Weak Copyleft, Permissiv, Commercial). ORT ermöglicht Lizenzkategorisierung und Policy-Enforcement. Ein strukturierter Ausnahme-Workflow mit Review-Prozess ist jedoch nur über externe Prozesse (Git-PR für Curations) abbildbar.

💡 Begründung: Die License-Policy-Funktionalität mit SPDX-basierter Klassifikation und mehreren Risikostufen ist stark und in der OSS-Edition enthalten. Ein natives, integriertes Ausnahme-Workflow-System mit GUI-gestütztem Genehmigungsprozess fehlt jedoch. Das entspricht Stufe 4: Policies mit Risikostufen vorhanden, Ausnahme-Workflow rudimentär über Git-Prozesse.

5 SPDX-konforme Lizenzauflösung inkl. komplexer Lizenz-Expressions CTX

ORT implementiert vollständiges SPDX-2.x License Expression Parsing inklusive AND/OR/WITH-Operatoren und LicenseRef-Support. Der Evaluator berücksichtigt diese Expressions korrekt bei der Policy-Bewertung, und der SPDX-Reporter gibt valide SPDX-Dokumente aus.

💡 Begründung: SPDX-Compliance ist ein zentrales Designziel von ORT. Die Kotlin-DSL des Evaluators erlaubt die Policy-Behandlung komplexer License Expressions. LicenseRef-Unterstützung und AND/OR/WITH-Parsing sind dokumentiert und produktiv einsetzbar in der OSS-Edition. Das entspricht klar Stufe 5.

5 Deklarative Policy-as-Code-Definition mit Versionierung (OPA/Rego oder äquivalent) CTX

ORT setzt konsequent auf Policy-as-Code: Alle Regeln werden in einer typsicheren Kotlin-DSL definiert, in Git-Repositories versioniert und via CI/CD (GitHub Actions, GitLab CI, Jenkins) deployed. Ein vollständiger GitOps-Workflow ohne GUI-Abhängigkeit ist nativ unterstützt.

💡 Begründung: ORT's gesamte Konfiguration (Regeln, Curations, Resolutions) ist als Code-Dateien in Git versionierbar. Die Kotlin-DSL ist ein offenes, dokumentiertes Format. CLI-basiertes Deployment ohne GUI ist der primäre Workflow. Dies erfüllt alle Kriterien von Stufe 5 vollständig in der OSS-Edition.

3 Granulare Policy-Gate-Aktionen: Blockieren, Warnen, Quarantäne, Notifizieren CTX

ORT's Evaluator kann über die Kotlin-DSL Regeln mit unterschiedlichen Severity-Levels (ERROR, WARNING, HINT) definieren, was Block- und Warn-Aktionen abbildet. Quarantäne-Workflows und automatische Notifikationen sind nicht nativ integriert, können aber über externe Webhooks und CI/CD-Exit-Codes partiell nachgebildet werden.

💡 Begründung: ORT unterstützt differenzierte Policy-Ergebnisse (ERROR=Block, WARNING=Warn) über die DSL, aber keine native Quarantäne-Funktion mit Review-Workflow oder integriertes Notification-System. Dies entspricht Skala 3: Block und Warn konfigurierbar, Quarantäne und differenzierte Notifikation nicht nativ.

3 Air-Gap / Offline-Betrieb für Vulnerability-Datenfeeds CTX

ORT ist ein On-Premise-Tool mit konfigurierbaren Feed-URLs, sodass NVD-, OSV- und andere Quellen prinzipiell auf interne Mirror umgeleitet werden können. Ein offiziell dokumentierter und getesteter Air-Gap-Betriebsmodus existiert jedoch nicht, die Einrichtung interner Mirror liegt in der Eigenverantwortung des Betreibers.

💡 Begründung: Feed-URLs sind konfigurierbar und können auf interne Mirror zeigen, aber es gibt keinen offiziellen Air-Gap-Support oder dokumentierten Mirror-Prozess mit Signaturprüfung. Das entspricht Skala 3: Feed-URL konfigurierbar, aber kein offizieller Air-Gap-Support.

3 Manipulationssicheres Audit-Log mit SIEM-Export (CEF/JSON/Syslog) CTX

ORT protokolliert alle Schritte (Analyzer, Scanner, Evaluator, Advisor) in strukturierten JSON-Ausgabedateien, die als Audit-Trail dienen. Ein dedizierter, manipulationssicherer Audit-Log-Mechanismus mit Echtzeit-SIEM-Export (CEF/Syslog/Kafka) ist nicht nativ vorhanden; der Export muss manuell oder über externe Tooling erfolgen.

💡 Begründung: ORT erzeugt vollständige, strukturierte JSON-Ergebnisdateien die als Audit-Basis dienen, aber kein dediziertes append-only/signiertes Audit-Log, kein nativer Echtzeit-SIEM-Stream. Dies entspricht Skala 3: Audit-Log vorhanden, JSON-Export manuell, kein Echtzeit-SIEM-Stream, Manipulationsschutz nicht dokumentiert.

3 Horizontale Skalierung des Scanning-Backends für Enterprise-Artefaktvolumen CTX

ORT Server bietet eine Queue-basierte Architektur und kann als mehrere Instanzen betrieben werden; Kubernetes-Deployment ist möglich und Helm-Charts existieren (teils community-getrieben). Offizielle Performance-Benchmarks für Enterprise-Volumen (>10.000 Artefakte/Tag) und ein vollständiger Kubernetes-Operator fehlen jedoch.

💡 Begründung: Horizontale Skalierung ist prinzipiell möglich (ORT Server mit Worker-Konzept, Kubernetes-Deployment), aber keine offiziellen Enterprise-Benchmarks und keine out-of-the-box skalierende Lösung mit dokumentierten SLAs. Entspricht Skala 3: Skalierung durch mehrere Instanzen möglich, manuelle Konfiguration erforderlich, keine offiziellen Enterprise-Benchmarks.

5 OWASP-Ökosystem-Alignment und aktive OWASP-Projektmitgliedschaft CTX

ORT ist ein aktives Linux-Foundation-Projekt mit dokumentierter Vendor-Neutralität, diversem Contributor-Base aus mehreren Organisationen und regelmäßigen Releases. Dies entspricht der Anforderung nach vergleichbarer Community-Governance zu OWASP-Projekten.

💡 Begründung: Linux Foundation-Mitgliedschaft mit aktiver, multi-organisationaler Community erfüllt explizit die Skalenbedingung 5: 'CNCF/Linux Foundation mit dokumentierter Vendor-Neutralität; regelmäßige Releases durch diverse Contributors'.

3 Native CI/CD-Integration mit Policy-Gate-Rückgabecodes für gängige Pipelines CTX

ORT bietet offizielle GitHub Actions und GitLab CI-Templates sowie einen CLI mit definierten Exit-Codes, der in beliebige Pipelines integriert werden kann. Die Policy-Konfiguration muss jedoch lokal in den Repositories oder Pipeline-Definitionen gepflegt werden; ein zentrales Policy-Referenz-Modell über Policy-IDs fehlt nativ.

💡 Begründung: GitHub Actions und GitLab CI-Templates sind vorhanden (mind. 2 CI/CD-Systeme), aber das zentrale Policy-Konfigurationsmodell fehlt – Teams müssen Policy-Parameter selbst in der Pipeline oder im Repo konfigurieren. Dies entspricht eher Skala 3: CLI-Tool in jede Pipeline integrierbar, Policy-Parameter müssen in der Pipeline/Repo definiert werden, kein zentrales Policy-Referenz-Modell.

3 Kubernetes-natives Deployment mit Helm-Chart und Operator-Support für HA CTX

Für ORT Server existieren Docker-basierte Deployments und community-gepflegte Kubernetes-Konfigurationen, jedoch kein offizielles, gepflegtes Helm-Chart mit HA-Konfiguration und externem PostgreSQL-Support out-of-the-box. Ein Kubernetes-Operator ist nicht vorhanden.

💡 Begründung: Community-Helm-Chart und Kubernetes-Deployment sind möglich, aber kein offizielles, gepflegtes Helm-Chart mit HA out-of-the-box und kein Operator. Entspricht Skala 3: Helm-Chart vorhanden (community oder inoffiziell), HA-Konfiguration beschrieben aber nicht out-of-the-box.

3 Compliance-Dashboard und automatisierter Report-Export für NIS2/BSI-Grundschutz CTX

ORT's Reporter-Modul erzeugt Compliance-Berichte in verschiedenen Formaten (SPDX, CycloneDX, HTML, JSON), jedoch fehlen vorkonfigurierte Compliance-Dashboards mit NIS2/BSI-spezifischen Metriken, mandantenspezifische Filterung und automatisiertes Report-Scheduling nativ.

💡 Begründung: Generische Report-Formate und manueller Export sind vorhanden, aber keine vorkonfigurierten NIS2/BSI-Dashboards, keine Scheduling-Funktion und keine mandantenspezifische Filterung im Export. Entspricht Skala 3: Generische Berichte und manueller Export, keine mandantenspezifische Filterung, keine Scheduling-Funktion.

3 SBOM-Enrichment aus Container-Image-Layern CTX

ORT unterstützt die Analyse von Container-Images über integrierte Scanner-Backends (z.B. ScanCode, SCANOSS) und kann SBOMs im CycloneDX/SPDX-Format ausgeben, jedoch erfolgt die Analyse primär auf Image-Ebene ohne native Layer-by-Layer-Differenzierung.

💡 Begründung: Container-Image-Analyse ist vorhanden und CycloneDX/SPDX-Ausgabe wird unterstützt, aber keine dokumentierte Layer-by-Layer-Analyse mit Layer-Zuordnung pro Komponente. Entspricht Skala 3: Container-Image-Analyse auf Image-Ebene, keine Layer-Differenzierung, aber CycloneDX/SPDX-Ausgabe vorhanden.

2 EPSS-Score-Integration und priorisierungsbasiertes Triage-Routing CTX

ORT aggregiert Vulnerability-Informationen aus verschiedenen Quellen (OSV, NVD, VulnerableCode etc.) über den Advisor-Schritt, jedoch ist EPSS-Score nicht nativ als Feed integriert und kann nicht direkt in Policy-Regeln als Schwellenwert verwendet werden. Priorisierung basiert primär auf CVSS.

💡 Begründung: EPSS ist nicht nativ integriert; der Advisor liefert CVSS-basierte Vulnerability-Daten, EPSS-Daten müssten extern ergänzt werden. Automatisches Triage-Routing auf EPSS-Basis ist nicht vorhanden. Entspricht Skala 2: Keine direkte EPSS-Integration, nur CVSS-basierte Priorisierung.

2 CISA KEV (Known Exploited Vulnerabilities) Catalogue-Integration CTX

ORT's Advisor-Schritt kann CISA KEV-Daten nicht als dedizierten, automatisch synchronisierten Feed einbinden; KEV-Informationen können allenfalls indirekt über OSV oder NVD-Feeds enthalten sein. Eine gesonderte Behandlung von KEV-gelisteten Vulnerabilities in Policy-Regeln ist nicht nativ unterstützt.

💡 Begründung: Kein dedizierter KEV-Feed oder KEV-Filter in ORT vorhanden; KEV-Status könnte theoretisch via OSV/NVD indirekt auftauchen, aber keine native Integration oder Policy-Unterstützung. Entspricht Skala 2: Kein nativer KEV-Feed, KEV-Status muss manuell gepflegt oder über externe Skripte importiert werden.

2 Mandantenspezifische Vulnerability-Feed-Konfiguration und -Isolation CTX

ORT ist primär als Build-Pipeline-Tool konzipiert und bietet über den ORT Server eine Mehrprojekt-Verwaltung, jedoch keine vollständige mandantenspezifische Isolation der Vulnerability-Feed-Konfiguration. Feed-Konfigurationen sind global und gelten für alle Projekte gleichermaßen.

💡 Begründung: ORT Server unterstützt Mehrprojekt-Szenarien, aber mandantenspezifische Feed-Konfiguration (unterschiedliche Quellen, Intervalle, Vertrauensstufen pro Mandant isoliert) ist nicht vorhanden. Entspricht Skala 2: Keine mandantenspezifische Feed-Trennung, globale Konfiguration gilt für alle, nur manuelle Workarounds möglich.

2 Rückmeldung von Scan-Ergebnissen in Artifactory-Properties/Metadata CTX

ORT bietet keine native oder out-of-the-box Artifactory-Property-Schreibfunktion. Eine Integration wäre nur über externe Skripte realisierbar, die ORT-Ergebnisse auslesen und separat die Artifactory REST-API aufrufen.

💡 Begründung: ORT ist eine SCA/Compliance-Toolchain ohne spezifische Artifactory-Integrationsfunktion. Es gibt keine dokumentierte Funktion zum Zurückschreiben von Scan-Ergebnissen als Artifactory-Properties. Externe Skripte wären notwendig, aber auch das ist kein explizit dokumentierter oder unterstützter Workflow – daher Score 2.

5 Automatisierte OSS-Komponenten-Attributionslisten-Generierung (NOTICE-Dateien) CTX

ORT generiert über seinen Reporter-Schritt vollständige Attributionslisten (NOTICE-Dateien) inklusive Lizenztexten und Copyright-Notices in verschiedenen Formaten wie HTML, PDF, TXT und SPDX. Der Reporter ist hochgradig konfigurierbar und unterstützt projektspezifische Anpassungen.

💡 Begründung: Die NOTICE-File-Generierung ist eine der Kernfunktionen von ORT. Der Reporter unterstützt multiple Ausgabeformate, integriert vollständige Lizenztexte und Copyright-Notices, ist Open Source und mandanten-/projektspezifisch konfigurierbar. Dies entspricht dem Score 5 der Bewertungsskala.

3 Trusted-Component-Registry und positives Whitelisting für Organisationen CTX

ORT bietet über seine Curations- und Resolutions-Mechanismen die Möglichkeit, Komponenten explizit freizugeben oder zu überschreiben. Dies ist jedoch kein vollständiges Whitelist-System mit Ablaufdaten, Freigabe-Workflow oder mandantenübergreifender Governance.

💡 Begründung: ORT's Package Curations ermöglichen versionsgranulare Korrekturen und Overrides, die als Code versioniert werden. Es fehlen jedoch dedizierte Whitelist-Konzepte mit Ablaufdatum, formalem Freigabe-Workflow (Approver), und automatischer Invalidierung bei neuen Versionen. Daher Score 3 – einfaches Whitelisting ohne vollständige Governance.

4 Transitive Dependency-Auflösung und Tiefenanalyse für SBOM-Vollständigkeit CTX

ORT's Analyzer löst transitive Abhängigkeiten für die meisten unterstützten Ökosysteme vollständig rekursiv auf und dokumentiert diese im SBOM. Für Binary-Artefakte ohne Quellcode bestehen dokumentierte Einschränkungen, und ein expliziter Vollständigkeits-Score wird nicht berechnet.

💡 Begründung: ORT ist für seine tiefe transitive Dependency-Auflösung bekannt und unterstützt CycloneDX-Output. Lücken bei reinen Binaries ohne Quellcode-Zugriff sind ein bekanntes Limitierung. Ein expliziter Vollständigkeits-Score im Sinne von CycloneDX Metadata Level 3 ist nicht dokumentiert, daher Score 4 statt 5.

2 Datenbankpartitionierung und Archivierungsstrategie für Langzeit-SBOM-Daten CTX

ORT als CLI-Tool und optionaler ORT-Server bietet keine dokumentierte Datenbankpartitionierungsstrategie oder automatisierte Archivierung. Langzeit-Datenhaltung und Retention-Policies müssen extern über Datenbankadministration verwaltet werden.

💡 Begründung: ORT ist primär als Pipeline-Tool konzipiert, nicht als Langzeit-Datenhaltungsplattform. Der ORT-Server ist relativ jung und bietet keine dokumentierten Retention-Policies oder automatisierten Archivierungsworkflows. Dies entspricht Score 2 – keine dokumentierte Archivierungsstrategie, externes Datenmanagement erforderlich.

2 Webhook- und Event-Bus-Integration für asynchrone Event-Driven-Architektur CTX

ORT bietet keine native Webhook- oder Message-Bus-Integration für asynchrone Event-Benachrichtigungen. Ergebnisse werden als Dateien ausgegeben und müssen durch externe Integrations-Layer weiterverarbeitet werden.

💡 Begründung: ORT ist eine Toolchain ohne eingebaute Event-Notification-Infrastruktur. Es gibt keinen dokumentierten Webhook-Support, keine Retry-Logik, keine Kafka/AMQP-Integration. CI/CD-Pipelines können Ergebnisse weiterleiten, aber das liegt außerhalb von ORT. Score 2 – nur rudimentäre externe Lösungen ohne Tool-Support.

1 Malware- und Typosquatting-Erkennung für Registry-Proxies CTX

ORT bietet keine native Malware-Erkennung oder Typosquatting-Heuristiken. Der Advisor-Schritt aggregiert Vulnerability-Informationen, deckt jedoch keine Malware-Datenbanken der OSSF oder Typosquatting-Erkennung ab.

💡 Begründung: ORT's Advisor-Komponente konzentriert sich auf CVE-basierte Schwachstelleninformationen aus Quellen wie OSV, GitHub Advisory, VulnerableCode etc. Es gibt keine Integration der OSSF Malicious Packages Database und keine Typosquatting-Heuristiken. Dies entspricht vollständig Score 1 der Skala.

1 Softwareintegrität und Artefakt-Signatur-Verifikation (Sigstore/Cosign) CTX

ORT bietet keine native Sigstore/Cosign-Signatur-Verifikation und keine Rekor-Integration. Artefakt-Integrität wird über Checksums/Hashes im SBOM dokumentiert, aber keine kryptografische Signaturprüfung durchgeführt.

💡 Begründung: Sigstore/Cosign-Verifikation ist kein dokumentiertes Feature von ORT. ORT fokussiert auf License-Compliance und Vulnerability-Scanning, nicht auf Artefakt-Signaturverifikation. Externe Sigstore-Verifikation als Pre-Step ist möglich, aber nicht von ORT unterstützt. Score 1 gemäß Skala.

1 Ressourcen-Quotierung und Rate-Limiting pro Mandant (Fair-Use-Enforcement) CTX

ORT – auch in seiner Server-Variante – bietet keine mandantenspezifischen Ressourcen-Quotas, API-Rate-Limits oder Speicherkontingente. Fair-Use-Enforcement muss vollständig auf Infrastrukturebene (Kubernetes, API-Gateway) realisiert werden.

💡 Begründung: ORT ist nicht als mandantenfähiger Enterprise-Service mit Quota-Management konzipiert. Der ORT-Server bietet grundlegende Multi-User-Funktionalität, aber keine dokumentierten mandantenspezifischen Rate-Limits oder Quota-Systeme. Dies entspricht Score 1 der Bewertungsskala.

3 SBOM-as-a-Service API für externe Tool-Integration (SBOM-Upload und -Abfrage) CTX

Der ORT-Server bietet eine REST-API für den Betrieb als zentrales Backend, über die ORT-Läufe getriggert und Ergebnisse abgefragt werden können. Eine vollständige OpenAPI-Spezifikation mit expliziter Versionierungsstrategie und Rückwärtskompatibilitätsgarantie ist jedoch nicht dokumentiert.

💡 Begründung: ORT-Server stellt REST-API-Endpunkte bereit, die für externe Integration nutzbar sind, und unterstützt CycloneDX/SPDX-Output. Die Dokumentation ist jedoch unvollständig bezüglich API-Versionierung und formaler OpenAPI-Spec-Vollständigkeit. Score 3 – Basisfunktionen vorhanden, aber nicht für stabile Enterprise-Integration spezifiziert.

3 Regulatorische Berichtspflichten: CRA (Cyber Resilience Act) SBOM-Anforderungen CTX

ORT implementiert CycloneDX 1.x und SPDX 2.3+ vollständig und kann damit die technischen SBOM-Anforderungen des CRA weitgehend erfüllen. Explizite CRA-Compliance-Workflows oder dedizierte Validierungstools gegen CRA-Anforderungen sind jedoch nicht dokumentiert.

💡 Begründung: CRA-Unterstützung ist kein explizit dokumentiertes Feature von ORT. Die vollständige Implementierung aktueller SBOM-Standards (CycloneDX, SPDX) macht CRA-Konformität über externe Validierung erreichbar. Es gibt keinen bekannten CRA-spezifischen Roadmap-Eintrag. Score 3 gemäß Skala – SBOM-Standards vollständig implementiert, CRA über externe Validierung erreichbar.

3 Dependency-Track-Migrationsbrücke: Erhalt historischer Triage-Daten CTX

ORT kann CycloneDX-SBOMs importieren und verarbeiten, was einen partiellen Datentransfer aus Dependency-Track ermöglicht. Ein dediziertes Migrationswerkzeug für Dependency-Track-Triage-Daten, Suppressions und VEX-Dokumente existiert nicht, sodass erhebliche manuelle Nacharbeit anfällt.

💡 Begründung: ORT und Dependency-Track sind unterschiedliche Tooling-Paradigmen. ORT kann CycloneDX-BOM-Inputs verarbeiten, aber Triage-Metadaten, Suppressions-Status und Finding-Historien aus Dependency-Track müssen manuell in ORT's Resolutions-/Curations-Format überführt werden. Kein dediziertes Migrationswerkzeug bekannt. Score 3 – SBOM-Import möglich, Triage-Daten manuell neu zu erfassen.

2 Zentraler Service-Delivery-Modus: Self-Service-Onboarding für Sub-Organisationen ohne Admin-Eskalation CTX

ORT bietet grundlegende Rollenkonzepte über den ORT Server, jedoch ist kein vollständiges Self-Service-Tenant-Admin-Modell dokumentiert oder implementiert. Die Verwaltung von Projekten, Teams und Berechtigungen erfordert in der Regel globale Admin-Eingriffe.

💡 Begründung: ORT ist primär als CLI-Toolchain konzipiert; der ORT Server befindet sich noch in früher Entwicklung und bietet kein dokumentiertes delegiertes Tenant-Admin-Modell. Es gibt keine strukturierte Rollentrennung mit Self-Service-Onboarding für Sub-Organisationen. Dies entspricht Skala 2: grobe Rollentrennung ohne Self-Service, zentrale IT muss Mandanten-Änderungen durchführen.

1 Reachability-Analyse: Exploitierbarkeits-Kontextbewertung auf Basis tatsächlicher Code-Nutzung CTX

ORT bietet keine Reachability-Analyse oder Call-Graph-basierte Kontextbewertung. Der Advisor-Schritt aggregiert lediglich CVE-Informationen aus Quellen wie OSV oder VulnerableCode, ohne tatsächliche Code-Erreichbarkeit zu analysieren.

💡 Begründung: ORT führt keine statische oder dynamische Reachability-Analyse durch. Es gibt keine Call-Graph-Integration, keine Semgrep-basierte Kontextbewertung und keinen Mechanismus zur Reduktion von False-Positives auf Basis tatsächlicher Code-Nutzung. Dies entspricht klar Skala 1: alle CVEs ohne Nutzungskontext, kein Mechanismus zur Erreichbarkeitsreduktion.

2 Operative Observability des Security-Services: Interne Metriken, Health-Checks und Kapazitätsplanung CTX

ORT als CLI-Toolchain bietet keine native Prometheus-Metriken-Exposition oder strukturierte Health-Check-Endpoints. Der ORT Server (Kotlin/Spring-basiert) kann theoretisch über externe Mittel gemonitort werden, jedoch fehlen dokumentierte Tenant-Metriken und OpenTelemetry-Integration.

💡 Begründung: Als primär CLI-basierte Toolchain fehlt ORT weitgehend jegliche native Observability. Der ORT Server könnte Spring-Actuator-Endpoints bereitstellen, jedoch sind Prometheus-Metriken, Tenant-Dimensionierung und OpenTelemetry-Tracing weder dokumentiert noch als Features ausgewiesen. Dies entspricht Skala 2: Metriken nur über externe Agents erreichbar, kein strukturierter Health-Endpoint, kein natives Tracing.

2 Differenziertes Ausnahme- und Dispensationsmanagement mit Genehmigungsworkflow und Ablaufdatum CTX

ORT unterstützt Curations und Resolutions als versionierte Code-Dateien mit Pflichtkommentaren, jedoch ohne formalisierten Genehmigungsworkflow, Vier-Augen-Prinzip oder automatische Ablaufdatum-Eskalation. Die Nachvollziehbarkeit erfolgt ausschließlich über Git-History.

💡 Begründung: ORT's Curation- und Resolution-System basiert auf YAML-Dateien in Git, was Versionierung und rudimentäre Nachvollziehbarkeit bietet, aber keinen formalisierten Genehmigungsprozess mit Antragsteller, Genehmiger, Ablaufdatum oder automatischer Eskalation implementiert. Dies entspricht Skala 2: optionaler Kommentar vorhanden, kein Ablaufdatum-Management, keine Genehmigungslogik im Tool selbst.

3.0 Produkt-Features

3 SBOM-Import (CycloneDX & SPDX) FEAT

ORT unterstützt nativ den Export von SBOMs in SPDX und CycloneDX, jedoch ist der Import externer SBOMs (z.B. als Input für weitere Analysen) nicht die primäre Stärke – ORT analysiert primär Quellcode und Package-Manifeste direkt.

💡 Begründung: ORT generiert SBOMs, kann aber extern erstellte SBOMs nicht vollständig als primären Input-Kanal importieren und verarbeiten wie spezialisierte SBOM-Management-Plattformen. Der Import ist rudimentär vorhanden, aber nicht der Kernfokus, daher Minimum erfüllt (Score 3).

5 SBOM-Export & Supply-Chain-Transparenz FEAT

ORT bietet nativen, ausgereiften SBOM-Export in SPDX (mehrere Versionen) und CycloneDX über den Reporter-Schritt und ist damit Best-in-Class für Open-Source-Tools in diesem Bereich.

💡 Begründung: SBOM-Export ist eine der Kernfunktionen von ORT mit expliziter Unterstützung beider Industriestandards, Multi-Format-Output und CI/CD-Integration – dies erfüllt die Anforderung vollständig und ausgereift (Score 5).

2 SBOM-Qualitätsbewertung FEAT

ORT bietet keine dedizierte SBOM-Qualitätsbewertungsfunktion; es prüft zwar auf fehlende Lizenzen oder Metadaten im Rahmen des Evaluators, aber ein systematisches SBOM-Completeness-Scoring fehlt.

💡 Begründung: Eine explizite SBOM-Qualitätsbewertung mit Hinweisen auf fehlende Metadaten ist kein dokumentiertes Feature von ORT. Der Evaluator kann partiell Lücken identifizieren, aber dies ist nicht auf SBOM-Qualität als solche ausgerichtet – erhebliche Lücken (Score 2).

2 SBOM-Versionierung & historischer Vergleich FEAT

ORT speichert Scan-Ergebnisse als Dateien und kann über versionierte Konfiguration als Code indirekt historische Zustände nachvollziehen, bietet aber keine integrierte SBOM-Versionierungs- und Diff-Funktionalität.

💡 Begründung: Ein dedizierter historischer SBOM-Vergleich (Diff-Ansicht, neue/entfernte Komponenten) ist kein natives Feature von ORT. Historische Zustände müssen manuell über Versionskontrolle nachvollzogen werden – rudimentär mit erheblichen Lücken (Score 2).

5 Standardisierte Komponenten-Identifikation (PURL) FEAT

ORT verwendet PURLs (Package URLs) als standardisierte Identifikatoren für Komponenten über alle unterstützten Ökosysteme hinweg und ist damit vollständig PURL-konform.

💡 Begründung: PURL-Unterstützung ist tief in ORT verankert und wird konsistent für alle Package-Ökosysteme genutzt, was ökosystemübergreifende Eindeutigkeit sicherstellt – Best-in-Class (Score 5).

3 Interne Komponenten-Datenbank mit Deduplizierung FEAT

ORT verwaltet Pakete intern mit Deduplizierung über PURLs und Package-Curation-Mechanismen, jedoch ist dies keine klassische zentrale Datenbank mit automatischer Merge-Logik, sondern eher eine scan-bezogene Verwaltung.

💡 Begründung: ORT erkennt und dedupliziert Pakete innerhalb eines Scans via PURL, und die Package Curation Database (z.B. ClearlyDefined-Integration) ergänzt dies. Eine vollständige zentrale Enterprise-Komponenten-Datenbank mit automatischer Deduplizierung über Projekte hinweg fehlt jedoch – Minimum erfüllt (Score 3).

2 Kontinuierliches Vulnerability Monitoring FEAT

ORT führt Vulnerability-Checks im Advisor-Schritt durch, aber nur bei aktiv ausgelösten Scans – ein kontinuierliches, automatisches Monitoring neu veröffentlichter CVEs ohne manuellen Re-Scan ist nicht nativ integriert.

💡 Begründung: Kontinuierliches Vulnerability Monitoring (Push-basiert bei neuen CVEs) ist kein Kernfeature von ORT; es erfordert externe Orchestrierung (z.B. geplante CI/CD-Runs). Dies stellt eine erhebliche Lücke für echtes kontinuierliches Monitoring dar (Score 2).

4 Multi-Feed Vulnerability Aggregation FEAT

ORT's Advisor-Schritt aggregiert Schwachstelleninformationen aus mehreren Quellen wie OSV, VulnerableCode, FossID und anderen, was eine gute Multi-Feed-Abdeckung bietet.

💡 Begründung: ORT unterstützt mehrere Vulnerability-Datenquellen parallel (OSV, VulnerableCode, FossID Advisories etc.), was die Mindestanforderung übertrifft. NVD direkt ist weniger prominent, aber die OSV-Integration deckt viele Quellen ab – gut, übertrifft Minimum (Score 4).

3 CVSS- & EPSS-Score-Integration FEAT

ORT übernimmt CVSS-Scores aus den angebundenen Vulnerability-Datenquellen und stellt sie im Report dar; EPSS-Score-Integration ist jedoch nicht als explizites Feature dokumentiert.

💡 Begründung: CVSS-Scores werden durch die Datenquellen (OSV etc.) mitgeliefert und von ORT durchgereicht, aber eine dedizierte EPSS-Integration ist nicht bekannt. Damit wird das Minimum für CVSS erfüllt, aber EPSS fehlt – ausreichend (Score 3).

2 VEX (Vulnerability Exploitability eXchange) Support FEAT

ORT unterstützt VEX nicht als dediziertes Feature; Resolutions und Curations bieten ähnliche Funktionalität zum manuellen Überschreiben von Vulnerability-Status, sind aber kein standardkonformer VEX-Export/-Import.

💡 Begründung: Dedizierter VEX-Import/-Export (CycloneDX VEX, OpenVEX, CSAF) ist kein dokumentiertes Feature von ORT. Die Resolution-Mechanismen sind funktional ähnlich, aber nicht VEX-standardkonform – rudimentär mit erheblichen Lücken (Score 2).

2 Vulnerability Lifecycle Management & Triage-Workflows FEAT

ORT bietet über Resolutions einen Mechanismus zum Umgang mit False Positives und bekannten Schwachstellen, aber keinen vollständigen Lifecycle-Workflow mit Triage-States, Risikobewertung und Remediation-Tracking.

💡 Begründung: Ein strukturiertes Vulnerability Lifecycle Management mit Status-Übergängen, Triage-Workflows und Audit-Trail für jede Schwachstelle ist kein Kernfeature von ORT – dies ist eher ein Ticket-System-Thema. Resolutions decken nur einen Teil ab – rudimentär (Score 2).

5 Konfigurierbare Policy Engine FEAT

ORT's Evaluator mit Kotlin-DSL ist eine mächtige, typsichere Policy-Engine, die beliebige Compliance-Regeln für Lizenzen, Schwachstellen-Schweregrade und Komponenten-Blacklists definieren und automatisch durchsetzen kann.

💡 Begründung: Die Kotlin-DSL-basierte Policy-Engine ist eine der herausragenden Stärken von ORT, bietet volle Flexibilität, Typsicherheit und CI/CD-Integration – dies erfüllt die Anforderung vollständig und Best-in-Class (Score 5).

5 Lizenz-Compliance & SPDX-Identifikation FEAT

ORT bietet einen vollständig integrierten License-Compliance-Workflow: Der Scanner (ScanCode, FossID, SCANOSS) erkennt Lizenzinformationen aus Quellcode und SBOMs, ordnet SPDX-Identifier zu und der Evaluator prüft automatisch konfigurierbare Policy-Regeln. SPDX- und CycloneDX-Export sowie Lizenz-Kategorisierung (Copyleft, permissiv etc.) sind nativ vorhanden.

💡 Begründung: ORT ist spezifisch für License Compliance gebaut und deckt alle genannten Anforderungen vollständig ab – Erkennung, SPDX-Zuordnung und automatische Policy-Prüfung via Kotlin-DSL. Dies entspricht Best-in-Class (Score 5).

2 SLA-Tracking für Schwachstellen FEAT

ORT aggregiert Schwachstelleninformationen über den Advisor-Schritt aus mehreren Quellen, bietet jedoch kein natives SLA-Tracking mit konfigurierbaren Fristen und automatischer Eskalation. Fristen müssten über externe CI/CD-Logik oder eigene Regelwerke approximiert werden.

💡 Begründung: ORT ist primär ein Scan- und Compliance-Tool, kein Vulnerability-Management-System mit SLA-Engine. Kein eingebautes Fristtracking, keine automatische Eskalation – erhebliche Lücken, daher Score 2.

2 Hierarchische Projekt- und Portfolio-Strukturierung FEAT

ORT analysiert einzelne Repositories und Projekte, bietet aber keine native hierarchische Portfolio-Strukturierung (Portfolio > Produkt > Projekt > Komponente) mit aggregierter Risikoansicht. Eine solche Struktur müsste extern aufgebaut werden, z. B. über den ORT-Server.

💡 Begründung: ORT ist pipeline-orientiert und projektbezogen. Eine hierarchische Multi-Ebenen-Portfolio-Verwaltung ist nicht als Feature vorhanden; nur rudimentäre Ansätze über den ORT-Server denkbar, daher Score 2.

2 Konfigurierbares Notification & Alerting Framework FEAT

ORT verfügt über kein natives Notification- und Alerting-Framework für E-Mail, Slack, MS Teams oder Webhooks. Benachrichtigungen bei Policy-Verstößen müssen über CI/CD-Systeme (z. B. GitHub Actions) oder externe Integrationen realisiert werden.

💡 Begründung: Kein eingebautes Alerting-System; Benachrichtigungen sind nur indirekt über CI/CD-Pipeline-Status möglich. Dies entspricht rudimentärer Abdeckung mit erheblichen Lücken, Score 2.

2 Dashboards & Risiko-Scoring (Projekt & Portfolio) FEAT

ORT erzeugt Compliance-Berichte und Reports, bietet jedoch keine eingebauten interaktiven Dashboards mit aggregierten Risiko-Scores oder Trend-Analysen auf Portfolio-Ebene. Der ORT-Server bietet ansatzweise eine Weboberfläche, ist aber kein vollwertiges Dashboard-Tool.

💡 Begründung: ORT ist ein CLI/Pipeline-Tool ohne natives Dashboard-Feature. Aggregierte Risiko-Scores und Trend-Analysen auf Portfolio-Ebene fehlen; erhebliche Lücken gegenüber der Anforderung, Score 2.

4 Automatisierte Bericht-Generierung FEAT

Der Reporter-Schritt von ORT generiert automatisiert Compliance-Berichte in mehreren Formaten (SPDX, CycloneDX, HTML, PDF) und unterstützt anpassbare Report-Templates. Die Integration in CI/CD-Pipelines ermöglicht vollautomatische Berichterstellung.

💡 Begründung: ORT erfüllt die Kernanforderung gut: automatisierte, anpassbare Berichte in HTML und anderen Formaten. PDF ist möglich, Template-Anpassung ist vorhanden. Leichte Abstriche gegenüber Best-in-Class, da Executive-Summary-Vorlagen begrenzt sind, Score 4.

4 CI/CD-Integration via REST-API & CLI FEAT

ORT bietet eine vollständige CLI für alle Pipeline-Schritte sowie einen optionalen ORT-Server mit REST-API, GitHub Actions, GitLab CI-Templates und Jenkins-Integration. SBOM-Uploads und Policy-Checks lassen sich vollständig automatisiert in CI/CD-Pipelines integrieren.

💡 Begründung: Die CI/CD-Integration ist eine ausgewiesene Kernstärke von ORT mit nativen Integrationen und REST-API über den ORT-Server. Leichter Abzug da der ORT-Server eine separate optionale Komponente ist und nicht immer out-of-the-box eingesetzt wird, Score 4.

2 Granulares RBAC mit Multi-Tenancy-Unterstützung FEAT

ORT als CLI-Tool bietet kein natives RBAC-System. Der ORT-Server kann grundlegende Zugriffskontrollen unterstützen, jedoch ist feingranulares RBAC auf Team-/Projektebene und echte Multi-Tenancy-Isolation nicht als ausgereiftes Feature dokumentiert.

💡 Begründung: RBAC und Multi-Tenancy sind für ein primär CLI-basiertes Open-Source-Tool nicht der Fokus. Allenfalls rudimentäre Ansätze über den ORT-Server, erhebliche Lücken gegenüber Enterprise-RBAC-Anforderungen, Score 2.

📋 Anforderungskatalog

Integration (2 Anforderungen)

ID	Name	Beschreibung	Quelle	Anwendbarkeit
INT-01	General Interfaces/APIs	- What kind of interface technologies are supported (e.g., Web Services, REST-APIs, …)? - Is there a documentation for a…	standard
INT-02	Interface monitoring	- Are there any functionalities to monitor the availability and performance of connected interfaces?	standard

Non-Functional Requirements (24 Anforderungen)

ID	Name	Beschreibung	Quelle	Anwendbarkeit
NFR-01	Authorization	- How flexible is the creation and adapation of authorizations and roles? - Are there predefined or recommended roles an…	standard
NFR-02	IDM connection	- Can user and role creation/provisioning/deletion be automated? - Is connection to active directory roles (using SCIM) …	standard
NFR-03	Single Sign-On	- Is Single-Sign-On supported using Azure AD (EntraID) with OIDC or SAML2.0 protocoll? - Can the customer configure the …	standard
NFR-04	Client/Instances	- is a (data) separation of several instances/clients supported?	standard
NFR-05	Storage of data (Metadata)	Evaluates the architecture for storing application metadata. Enterprise-readiness is demonstrated by the mandatory use o…	standard
NFR-06	Data/Object Storage Backend Flexibility	Evaluates the flexibility in choosing the storage backend for the core data objects. The ability to use modern, scalable…	standard
NFR-07	Data Archiving & Cleanup	How is the archiving of data supported and what options can be configured by the customer?	standard
NFR-08	Hosting Flexibility	Is hosting as SaaS supported? - running on preferred Hyperscalers (AWS, Azure)? Is hosting as PaaS supported? - flexibi…	standard	⚠ eingeschränkt
NFR-09	Hardware and Component Requirements	- What are the minimum and recommended hardware requirements for installing the solution? (e.g., memory, CPU cores, hard…	standard
NFR-10	Installation Mode (automatic / manual)	- What are the steps for installing the solution? - Is there an automated installation process available?	standard
NFR-11	Multi-location Deployment Options	- What are the deployment options for a distributed environment? - Is a central data repository supported when using a m…	standard	⚠ eingeschränkt
NFR-12	Application Performance	Evaluates expected response and execution performance for typical package operations (browse/search/publish/download), c…	standard
NFR-13	Scalability (manage increase No. of users)	Evaluates behavior under high concurrency and parallel transactions, including scaling options, queue/task handling, and…	standard
NFR-14	Remote Performance for foreign locations	Evaluates sensitivity to bandwidth and latency in distributed usage (including remote/offshore teams), and whether archi…	standard
NFR-15	Deployment of Customizing --> no coding	Ability to configure and customize the solution behavior without writing custom code, including role/permission setup, f…	standard
NFR-16	Deployment of Development --> coding	Ability for customer-side teams to implement code-based extensions/integrations, including APIs, scripting/plugin models…	standard
NFR-17	Experience/Possibility with/of offshore development	Ability to onboard and govern distributed or offshore development teams through external user integration, role-based ac…	standard
NFR-18	Flexibility via side-by-side or other extension points	Evaluates whether the platform provides supported extension points for side-by-side capabilities, such as plugins, scrip…	standard
NFR-19	Maintenance and consistency of control tables	Assesses how easily repository/feed control structures (for example repository/feed definitions, access/permission rules…	standard
NFR-20	Source code availability	Evaluates source-code availability and modifiability of the product itself, including whether customers can review inter…	standard
NFR-21	Maintenance effort (upgrades & testing)	Evaluates release/maintenance model for functionality upgrades, bug fixes, and security updates, including release caden…	standard
NFR-22	Backup & Recovery/Redundancy layer in case of break down	Evaluates resilience concepts for hardware/software failure, including high-availability patterns, backup/restore option…	standard
NFR-23	Availability (Maintenance windows, unannounced maintenance)	Evaluates whether planned updates can be applied with no or low downtime, considering rolling/blue-green capabilities, m…	standard	⚠ eingeschränkt
NFR-24	Availability defined/possible SLA	Evaluates formal availability commitments (SLA) and practical service availability expectations, including whether the p…	standard	⚠ eingeschränkt

Usability & User Experience (8 Anforderungen)

ID	Name	Beschreibung	Quelle
UX-01	Ease of Use	Evaluates how quickly typical users can understand and use core package/repository workflows (browse, search, publish, c…	standard
UX-02	Consistent, seamless user interface	Evaluates visual and interaction consistency across the product experience, and practical ability to align appearance/us…	standard
UX-03	Explicit user guidance	Evaluates explicit in-product guidance (assistants/wizards, contextual help, guided setup steps) for complex setup and o…	standard
UX-04	Use-case-oriented design	Evaluates whether the UI design fits real target-user workflows (end-user and admin tasks), including clarity of core ac…	standard
UX-05	Flexibility of UI	Evaluates productivity features for experienced users, including shortcuts, efficient navigation, and fast filtering/sea…	standard
UX-06	Customizable by end-user / user groups	Evaluates end-user and group-level adaptability of the interface, including personal preferences (theme/layout/behavior)…	standard
UX-07	Language Capabilities	Evaluates language and localization capabilities in the UI (multi-language support, locale/time settings) and practical …	standard
UX-08	Design thinking approach	Evaluates accessibility and inclusive interaction support (keyboard accessibility and efficient non-mouse operation) for…	standard

IT Compliance (6 Anforderungen)

ID	Name	Beschreibung	Quelle	Anwendbarkeit
COMP-01	Single Source of Truth for each data object	- prevent replication of data wherever possible - usage of data from leading source systems (e.g. REF-MDS)by APIs	standard
COMP-02	Where is the cloud server located? (country)	- Does the vendor have cloud infrastructure in relevant countries? (e.g., EU, CN) - Does the vendor use a den bevorzugte…	standard	⚠ eingeschränkt
COMP-03	Does the cloud service provide the encryption of data at rest and in transit?	- Which kind of data are affected? - SC0,1,2,3 for confidentiality, availability, integrity	standard
COMP-04	GDPR and BDSG	- Are there further subcontractors with access to personal related data? - Is the cloud service provider compliant with …	standard
COMP-05	ISO certificates	- Does the cloud service provider (or Data Processor) hold an ISO 27001 certification?	standard
COMP-06	Data export and import	- Does the cloud service provider support data export (and import)? - Additional manual download/upload functions possib…	standard

Risks & Opportunities (8 Anforderungen)

ID	Name	Beschreibung	Quelle
RISK-01	Dependencies and Lock-In from Software Vendor	The target is to minimize lock-in risks - How easy is it to de-integrate solution if necessary? - How easy is it to repl…	standard
RISK-02	Project team setup and continuity	- How is the setup of the development team? (Junior/Senior)? - Is the development team stable or are the fluctuations th…	standard
RISK-03	Time to Market	- How fast could a provider setup a possible project team (lead time)? - How fast can the solution be used productively?	standard
RISK-04	Skill of supplier	- What is the skill setup of possible project team? (Consulting/Concept/Implementation/Deployment) - What are the experi…	standard
RISK-05	Size of supplier (Skalierbarkeit für Großkunden), risk of insolvency	- How many employees in the company are working on supporting and developing the solution?	standard
RISK-06	World wide rollout	- Are there regional support teams and experiences in rollout and support of the solution across different regions?	standard
RISK-07	Dependencies to other strategic projects	- Are there positive or negative dependencies to other projects or programs e.g. S/4HANA etc. (regarding time, functiona…	standard
RISK-08	Development method (agile or waterfall)	- Which development methods (agile, waterfall or combination) are supported by the developer and does it fit to the type…	standard

Total Cost of Ownership (5 Anforderungen)

ID	Name	Beschreibung	Quelle
TCO-01	Setup/Project Costs	e.g., one-time costs for project setup, organization, concept..	standard
TCO-02	Implementation Costs	e.g., development and customizing costs	standard
TCO-03	Maintenance / Operation Costs	Evaluates recurring maintenance and operational effort, including platform administration and day-2 operations.	standard
TCO-04	License Costs	Charging model (User, volume, …)?	standard
TCO-05	expected benefit/efficiency	Cost impact in subsequent years based on improved efficiencies	standard

Support & Operations (7 Anforderungen)

ID	Name	Beschreibung	Quelle
SUP-01	1st level	- How can the 1st level support (e.g. hotlines) be organized in collaboration with the vendor of this solution?	standard
SUP-02	2nd level	- How can the 2nd level support be organized in collaboration with the vendor of this solution?	standard
SUP-03	3rd level	- How can the 3rd level support (e.g. bugfixing process) be organized in collaboration with the vendor of this solution?	standard
SUP-04	General support concept/approach	- Which support is offered by the vendor? - How can des Kunden be integrated into the support process? - Can the vendor …	standard
SUP-05	SLA for tickets	- Is there an SLA on how fast tickets are solved? - What are solution times for high, medium, low tickets?	standard
SUP-06	Support coverage	- Does the support cover 24/7 - Are there regional differences?	standard
SUP-07	Training, tool documentation	- Does the vendor offer trainings (tool embedded, videos, webinar, face to face, remote, ...)? - Are there specific trai…	standard

Projektspezifische Anforderungen (40 Anforderungen)

ID	Name	Beschreibung	Quelle
CTX-01	Hierarchische Mandantentrennung mit vererbten Policies	Das System muss eine mehrstufige Mandantenhierarchie (Organisation > Sub-Organisation > Projekt > Team > Individuum) mit…	context
CTX-02	Mandanten-scoped API-Tokens und Service-Accounts	CI/CD-Pipelines verschiedener Teams benötigen API-Tokens, die exakt auf einen Mandanten (Projekt/Team) beschränkt sind u…	context
CTX-03	Proxy-/Pull-Policy-Gate für JFrog Artifactory ohne XRay-Lizenz	Da JFrog XRay und Curation nicht lizenziert sind, muss ein alternatives Tool in der Lage sein, als Policy-Gate beim Arti…	context
CTX-04	Bidirektionale Integration mit bestehendem Dependency-Track ohne Datenduplizierung	Dependency-Track ist bereits als SBOM-Service im Einsatz. Neu einzuführende Tools müssen so integriert werden können, da…	context
CTX-05	SBOM-Generierung für Binary-Artefakte in Artifactory (ohne Quellcode-Zugriff)	Im Enterprise-Kontext liegen viele Artefakte in Artifactory als Binaries vor, ohne dass der Quellcode im gleichen Kontex…	context
CTX-06	SBOM-Versionierung und Differenz-Tracking über Artefakt-Versionen	Im Lifecycle eines Artefakts entstehen mehrere SBOM-Versionen (je Build-Version, Patch-Release, etc.). Das Tool muss SBO…	context
CTX-07	VEX/OpenVEX-Erstellung und -Verwaltung als First-Class-Feature	Im KRITIS-Umfeld mit 100.000 Usern entstehen massenhaft Vulnerability-Findings, von denen ein großer Teil durch VEX-Stat…	context
CTX-08	Organisationsweite Suppression und Wiederverwendung von Triage-Entscheidungen	Wenn eine CVE in 500 Projekten als 'not_affected' triagiert wurde, darf diese Entscheidung nicht 500-mal manuell wiederh…	context
CTX-09	Aggregierte Vulnerability-Feeds aus mehreren Quellen mit Konfliktauflösung	Im Gegensatz zu einem reinen NVD-Feed benötigt eine KRITIS-Organisation mehrere parallele Vulnerability-Datenquellen (NV…	context
CTX-10	License-Policy-Enforcement mit Copyleft-Risikostufen und Ausnahme-Workflow	Für eine 100.000-User-Organisation mit verschiedenen Produkttypen (intern, SaaS, Embedded) müssen License-Policies mit d…	context
CTX-11	SPDX-konforme Lizenzauflösung inkl. komplexer Lizenz-Expressions	Moderne Open-Source-Pakete verwenden SPDX License Expressions wie 'Apache-2.0 AND MIT', 'GPL-2.0-only OR GPL-3.0-only', …	context
CTX-12	Deklarative Policy-as-Code-Definition mit Versionierung (OPA/Rego oder äquivalent)	Für eine Organisation mit 100.000 Usern müssen Security- und License-Policies versioniert, peer-reviewed (Git-Workflow) …	context
CTX-13	Granulare Policy-Gate-Aktionen: Blockieren, Warnen, Quarantäne, Notifizieren	Ein Policy-Gate, der JFrog Curation ersetzen soll, muss mehr als 'block/allow' unterstützen. Für unterschiedliche Risiko…	context
CTX-14	Air-Gap / Offline-Betrieb für Vulnerability-Datenfeeds	KRITIS-Infrastrukturen können strenge Netzwerksegmentierungen haben, bei denen der Produktionsbereich keinen direkten In…	context
CTX-15	Manipulationssicheres Audit-Log mit SIEM-Export (CEF/JSON/Syslog)	Im KRITIS-Umfeld ist ein manipulationssicheres Audit-Log aller sicherheitsrelevanten Aktionen (Policy-Änderungen, Triage…	context
CTX-16	Horizontale Skalierung des Scanning-Backends für Enterprise-Artefaktvolumen	Bei 100.000 Usern und einer zentralen Artifactory-Instanz können täglich tausende neue Artefakt-Versionen eingecheckt we…	context
CTX-17	OWASP-Ökosystem-Alignment und aktive OWASP-Projektmitgliedschaft	Der Kunden-Kontext präferiert Tools, die im OWASP-Ökosystem verankert sind (OWASP Flagship oder Lab Project), da dies Co…	context
CTX-18	Native CI/CD-Integration mit Policy-Gate-Rückgabecodes für gängige Pipelines	Die zentrale IT muss den Teams standardisierte CI/CD-Integrationen bereitstellen. Das Tool muss native Plugins oder Acti…	context
CTX-19	Kubernetes-natives Deployment mit Helm-Chart und Operator-Support für HA	Die zentrale IT betreibt Self-Hosted-Services auf Kubernetes. Das Tool muss ein offizielles, gepflegtes Helm-Chart berei…	context
CTX-20	Compliance-Dashboard und automatisierter Report-Export für NIS2/BSI-Grundschutz	Als KRITIS-Betreiber muss die Organisation Compliance-Nachweise für NIS2, BSI IT-Grundschutz und interne Revisionen erbr…	context
CTX-21	SBOM-Enrichment aus Container-Image-Layern	Für Organisationen, die Container-Images in Artifactory ablegen, muss das Tool SBOM-Komponenten nicht nur auf Image-Eben…	context
CTX-22	EPSS-Score-Integration und priorisierungsbasiertes Triage-Routing	Neben CVSS-Scores soll der Exploit Prediction Scoring System (EPSS)-Score als zusätzliche Priorisierungsdimension in den…	context
CTX-23	CISA KEV (Known Exploited Vulnerabilities) Catalogue-Integration	Das CISA Known Exploited Vulnerabilities Catalogue ist für KRITIS-Umgebungen besonders relevant, da aktiv ausgenutzte Sc…	context
CTX-24	Mandantenspezifische Vulnerability-Feed-Konfiguration und -Isolation	In einer Multi-Tenant-Umgebung mit Sub-Organisationen kann es legitime Gründe geben, dass verschiedene Mandanten untersc…	context
CTX-25	Rückmeldung von Scan-Ergebnissen in Artifactory-Properties/Metadata	JFrog Artifactory erlaubt das Setzen von Artefakt-Properties (Key-Value-Metadaten) über seine REST-API. Ohne XRay-Lizenz…	context
CTX-26	Automatisierte OSS-Komponenten-Attributionslisten-Generierung (NOTICE-Dateien)	Neben License-Policy-Enforcement benötigen Organisationen, die Software ausliefern, automatisiert generierte Attribution…	context
CTX-27	Trusted-Component-Registry und positives Whitelisting für Organisationen	Als Pendant zum Blocking (Blacklisting) muss ein positives Whitelisting existieren: Eine zentral verwaltete 'Trusted Com…	context
CTX-28	Transitive Dependency-Auflösung und Tiefenanalyse für SBOM-Vollständigkeit	Für eine valide SBOM nach CycloneDX Metadata Level 3 (oder SPDX SBOM-Completeness) müssen auch transitive Abhängigkeiten…	context
CTX-29	Datenbankpartitionierung und Archivierungsstrategie für Langzeit-SBOM-Daten	Bei 100.000 Usern, hunderten Projekten und kontinuierlichem CI/CD-Betrieb akkumulieren SBOM-Daten, Scan-Ergebnisse und A…	context
CTX-30	Webhook- und Event-Bus-Integration für asynchrone Event-Driven-Architektur	In einer organisationsweiten Plattform mit 100.000 Usern werden Scan-Events, Policy-Violations, neue Vulnerabilities für…	context
CTX-31	Malware- und Typosquatting-Erkennung für Registry-Proxies	JFrog Curation bietet als Premium-Feature die Erkennung von Malware-verseuchten und Typosquatting-Paketen beim Pull aus …	context
CTX-32	Softwareintegrität und Artefakt-Signatur-Verifikation (Sigstore/Cosign)	Im Kontext Software Supply Chain Security ist die Verifikation der Integrität und Authentizität von Artefakten (nicht nu…	context
CTX-33	Ressourcen-Quotierung und Rate-Limiting pro Mandant (Fair-Use-Enforcement)	In einem mandantenfähigen, organisationsweiten Service-Betrieb für 100.000 User besteht das Risiko, dass einzelne Mandan…	context
CTX-34	SBOM-as-a-Service API für externe Tool-Integration (SBOM-Upload und -Abfrage)	Da die zentrale IT das Tool als organisationsweiten Service betreibt, müssen externe Tools (eigene Entwicklungstools, an…	context
CTX-35	Regulatorische Berichtspflichten: CRA (Cyber Resilience Act) SBOM-Anforderungen	Der EU Cyber Resilience Act (CRA) stellt ab 2026/2027 konkrete Anforderungen an SBOM-Vollständigkeit und -Verfügbarkeit …	context
CTX-36	Dependency-Track-Migrationsbrücke: Erhalt historischer Triage-Daten	Da Dependency-Track bereits produktiv als SBOM-Service betrieben wird, müssen historische Triage-Entscheidungen (Suppres…	context
CTX-37	Zentraler Service-Delivery-Modus: Self-Service-Onboarding für Sub-Organisationen ohne Admin-Eskalation	Die zentrale IT betreibt das Tool als organisationsweiten Service für ca. 100.000 User aus zahlreichen Sub-Organisatione…	context
CTX-38	Reachability-Analyse: Exploitierbarkeits-Kontextbewertung auf Basis tatsächlicher Code-Nutzung	Im KRITIS-Umfeld mit 100.000 Usern und potenziell tausenden verwalteten Komponenten führt eine reine CVE-Zählung ohne Ko…	context
CTX-39	Operative Observability des Security-Services: Interne Metriken, Health-Checks und Kapazitätsplanung	Die zentrale IT betreibt das Tool als Shared Service für die gesamte Organisation. Für einen stabilen Betrieb auf Enterp…	context
CTX-40	Differenziertes Ausnahme- und Dispensationsmanagement mit Genehmigungsworkflow und Ablaufdatum	Im KRITIS-Umfeld reicht es nicht, Vulnerabilities oder Lizenzprobleme zu unterdrücken – jede Ausnahme (Policy-Exception,…	context

Produkt-Features (20 Anforderungen)

ID	Name	Beschreibung	Quelle
FEAT-101	SBOM-Import (CycloneDX & SPDX)	Das System soll SBOMs in den gängigen Industriestandards CycloneDX und SPDX importieren können, um eine breite Tool-Komp…	feature
FEAT-102	SBOM-Export & Supply-Chain-Transparenz	Neben dem Import sollen SBOMs für verwaltete Projekte auch exportiert werden können, um Supply-Chain-Transparenz gegenüb…	feature
FEAT-103	SBOM-Qualitätsbewertung	Das System soll die Qualität und Vollständigkeit importierter SBOMs bewerten und Hinweise auf fehlende oder unvollständi…	feature
FEAT-104	SBOM-Versionierung & historischer Vergleich	Das System soll SBOM-Versionen historisch speichern und Unterschiede zwischen Versionen (neue, entfernte oder geänderte …	feature
FEAT-105	Standardisierte Komponenten-Identifikation (PURL)	Komponenten sollen über standardisierte Package URLs (PURLs) identifiziert werden, um ökosystemübergreifende Eindeutigke…	feature
FEAT-106	Interne Komponenten-Datenbank mit Deduplizierung	Das System soll eine zentrale Datenbank aller bekannten Komponenten führen und Duplikate automatisch erkennen und zusamm…	feature
FEAT-107	Kontinuierliches Vulnerability Monitoring	Schwachstellen sollen nicht nur zum Scan-Zeitpunkt, sondern kontinuierlich überwacht werden, sodass neu veröffentlichte …	feature
FEAT-108	Multi-Feed Vulnerability Aggregation	Das System soll Schwachstelleninformationen aus mehreren Quellen (z. B. NVD, OSV, GitHub Advisories) gleichzeitig integr…	feature
FEAT-109	CVSS- & EPSS-Score-Integration	Das System soll CVSS-Scores (v2/v3/v4) sowie EPSS-Scores (Exploit Prediction Scoring System) für Schwachstellen anzeigen…	feature
FEAT-110	VEX (Vulnerability Exploitability eXchange) Support	Das System soll VEX-Dokumente importieren und exportieren können, um den tatsächlichen Ausnutzbarkeitsstatus von Schwach…	feature
FEAT-111	Vulnerability Lifecycle Management & Triage-Workflows	Das System soll einen vollständigen Lebenszyklus für Schwachstellen abbilden – von der Entdeckung über Triage, Risikobew…	feature
FEAT-112	Konfigurierbare Policy Engine	Das System soll eine integrierte Policy-Engine bieten, mit der Compliance-Regeln (z. B. verbotene Lizenzen, Schweregrad-…	feature
FEAT-113	Lizenz-Compliance & SPDX-Identifikation	Das System soll Lizenzinformationen aus SBOMs und Quellcode-Scans erkennen, SPDX-Bezeichner zuordnen und Lizenz-Complian…	feature
FEAT-114	SLA-Tracking für Schwachstellen	Das System soll konfigurierbare SLA-Fristen pro Schweregrad unterstützen und automatisch warnen oder eskalieren, wenn Fr…	feature
FEAT-115	Hierarchische Projekt- und Portfolio-Strukturierung	Das System soll Projekte, Produkte und Anwendungen hierarchisch strukturieren können (z. B. Portfolio > Produkt > Projek…	feature
FEAT-116	Konfigurierbares Notification & Alerting Framework	Das System soll Benachrichtigungen bei neuen Schwachstellen, Policy-Verstößen oder SLA-Überschreitungen über konfigurier…	feature
FEAT-117	Dashboards & Risiko-Scoring (Projekt & Portfolio)	Das System soll eingebaute Dashboards mit aggregierten Risiko-Scores, Trend-Analysen und Severity-Verteilungen auf Proje…	feature
FEAT-118	Automatisierte Bericht-Generierung	Das System soll automatisierte, anpassbare Sicherheitsberichte (z. B. Executive Summary, technischer Detailbericht) in g…	feature
FEAT-119	CI/CD-Integration via REST-API & CLI	Das System soll eine vollständige REST-API sowie CLI-Unterstützung für die Integration in CI/CD-Pipelines bieten, um Sca…	feature
FEAT-120	Granulares RBAC mit Multi-Tenancy-Unterstützung	Das System soll feingranulare rollenbasierte Zugriffskontrollen (RBAC) auf Team- und Projektebene sowie die Isolation me…	feature