Grundlagen 13/13 ●

Allgemein

Was ist der von Menschen lesbare Name des Projekts?
Hinweis: Andere Projekte können den selben Namen benutzen.

Was ist eine Kurzbeschreibung des Projektes?

Find AI infrastructure vulnerabilities before attackers do. Security testing for MCP servers, AI agents, CLI AI platforms and LLM systems.

Wie lautet die URL für das Projekt (vollständig)?
https://github.com/macawi-ai/Strigoi

Was ist die URL für das Versionskontroll-Repository (es kann mit der Projekt-URL identisch sein)?
https://github.com/macawi-ai/Strigoi

Unter welcher Lizenz/welchen Lizenzen ist das Projekt veröffentlicht?
Bitte verwenden Sie das SPDX-License-Expression-Format; Beispiele sind "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "GPL-2.0+", "LGPL-3.0+", "MIT" und "(BSD-2-Clause OR Ruby)". Geben sie nicht die einfachen oder doppelten Anführungszeichen mit an.

Welche Programmiersprache wird verwendet, um das Projekt umzusetzen?
Wenn es mehr als eine Programmiersprache gibt, listen Sie sie als kommagetrennte Werte (Leerzeichen sind optional) auf und sortieren Sie sie von am häufigsten zum am wenigsten verwendeten. Wenn es eine lange Liste gibt, bitte mindestens die ersten drei häufigsten auflisten. Wenn es keine Programmiersprache gibt (z. B. ist dies nur ein Dokumentations- oder Testprojekt), verwenden Sie das einzelne Zeichen "-". Bitte verwenden Sie eine herkömmliche Großschreibung für jede Sprache, z.B. "JavaScript".

Was ist der Common-Platform-Enumeration-/CPE-Name für das Projekt (wenn es einen gibt)?
Das Common Platform Enumeration (CPE) ist ein strukturiertes Namensschema für IT-Systeme, Software und Pakete. Es wird in diversen Systemen und Datenbanken bei der Meldung von Schwachstellen verwendet.

Andere allgemeine Hinweise zum Projekt?
Grundlegende Informationen auf der Projektwebseite
Criterion [description_good]
Erfüllt

Unerfüllt

?

Die Projekt-Website MUSS prägnant beschreiben, was die Software tut (welches Problem löst sie?). ^{[description_good]}
Dies MUSS in einer Sprache sein, die potenzielle Nutzer verstehen können (z. B. möglichst wenig Fachbegriffe verwenden).
https://github.com/macawi-ai/strigoi/
(e.g. core capabilities -->
Core Capabilities
🛡️ Security Assessment
```
Interactive CLI - Bash-like navigation with directional reconnaissance (north/south/east/west)
17+ Detection Patterns - API keys, credentials, PII, prompt injection, SSRF, path traversal
MCP Vulnerability Scanner - Specialized scanning for Model Context Protocol servers
Multi-Layer Analysis - 7-layer protocol inspection with Russian doll unpacking
```
📡 Real-Time Monitoring
```
NATS JetStream Integration - Distributed event streaming with persistent storage
A2MCP Bridge - Monitor AI CLI tools (Claude Code, Gemini, ChatGPT) via MCP protocol
Stream Tap - Live STDIO capture with security detection and smart redaction
MetaFrame Protocol - Standardized security telemetry format
```
🏗️ Platform Features
```
Multi-Architecture - AMD64, ARM64, ARMv7 (Raspberry Pi, NanoPi, Orange Pi)
Container-Native - Podman/Docker with rootless support
Web UI Dashboard - Real-time monitoring via http://localhost:8081/
Pre-compiled Binaries - Linux, macOS (Intel/Apple Silicon), Windows
```
Criterion [interact]
Erfüllt

Unerfüllt

?

Die Projekt-Website MUSS Informationen darüber enthalten, wie Feedback erhalten und gegeben werden kann (als Fehlerberichte oder Verbesserungsvorschläge), und wie man zur Softwareentwicklung beitragen kann. ^[interact]
The README provides clear information on all three requirements:
1. Obtain: Multiple installation methods documented including pre-built binaries from GitHub Releases, wget commands for Linux/macOS/Windows, and build-from-source
  via install.sh. Direct links: https://github.com/macawi-ai/strigoi/releases
2. Feedback: Bug reports and enhancement requests via GitHub Issues, linked in README: https://github.com/macawi-ai/strigoi/issues
3. Contribute: Contributing section in README links to Development Methodology guide (docs/DEVELOPMENT_METHODOLOGY.md) covering code of conduct, development process, and pull request submission.
Criterion [contribution]
Erfüllt

Unerfüllt

?

Die Informationen darüber, wie jemand beitragen kann, MÜSSEN den Prozess erklären (z.B. wie werden Pull-Requests verwendet?) (URL erforderlich) ^{[contribution]}
Wir nehmen an, dass Projekte auf GitHub Issues und Pull-Requests verwenden, sofern nichts anders angegeben ist. Diese Information kann kurz sein, z. B., dass das Projekt Pull-Requests, einen Issue-Tracker oder eine Mailing-Liste verwendet (welche?)

Projects on GitHub by default use issues and pull requests, as encouraged by documentation such as https://guides.github.com/activities/contributing-to-open-source/.

Criterion [contribution_requirements]
Erfüllt

Unerfüllt

?

Die Informationen darüber, wie jemand beitragen können, SOLLTEN die Anforderungen für akzeptable Beiträge (z. B. einen Hinweis auf jeden erforderlichen Programmierstandard) enthalten. (URL erforderlich) ^{[contribution_requirements]}

https://github.com/macawi-ai/strigoi/blob/main/CONTRIBUTING.md
FLOSS-Lizenz
Criterion [floss_license]
Erfüllt

Unerfüllt

?
Die vom Projekt entwickelte Software MUSS als FLOSS lizensiert veröffentlicht sein. ^{[floss_license]}
FLOSS-Software erfüllt die Open Source Definition oder die Free Software Definition. Beispiele für solche Lizenzen sind die CC0 , MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0 , Lesser GNU General Public License (LGPL) und die GNU General Public License (GPL) . Für unsere Zwecke bedeutet dies, dass die Lizenz:
Die Software kann auch über andere Wege lizenziert werden (z.B. "GPLv2 oder proprietär" ist akzeptabel).
Open Source License

This software is licensed under the GNU Affero General Public License v3.0 (AGPL-3.0).

Key AGPL-3.0 Requirements:
```
✅ Freedom to use — Use for any purpose including commercial
✅ Freedom to study — Access to source code guaranteed
✅ Freedom to modify — Make changes and improvements
✅ Freedom to distribute — Share copies and modifications
🔒 Copyleft requirement — Derivative works must be open source
🌐 Network copyleft — SaaS use requires offering source code
```
The AGPL-3.0-or-later license is approved by the Open Source Initiative (OSI).
Criterion [floss_license_osi]
Erfüllt

Unerfüllt

?

Es wird EMPFHOLEN, dass alle erforderlichen Lizenz(en) für die vom Projekt entwickelte Software von der Open Source Initiative (OSI) anerkannt werden. ^{[floss_license_osi]}
Die OSI verwendet einen anspruchsvollen Genehmigungsprozess, um festzulegen, welche Lizenzen OSS sind.

We utilize the AGPL-3.0 The AGPL-3.0-or-later license is approved by the Open Source Initiative (OSI).

Criterion [license_location]
Erfüllt

Unerfüllt

?

Das Projekt MUSS die Lizenz(en) seiner Erzeugnisse an einem üblichen Ort in ihrem Quell-Repository veröffentlichen. (URL erforderlich) ^{[license_location]}
Eine Konvention ist es die Lizenz als eine Top-Level-Datei mit der Bezeichnung LICENSE oder COPYING zu veröffentlichen. Lizenzdateinamen DÜRFEN eine Erweiterung wie ".txt" oder ".md" haben. Eine alternative Konvention ist es einen Ordern mit dem namen LICENSES zu erstellen und dort alle Lizenz(en) abzuspeicehrn; diese dateien sind typischerweise mit ihreren SPDX License Identifier benannt und einer passendend Dateiendung; siehe Beschreibung dieser Konvention in der REUSE Specification. Beachten Sie, dass dieses Kriterium nur eine Voraussetzung für das Quell-Repository ist. Sie müssen die Lizenzdatei NICHT hinzufügen, wenn Sie etwas aus dem Quellcode generieren (z. B. eine ausführbare Datei, ein Paket oder einen Container). Wenn Sie beispielsweise ein R-Paket für das Comprehensive R Archive Network (CRAN) generieren, befolgen Sie die Standard-CRAN-Praxis: Wenn die Lizenz eine Standardlizenz ist, verwenden Sie die Standard-Kurzlizenzspezifikation (um die Installation einer weiteren Kopie des Textes zu vermeiden) die LICENSE-Datei in einer Ausschlussdatei wie .Rbuildignore. Ebenso können Sie beim Erstellen eines Debian-Pakets einen Link in die Copyright-Datei zum Lizenztext in /usr/share/common-licenses einfügen und die Lizenzdatei vom erstellten Paket ausschließen (z.B. durch Löschen der Datei nach dem Aufruf von dh_auto_install). Wir empfehlen, maschinenlesbare Lizenzinformationen in generierten Formaten zu integrieren, wo dies praktisch ist.

Non-trivial license location file in repository: https://github.com/macawi-ai/Strigoi/blob/main/LICENSE.
Dokumentation

Criterion [documentation_basics]
Erfüllt

Unerfüllt

N/A

?

Das Projekt MUSS eine grundlegende Dokumentation für die vom Projekt entwickelte Software liefern. ^{[documentation_basics]}
Diese Dokumentation muss in irgendeinem Medium sein (z.B. Text oder Video), das Folgendes beinhaltet: wie man die Software installiert, wie man sie startet, wie man sie benutzt (evtl. ein Tutorial mit Beispielen) und wie man sie sicher benutzt (z. B. was zu tun und zu lassen ist), wenn das ein passendes Einsatzgebiet für die Software ist. Die Sicherheitsdokumentation muss nicht lange sein. Das Projekt DARF Hypertext-Links zu Nicht-Projekt-Materialien als Dokumentation verwenden. Wenn das Projekt keine Software entwickelt, wählen Sie "nicht anwendbar" (N/A) aus.

Some documentation basics file contents found.
Criterion [documentation_interface]
Erfüllt

Unerfüllt

N/A

?

Das Projekt MUSS Referenzdokumentationen enthalten, die externe Schnittstellen (beides, Eingabe und Ausgabe) der vom Projekt entwickelten Software beschreiben. ^{[documentation_interface]}
Die Dokumentation einer externen Schnittstelle erklärt einem Endbenutzer oder Entwickler, wie man sie benutzt. Dies beinhaltet auch eine Programmierschnittstelle (API), falls die Software eine hat. Wenn es sich um eine Bibliothek handelt, dokumentieren Sie die wichtigsten Klassen/Typen und Methoden/Funktionen, die aufgerufen werden können. Wenn es sich um eine Webanwendung handelt, definieren Sie ihre URL-Schnittstelle (häufig eine REST-Schnittstelle). Wenn es sich um eine Befehlszeilenschnittstelle handelt, dokumentieren Sie die Parameter und Optionen, die sie unterstützt. In vielen Fällen ist es am besten, wenn die meisten dieser Dokumente automatisch generiert werden, so dass diese Dokumentation mit der sich ändernden Software synchronisiert bleibt, aber dies ist nicht erforderlich. Das Projekt DARF Hypertext-Links zu Nicht-Projekt-Materialien als Dokumentation verwenden. Dokumentation DARF automatisch generiert werden (falls möglich ist dies oft der beste Weg). Die Dokumentation einer REST-Schnittstelle kann mit Swagger/OpenAPI erzeugt werden. Code-Interface-Dokumentation kann mit Werkzeugen wie JSDoc (JavaScript), ESDoc (JavaScript), pydoc (Python), devtools (R), pkgdown (R) und Doxygen (verschiedene) generiert werden. Nur Kommentare im Quelltext reicht nicht aus, um dieses Kriterium zu erfüllen; Es muss einen einfacheren Weg geben, um die Informationen zu sehen, ohne den ganzen Quellcode durchzulesen. Wenn das Projekt keine Software entwickelt, wählen Sie "nicht anwendbar" (N/A) aus.
┌────────────┬───────────────────────────────────────────┬───────────────────────────────────────────────────────────────────────────────┐
│ Interface │ Documentation │ URL │
├────────────┼───────────────────────────────────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ CLI │ USER_GUIDE.md with full command reference │ https://github.com/macawi-ai/strigoi/blob/main/USER_GUIDE.md │
├────────────┼───────────────────────────────────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ CLI │ Built-in --help flags │ strigoi --help, strigoi <cmd> --help │
├────────────┼───────────────────────────────────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ REST API │ FLEET_MANAGER_API_SPEC.md │ https://github.com/macawi-ai/strigoi/blob/main/docs/FLEET_MANAGER_API_SPEC.md │
├────────────┼───────────────────────────────────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ Go Package │ pkg.go.dev (auto-generated) │ https://pkg.go.dev/github.com/macawi-ai/strigoi │
└────────────┴───────────────────────────────────────────┴───────────────────────────────────────────────────────────────────────────────┘

Justification for OpenSSF:

The project provides comprehensive interface documentation:
1. CLI Interface: USER_GUIDE.md documents all commands, subcommands, flags, and usage examples. Built-in --help provides real-time command reference.
2. REST API: docs/FLEET_MANAGER_API_SPEC.md documents all API endpoints with request/response examples in JSON format.
3. Go Package API: Automatically generated documentation available at pkg.go.dev/github.com/macawi-ai/strigoi
URLs:
- https://github.com/macawi-ai/strigoi/blob/main/USER_GUIDE.md
- https://github.com/macawi-ai/strigoi/blob/main/docs/FLEET_MANAGER_API_SPEC.md
Andere

Criterion [sites_https]
Erfüllt

Unerfüllt

?

Die Projekt-Seiten (Website, Repository und Download-URLs) MÜSSEN HTTPS mit TLS unterstützen. ^{[sites_https]}
Dies setzt voraus, dass die Projekt-Homepage-URL und die URL des Versionskontroll-Repositories mit "https:", nicht "http:" beginnt. Sie können kostenlose Zertifikate von Let's Encrypt erhalten. Projekte KÖNNEN dieses Kriterium implementieren, indem Sie (z. B.) GitHub-Pages verwenden, GitLab-Pages oder SourceForge project pages. Wenn Sie HTTP unterstützen, empfehlen wir Ihnen, den HTTP-Datenverkehr an HTTPS umzuleiten.

Given only https: URLs.

Criterion [discussion]
Erfüllt

Unerfüllt

?

Das Projekt MUSS einen oder mehrere Mechanismen zur Diskussion (einschließlich der vorgeschlagenen Änderungen und Issues) haben, die durchsuchbar sind, bei denen Nachrichten und Themen durch URL adressiert werden, neue Personen an einigen der Diskussionen teilnehmen können und keine lokale Installation von proprietärer Software erfordern. ^[discussion]
Beispiele für akzeptable Mechanismen umfassen archivierte Mailingliste(n), GitHub Issues und Pull-Request-Diskussionen, Bugzilla, Mantis und Trac. Asynchrone Diskussionsmechanismen (wie IRC) sind akzeptabel, wenn sie diese Kriterien erfüllen; Stellen Sie sicher, dass es einen URL-adressierbaren Archivierungsmechanismus gibt. Proprietäres JavaScript ist ungern gesehen, aber erlaubt.

GitHub supports discussions on issues and pull requests.

Criterion [english]
Erfüllt

Unerfüllt

?

Das Projekt SOLLTE Dokumentationen in englischer Sprache zur Verfügung stellen und in der Lage sein, Fehlerberichte und Kommentare zum Code in Englisch zu akzeptieren. ^[english]
Englisch ist derzeit die Lingua Franca der Computertechnik; Wenn Englisch unterstützt wird, erhöht das die Anzahl der verschiedenen potenziellen Entwickler und Reviewer weltweit. Ein Projekt kann dieses Kriterium auch dann erfüllen, wenn die Hauptsprache der Kernentwickler nicht Englisch ist.

Criterion [maintained]
Erfüllt

Unerfüllt

?

Das Projekt MUSS gepflegt werden. ^[maintained]
Als Minimum sollte das Projekt versuchen, auf wichtige Problem- und Schwachstellenberichte zu reagieren. Ein Projekt, das aktiv ein Badge anstrebt, wird wahrscheinlich gepflegt. Alle Projekte und Menschen haben begrenzte Ressourcen, und typische Projekte müssen einige vorgeschlagene Änderungen ablehnen, daher deuten begrenzte Ressourcen und Ablehnungen von Vorschlägen allein nicht auf ein ungepflegtes Projekt hin.

Wenn ein Projekt weiß, dass es nicht mehr gepflegt wird, sollte es dieses Kriterium auf "Unerfüllt" setzen und die entsprechenden Mechanismen verwenden, um anderen anzuzeigen, dass es nicht gepflegt wird. Verwenden Sie zum Beispiel "DEPRECATED" als erste Überschrift seiner README, fügen Sie "DEPRECATED" am Anfang seiner Homepage hinzu, fügen Sie "DEPRECATED" am Anfang der Projektbeschreibung seines Code-Repositorys hinzu, fügen Sie ein no-maintenance-intended Badge in seiner README und/oder Homepage hinzu, markieren Sie es als veraltet in allen Paket-Repositories (z. B. npm deprecate) und/oder verwenden Sie das Markierungssystem des Code-Repositorys, um es zu archivieren (z. B. GitHubs "archive"-Einstellung, GitLabs "archived"-Markierung, Gerrits "readonly"-Status oder SourceForges "abandoned"-Projektstatus). Weitere Diskussionen finden Sie hier.

Regular maintenance evidenced on github

Sicherheit 16/16 ●

Wissen über sichere Entwicklungspraktiken
Criterion [know_secure_design]
Erfüllt

Unerfüllt

?
Das Projekt MUSS mindestens einen primären Entwickler haben, der weiß, wie man sichere Software entwerfen kann. (Siehe "Details" für spezifische Anforderungen.) ^{[know_secure_design]}
Dies erfordert das Verständnis der folgenden Designprinzipien, einschließlich der 8 Prinzipien von Saltzer und Schroeder:
- Wirtschaftlichkeit des Mechanismus (halten Sie das Design so einfach und klein wie möglich, z. B. durch umfassende Vereinfachungen)
- Fehlersichere Voreinstellungen (Zugriffsentscheidungen sollten standardmäßig verweigert werden und die Installation der Projekte sollte standardmäßig sicher sein)
- Vollständige Vermittlung (jeder Zugang, der begrenzt werden kann, muss auf Berechtigungen überprüft werden und darf nicht umgangen werden können)
- Offenes Design (Sicherheitsmechanismen sollten nicht von der Unkenntnis der Angreifer über das Designs abhängig gemacht werden, sondern stattdessen auf leichter schützbare und änderbare Informationen wie Schlüssel und Passwörter)
- Trennung von Privilegien (Idealerweise sollte der Zugriff auf wichtige Objekte von mehr als einer Bedingung abhängen, so dass die Beseitigung eines Schutzsystems keinen vollständigen Zugriff ermöglicht. z. B., Multi-Faktor-Authentifizierung wie die Erfordernis eines Passwortes und eines Hardware-Token ist stärker als die Single-Faktor-Authentifizierung)
- So wenige Privilegien wie möglich (Prozesse sollten nur mit den geringsten Privilegien laufen)
- So wenig gemeinsame Mechanismen wie möglich (Das Design sollte die Mechanismen minimieren, die von mehreren Benutzern gemeinsam verwendet werden und von allen Benutzern abhängig sind, z.B. Verzeichnisse für temporäre Dateien)
- Psychologische Akzeptanz (Die menschliche Schnittstelle muss benutzerfreundlich entworfen werden - Design für "geringeste Überraschung" kann dabei helfen)
- Begrenzte Angriffsfläche (die Angriffsfläche - die Menge der verschiedenen Punkte, wo ein Angreifer versuchen kann, Daten einzugeben oder zu extrahieren - sollte begrenzt sein)
- Eingabevalidierung mit Positivliste (Eingaben sollten in der Regel überprüft werden, um festzustellen, ob sie gültig sind, bevor sie akzeptiert werden; diese Validierung sollte Postitivlisten verwenden (die nur bekannte gute Werte akzeptieren), nicht Negativlisten (die versuchen, bekannte schlechte Werte aufzulisten)).
Ein "Primärer Entwickler" in einem Projekt ist jedermann, der mit der Codebasis des Projekts vertraut ist, der in der Lage ist Änderungen daran vorzunehmen und von den meisten anderen Teilnehmern des Projekts als solches anerkannt wird. Ein primärer Entwickler hat üblicherweise im vergangen Jahr eine Reihe von Aufgaben übernommen (Code, Dokumentation oder Beantwortung von Fragen). Die Entwickler würden typischerweise als primäre Entwickler betrachtet, wenn sie das Projekt initiiert haben (und das Projekt nicht vor mehr als drei Jahre verlassen haben), die Möglichkeit haben, Informationen zu Schwachstellen über einen privaten Berichtskanal zu erhalten (falls vorhanden), neuen Code zum Projekt entgegennehmen zu können, oder die endgültige Freigaben der Projektsoftware durchzuführen. Wenn es nur einen Entwickler gibt, ist diese Person der primäre Entwickler. Es gibt viele Bücher und Kurse die Wissen vermitteln,wie sichere Software entwickelt und entworfen werden kann. Zum Beispiel bietet der kostenlose Kurs Secure Software Development Fundamentals drei Module an, die erklären wie man sichere Software entwickelt.
Primary developer Jamie Saker is a senior cybersecurity executive with 30+ years technical hands-on experience with secure networking, infrastructure and code.
Criterion [know_common_errors]
Erfüllt

Unerfüllt

?

Mindestens einer der primären Entwickler des Projekts MUSS über weitläufige Arten von Fehlern, die zu Schwachstellen in dieser Art von Software führen, Bescheid wissen sowie mindestens eine Methode, um jede von ihnen zu beseitigen oder zu mildern. ^{[know_common_errors]}
Beispiele (je nach Art der Software) beinhalten SQL-Injektion, OS-Injektion, klassischer Pufferüberlauf, Cross-Site-Scripting, fehlende Authentifizierung und fehlende Autorisierung. Siehe die CWE/SANS top 25 oder OWASP Top 10 für häufig verwendete Listen. Es gibt viele Bücher und Kurse die Wissen vermitteln,wie sichere Software entwickelt und entworfen werden kann. Zum Beispiel bietet der kostenlose Kurs Secure Software Development Fundamentals drei Module an, die erklären wie man sichere Software entwickelt.

Verwende grundlegend gute kryptographische Praktiken

Beachten Sie, dass einige Software keine kryptographischen Mechanismen verwenden muss. Wenn Ihr Project Software erstellt das (1) kryptographische funktionen einbindet, aktiviert, oder ermöglicht und (2) aus den USA heraus an nicht US-Bürger verteilt wird, dann könnten sie rechtlich zu weiterne Schritten gezwungen sein. Meistens beinhaltet dies lediglich das Senden einer E-Mail. Für mehr Informationen, siehe den Abschnitt zu Encryption in Understanding Open Source Technology & US Export Controls.

Erfüllt

Unerfüllt

N/A

Die vom Projekt entwickelte Software MUSS standardmäßig nur kryptografische Protokolle und Algorithmen verwenden, die öffentlich sind und von Experten überprüft wurden (falls kryptographische Protokolle und Algorithmen verwendet werden). ^{[crypto_published]}

Diese kryptographischen Kriterien gelten nicht immer, da einige Software keine direkten kryptografischen Funktionen benötigt.

All cryptographic implementations use publicly published, expert-reviewed algorithms:

Key Derivation: Argon2id (RFC 9106, winner of Password Hashing Competition 2015)

Parameters: 64MB memory, 4 threads, 32-byte key output

Encryption: AES-256-GCM (NIST FIPS 197 + SP 800-38D)

Authenticated encryption with 12-byte nonce
Go's standard library crypto/aes and crypto/cipher

Random Generation: Go crypto/rand (cryptographically secure)

Timing-Safe Comparison: crypto/subtle.ConstantTimeCompare

TLS: Standard Go crypto/tls (optional, configurable)

No custom or proprietary cryptographic algorithms. See implementations:

pkg/strigoictl/crypto/keystore.go - API key encryption
pkg/session/crypto.go - Session encryption

Erfüllt

Unerfüllt

N/A

Wenn die Software, die durch das Projekt produziert wird, eine Anwendung oder Bibliothek ist, und ihr Hauptzweck nicht die Kryptographie ist, dann SOLLTE sie lediglich Software einbinden, die speziell für kryptographische Funktionen entworfen ist; Sie SOLLTE NICHT eine eigene Implementierung vornehmen. ^{[crypto_call]}

Software does not implement any cryptography of its own and relies on well supported public libraries for the functionality.

Erfüllt

Unerfüllt

N/A

Alle Funktionalitäten in der vom Projekt entwickelten Software, die von Kryptographie abhängigen, MÜSSEN mit FLOSS implementiert werden. ^{[crypto_floss]}

Siehe Open Standards Requirement for Software by the Open Source Initiative.

Erfüllt

Unerfüllt

N/A

Die Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software, MÜSSEN Standard-Keylängen verwenden, die die NIST-Mindestanforderungen bis zum Jahr 2030 erfüllen (wie im Jahr 2012 festgelegt). Es MUSS möglich sein, die Software so zu konfigurieren, dass kürzere Keylängen vollständig deaktiviert werden können. ^{[crypto_keylength]}

Diese minimalen Bitlängen sind: symmetric key 112, factoring modulus 2048, discrete logarithm key 224, discrete logarithmic group 2048, elliptic curve 224, und hash 224 (das Passworthashing ist nicht von dieser Bitlänge abgedeckt, weitere Informationen zum Passworthashing finden sich im crypto_password_storage Kriterium). Siehe https://www.keylength.com für einen Vergleich von Keylängen Empfehlungen von verschiedenen Organisationen. Die Software KANN kleinere Keylängen in einigen Konfigurationen erlauben (idealerweise nicht, da dies Downgrade-Angriffe erlaubt, aber kürzere Keylängen sind manchmal für die Interoperabilität notwendig).

All cryptographic key lengths exceed NIST 2030 minimums:

Algorithm	Our Implementation	NIST 2030 Minimum	Status
Symmetric (AES)	256-bit	112-bit	✅ 2.3x minimum
Key Derivation (Argon2id)	256-bit output	N/A (password hashing)	✅
GCM Nonce	96-bit	Standard	✅
Salt	128-256 bit	N/A	✅

Hardcoded, not configurable to weaker values:
// pkg/strigoictl/crypto/keystore.go
argon2KeyLen = 32 // AES-256 (256 bits) - hardcoded constant

// pkg/session/crypto.go
KeyLen: 32 // AES-256 - in DefaultCryptoConfig()

No downgrade path: Key lengths are defined as constants, not user-configurable. There is no option to use AES-128 or smaller keys. The only configurable parameters
are Argon2 work factors (time/memory/threads), which affect security strength, not key length.

See: pkg/strigoictl/crypto/keystore.go:40-41, pkg/session/crypto.go:24

Erfüllt

Unerfüllt

N/A

Die Standard-Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software DÜRFEN NICHT von defekten kryptographischen Algorithmen abhängen (z.B. MD4, MD5, Single DES, RC4, Dual_EC_DRBG) oder Chiffre-Modi verwenden, die dem Kontext unangemessen sind, außer sie sind notwendig, um kompatible Protokolle bereitzustellen (wenn das Protokoll in der neusten Version in der Zielumgebung zum Einsatz kommt, die Zielumgebung solch ein Protokoll erfordert und das Zielsystem keine sicherere Alternative anbietet). Die Dokumentation MUSS auf jegliche Sicherheitsrisiken hinweisen und bekannte Vorsichtsmaßnahmen beschreiben, sollten unsichere Protokolle unumgäglich sein. ^{[crypto_working]}

Der EZB-Modus ist fast nie angemessen, da er identische Blöcke innerhalb des Geheimtextes aufdeckt, wie der ECB-Pinguin zeigt. Der CTR-Modus ist oft unangemessen, da er keine Authentifizierung durchführt und Duplikate verursacht, wenn eine Eingabe wiederholt wird. In vielen Fällen ist es am besten, einen Block-Chiffre-Algorithmus-Modus zu wählen, der entworfen wurde, um Geheimhaltung und Authentifizierung zu kombinieren, z.B. Galois/ Counter Mode (GCM) und EAX. Projekte KÖNNTEN Benutzern erlauben, defekte Mechanismen zu ermöglichen (z. B. während der Einrichtung), falls nötig für Kompatibilität, aber dann wissen die Benutzer, dass sie es tun.

No broken algorithms used:

❌ MD4, MD5, DES, RC4, Dual_EC_DRBG - None used
❌ ECB mode - Not used
❌ Unauthenticated CTR mode - Not used

Only secure algorithms/modes:

✅ AES-256-GCM (authenticated encryption, as recommended)
✅ Argon2id (modern password hashing)
✅ crypto/rand (secure PRNG)

Cipher mode verification:
$ grep -E "NewGCM|NewCBC|NewECB|NewCTR" pkg/ cmd/ --include="*.go"

Only NewGCM found (4 occurrences in crypto.go and keystore.go)

Note on MD5 reference: One struct field (Checksums map[string]string // md5, sha256) exists in protocol/layers.go for optional integrity metadata from external
sources - this is not a security mechanism, just a data container. No MD5 hashing is performed by the project.

All encryption uses GCM mode which combines secrecy and authentication as recommended.

Erfüllt

Unerfüllt

N/A

Die Standard-Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software SOLLTEN NICHT nicht von kryptographischen Algorithmen oder Modi mit bekannten schweren Schwächen abhängen (z.B. SHA-1-Kryptographie-Hash-Algorithmus oder CBC-Modus in SSH). ^{[crypto_weaknesses]}

Sorgen über den CBC-Modus in SSH werden in CERT: SSH CBC vulnerability erläutert.

No weak algorithms or modes used:

❌ SHA-1 - Not used anywhere
❌ CBC mode - Not used (only GCM)
❌ MD5 for security - Not used

Only strong algorithms:

✅ SHA-256 for hashing (HMAC-SHA256, integrity checks)
✅ AES-256-GCM for encryption
✅ Argon2id for password hashing

Verification:
$ grep -riE "sha1|SHA1|NewCBC" pkg/ cmd/ internal/ --include="*.go"

No results

$ grep -r "sha256" pkg/ --include="*.go" | wc -l

14 occurrences - all SHA-256

All cryptographic operations use modern, well-reviewed algorithms without known serious weaknesses.

Erfüllt

Unerfüllt

N/A

Die Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software SOLLTEN Perfect Forward Secrecy für wichtige Vereinbarungsprotokolle implementieren, so dass ein Sitzungsschlüssel, der aus einer Reihe von Langzeitschlüsseln abgeleitet wird, nicht beeinträchtigt werden kann, wenn einer der Langzeitschlüssel in der Zukunft kompromittiert wird. ^[crypto_pfs]

TLS Communications: The project uses Go's standard crypto/tls library with default configuration. Go 1.17+ (project requires Go 1.25+) defaults to:

TLS 1.2 and TLS 1.3 with ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) cipher suites
All default cipher suites provide PFS via ephemeral key exchange
No custom CipherSuites configured that would disable PFS

Verification:
$ grep -r "CipherSuites" pkg/ cmd/ --include="*.go"

No custom cipher suite configuration found

Go's default TLS cipher suites (as of Go 1.25):

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ✅ PFS
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ✅ PFS
TLS_CHACHA20_POLY1305_SHA256 (TLS 1.3) ✅ PFS

Local encryption: Uses Argon2id key derivation (not a key exchange protocol, so PFS not applicable). Each encryption operation uses unique salt/nonce preventing key
reuse.

See: pkg/a2a/protocol.go, pkg/a2a/bridge.go

Erfüllt

Unerfüllt

N/A

Wenn die vom Projekt erzeugte Software Passwörter für die Authentifizierung von externen Benutzern speichert, MÜSSEN die Passwörter als iterierte Hashes mit einem per-User-Salt unter Verwendung eines Key-Stretching (iterierten) Algorithmus (z.B. Argon2id, Bcrypt, Scrypt, or PBKDF2). Siehe auch OWASP Password Storage Cheat Sheet). ^{[crypto_password_storage]}

Dieses Kriterium gilt nur, wenn die Software die Authentifizierung von externan Benutzern mit Passwörtern erzwingt (inbound authentication), wie z. B. bei serverseitigen Webanwendungen. Es gilt nicht in Fällen, in denen die Software Kennwörter für die Authentifizierung in andere Systeme speichert (outbound authentication, z. B. die Software implementiert einen Client für ein anderes System), da zumindest Teile dieser Software oft Zugriff auf das Passwort im Klartext haben müssen.

Strigoi does not store passwords for external user authentication. The project is a security assessment CLI tool, not a multi-user web application.

Authentication model:

Agent authentication: Uses PSK (pre-shared key) and HMAC-SHA256 signatures, not passwords
API key storage: Uses Argon2id encryption for outbound authentication (storing keys to connect TO external services like OpenAI, Gemini) - this is explicitly
excluded by the criterion
Session encryption: Passphrase-derived keys using Argon2id for local file encryption

No inbound user authentication:

No user registration/login system
No user database
No password hashing for user accounts

If password storage were added in the future: The existing Argon2id infrastructure (pkg/strigoictl/crypto/keystore.go, pkg/session/crypto.go) would be used, which
already implements iterated hashing with per-user salt as required by OWASP guidelines.

Erfüllt

Unerfüllt

N/A

Die Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software MÜSSEN alle kryptographischen Schlüssel und Nonces mit einem kryptographisch sicheren Zufallszahlengenerator erzeugen und DÜRFEN NICHT mit Generatoren arbeiten, die kryptographisch unsicher sind. ^{[crypto_random]}

Ein kryptographisch sicherer Zufallszahlengenerator kann ein Hardware-Zufallszahlengenerator sein oder es kann ein kryptographisch sicherer Pseudozufallszahlengenerator (CSPRNG) sein, der einen Algorithmus wie Hash_DRBG, HMAC_DRBG, CTR_DRBG, Yarrow oder Fortuna verwendet. Beispiele für Aufrufe von sicheren Zufallszahlengeneratoren umfassen Javas java.security.SecureRandom und JavaScripts window.crypto.getRandomValues. Beispiele für Anrufe von unsicheren Zufallszahlengeneratoren sind Javas java.util.Random und JavaScripts Math.random.

All cryptographic key and nonce generation uses Go's crypto/rand (CSPRNG):

Security-critical code uses crypto/rand exclusively:
// pkg/strigoictl/crypto/keystore.go
import "crypto/rand"
rand.Read(salt) // Salt generation
rand.Read(nonce) // Nonce generation

// pkg/session/crypto.go
io.ReadFull(rand.Reader, salt)
io.ReadFull(rand.Reader, nonce)

// pkg/a2a/auth.go
ed25519.GenerateKey(rand.Reader) // Key pair generation
rand.Read(psk) // PSK generation

// pkg/security/auth.go
rand.Read(pskBytes) // Authentication key generation

math/rand usage is non-security only:

pkg/logging/txcontext.go - Transaction IDs for log tracing
cmd/traffic-simulator/ - Test traffic generation
cmd/test.go - Test files

Go's crypto/rand uses the operating system's CSPRNG (getrandom() on Linux, CryptGenRandom on Windows) which meets NIST SP 800-90A requirements.

Gesicherte Zustellung gegen Man-in-the-Middle-/MITM-Angriffe
Criterion [delivery_mitm]
Erfüllt

Unerfüllt

?

Das Projekt MUSS einen Auslieferungsmechanismus verwenden, der den MITM-Angriffen entgegenwirkt. Die Verwendung von https oder ssh + scp ist akzeptabel. ^{[delivery_mitm]}
Ein noch stärkerer Mechanismus ist die Freigabe der Software mit digital signierten Paketen, da dies Angriffe auf das Verteilungssystem verringert, aber das funktioniert nur, wenn die Benutzer sicher sein können, dass die öffentlichen Schlüssel für Signaturen korrekt sind und wenn die Benutzer die Signatur tatsächlich überprüfen.
Primary delivery via HTTPS:
- GitHub Releases: https://github.com/macawi-ai/strigoi/releases (TLS 1.3)
- Source clone: git clone https://github.com/macawi-ai/strigoi.git
- Container images: ghcr.io/macawi-ai/ (HTTPS registry)
Integrity verification provided:
- SHA256 checksums published with each release (checksums.txt)
- Git commit signatures available
- Container image digests via GHCR
The irony:
Strigoi is literally a security assessment platform that detects MITM attacks, credential exposure, and TLS misconfigurations in AI/LLM systems. The tool includes:
- TLS verification scanning (pkg/security/mcp_scanner.go)
- Credential leak detection (17+ patterns)
- Stream Tap for real-time STDIO security monitoring
We practice what we preach. Be curious if anyone reads this deep - if so, reach out to jamie.saker@macawi.ai and I'll even offer a free tool walkthru if interested :)
Criterion [delivery_unsigned]
Erfüllt

Unerfüllt

?

Ein kryptographischer Hash (z.B. sha1sum) DARF NICHT über http abgerufen und ohne Überprüfung einer kryptographischen Signatur verwendet werden. ^{[delivery_unsigned]}
Diese Hashes könnten bei der Übermittlung verändert werden.
All checksums delivered via HTTPS:
- checksums.txt is published on GitHub Releases at https://github.com/macawi-ai/strigoi/releases
- GitHub enforces TLS 1.2+ for all connections
- No HTTP endpoints exist for checksum retrieval
Verification instructions in README use HTTPS:
wget https://github.com/macawi-ai/strigoi/releases/download/v1.0.0/checksums.txt
sha256sum -c checksums.txt

Additional integrity mechanisms:
- Git tags are used for releases (cryptographically linked to commit history)
- Container images use content-addressable digests via GHCR
- GitHub's infrastructure provides additional transport security guarantees
No retrieval of cryptographic hashes over unencrypted HTTP.
Öffentlich bekannte Schwachstellen wurden behoben

Criterion [vulnerabilities_fixed_60_days]
Erfüllt

Unerfüllt

?

Es DARF KEINE ungepatchte Schwachstelle von mittlerer oder höherer Schwere enthalten sein, die seit mehr als 60 Tagen öffentlich bekannt ist. ^{[vulnerabilities_fixed_60_days]}
Die Sicherheitslücke muss vom Projekt selbst gepatched und freigegeben werden (Patches dürfen woanders entwickelt werden). Eine Sicherheitsücke wird (für diesen Zweck) öffentlich bekannt, sobald es einen CVE mit öffentlich freigegebenen, nicht bezahlten Informationen hat (veröffentlicht beispielsweise in der National Vulnerability Database) oder wenn das Projekt informiert und die Informationen der Öffentlichkeit zugänglich gemacht wurden (evtl. durch das Projekt). Eine Sicherheitslücke ist hat einen mittlerem oder höheren Schweregrad, wenn ihr Common Vulnerability Scoring System (CVSS) Basis-Score 4 oder höher ist. In CVSS Versionen 2.0 bis 3.1 entspricht dies einem CVSS score von 4.0 oder höher. Projekte können einen CVSS Score der in einer viel verwendeten Schwachstellendatenbank (wie z.B. National Vulnerability Database) verwenden, wenn der Score entsprechend der aktuellsten CVSS Version in der Datenbank gelistet ist. Projekte können stattdessen den Schweregrad selbst berechnen, indem sie die neuste Version der CVSS zum Zeitpunkt der Schwachstellenmeldung verwendend, wenn die Eingaben für die Berechnung veröffentlicht werden sobald die Schwachstelle öffentlich bekannt gegeben wurde. Hinweis: Das bedeutet, dass Benutzer bis zu 60 Tage für alle Angreifer weltweit anfällig bleiben können. Dieses Kriterium ist oft viel einfacher zu treffen als das, was Google empfiehlt in Rebooting responsible disclosure, weil Google empfiehlt, dass die 60-Tage-Periode beginnen, wenn das Projekt benachrichtigt wird, selbst dann, wenn der Bericht nicht öffentlich ist. Beachten Sie auch, dass dieses Badge-Kriterium, wie andere Kriterien, auf einzelne Projekte zutrifft. Manche Projekte sind teil einer größeren Organisation oder eines größeren Projektes, möglicherweise als Teil mehrer Lagen, und manche Projekte füttern ihre Ergebnisse an andere Organisationen oder Projekte als teil einer möglicherweisen komplexen Lieferkette. Daher fokussieren wir uns auf die Antwortzeit einzelner Projekte. Wenn ein Projekt einen Patch bereitgestellt hat können andere entscheiden wie sie damit umgehen möchten (z. B. können sie auf eine neue Version upgraden oder nur einzelne Patches auswählen und einspielen).

Criterion [vulnerabilities_critical_fixed]
Erfüllt

Unerfüllt

?

Projekte SOLLTEN alle kritischen Schwachstellen schnell beheben, nachdem sie gemeldet wurden. ^{[vulnerabilities_critical_fixed]}
Andere Sicherheitsissues
Criterion [no_leaked_credentials]
Erfüllt

Unerfüllt

?

Die öffentlichen Repositorys DÜRFEN NICHT gültige private Zugriffsdaten enthalten (z. B. ein funktionierendes Passwort oder einen privaten Schlüssel), die den öffentlichen Zugriff einschränken sollen. ^{[no_leaked_credentials]}
Ein Projekt DARF "Beispiel"-Zugriffsdaten für Tests und unwichtige Datenbanken herausgeben, solange sie nicht den öffentlichen Zugang einschränken sollen.
No valid private credentials in repository:

Scanned and verified clean:
- No AWS keys (AKIA...), GitHub tokens (ghp_), OpenAI keys (sk-...)
- No private keys (RSA, EC, SSH, OPENSSH)
- No hardcoded passwords for production systems
What exists (all safe):
- Detection patterns in modules/probe/ - regex patterns for finding credentials (the scanner's job)
- Key generation scripts - openssl rand -hex 16 generates new random keys at deploy time
- Local dev paths - .env contains only DATABASE_URL=./sqlite.db
Intentional test fixtures (permitted):
- examples/insecure-mcps/ contains intentionally vulnerable MCPs for testing
- Clearly documented as test targets, not production credentials
- Criterion explicitly allows "sample credentials for testing"
Preventive measures:
- .gitignore excludes: .env, .env.local, nkeys/*.txt
- Keystore encrypts API keys with Argon2id before storage
- gosec linter enabled to detect credential patterns

Analyse 8/8 ●

Statische Codeanalyse

Erfüllt

Unerfüllt

N/A

Mindestens ein Tool zur Analyse statischer Codes (über Compiler-Warnungen und "sichere" Sprachmodi hinaus) MUSS vor der Veröffentlichung auf jede vorgeschlagene größere Produktionsversion der Software angewendet werden, wenn mindestens ein FLOSS-Tool dieses Kriterium in der ausgewählten Sprache implementiert. ^{[static_analysis]}

Ein Tool zur statischen Codeanalyse untersucht den Softwarecode (als Quellcode, Zwischencode oder ausführbare Datei), ohne ihn mit bestimmten Eingaben auszuführen. Für dieses Kriterium zählen Compilerwarnungen und "sichere" Sprachmodi nicht als statische Codeanalyse-Tools (diese vermeiden typischerweise eine tiefgreifende Analyse, da Geschwindigkeit entscheidend ist). Manche statischen Codeanalyse-Tools spezialisieren sich auf das Auffinden von generischen Defekten, andere spezialisieren sich auf das Finden von bestimmte Arten von Defekten (z.B. Schwachstellen) und manche können beides. Beispiele für solche Tools zur statischen Codeanalyse sind cppcheck (C, C++), clang static analyzer (C, C++), SpotBugs (Java), FindBugs (Java) (including FindSecurityBugs), PMD (Java), Brakeman (Ruby on Rails), lintr (R), goodpractice (R), Coverity Quality Analyzer, SonarQube, Codacy, und HP Enterprise Fortify Static Code Analyzer.. Mehr Tools finden Sie beispielsweise in der Wikipedia-Liste von Tools zur statischen Codeanalyse, OWASP Informationen zur statischen Code-Analyse , NIST-Liste der Quellcode-Sicherheitsanalyse-Tools und Wheelers Liste der statischen Analyse-Tools. Das SWAMP ist eine kostenlose Plattform zur Bewertung von Schwachstellen in Software mit einer Vielzahl von Tools. Wenn für die verwendete(n) Implementierungssprache(n) keine statischen FLOSS-Analysewerkzeuge verfügbar sind, wählen Sie "N/V".

Multiple static analysis tools applied before every release:

golangci-lint (meta-linter with 11+ analyzers):

staticcheck - advanced static analysis
gosec - security vulnerability detection
govet - Go vet checks
ineffassign, unused, typecheck, etc.
Run via make lint and in CI

gosec (dedicated security scanner):

Standalone run via make security
Separate CI step using securego/gosec@master action
Checks for: SQL injection, command injection, hardcoded credentials, weak crypto, etc.

Release process requires static analysis:
release: clean lint security test build # All must pass
ci: deps lint security test-coverage test-race build

CI enforcement:

GitHub Actions runs golangci-lint and gosec on every push/PR
Builds blocked if static analysis fails
Results logged for review

See: .github/workflows/strigoi-v1rc1-ci.yml, Makefile, .golangci.yml

Erfüllt

Unerfüllt

N/A

Es wird davon ausgegangen, dass mindestens eines der statischen Analysewerkzeuge, die für das statische Analysekriterium verwendet wurde, Regeln oder Ansätze einschließt, um nach häufigen Schwachstellen in der analysierten Sprache oder Umgebung zu suchen. ^{[static_analysis_common_vulnerabilities]}

Statische Analysetools, die speziell dafür entwickelt wurden, nach Schwachstellen zu suchen, finden diese eher. Das heißt, dass die Verwendung von statischen Tools in der Regel helfen wird einige Probleme zu finden. Wir schlagen dies vor, aber erwarten es für das "passing" -Level-Badge nicht.

gosec is specifically designed to detect common vulnerabilities:

Vulnerability categories checked:

G101: Hardcoded credentials
G102: Bind to all interfaces
G103: Unsafe block usage
G104: Unhandled errors
G107: SSRF via variable URL
G108: Profiling endpoint exposure
G201-G203: SQL injection
G301-G307: File permission issues
G401-G404: Weak cryptography
G501-G505: Blocklisted imports
G601: Implicit memory aliasing

Mapped to common vulnerability standards:

OWASP Top 10 coverage
CWE (Common Weakness Enumeration) mappings
SANS Top 25 alignment

Integration:

.github/workflows/strigoi-v1rc1-ci.yml

uses: securego/gosec@master
with:
args: '-no-fail -fmt json -out gosec-results.json ./...'

Additionally, golangci-lint includes staticcheck which detects correctness issues that could lead to vulnerabilities.

See: https://github.com/securego/gosec

Erfüllt

Unerfüllt

N/A

Alle mittel- und höhergradig ausnutzbaren Schwachstellen, die mit statischer Codeanalyse entdeckt wurden, MÜSSEN nach der Entdeckung rechtzeitig behoben werden. ^{[static_analysis_fixed]}

Eine Sicherheitslücke ist hat einen mittlerem oder höheren Schweregrad, wenn ihr Common Vulnerability Scoring System (CVSS) Basis-Score 4 oder höher ist. In CVSS Versionen 2.0 bis 3.1 entspricht dies einem CVSS score von 4.0 oder höher. Projekte können einen CVSS Score der in einer viel verwendeten Schwachstellendatenbank (wie z.B. National Vulnerability Database) verwenden, wenn der Score entsprechend der aktuellsten CVSS Version in der Datenbank gelistet ist. Projekte können stattdessen den Schweregrad selbst berechnen, indem sie die neuste Version der CVSS zum Zeitpunkt der Schwachstellenmeldung verwendend, wenn die Eingaben für die Berechnung veröffentlicht werden sobald die Schwachstelle öffentlich bekannt gegeben wurde. Beachten Sie, dass das Kriterium vulnerabilities_fixed_60_days verlangt, dass alle diese Schwachstellen innerhalb 60 Tagen nach Bekanntgabe gefixt werden.

Current status: All confirmed exploitable medium+ vulnerabilities addressed.

Current gosec findings (62 medium+) are documented exclusions or false positives:

Rule	Count	Status
G115 (integer overflow)	41	Excluded - Go type conversions for array/slice lengths
G304 (file path taint)	9	Intentional - security scanner must read user-specified files
G204 (subprocess variable)	4	Intentional - scanner executes commands by design
G302/G301 (permissions)	7	Non-exploitable - internal config directories
G404 (weak random)	1	Excluded - used in non-security logging context

Evidence of timely fixes (git history):
8586a44 fix: resolve all gosec, unused, and code quality issues
5797609 fix: resolve all 10 golangci-lint issues for clean CI
f533dd1 fix: resolve all remaining linting issues for Go 1.25 compliance

Exclusions documented in .golangci.yml:
gosec:
excludes: [G104, G115, G402, G404] # With justification comments

No CVEs: Zero CVE-assigned vulnerabilities in project history.

Erfüllt

Unerfüllt

N/A

Es wird EMPFOHLEN, dass eine statische Quellcode-Analyse bei jedem Commit oder zumindest täglich ausgeführt wird. ^{[static_analysis_often]}

Dynamische Codeanalyse
Criterion [dynamic_analysis]
Erfüllt

Unerfüllt

?

Es ist EMPFHOLEN, dass mindestens ein dynamisches Analyse-Tool auf jede vorgeschlagene größere Veröffentlichung der Software vor seiner Freigabe angewendet wird. ^{[dynamic_analysis]}
Ein dynamisches Analyse-Tool untersucht die Software, indem es sie mit bestimmten Eingaben ausführt. Beispielsweise DARF das Projekt ein Fuzzing-Tool verwenden (z.B. American Fuzzy Lop) oder einen Web Application Scanner (z.B. OWASP ZAP oder w3af). In einigen Fällen ist das OSS-Fuzz Projekt bereit, Fuzz-Tests auf Ihr Projekt anzuwenden. Für die Zwecke dieses Kriteriums muss das dynamische Analyse-Tool die Eingaben in irgendeiner Weise variieren, um nach verschiedenen Arten von Problemen zu suchen oder eine automatisierte Test-Suite mit mindestens 80% Zweig-Abdeckung sein. Die Englische Wikipedia-Seite zur dynamischen Analysen und die OWASP Seite über Fuzzing nennen einige dynamische Analyse-Tools. Das Analyse-Tool(s) DARF für der Suche nach Sicherheitslücken eingesetzt werden, aber das ist nicht erforderlich.
Dynamic analysis tools applied before releases:
1. Go Race Detector (ThreadSanitizer-based):
- Instruments code at runtime to detect data races
- Run via go test -race in CI on every push/PR
- Applied to all packages: ./cmd/... ./pkg/... ./internal/...
CI workflow

run: go test -v -race -short -timeout=10m -coverprofile=coverage.out ./...
1. Automated Test Suite with Coverage:
- Unit and integration tests executed on every build
- Coverage tracked and reported via Codecov
- make test-coverage generates HTML coverage reports
- CI enforces minimum coverage threshold
1. Release gate (make ci):
  ci: deps lint security test-coverage test-race build
  All dynamic analysis must pass before builds succeed.
Evidence of effectiveness:
a25b207 Phase 3.1 Complete: ZERO Race Conditions Found! 🎉
a3ed353 Fix CrossSessionChecker deadlock with read-lock optimization
2ee9653 fix: Add comprehensive mutex protection to SessionManager

Race detector has caught and helped fix real concurrency bugs.
Criterion [dynamic_analysis_unsafe]
Erfüllt

Unerfüllt

N/A

?

Es ist EMPFHOLEN, dass die vom Projekt entwickelte Software, falls sie Software von einer Speicher-unsicheren Sprache (z. B. C oder C ++) enthält, regelmäßig mindestens ein dynamisches Werkzeug (z.B. ein Fuzzer oder ein Web-Anwendungs-Scanner) in Kombination mit einem Mechanismus zur Erkennung von Speichersicherheitsproblemen wie Puffer-Overwrites verwendet. Wenn das Projekt keine Software entwickelt, die in einer Speicher-unsicheren Sprache geschrieben ist, wählen Sie "nicht anwendbar" (N/A). ^{[dynamic_analysis_unsafe]}
Beispiele für Mechanismen zur Erkennung von Arbeitsspeicher Sicherheitsproblemen sind Adresse Sanitizer (ASAN) (verfügbar in GCC und LLVM), Memory Sanitizer und valgrind. Andere möglicherweise verwendete Werkzeuge sind Thread Sanitizer und Undefined Behavior Sanitizer. Weit verbreitete Assertions würden auch funktionieren.
Primary language: Go
- Garbage collected
- Bounds-checked array/slice access
- No pointer arithmetic
- No manual memory allocation/deallocation
- No buffer overflow vulnerabilities by design
Supporting languages (also memory-safe):
- Python (A2MCP agents)
- Shell scripts (deployment/build)
- YAML/JSON (configuration)
No C/C++ code in the project.

Go's memory safety is why we chose it - eliminates entire vulnerability classes (CWE-119, CWE-120, CWE-122, CWE-125, CWE-787) that plague C/C++ security tools.

Note: Go's race detector (used in CI) provides similar runtime instrumentation benefits for concurrency safety.
Criterion [dynamic_analysis_enable_assertions]
Erfüllt

Unerfüllt

?

Es ist EMPFHOLEN, dass das Projekt eine Konfigurations benutzt, die zumindest etwas dynamischen Analyse nutzt (wie z.B. testing oder fuzzing), welche Assertions erlauben. In vielen Fällen sollten diese Assertions nicht in Production Builds aktiviert sein. ^{[dynamic_analysis_enable_assertions]}
Dieses Kriterium schlägt nicht vor, Assertions in der Produktionsumgebung zu aktivieren; das liegt ganz beim Projekt und seinen Benutzern. Stattdessen liegt der Fokus dieses Kriteriums darauf, die Fehlererkennung während der dynamischen Analyse vor der Bereitstellung zu verbessern. Das Aktivieren von Assertions im Produktionseinsatz unterscheidet sich völlig vom Aktivieren von Assertions während der dynamischen Analyse (wie z.B. Tests). In einigen Fällen ist das Aktivieren von Assertions im Produktionseinsatz äußerst unklug (insbesondere bei hochintegren Komponenten). Es gibt viele Argumente gegen das Aktivieren von Assertions in der Produktion, z.B. sollten Bibliotheken keine Aufrufer zum Absturz bringen, ihre Anwesenheit kann zur Ablehnung durch App Stores führen und/oder das Auslösen einer Assertion in der Produktion kann private Daten wie private Schlüssel offenlegen. Beachten Sie, dass in vielen Linux-Distributionen NDEBUG nicht definiert ist, sodass C/C++ assert() standardmäßig für die Produktion in diesen Umgebungen aktiviert wird. Es kann wichtig sein, einen anderen Assertion-Mechanismus zu verwenden oder NDEBUG für die Produktion in diesen Umgebungen zu definieren.
Race detector enabled during dynamic analysis (testing), disabled in production:

Makefile - test mode with assertions

test-race:
go test -short -race ./cmd/strigoi ./pkg/... ./internal/...

CI runs with race detector

run: go test -v -race -short -timeout=10m ./...

Go's race detector acts as runtime assertions:
- Instruments memory access patterns at runtime
- Detects data races, deadlocks, and synchronization bugs
- Panics (asserts) on any detected race condition
- Only enabled via -race flag during testing
- Not included in production binaries
Test assertions used throughout:
- t.Fatal(err) - Stops test on invariant violation
- t.Error() - Records assertion failure
- t.Errorf() - Records formatted assertion failure
- Bounds checking panics in test scenarios
Production builds:
build:
go build -o strigoi ./cmd/strigoi # No -race flag

This follows the criterion's recommendation: assertions enabled during analysis, disabled in production.
Criterion [dynamic_analysis_fixed]
Erfüllt

Unerfüllt

N/A

?

Alle mittel- und höhergradig ausnutzbaren Schwachstellen, die mit dynamischer Codeanalyse entdeckt werden, MÜSSEN zügig behoben werden, nachdem sie bestätigt wurden. ^{[dynamic_analysis_fixed]}
Wenn Sie keine dynamische Codeanalyse ausführen und somit keine Schwachstellen auf diese Weise finden, wählen Sie "nicht anwendbar" (N/A). Eine Sicherheitslücke ist hat einen mittlerem oder höheren Schweregrad, wenn ihr Common Vulnerability Scoring System (CVSS) Basis-Score 4 oder höher ist. In CVSS Versionen 2.0 bis 3.1 entspricht dies einem CVSS score von 4.0 oder höher. Projekte können einen CVSS Score der in einer viel verwendeten Schwachstellendatenbank (wie z.B. National Vulnerability Database) verwenden, wenn der Score entsprechend der aktuellsten CVSS Version in der Datenbank gelistet ist. Projekte können stattdessen den Schweregrad selbst berechnen, indem sie die neuste Version der CVSS zum Zeitpunkt der Schwachstellenmeldung verwendend, wenn die Eingaben für die Berechnung veröffentlicht werden sobald die Schwachstelle öffentlich bekannt gegeben wurde.
Dynamic analysis IS performed, and all discovered issues have been fixed:

Race detector findings - all fixed:
a3ed353 Fix CrossSessionChecker deadlock with read-lock optimization
2ee9653 fix: Add comprehensive mutex protection to SessionManager
99183df fix(concurrency): Eliminate race conditions in coordinator and load tester
a25b207 Phase 3.1 Complete: ZERO Race Conditions Found! 🎉

Current status:
- Race detector runs on every CI build
- Zero race conditions currently detected
- All historically detected races were fixed within days of discovery
No CVE-assigned vulnerabilities discovered through dynamic analysis.

If N/A is selected, context:
While dynamic analysis (race detector, test suite) is actively used, no exploitable security vulnerabilities with CVSS 4.0+ have been discovered through these
methods. The race conditions found were correctness/reliability issues, not security vulnerabilities with CVSS scores. Therefore N/A is technically accurate - no
medium+ security vulnerabilities to fix.

Diese Daten sind unter der Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0) verfügbar. Dies bedeutet, dass ein Datenempfänger die Daten mit oder ohne Änderungen weitergeben darf, solange der Datenempfänger den Text dieser Vereinbarung mit den weitergegebenen Daten zur Verfügung stellt. Bitte nennen Sie Macawi AI und die OpenSSF Best Practices Badge-Mitwirkenden als Urheber.

Strigoi

Grundlagen 13/13 ●

Allgemein

Grundlegende Informationen auf der Projektwebseite

FLOSS-Lizenz

Dokumentation

Andere

Verbesserungs-/Nacharbeits-Kontrolle 9/9 ●

Öffentliches Versionskontroll-Source-Repository

Einzigartige Versionsnummerierung

Versionshinweise

Berichterstattung 8/8 ●

Bug-Report-Prozess

Anfälligkeits-Prozessbericht

Qualität 13/13 ●

Produktivsystem

Automatisierte Test-Suite

Neue Funktionalitätsüberprüfung

Warnhinweise

Sicherheit 16/16 ●

Wissen über sichere Entwicklungspraktiken

Verwende grundlegend gute kryptographische Praktiken

Only NewGCM found (4 occurrences in crypto.go and keystore.go)

No results

14 occurrences - all SHA-256

No custom cipher suite configuration found

Gesicherte Zustellung gegen Man-in-the-Middle-/MITM-Angriffe

Öffentlich bekannte Schwachstellen wurden behoben

Andere Sicherheitsissues

Analyse 8/8 ●

Statische Codeanalyse

.github/workflows/strigoi-v1rc1-ci.yml

Dynamische Codeanalyse

CI workflow

Makefile - test mode with assertions

CI runs with race detector