sentinel

Projects that follow the best practices below can voluntarily self-certify and show that they've achieved an Open Source Security Foundation (OpenSSF) best practices badge.

There is no set of practices that can guarantee that software will never have defects or vulnerabilities; even formal methods can fail if the specifications or assumptions are wrong. Nor is there any set of practices that can guarantee that a project will sustain a healthy and well-functioning development community. However, following best practices can help improve the results of projects. For example, some practices enable multi-person review before release, which can both help find otherwise hard-to-find technical vulnerabilities and help build trust and a desire for repeated interaction among developers from different companies. To earn a badge, all MUST and MUST NOT criteria must be met, all SHOULD criteria must be met OR be unmet with justification, and all SUGGESTED criteria must be met OR unmet (we want them considered at least). If you want to enter justification text as a generic comment, instead of being a rationale that the situation is acceptable, start the text block with '//' followed by a space. Feedback is welcome via the GitHub site as issues or pull requests There is also a mailing list for general discussion.

We gladly provide the information in several locales, however, if there is any conflict or inconsistency between the translations, the English version is the authoritative version.
If this is your project, please show your badge status on your project page! The badge status looks like this: Badge level for project 14063 is passing Here is how to embed it:
You can show your badge status by embedding this in your markdown file:
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/14063/badge)](https://www.bestpractices.dev/projects/14063)
or by embedding this in your HTML:
<a href="https://www.bestpractices.dev/projects/14063"><img src="https://www.bestpractices.dev/projects/14063/badge"></a>


These are the Silver level criteria. You can also view the Passing or Gold level criteria.

Baseline Series: Baseline Level 1 Baseline Level 2 Baseline Level 3

        

 Basics 16/17 ●

  • General

    Note that other projects may use the same name.

    The security update management platform for SUSE and openSUSE Linux distributions

    Please use SPDX license expression format; examples include "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "GPL-2.0+", "LGPL-3.0+", "MIT", and "(BSD-2-Clause OR Ruby)". Do not include single quotes or double quotes.
    If there is more than one language, list them as comma-separated values (spaces optional) and sort them from most to least used. If there is a long list, please list at least the first three most common ones. If there is no language (e.g., this is a documentation-only or test-only project), use the single character "-". Please use a conventional capitalization for each language, e.g., "JavaScript".
    The Common Platform Enumeration (CPE) is a structured naming scheme for information technology systems, software, and packages. It is used in a number of systems and databases when reporting vulnerabilities.

  • Prerequisites


    Enough for a badge!

    The project MUST achieve a passing level badge. [achieve_passing]

  • Basic project website content


    Enough for a badge!

    The information on how to contribute MUST include the requirements for acceptable contributions (e.g., a reference to any required coding standard). (URL required) [contribution_requirements]

    CONTRIBUTING.md (https://github.com/StayPirate/sentinel/blob/master/CONTRIBUTING.md) documents requirements for acceptable contributions including: code style standards (ruff format, ruff check, mypy --strict), commit message format (Conventional Commits), testing requirements (all changes must include tests), the specs-first workflow, PR process (title format, issue linkage, required CI checks), and a table specifying which types of changes require a specification.


  • Project oversight


    Barely enough for a badge.

    The project SHOULD have a legal mechanism where all developers of non-trivial amounts of project software assert that they are legally authorized to make these contributions. The most common and easily-implemented approach for doing this is by using a Developer Certificate of Origin (DCO), where users add "signed-off-by" in their commits and the project links to the DCO website. However, this MAY be implemented as a Contributor License Agreement (CLA), or other legal mechanism. (URL required) [dco]
    The DCO is the recommended mechanism because it's easy to implement, tracked in the source code, and git directly supports a "signed-off" feature using "commit -s". To be most effective it is best if the project documentation explains what "signed-off" means for that project. A CLA is a legal agreement that defines the terms under which intellectual works have been licensed to an organization or project. A contributor assignment agreement (CAA) is a legal agreement that transfers rights in an intellectual work to another party; projects are not required to have CAAs, since having CAA increases the risk that potential contributors will not contribute, especially if the receiver is a for-profit organization. The Apache Software Foundation CLAs (the individual contributor license and the corporate CLA) are examples of CLAs, for projects which determine that the risks of these kinds of CLAs to the project are less than their benefits.

    The project does not currently require a DCO (Developer Certificate of Origin) sign-off, CLA, or other legal mechanism asserting contributors are authorized to make their contributions. There is no Signed-off-by requirement in CONTRIBUTING.md, no DCO bot configured, and no CLA process in place.


    Enough for a badge!

    The project MUST clearly define and document its project governance model (the way it makes decisions, including key roles). (URL required) [governance]
    There needs to be some well-established documented way to make decisions and resolve disputes. In small projects, this may be as simple as "the project owner and lead makes all final decisions". There are various governance models, including benevolent dictator and formal meritocracy; for more details, see Governance models. Both centralized (e.g., single-maintainer) and decentralized (e.g., group maintainers) approaches have been successfully used in projects. The governance information does not need to document the possibility of creating a project fork, since that is always possible for FLOSS projects.

    The project's governance model is documented in CONTRIBUTING.md (https://github.com/StayPirate/sentinel/blob/master/CONTRIBUTING.md): single maintainer with sole authority over merge decisions, release management, and security response. Decision-making follows the specs-first workflow — feature specifications are authored and reviewed before implementation, and the repository owner is the final approver for all PRs. Roles are implicit but clear: one maintainer/owner (full authority), external contributors (submit PRs, subject to CI and review requirements). SECURITY.md documents the security response role.


    Enough for a badge!

    The project MUST adopt a code of conduct and post it in a standard location. (URL required) [code_of_conduct]
    Projects may be able to improve the civility of their community and to set expectations about acceptable conduct by adopting a code of conduct. This can help avoid problems before they occur and make the project a more welcoming place to encourage contributions. This should focus only on behavior within the community/workplace of the project. Example codes of conduct are the Linux kernel code of conduct, the Contributor Covenant Code of Conduct, the Debian Code of Conduct, the Ubuntu Code of Conduct, the Fedora Code of Conduct, the GNOME Code Of Conduct, the KDE Community Code of Conduct, the Python Community Code of Conduct, The Ruby Community Conduct Guideline, and The Rust Code of Conduct.

    The project has a Code of Conduct (CODE_OF_CONDUCT.md) posted in the repository root — the standard location recognized by GitHub (https://github.com/StayPirate/sentinel/blob/master/CODE_OF_CONDUCT.md). It was added as part of PR #207 (open-source readiness files). GitHub automatically surfaces it in the repository's community profile and in the "Code of Conduct" sidebar link.


    Enough for a badge!

    The project MUST clearly define and publicly document the key roles in the project and their responsibilities, including any tasks those roles must perform. It MUST be clear who has which role(s), though this might not be documented in the same way. (URL required) [roles_responsibilities]
    The documentation for governance and roles and responsibilities may be in one place.

    CONTRIBUTING.md (https://github.com/StayPirate/sentinel/blob/master/CONTRIBUTING.md) documents the project roles and responsibilities: the repository owner/maintainer is responsible for reviewing and merging contributions, managing releases, triaging issues, and security response. SECURITY.md documents the security contact role. The GitHub repository's collaborator settings publicly show who holds the owner role (StayPirate). For a single-maintainer project, this is sufficient — there is one role (maintainer) with clearly documented responsibilities (merge authority, release management, security triage).


    Not enough for a badge.

    The project MUST be able to continue with minimal interruption if any one person dies, is incapacitated, or is otherwise unable or unwilling to continue support of the project. In particular, the project MUST be able to create and close issues, accept proposed changes, and release versions of software, within a week of confirmation of the loss of support from any one individual. This MAY be done by ensuring someone else has any necessary keys, passwords, and legal rights to continue the project. Individuals who run a FLOSS project MAY do this by providing keys in a lockbox and a will providing any needed legal rights (e.g., for DNS names). (URL required) [access_continuity]

    The project is single-maintainer with no documented bus factor mitigation. There is no evidence of a second person having repository admin access, release token credentials, or legal rights to continue the project if the sole maintainer becomes unavailable. No lockbox arrangement, succession plan, or co-maintainer is documented. GitHub's repository settings show a single owner, and the RELEASE_TOKEN PAT is presumably held by one individual. The project could not create releases or merge PRs within a week of losing its sole maintainer.


    Barely enough for a badge.

    The project SHOULD have a "bus factor" of 2 or more. (URL required) [bus_factor]
    A "bus factor" (aka "truck factor") is the minimum number of project members that have to suddenly disappear from a project ("hit by a bus") before the project stalls due to lack of knowledgeable or competent personnel. The truck-factor tool can estimate this for projects on GitHub. For more information, see Assessing the Bus Factor of Git Repositories by Cosentino et al.

    The project has a bus factor of 1 — a single maintainer (StayPirate) with sole repository admin access, release credentials, and merge authority. No second person has the necessary permissions to create releases, merge PRs, or manage the repository infrastructure. This is the same underlying gap as the previous criterion.


  • Documentation


    Enough for a badge!

    The project MUST have a documented roadmap that describes what the project intends to do and not do for at least the next year. (URL required) [documentation_roadmap]
    The project might not achieve the roadmap, and that's fine; the purpose of the roadmap is to help potential users and contributors understand the intended direction of the project. It need not be detailed.

    The project maintains a public GitHub Project board ("Sentinel Backend Implementation") with phased implementation planning covering the project's development roadmap, including prioritized issues organized by development phase and domain area. The board documents intended work and scope boundaries for the project's upcoming development. (https://github.com/users/StayPirate/projects/3)


    Enough for a badge!

    The project MUST include documentation of the architecture (aka high-level design) of the software produced by the project. If the project does not produce software, select "not applicable" (N/A). (URL required) [documentation_architecture]
    A software architecture explains a program's fundamental structures, i.e., the program's major components, the relationships among them, and the key properties of these components and relationships.

    The project includes comprehensive architecture documentation in (https://github.com/StayPirate/sentinel/blob/master/docs/architecture.md) covering: system boundary, architectural decisions with rationale (async-only database layer, single Docker image, Celery + Redis, PostgreSQL as single source of truth, capability-based RBAC, specs-first development), design constraints (stateless containers, deployment-agnostic packaging, API-first, HTTP APIs for external services, environment-variable configuration), backend layer architecture (7 layers with strict dependency direction), and integration patterns (scheduled fetchers, event-driven consumers). Additional detail in docs/system-map.md (component diagrams and data flows).


    Enough for a badge!

    The project MUST document what the user can and cannot expect in terms of security from the software produced by the project (its "security requirements"). (URL required) [documentation_security]
    These are the security requirements that the software is intended to meet.

    The project documents security requirements in its feature specifications. The RBAC specification (https://github.com/StayPirate/sentinel/blob/master/docs/features/identity/rbac.md) defines the authorization model (capabilities, roles, access levels, endpoint permission map). The authentication specification (https://github.com/StayPirate/sentinel/blob/master/docs/features/identity/authentication.md) documents session security guarantees, JWT handling, API key restrictions, and credential-kind limitations. The local authentication specification (https://github.com/StayPirate/sentinel/blob/master/docs/features/identity/local-authentication.md) specifies password policy, brute-force protections, and bcrypt parameters. SECURITY.md (https://github.com/StayPirate/sentinel/blob/master/SECURITY.md) defines the vulnerability response process. Together these establish what users can expect (encrypted passwords, session expiry, capability-based access control, rate limiting) and what is explicitly out of scope.


    Enough for a badge!

    The project MUST provide a "quick start" guide for new users to help them quickly do something with the software. (URL required) [documentation_quick_start]
    The idea is to show users how to get started and make the software do anything at all. This is critically important for potential users to get started.

    The project provides a quick start guide in CONTRIBUTING.md (https://github.com/StayPirate/sentinel/blob/master/CONTRIBUTING.md) under the "Quick Start" section, which walks new users through installing dependencies (uv sync), starting the local infrastructure (./scripts/dev-env.sh up), running database migrations, launching the development server, and running tests — all within a few commands. The README.md (https://github.com/StayPirate/sentinel/blob/master/README.md) also links to this guide and provides an overview of available make targets for common tasks.


    Enough for a badge!

    The project MUST make an effort to keep the documentation consistent with the current version of the project results (including software produced by the project). Any known documentation defects making it inconsistent MUST be fixed. If the documentation is generally current, but erroneously includes some older information that is no longer true, just treat that as a defect, then track and fix as usual. [documentation_current]
    The documentation MAY include information about differences or changes between versions of the software and/or link to older versions of the documentation. The intent of this criterion is that an effort is made to keep the documentation consistent, not that the documentation must be perfect.

    The project enforces documentation-code consistency through multiple mechanisms: Guardrail 3 (coherent spec-code updates) requires that any code change affecting feature behavior is accompanied by corresponding specification updates. The mandatory @docs-reviewer (Guardrail 9) verifies documentation completeness after significant changes. The docs/reviews/ directory tracks 50+ review findings ensuring specs remain aligned with implementation. The specs-first workflow (Guardrail 1) means documentation is written before code, reducing drift. Any known inconsistencies are tracked as defects in GitHub Issues and fixed in subsequent PRs.


    Enough for a badge!

    The project repository front page and/or website MUST identify and hyperlink to any achievements, including this best practices badge, within 48 hours of public recognition that the achievement has been attained. (URL required) [documentation_achievements]
    An achievement is any set of external criteria that the project has specifically worked to meet, including some badges. This information does not need to be on the project website front page. A project using GitHub can put achievements on the repository front page by adding them to the README file.

    The README.md (https://github.com/StayPirate/sentinel/blob/master/README.md) displays the OpenSSF Best Practices badge (linked to the project's badge page at https://www.bestpractices.dev/projects/14063) in the badges section at the top of the repository front page. The badge was added within 48 hours of the project being registered, via PR #208.


  • Accessibility and internationalization


    Enough for a badge!

    The project (both project sites and project results) SHOULD follow accessibility best practices so that persons with disabilities can still participate in the project and use the project results where it is reasonable to do so. [accessibility_best_practices]
    For web applications, see the Web Content Accessibility Guidelines (WCAG 2.0) and its supporting document Understanding WCAG 2.0; see also W3C accessibility information. For GUI applications, consider using the environment-specific accessibility guidelines (such as Gnome, KDE, XFCE, Android, iOS, Mac, and Windows). Some TUI applications (e.g. `ncurses` programs) can do certain things to make themselves more accessible (such as `alpine`'s `force-arrow-cursor` setting). Most command-line applications are fairly accessible as-is. This criterion is often N/A, e.g., for program libraries. Here are some examples of actions to take or issues to consider:
    • Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language ( WCAG 2.0 guideline 1.1)
    • Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. ( WCAG 2.0 guideline 1.4.1)
    • The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for large text, incidental text, and logotypes ( WCAG 2.0 guideline 1.4.3)
    • Make all functionality available from a keyboard (WCAG guideline 2.1)
    • A GUI or web-based project SHOULD test with at least one screen-reader on the target platform(s) (e.g. NVDA, Jaws, or WindowEyes on Windows; VoiceOver on Mac & iOS; Orca on Linux/BSD; TalkBack on Android). TUI programs MAY work to reduce overdraw to prevent redundant reading by screen-readers.

    The project is a backend API platform with no web UI (the frontend will be developed in a separate repository). The REST API follows standard HTTP conventions and returns structured JSON, which is inherently accessible to assistive technologies and screen readers through any HTTP client or API consumer. The GitHub repository itself (where all project documentation and interaction occurs) inherits GitHub's accessibility features (keyboard navigation, screen reader support, ARIA labels). The CLI output uses plain text without color-only semantics, and the documentation is standard Markdown rendered by GitHub's accessible web interface.


    Enough for a badge!

    The software produced by the project SHOULD be internationalized to enable easy localization for the target audience's culture, region, or language. If internationalization (i18n) does not apply (e.g., the software doesn't generate text intended for end-users and doesn't sort human-readable text), select "not applicable" (N/A). [internationalization]
    Localization "refers to the adaptation of a product, application or document content to meet the language, cultural and other requirements of a specific target market (a locale)." Internationalization is the "design and development of a product, application or document content that enables easy localization for target audiences that vary in culture, region, or language." (See W3C's "Localization vs. Internationalization".) Software meets this criterion simply by being internationalized. No localization for another specific language is required, since once software has been internationalized it's possible for others to work on localization.

    Sentinel is a backend API platform that returns structured JSON responses with machine-readable error codes. It does not generate localized text intended for end-users — all API responses use standardized error codes and English-only technical messages consumed by programmatic clients. The CLI is an operational tool for system administrators, not a consumer-facing application. Internationalization does not apply to this type of software.


  • Other


    Enough for a badge!

    If the project sites (website, repository, and download URLs) store passwords for authentication of external users, the passwords MUST be stored as iterated hashes with a per-user salt by using a key stretching (iterated) algorithm (e.g., Argon2id, Bcrypt, Scrypt, or PBKDF2). If the project sites do not store passwords for this purpose, select "not applicable" (N/A). [sites_password_security]
    Note that the use of GitHub meets this criterion. This criterion only applies to passwords used for authentication of external users into the project sites (aka inbound authentication). If the project sites must log in to other sites (aka outbound authentication), they may need to store authorization tokens for that purpose differently (since storing a hash would be useless). This applies criterion crypto_password_storage to the project sites, similar to sites_https.

    The project sites (GitHub repository, GitHub Pages) do not store passwords for authentication of external users — authentication is handled entirely by GitHub's infrastructure. The Sentinel application itself stores passwords using bcrypt (as documented in earlier criteria), but that is the software produced by the project, not the project sites themselves.


 Change Control 1/1 ●

  • Previous versions


    Enough for a badge!

    The project MUST maintain the most often used older versions of the product or provide an upgrade path to newer versions. If the upgrade path is difficult, the project MUST document how to perform the upgrade (e.g., the interfaces that have changed and detailed suggested steps to help upgrade). [maintenance_or_update]

    The project uses Alembic database migrations with a forward-migration path — each release includes migration scripts that upgrade the database schema from any previous version to the current one (alembic upgrade head). The deployment documentation (https://github.com/StayPirate/sentinel/blob/master/docs/deployment.md) covers migration procedures and the SemVer policy in conventions (https://github.com/StayPirate/sentinel/blob/master/docs/conventions.md) clearly defines what constitutes a breaking change (MAJOR bump). The project is pre-1.0, where breaking changes may occur in minor bumps — consumers are advised to pin exact versions. Release changelogs (generated by release-please) document all changes between versions, and the API versioning strategy (/api/v1/) ensures backward compatibility within a major version.


 Reporting 3/3 ●

  • Bug-reporting process


    Enough for a badge!

    The project MUST use an issue tracker for tracking individual issues. [report_tracker]

    The project uses GitHub Issues as its issue tracker. Every substantive change is tracked by an issue (enforced by pr-metadata.yml which requires Closes #N or N/A - <reason> in every PR body). Issue templates ("Work item" form) are configured for structured reporting. Issues track bugs, features, documentation changes, and CI/CD improvements with labels, direct blockers, and linkage to owning specifications.


  • Vulnerability report process


    Enough for a badge!

    The project MUST give credit to the reporter(s) of all vulnerability reports resolved in the last 12 months, except for the reporter(s) who request anonymity. If there have been no vulnerabilities resolved in the last 12 months, select "not applicable" (N/A). (URL required) [vulnerability_report_credit]

    No vulnerability reports have been received or resolved in the last 12 months. The project has had no reported security vulnerabilities since its creation.


    Enough for a badge!

    The project MUST have a documented process for responding to vulnerability reports. (URL required) [vulnerability_response_process]
    This is strongly related to vulnerability_report_process, which requires that there be a documented way to report vulnerabilities. It also related to vulnerability_report_response, which requires response to vulnerability reports within a certain time frame.

    SECURITY.md (https://github.com/StayPirate/sentinel/blob/master/SECURITY.md) documents the complete vulnerability response process: private reporting via security@suse.com, acknowledgment within 5 business days, initial assessment within 15 business days, coordinated disclosure timeline with the reporter, and the commitment to issue security advisories with fixes. GitHub's Private Vulnerability Reporting is also enabled as an alternative intake channel.


 Quality 19/19 ●

  • Coding standards


    Enough for a badge!

    The project MUST identify the specific coding style guides for the primary languages it uses, and require that contributions generally comply with it. (URL required) [coding_standards]
    In most cases this is done by referring to some existing style guide(s), possibly listing differences. These style guides can include ways to improve readability and ways to reduce the likelihood of defects (including vulnerabilities). Many programming languages have one or more widely-used style guides. Examples of style guides include Google's style guides and SEI CERT Coding Standards.

    CONTRIBUTING.md (https://github.com/StayPirate/sentinel/blob/master/CONTRIBUTING.md) references the project's coding conventions, and docs/conventions.md (https://github.com/StayPirate/sentinel/blob/master/docs/conventions.md) is the comprehensive coding style guide. It covers Python style (ruff format + ruff check, line length, quotes, imports, naming), type hints (strict mypy), FastAPI conventions, SQLAlchemy conventions, Pydantic conventions, CLI conventions, shell scripting (shellcheck + shfmt), git/commit conventions, and specification writing standards. Compliance is enforced automatically in CI via ruff, mypy --strict, shellcheck, shfmt, and actionlint.


    Enough for a badge!

    The project MUST automatically enforce its selected coding style(s) if there is at least one FLOSS tool that can do so in the selected language(s). [coding_standards_enforced]
    This MAY be implemented using static analysis tool(s) and/or by forcing the code through code reformatters. In many cases the tool configuration is included in the project's repository (since different projects may choose different configurations). Projects MAY allow style exceptions (and typically will); where exceptions occur, they MUST be rare and documented in the code at their locations, so that these exceptions can be reviewed and so that tools can automatically handle them in the future. Examples of such tools include ESLint (JavaScript), Rubocop (Ruby), and devtools check (R).

    Coding style is automatically enforced in CI (.github/workflows/ci.yml):

    • Python formatting: ruff format --check . — fails the build if code is not formatted per the project's black-compatible style
    • Python linting: ruff check . — enforces import sorting, naming conventions, and style rules
    • Python type checking: mypy --strict — enforces type annotations on all function signatures
    • Shell formatting: shfmt -d -i 4 -ci — fails the build if shell scripts are not formatted per project conventions
    • Shell linting: shellcheck — enforces shell scripting best practices
    • Workflow linting: actionlint — validates GitHub Actions workflow syntax and embedded shell

    The pre-commit hook (.githooks/pre-commit) also runs ruff, shellcheck, and shfmt locally before commits reach CI. All tools are FLOSS.


  • Working build system


    Enough for a badge!

    Build systems for native binaries MUST honor the relevant compiler and linker (environment) variables passed in to them (e.g., CC, CFLAGS, CXX, CXXFLAGS, and LDFLAGS) and pass them to compiler and linker invocations. A build system MAY extend them with additional flags; it MUST NOT simply replace provided values with its own. If no native binaries are being generated, select "not applicable" (N/A). [build_standard_variables]
    It should be easy to enable special build features like Address Sanitizer (ASAN), or to comply with distribution hardening best practices (e.g., by easily turning on compiler flags to do so).

    Sentinel is a pure Python application — no native binaries are compiled during the build process. The Dockerfile installs Python wheels (pre-built or pure-Python) via uv pip install. No C/C++ compiler or linker is invoked.


    Enough for a badge!

    The build and installation system SHOULD preserve debugging information if they are requested in the relevant flags (e.g., "install -s" is not used). If there is no build or installation system (e.g., typical JavaScript libraries), select "not applicable" (N/A). [build_preserve_debug]
    E.G., setting CFLAGS (C) or CXXFLAGS (C++) should create the relevant debugging information if those languages are used, and they should not be stripped during installation. Debugging information is needed for support and analysis, and also useful for measuring the presence of hardening features in the compiled binaries.

    Sentinel is a pure Python application with no compiled artifacts. The build process (uv pip install / uv sync) installs Python packages — there are no native binaries to strip or preserve debugging information for.


    Enough for a badge!

    The build system for the software produced by the project MUST NOT recursively build subdirectories if there are cross-dependencies in the subdirectories. If there is no build or installation system (e.g., typical JavaScript libraries), select "not applicable" (N/A). [build_non_recursive]
    The project build system's internal dependency information needs to be accurate, otherwise, changes to the project may not build correctly. Incorrect builds can lead to defects (including vulnerabilities). A common mistake in large build systems is to use a "recursive build" or "recursive make", that is, a hierarchy of subdirectories containing source files, where each subdirectory is independently built. Unless each subdirectory is fully independent, this is a mistake, because the dependency information is incorrect.

    Sentinel is a pure Python application. The build process uses uv pip install / uv sync with a single pyproject.toml — there is no recursive subdirectory build system and no cross-dependency resolution between subdirectories.


    Enough for a badge!

    The project MUST be able to repeat the process of generating information from source files and get exactly the same bit-for-bit result. If no building occurs (e.g., scripting languages where the source code is used directly instead of being compiled), select "not applicable" (N/A). [build_repeatable]
    GCC and clang users may find the -frandom-seed option useful; in some cases, this can be resolved by forcing some sort order. More suggestions can be found at the reproducible build site.

    Sentinel is a pure Python application — the source code is interpreted directly, not compiled into binary artifacts. The Docker image build involves installing Python packages from a lockfile (uv.lock), but the application itself has no compilation step that would produce bit-for-bit reproducible build artifacts.


  • Installation system


    Enough for a badge!

    The project MUST provide a way to easily install and uninstall the software produced by the project using a commonly-used convention. [installation_common]
    Examples include using a package manager (at the system or language level), "make install/uninstall" (supporting DESTDIR), a container in a standard format, or a virtual machine image in a standard format. The installation and uninstallation process (e.g., its packaging) MAY be implemented by a third party as long as it is FLOSS.

    Sentinel provides standard installation mechanisms:

    • Python package: installable via uv pip install . or pip install . using the standard pyproject.toml with declared dependencies and a console script entry point (sentinel). Uninstall via uv pip uninstall sentinel or pip uninstall sentinel
    • Docker image: installable via docker pull / podman pull from the container registry. Uninstall by removing the container and image (docker rmi)
    • Development setup: uv sync creates a virtualenv with the project installed in editable mode, following Python ecosystem conventions

    Enough for a badge!

    The installation system for end-users MUST honor standard conventions for selecting the location where built artifacts are written to at installation time. For example, if it installs files on a POSIX system it MUST honor the DESTDIR environment variable. If there is no installation system or no standard convention, select "not applicable" (N/A). [installation_standard_variables]

    Sentinel is a pure Python application installed via pip / uv pip into a Python environment (virtualenv or system site-packages), which follows Python's own installation conventions (not POSIX DESTDIR). The production deployment is containerized (Docker/Podman) where the concept of DESTDIR does not apply — the image is the installation unit. There is no make install or similar POSIX installation target.


    Enough for a badge!

    The project MUST provide a way for potential developers to quickly install all the project results and support environment necessary to make changes, including the tests and test environment. This MUST be performed with a commonly-used convention. [installation_development_quick]
    This MAY be implemented using a generated container and/or installation script(s). External dependencies would typically be installed by invoking system and/or language package manager(s), per external_dependencies.

    CONTRIBUTING.md provides step-by-step build instructions: install uv, run uv sync (which automatically downloads the correct Python 3.13 interpreter and all dependencies from the lockfile), start infrastructure via ./scripts/dev-env.sh up, run migrations, and launch the server. docs/deployment.md documents the production build process (multi-stage Dockerfile with uv sync --frozen), required infrastructure (PostgreSQL, Redis), and the software requirements table listing all runtime dependencies with minimum versions. [osps_do_07_01]


  • Externally-maintained components


    Enough for a badge!

    The project MUST list external dependencies in a computer-processable way. (URL required) [external_dependencies]
    Typically this is done using the conventions of package manager and/or build system. Note that this helps implement installation_development_quick.

    backend/pyproject.toml (https://github.com/StayPirate/sentinel/blob/master/backend/pyproject.toml) lists all external dependencies in the standard Python [project.dependencies] format, which is computer-processable by pip, uv, and any PEP 621-compliant tool. Additionally, backend/uv.lock (https://github.com/StayPirate/sentinel/blob/master/backend/uv.lock) pins exact versions of all transitive dependencies in a machine-readable lockfile.


    Enough for a badge!

    Projects MUST monitor or periodically check their external dependencies (including convenience copies) to detect known vulnerabilities, and fix exploitable vulnerabilities or verify them as unexploitable. [dependency_monitoring]
    This can be done using an origin analyzer / dependency checking tool / software composition analysis tool such as OWASP's Dependency-Check, Sonatype's Nexus Auditor, Synopsys' Black Duck Software Composition Analysis, and Bundler-audit (for Ruby). Some package managers include mechanisms to do this. It is acceptable if the components' vulnerability cannot be exploited, but this analysis is difficult and it is sometimes easier to simply update or fix the part.

    Every change to the codebase is automatically evaluated by the CI pipeline before merge: pip-audit (in the backend-security job of ci.yml) checks all Python dependencies against known vulnerability databases and blocks the PR if a violation is found. bandit runs static security analysis in the same job. Branch protection requires the "Backend Security Scan" status check to pass — no code reaches master without passing these gates. Dependabot is configured to propose dependency updates weekly, providing proactive notification of vulnerable or outdated dependencies. The suppression mechanism exists via pip-audit's --ignore-vuln flag (though currently unused), which would require explicit declaration of non-exploitability. [osps_vm_05_03]


    Enough for a badge!

    The project MUST either:
    1. make it easy to identify and update reused externally-maintained components; or
    2. use the standard components provided by the system or programming language.
    Then, if a vulnerability is found in a reused component, it will be easy to update that component. [updateable_reused_components]
    A typical way to meet this criterion is to use system and programming language package management systems. Many FLOSS programs are distributed with "convenience libraries" that are local copies of standard libraries (possibly forked). By itself, that's fine. However, if the program *must* use these local (forked) copies, then updating the "standard" libraries as a security update will leave these additional copies still vulnerable. This is especially an issue for cloud-based systems; if the cloud provider updates their "standard" libraries but the program won't use them, then the updates don't actually help. See, e.g., "Chromium: Why it isn't in Fedora yet as a proper package" by Tom Callaway.

    backend/pyproject.toml declares all direct Python dependencies under [project.dependencies]. uv.lock is committed to the repository as a lockfile pinning exact resolved versions (including transitive dependencies). [osps_qa_02_01]


    Enough for a badge!

    The project SHOULD avoid using deprecated or obsolete functions and APIs where FLOSS alternatives are available in the set of technology it uses (its "technology stack") and to a supermajority of the users the project supports (so that users have ready access to the alternative). [interfaces_current]

    Sentinel actively avoids deprecated and obsolete APIs:

    • Python: targets Python 3.13 (current stable). Uses datetime.now(UTC) instead of the deprecated datetime.utcnow(). Uses SQLAlchemy 2.0 style (mapped_column, declarative base) instead of the legacy 1.x API. Uses Pydantic v2 (model_config = ConfigDict(...)) instead of the deprecated v1 class Config
    • Dependencies: Dependabot is configured (.github/dependabot.yml) for weekly updates across Python (uv), GitHub Actions, and Docker ecosystems, keeping the stack current
    • CI enforcement: ruff check flags usage of deprecated Python standard library APIs (via pyupgrade and pyflakes rules), and pip-audit flags dependencies with known vulnerabilities (which often correlate with obsolescence)

  • Automated test suite


    Enough for a badge!

    An automated test suite MUST be applied on each check-in to a shared repository for at least one branch. This test suite MUST produce a report on test success or failure. [automated_integration_testing]
    This requirement can be viewed as a subset of test_continuous_integration, but focused on just testing, without requiring continuous integration.

    The CI pipeline (ci.yml) runs on every pull request targeting master and includes a full automated test suite: uv run pytest executes 850+ unit and integration tests. Branch protection requires the "Backend Tests" status check to pass before merge — no commit reaches master without the test suite passing. [osps_qa_06_01]


    Enough for a badge!

    The project MUST add regression tests to an automated test suite for at least 50% of the bugs fixed within the last six months. [regression_tests_added50]

    Sentinel's development workflow requires regression tests for all bug fixes — this is enforced by project conventions (AGENTS.md Guardrail 6: "Bug fixes: add a regression test that reproduces the bug") and verified by @test-reviewer invocations on bug fix PRs. The CI pipeline runs 850+ tests (uv run pytest) as a required status check before any PR can merge. All fix: commits in the last six months include corresponding regression tests in backend/tests/.


    Enough for a badge!

    The project MUST have FLOSS automated test suite(s) that provide at least 80% statement coverage if there is at least one FLOSS tool that can measure this criterion in the selected language. [test_statement_coverage80]
    Many FLOSS tools are available to measure test coverage, including gcov/lcov, Blanket.js, Istanbul, JCov, and covr (R). Note that meeting this criterion is not a guarantee that the test suite is thorough, instead, failing to meet this criterion is a strong indicator of a poor test suite.

    Sentinel uses pytest-cov (https://github.com/pytest-cov/pytest-cov) (a FLOSS tool) to measure statement coverage, with results uploaded to Codecov (https://app.codecov.io/) on every CI run. The project currently has 850+ tests achieving high statement coverage. The CI pipeline (.github/workflows/ci.yml) runs uv run pytest --cov and the Codecov badge is displayed in the README (https://github.com/StayPirate/sentinel/blob/master/README.md).


  • New functionality testing


    Enough for a badge!

    The project MUST have a formal written policy that as major new functionality is added, tests for the new functionality MUST be added to an automated test suite. [test_policy_mandated]

    AGENTS.md (Guardrail 6, Mandatory Testing) defines an explicit policy: "Every code change (new feature or modification) MUST include tests." It requires tests for new API endpoints (happy path, validation, auth), new models (creation, constraints, relationships), new services (business logic, edge cases, error handling), and bug fixes (regression tests). The policy explicitly states "NEVER skip tests" and instructs that if asked to skip, the developer must be reminded of the requirement. CONTRIBUTING.md reinforces this under the "Pull Request Checklist" — all PRs must include tests and CI must pass before merge. [osps_qa_06_03]


    Enough for a badge!

    The project MUST include, in its documented instructions for change proposals, the policy that tests are to be added for major new functionality. [tests_documented_added]
    However, even an informal rule is acceptable as long as the tests are being added in practice.

    AGENTS.md (Guardrail 6, Mandatory Testing) defines an explicit policy: "Every code change (new feature or modification) MUST include tests." It requires tests for new API endpoints (happy path, validation, auth), new models (creation, constraints, relationships), new services (business logic, edge cases, error handling), and bug fixes (regression tests). The policy explicitly states "NEVER skip tests" and instructs that if asked to skip, the developer must be reminded of the requirement. CONTRIBUTING.md reinforces this under the "Pull Request Checklist" — all PRs must include tests and CI must pass before merge. [osps_qa_06_03]


  • Warning flags


    Enough for a badge!

    Projects MUST be maximally strict with warnings in the software produced by the project, where practical. [warnings_strict]
    Some warnings cannot be effectively enabled on some projects. What is needed is evidence that the project is striving to enable warning flags where it can, so that errors are detected early.

    The project applies maximally strict settings where practical: mypy --strict enables all optional strictness flags (no implicit Optional, disallow untyped defs, disallow any generics, warn return any, etc.). ruff check runs with a broad rule set covering multiple linting categories. bandit runs without severity filters (all findings block). shellcheck runs without suppressed categories. The only permitted relaxations are narrowly-scoped, per-line suppressions with mandatory justification comments — blanket disables and file-level suppressions are forbidden by convention.


 Security 11/13 ●

  • Secure development knowledge


    Enough for a badge!

    The project MUST implement secure design principles (from "know_secure_design"), where applicable. If the project is not producing software, select "not applicable" (N/A). [implement_secure_design]
    For example, the project results should have fail-safe defaults (access decisions should deny by default, and projects' installation should be secure by default). They should also have complete mediation (every access that might be limited must be checked for authority and be non-bypassable). Note that in some cases principles will conflict, in which case a choice must be made (e.g., many mechanisms can make things more complex, contravening "economy of mechanism" / keep it simple).

    Sentinel implements secure design principles throughout its architecture:

    • Least privilege: capability-based RBAC with per-endpoint authorization checks (require_capability()); CI workflows default to permissions: read-all; database roles scoped to required operations
    • Defense in depth: input validation at multiple layers (Pydantic schemas, SQLAlchemy constraints, CHECK constraints); SAST (bandit), SCA (pip-audit), and static type checking (mypy --strict) all enforced in CI
    • Fail-safe defaults: new users have no capabilities until roles are assigned; API endpoints deny access unless the required capability is explicitly granted; strict mode branch protection on master
    • Complete mediation: all mutations go through centralized service modules (user_service, ticket_mutations, package_service) — direct model manipulation from API handlers is forbidden by architecture
    • Separation of privilege: authentication (JWT + API keys) is separate from authorization (capability checks); credential kind is tracked via AuthenticatedPrincipal
    • Economy of mechanism: single Docker image for all process roles; single source of truth in PostgreSQL; async-only database layer eliminates an entire class of sync/async mixing bugs
    • Open design: the security model is fully documented in specifications (rbac.md, authentication.md, SECURITY.md); no security through obscurity
    • Psychological acceptability: password policy uses bcrypt with configurable rounds; API error responses use consistent envelope format with actionable error codes

    These principles are documented across docs/architecture.md (https://github.com/StayPirate/sentinel/blob/master/docs/architecture.md), docs/conventions.md (https://github.com/StayPirate/sentinel/blob/master/docs/conventions.md), and the feature specifications in docs/features/identity/ (https://github.com/StayPirate/sentinel/tree/master/docs/features/identity).


  • Use basic good cryptographic practices

    Note that some software does not need to use cryptographic mechanisms. If your project produces software that (1) includes, activates, or enables encryption functionality, and (2) might be released from the United States (US) to outside the US or to a non-US-citizen, you may be legally required to take a few extra steps. Typically this just involves sending an email. For more information, see the encryption section of Understanding Open Source Technology & US Export Controls.

    Enough for a badge!

    The default security mechanisms within the software produced by the project MUST NOT depend on cryptographic algorithms or modes with known serious weaknesses (e.g., the SHA-1 cryptographic hash algorithm or the CBC mode in SSH). [crypto_weaknesses]
    Concerns about CBC mode in SSH are discussed in CERT: SSH CBC vulnerability.

    Sentinel does not depend on cryptographic algorithms or modes with known serious weaknesses. HMAC-SHA256 (not SHA-1) is used for JWT signing. bcrypt (not PBKDF2-SHA1) is used for password hashing. TLS connections via httpx/Python's ssl module negotiate modern cipher suites (AES-GCM, ChaCha20-Poly1305) — not CBC mode. No SSH protocol is implemented. The project exclusively uses algorithms considered secure by current standards (NIST SP 800-131A).


    Enough for a badge!

    The project SHOULD support multiple cryptographic algorithms, so users can quickly switch if one is broken. Common symmetric key algorithms include AES, Twofish, and Serpent. Common cryptographic hash algorithm alternatives include SHA-2 (including SHA-224, SHA-256, SHA-384 AND SHA-512) and SHA-3. [crypto_algorithm_agility]

    Sentinel uses cryptographic algorithms in two areas, both supporting alternatives:

    • Password hashing: uses bcrypt (via the bcrypt library) with configurable work factor. The passlib-compatible approach allows switching to alternative algorithms (argon2, scrypt) if bcrypt is compromised
    • JWT signing: uses HMAC-SHA256 (HS256) via PyJWT, which supports multiple algorithms (HS384, HS512, RS256, RS384, RS512, ES256, ES384, ES512) — switching is a configuration change
    • TLS: relies on Python's ssl module and the system OpenSSL library, which supports multiple cipher suites and can be configured to exclude broken algorithms

    No custom cryptographic implementations exist in the codebase — all crypto is delegated to well-maintained FLOSS libraries (bcrypt, PyJWT, OpenSSL). See docs/conventions.md (https://github.com/StayPirate/sentinel/blob/master/docs/conventions.md) (Secret Field Typing) and docs/features/identity/authentication.md (https://github.com/StayPirate/sentinel/blob/master/docs/features/identity/authentication.md).


    Enough for a badge!

    The project MUST support storing authentication credentials (such as passwords and dynamic tokens) and private cryptographic keys in files that are separate from other information (such as configuration files, databases, and logs), and permit users to update and replace them without code recompilation. If the project never processes authentication credentials and private cryptographic keys, select "not applicable" (N/A). [crypto_credential_agility]

    Sentinel stores all authentication credentials and cryptographic keys in environment variables, separate from application code, configuration files, and logs:

    • JWT secret key: JWT_SECRET_KEY environment variable, typed as SecretStr in config.py to prevent accidental exposure via repr/logging
    • Database password: embedded in DATABASE_URL environment variable, with Field(..., repr=False) to hide from repr
    • Redis credentials: embedded in REDIS_URL environment variable, with Field(..., repr=False)
    • IBS password: IBS_PASSWORD environment variable, typed as SecretStr
    • NVD API key: NVD_API_KEY environment variable, typed as SecretStr
    • RabbitMQ credentials: IBS_RABBITMQ_URL environment variable, with Field(..., repr=False)

    All credentials can be updated without code recompilation (Python is interpreted) and without rebuilding the container image — changing the environment variable value is sufficient. Secrets are never baked into images or committed to the repository (enforced by GitHub Secret Scanning + Push Protection). See docs/conventions.md (https://github.com/StayPirate/sentinel/blob/master/docs/conventions.md) (Secret Field Typing) and docs/configuration.md (https://github.com/StayPirate/sentinel/blob/master/docs/configuration.md).


    Enough for a badge!

    The software produced by the project SHOULD support secure protocols for all of its network communications, such as SSHv2 or later, TLS1.2 or later (HTTPS), IPsec, SFTP, and SNMPv3. Insecure protocols such as FTP, HTTP, telnet, SSLv3 or earlier, and SSHv1 SHOULD be disabled by default, and only enabled if the user specifically configures it. If the software produced by the project does not support network communications, select "not applicable" (N/A). [crypto_used_network]

    Sentinel supports secure protocols for all network communications and does not enable insecure protocols by default:

    • API server: serves over HTTPS; TLS configuration is handled at the deployment layer (reverse proxy / load balancer)
    • External service integrations: all HTTP clients (IBS, SMELT, AIMAAS, NVD, MITRE, Bugzilla, etc.) use HTTPS exclusively. The networking infrastructure (docs/features/platform/networking.md) configures TLS with certificate verification enabled by default
    • Database: connects to PostgreSQL via asyncpg, which supports TLS connections (sslmode parameter in DATABASE_URL)
    • Redis: connects via REDIS_URL, which supports rediss:// (TLS) scheme
    • RabbitMQ: connects via IBS_RABBITMQ_URL, which supports amqps:// (TLS) scheme
    • Git transport: git-based fetchers clone via HTTPS
    • No insecure defaults: no HTTP, FTP, telnet, or unencrypted protocols are used in application code. Plain HTTP is only accepted for local development (CORS_ORIGINS may include http://localhost:*)

    See docs/features/platform/networking.md (https://github.com/StayPirate/sentinel/blob/master/docs/features/platform/networking.md) and docs/data-sources.md (https://github.com/StayPirate/sentinel/blob/master/docs/data-sources.md) for the full external service catalog and protocol details.


    Enough for a badge!

    The software produced by the project SHOULD, if it supports or uses TLS, support at least TLS version 1.2. Note that the predecessor of TLS was called SSL. If the software does not use TLS, select "not applicable" (N/A). [crypto_tls12]

    Sentinel's TLS configuration supports TLS 1.2 and later:

    • Python runtime: Python 3.13's ssl module uses OpenSSL's default minimum protocol version, which is TLS 1.2 on all modern distributions (TLS 1.0 and 1.1 were deprecated in OpenSSL 1.1.1 and disabled by default in OpenSSL 3.x)
    • HTTP clients: the httpx library (used for all external service integrations) uses Python's ssl module, which enforces TLS 1.2+ by default
    • Database: asyncpg TLS connections negotiate TLS 1.2+ via the system OpenSSL
    • Redis/RabbitMQ: TLS connections via rediss:// and amqps:// schemes use Python's ssl module, defaulting to TLS 1.2+
    • Custom TLS context: the networking infrastructure (docs/features/platform/networking.md) supports configurable TLS contexts with certificate verification enabled by default, using the system trust store

    TLS versions prior to 1.2 (SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1) are disabled by the underlying OpenSSL library in the Python 3.13 base image (python:3.13-slim).


    Enough for a badge!

    The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS, including on subresources. If the software does not use TLS, select "not applicable" (N/A). [crypto_certificate_verification]
    Note that incorrect TLS certificate verification is a common mistake. For more information, see "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software" by Martin Georgiev et al. and "Do you trust this application?" by Michael Catanzaro.

    Sentinel performs TLS certificate verification by default on all outgoing connections:

    • HTTP clients: the httpx library verifies TLS certificates by default using the system trust store (certifi). The networking infrastructure (docs/features/platform/networking.md) configures TLS with verify=True as the default — disabling verification requires explicit configuration
    • Database: asyncpg TLS connections verify certificates when sslmode=verify-ca or sslmode=verify-full is configured in the DATABASE_URL
    • Redis: Python redis library verifies TLS certificates by default when using rediss:// scheme
    • RabbitMQ: aio-pika verifies TLS certificates by default when using amqps:// scheme
    • Git transport: HTTPS clones via git verify server certificates by default (OpenSSL/system trust store)
    • Internal CA support: for SUSE internal services using an internal CA, the project supports configuring a custom CA bundle (REQUESTS_CA_BUNDLE / SSL_CERT_FILE) rather than disabling verification

    No connection in the codebase disables certificate verification by default. See docs/features/platform/networking.md (https://github.com/StayPirate/sentinel/blob/master/docs/features/platform/networking.md) for TLS configuration details.


    Enough for a badge!

    The software produced by the project MUST, if it supports TLS, perform certificate verification before sending HTTP headers with private information (such as secure cookies). If the software does not use TLS, select "not applicable" (N/A). [crypto_verification_private]

    Sentinel's TLS implementation ensures certificate verification completes before any private data is transmitted. This is inherent in how the underlying libraries operate:

    • httpx: the TLS handshake (including certificate verification) completes during connection establishment, before any HTTP headers (including cookies, authorization tokens, API keys) are sent. This is enforced by the TLS protocol itself — the HTTP layer cannot transmit data until the TLS session is established and verified
    • asyncpg: database connection authentication credentials are sent only after the TLS handshake succeeds
    • aio-pika / Redis: AMQP and Redis authentication credentials are transmitted only after TLS negotiation completes

    Sentinel transmits private information (JWT tokens, API keys, IBS/NVD credentials) exclusively over HTTPS connections where certificate verification is the default. The TLS protocol guarantees that verification precedes any application-layer data exchange — no application-level ordering logic is needed because the transport layer enforces it.


  • Secure release


    Not enough for a badge.

    The project MUST cryptographically sign releases of the project results intended for widespread use, and there MUST be a documented process explaining to users how they can obtain the public signing keys and verify the signature(s). The private key for these signature(s) MUST NOT be on site(s) used to directly distribute the software to the public. If releases are not intended for widespread use, select "not applicable" (N/A). [signed_releases]
    The project results include both source code and any generated deliverables where applicable (e.g., executables, packages, and containers). Generated deliverables MAY be signed separately from source code. These MAY be implemented as signed git tags (using cryptographic digital signatures). Projects MAY provide generated results separately from tools like git, but in those cases, the separate results MUST be separately signed.

    Releases are created via release-please with a unique Git tag, but no cryptographic signing or attestation is currently applied. The GitHub Release has no attached assets, no SLSA provenance attestation, no cosign signature, and no signed manifest containing cryptographic hashes of build artifacts. The container images pushed to ghcr.io are similarly unattested (no docker/attest-build-provenance or cosign sign step in build-images.yml). [osps_br_06_01]


    Barely enough for a badge.

    It is SUGGESTED that in the version control system, each important version tag (a tag that is part of a major release, minor release, or fixes publicly noted vulnerabilities) be cryptographically signed and verifiable as described in signed_releases. [version_tags_signed]

    Sentinel does not currently sign version tags. Tags are created automatically by release-please, but they are not cryptographically signed (GPG or sigstore). This is consistent with the "Unmet" status on the related signed_releases criterion (release signing/attestation).


  • Other security issues


    Enough for a badge!

    The project results MUST check all inputs from potentially untrusted sources to ensure they are valid (an *allowlist*), and reject invalid inputs, if there are any restrictions on the data at all. [input_validation]
    Note that comparing input against a list of "bad formats" (aka a *denylist*) is normally not enough, because attackers can often work around a denylist. In particular, numbers are converted into internal formats and then checked if they are between their minimum and maximum (inclusive), and text strings are checked to ensure that they are valid text patterns (e.g., valid UTF-8, length, syntax, etc.). Some data may need to be "anything at all" (e.g., a file uploader), but these would typically be rare.

    Sentinel validates all inputs from untrusted sources using allowlist-based validation at multiple layers:

    • API input validation: all request bodies are validated via Pydantic schemas (backend/app/schemas/) with strict type checking, field constraints, and allowed value enumerations before reaching service logic. Invalid inputs are rejected with 422 VALIDATION_ERROR responses
    • Query parameter validation: a shared dependency enforces a 500-character string parameter length limit across all endpoints (docs/api-spec.md). Enum-typed query parameters (status filters, sort fields) only accept explicitly defined values
    • Username validation: allowlist pattern — must match [a-z0-9._-], 1-64 characters, start with a letter. Enforced at every entry point (API, CLI)
    • Password validation: domain-specific policy validation (PasswordValidationError) before storage
    • CVE identifiers: validated against the CVE-YYYY-NNNNN+ format pattern
    • Database-level constraints: CHECK constraints enforce valid enum values for state-machine columns (ticket status, audit event types). VARCHAR(N) length limits on all string columns
    • External data ingestion: fetchers that ingest data from external sources (NVD, MITRE, GHSA, OSV, etc.) validate and normalize incoming data before database storage (e.g., ecosystem normalization to OSSF canonical values, CVSS score validation)
    • Path/identifier parameters: UUID and username resolution validates format before database lookup, rejecting malformed identifiers early

    See docs/api-spec.md (https://github.com/StayPirate/sentinel/blob/master/docs/api-spec.md) and docs/conventions.md (https://github.com/StayPirate/sentinel/blob/master/docs/conventions.md) (Username Format, Pydantic Conventions).


    Enough for a badge!

    Hardening mechanisms SHOULD be used in the software produced by the project so that software defects are less likely to result in security vulnerabilities. [hardening]
    Hardening mechanisms may include HTTP headers like Content Security Policy (CSP), compiler flags to mitigate attacks (such as -fstack-protector), or compiler flags to eliminate undefined behavior. For our purposes least privilege is not considered a hardening mechanism (least privilege is important, but separate).

    Sentinel employs multiple hardening mechanisms to reduce the likelihood that software defects result in security vulnerabilities:

    • Memory-safe language: Python is memory-safe by design — no buffer overflows, use-after-free, or memory corruption
    • Strict static type checking: mypy --strict is a mandatory CI gate, catching type errors, unhandled None values, and forgotten await calls before production
    • SQL injection prevention: all database queries use SQLAlchemy's parameterized query API — no raw SQL string concatenation
    • Input validation at boundaries: Pydantic schemas reject malformed input before business logic; database CHECK constraints provide defense-in-depth
    • Secret masking: SecretStr type prevents accidental credential exposure in tracebacks, logs, and repr output
    • SAST: bandit detects common Python security anti-patterns (hardcoded passwords, eval, insecure deserialization) in CI
    • SCA: pip-audit blocks dependencies with known vulnerabilities pre-merge
    • Container scanning: Trivy scans the Docker image for OS and library vulnerabilities
    • Least-privilege CI: workflows default to permissions: read-all; jobs escalate only specific permissions needed
    • Secret scanning: GitHub Secret Scanning with Push Protection prevents accidental credential commits
    • Pessimistic locking: centralized mutation modules use SELECT ... FOR UPDATE to prevent race conditions
    • No custom cryptography: all crypto delegates to vetted FLOSS libraries (bcrypt, PyJWT, OpenSSL)

    These mechanisms are documented across docs/conventions.md (https://github.com/StayPirate/sentinel/blob/master/docs/conventions.md), docs/architecture.md (https://github.com/StayPirate/sentinel/blob/master/docs/architecture.md), and docs/deployment.md (https://github.com/StayPirate/sentinel/blob/master/docs/deployment.md) (CI Pipeline).


    Not enough for a badge.

    The project MUST provide an assurance case that justifies why its security requirements are met. The assurance case MUST include: a description of the threat model, clear identification of trust boundaries, an argument that secure design principles have been applied, and an argument that common implementation security weaknesses have been countered. (URL required) [assurance_case]
    An assurance case is "a documented body of evidence that provides a convincing and valid argument that a specified set of critical claims regarding a system’s properties are adequately justified for a given application in a given environment" ("Software Assurance Using Structured Assurance Case Models", Thomas Rhodes et al, NIST Interagency Report 7608). Trust boundaries are boundaries where data or execution changes its level of trust, e.g., a server's boundaries in a typical web application. It's common to list secure design principles (such as Saltzer and Schroeer) and common implementation security weaknesses (such as the OWASP top 10 or CWE/SANS top 25), and show how each are countered. The BadgeApp assurance case may be a useful example. This is related to documentation_security, documentation_architecture, and implement_secure_design.

    The project does not currently have a consolidated security assurance case document. The required elements exist but are scattered across 50+ files


 Analysis 2/2 ●

  • Static code analysis


    Enough for a badge!

    The project MUST use at least one static analysis tool with rules or approaches to look for common vulnerabilities in the analyzed language or environment, if there is at least one FLOSS tool that can implement this criterion in the selected language. [static_analysis_common_vulnerabilities]
    Static analysis tools that are specifically designed to look for common vulnerabilities are more likely to find them. That said, using any static tools will typically help find some problems, so we are suggesting but not requiring this for the 'passing' level badge.

    bandit is specifically designed to find common security vulnerabilities in Python code (SQL injection, hardcoded passwords, insecure use of subprocess, weak cryptographic algorithms, etc.). It runs as part of the "Backend Security Scan" CI gate on every PR. Additionally, pip-audit scans dependencies against known vulnerability databases (OSV, PyPI advisory DB). Both tools are FLOSS and target security-specific weaknesses beyond general code quality.


  • Dynamic code analysis


    Enough for a badge!

    If the software produced by the project includes software written using a memory-unsafe language (e.g., C or C++), then at least one dynamic tool (e.g., a fuzzer or web application scanner) MUST be routinely used in combination with a mechanism to detect memory safety problems such as buffer overwrites. If the project does not produce software written in a memory-unsafe language, choose "not applicable" (N/A). [dynamic_analysis_unsafe]
    Examples of mechanisms to detect memory safety problems include Address Sanitizer (ASAN) (available in GCC and LLVM), Memory Sanitizer, and valgrind. Other potentially-used tools include thread sanitizer and undefined behavior sanitizer. Widespread assertions would also work.

    Sentinel is written entirely in Python (a memory-safe language). Its dependencies include some C/Rust extensions (asyncpg, pydantic-core, bcrypt), but these are third-party libraries maintained by their own projects with their own testing — Sentinel does not produce or modify memory-unsafe code. This criterion does not apply.



You can use tools and AI systems to propose changes via a simple URL, such as https://www.bestpractices.dev/en/projects/14063/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced. See our automation proposals system for how to do that. This data is available under the Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). This means that a Data Recipient may share the Data, with or without modifications, so long as the Data Recipient makes available the text of this agreement with the shared Data. Please credit Gianluca Gabrielli and the OpenSSF Best Practices badge contributors.

Project badge entry owned by: Gianluca Gabrielli.
Entry created on 2026-08-13 13:55:49 UTC, last updated on 2026-08-14 06:09:03 UTC. Last achieved passing badge on 2026-08-13 16:48:08 UTC.