carbon-footprint-program

Repository on GitHub, which provides public git repositories with URLs: https://github.com/undp/carbon-footprint-program (visibility: public).

Repository on GitHub, which uses git. git records the author, committer and timestamp of every change, together with the full parent history.

Development happens in the open between releases: every change lands as a pull request merged to main, and those interim commits are public immediately rather than only at release time. 519 commits, 505 pull requests (425 of them merged) and 49 issues are publicly visible, and each release is cut from already-public main history rather than from a private branch.

Repository on GitHub, which uses git. git is a distributed version control system.

Every release has a unique identifier: an annotated git tag and a matching GitHub Release (1.1.1, 1.1.2, 1.2.0, 1.3.0, 1.3.1, 1.3.2, 1.4.0, 1.4.1, 1.4.2, 1.5.0, 1.6.0) — see https://github.com/undp/carbon-footprint-program/releases. The canonical version lives in the root package.json, is baked into the Docker image tag, and is exposed at runtime through the APP_VERSION value returned by the API health endpoint.

The project uses Semantic Versioning (MAJOR.MINOR.PATCH) and documents the increment rules at https://github.com/undp/carbon-footprint-program/blob/main/docs/release/versioning.md. The published tags follow SemVer (e.g. 1.4.1 → 1.4.2 for fixes, 1.5.0 → 1.6.0 for backward-compatible features).

Each release is identified by a git tag with the exact version number, and the tag is what the GitHub Release points at: https://github.com/undp/carbon-footprint-program/tags.

Every release publishes human-readable release notes as a GitHub Release: https://github.com/undp/carbon-footprint-program/releases. Each entry has a "What's Changed" summary grouped by area (e.g. "User Modules", infrastructure, dependencies) listing each merged change with its author and pull-request link — for example https://github.com/undp/carbon-footprint-program/releases/tag/1.6.0. Notes are provided for all eleven releases, 1.1.1 through 1.6.0.

No publicly known, CVE-assigned vulnerability in this project's own code has been fixed in any release to date, so there is nothing of that kind to enumerate. Dependency vulnerabilities are handled by Dependabot security updates, and the resulting pull requests appear by name in the "What's Changed" list of the release that includes them (see https://github.com/undp/carbon-footprint-program/releases). Should a vulnerability in the project's own code ever be fixed, SECURITY.md commits the maintainers to coordinated disclosure and the release notes will call it out.

The bug-reporting process is documented in three places: CONTRIBUTING.md "Reporting bugs & requesting features" https://github.com/undp/carbon-footprint-program/blob/main/CONTRIBUTING.md, .github/SUPPORT.md, which routes each kind of report to the right channel https://github.com/undp/carbon-footprint-program/blob/main/.github/SUPPORT.md, and structured issue forms at https://github.com/undp/carbon-footprint-program/issues/new/choose (bug report, feature request, refactor, DPG compliance). Security vulnerabilities are explicitly excluded from public issues and routed to the private process in https://github.com/undp/carbon-footprint-program/blob/main/SECURITY.md.

GitHub Issues is used as the issue tracker: https://github.com/undp/carbon-footprint-program/issues. It is backed by structured issue forms in .github/ISSUE_TEMPLATE/ (bug_report.yml, feature_request.yml, refactor.yml, dpg_compliance.yml) and a namespaced label taxonomy maintained as code in .github/labels.yml (type:, area:, priority:, status:), so reports are consistently classified and triaged.

Bug reports are consistently acknowledged and acted on. Of the 49 issues filed in the last 12 months, 18 are already closed, and bugs are typically triaged within a day — for example issue #547 (equivalence computed in the wrong unit) was filed 2026-07-28 and fixed and closed 2026-07-29 by PR #550. Every incoming report is labelled (type:bug, area:, priority:, status:triage), which is the acknowledgement step, and priority:critical bugs such as #395 and #391 were closed with fixes. To date no report has been left unanswered.

Enhancement requests are triaged the same way as bugs: they are labelled type:feature (or type:refactor / type:tech-debt), given an area and a priority, and either scheduled or answered in the thread. Several have been implemented and shipped — for example the "optional comment on approving a submission" request (PR #409, released in 1.6.0) and the provider-agnostic backend auth refactor (#398, closed 2026-07-09). Requests that conflict with the project's country-agnosticism principle are answered with that rationale, as documented in .github/SUPPORT.md.

The issue tracker is public, searchable and permanently archived at https://github.com/undp/carbon-footprint-program/issues?q=is%3Aissue, covering both open and closed issues. Pull-request discussions are similarly public at https://github.com/undp/carbon-footprint-program/pulls?q=is%3Apr, and GitHub Discussions is enabled for longer-form threads.

The vulnerability reporting process is published in https://github.com/undp/carbon-footprint-program/blob/main/SECURITY.md. The declared security contact is the maintainer team collectively — the @undp/carbon-footprint-program-maintainers GitHub team (see https://github.com/undp/carbon-footprint-program/blob/main/.github/CODEOWNERS and https://github.com/undp/carbon-footprint-program/blob/main/GOVERNANCE.md) — so handling a report never depends on one individual's availability. SECURITY.md states that vulnerabilities must not be reported through public issues, discussions or pull requests, names GitHub private vulnerability reporting as the private channel, tells a reporter who cannot use it to open a detail-free issue requesting a private channel, and gives an escalation path to the maintainer team after 5 business days. It also lists what to include in a report and the in-scope and out-of-scope components.

Private reporting is available through GitHub Private Vulnerability Reporting, which is enabled on the repository and reachable from the Security tab at https://github.com/undp/carbon-footprint-program/security/advisories. It is documented as the preferred channel in https://github.com/undp/carbon-footprint-program/blob/main/SECURITY.md. Reports go privately to the maintainer team collectively (@undp/carbon-footprint-program-maintainers) rather than to a named individual, which keeps the report, the discussion, the fix and any resulting advisory in one private place with no single point of failure. SECURITY.md explicitly asks reporters not to use public issues, discussions or pull requests, and offers a detail-free public issue as a way to request a private channel for anyone who cannot use GitHub PVR.

https://github.com/undp/carbon-footprint-program/blob/main/SECURITY.md publishes the maintainer team's commitment to acknowledge a vulnerability report within 3 business days — well inside the 14-day requirement — and tells reporters to escalate to the maintainer team if they have not heard back within 5 business days. It further commits to validating the issue, agreeing a remediation timeline with the reporter, and practising coordinated disclosure with credit unless the reporter prefers anonymity. In the interest of accuracy: this is the maintainer team's published working target, and formal ratification of the acknowledgement and remediation SLAs by UNDP as the owning organization is still in progress (tracked in issue #460).

The software is built from source with two standard commands: "pnpm install" then "pnpm build". The root package.json "build" script drives Turborepo, which builds the shared packages (@repo/types, constants, utils, database, storage), the Fastify API and the React/Vite web app in dependency order. Prerequisites and exact toolchain versions are pinned in .tool-versions and .nvmrc and documented in https://github.com/undp/carbon-footprint-program/blob/main/docs/development/local-setup.md. CI proves the build works from a clean checkout on every pull request via the required "Build" job in .github/workflows/ci.yml.

The build uses widely available, conventional tooling: Node.js, pnpm (workspaces), Turborepo, the TypeScript compiler (tsc), Vite for the web bundle, Prisma for schema/client generation, and Docker for containerization. There are no bespoke build tools to learn.

Every tool required to build the project is FLOSS: Node.js, pnpm, Turborepo, TypeScript, Vite, Prisma, ESLint, Prettier, Vitest and Docker. The project can be built and tested end to end on a FLOSS platform with no proprietary software; a docker-compose setup provides Postgres, Keycloak and MinIO as open-source local dependencies.

The project has an automated test suite documented at https://github.com/undp/carbon-footprint-program/blob/main/docs/development/testing.md. apps/api has 199 test files, of which 161 are integration tests that exercise real HTTP routes through Fastify's app.inject() against a real PostgreSQL instance provisioned with Testcontainers (plus Azurite and MinIO for the storage legs). apps/web adds 37 Vitest suites running under jsdom with React Testing Library. tools/seed has its own unit suite. The whole suite runs in CI on every pull request.

The suite runs with the standard single command "pnpm test" from the repository root (Turborepo fans it out to every workspace). Narrower entry points exist for convenience: "pnpm test:api", "pnpm test:web", "pnpm test:seed", and "pnpm test:api -- /<feature>" for a single feature.

The test suite covers most of the code and most of the functionality. apps/api — which holds essentially all of the business logic, including emission calculations, authorization, and the data layer — is gated in CI at 90% coverage for lines, statements, functions and branches, merged across the three test legs by the required "Coverage" job in .github/workflows/ci.yml. That gate is enforced on every pull request, so the figure is a floor rather than a snapshot, and every externally reachable endpoint has an integration test (161 integration test files exercising real HTTP routes against a real PostgreSQL instance via Testcontainers). Stated transparently: apps/web is covered by a smaller Vitest + jsdom + React Testing Library suite (37 files) over its logic layers — utils, hooks, stores, chatbot — behind an enforced floor that is deliberately ratcheted upward as tests are added, so a share of its render-heavy UI is not yet covered. The judgement recorded here is that a 90%-gated backend plus a growing frontend suite satisfies "most".

Continuous integration runs the full suite on every pull request to main via .github/workflows/ci.yml. "Test (base)", "Test (storage-azure)", "Test (storage-minio)", "Test (web)", "Seed Unit Tests" and "Coverage" are required status checks under branch protection, alongside Lint, Type Check, Format Check, Build, Audit, Zizmor, Secret Scan and Docs Link Check. See https://github.com/undp/carbon-footprint-program/actions/workflows/ci.yml.

The policy is written down in CONTRIBUTING.md under "Contribution acceptance criteria": "Test coverage — new features include integration tests" https://github.com/undp/carbon-footprint-program/blob/main/CONTRIBUTING.md#contribution-acceptance-criteria. docs/development/testing.md gives the concrete conventions for writing them, and the policy is mechanically enforced by the 90% merged-coverage gate in CI, which fails a pull request that adds logic without adding tests.

Tests accompany functional changes as a matter of course — apps/api currently carries 199 test files across 161 integration suites, grown alongside the features they cover, and apps/web has 37. The requirement is enforced rather than merely encouraged: the required "Coverage" check re-computes merged coverage across all three test legs and fails below 90% on lines, statements, functions and branches, so a feature pull request without matching tests cannot merge. Recent examples of test-only ratchets are PRs #509, #515 and #518.

The policy is documented in two places: the "Contribution acceptance criteria" section of https://github.com/undp/carbon-footprint-program/blob/main/CONTRIBUTING.md, and the testing guide at https://github.com/undp/carbon-footprint-program/blob/main/docs/development/testing.md, which explains the Vitest + Testcontainers setup, the app.inject() pattern, and the factory helpers a contributor should use when adding tests.

Compiler and linter warnings are enabled at a strict level. TypeScript runs with "strict": true (packages/typescript-config/base.json), and ESLint uses typescript-eslint's recommendedTypeChecked configuration (packages/eslint-config/base.ts), which requires full type information and therefore reports type-aware problems, not just syntactic ones. Both run over the whole monorepo via "pnpm lint" and "pnpm type-check".

There are no outstanding warnings, and the build enforces that: "pnpm lint" is invoked as "turbo run lint -- --max-warnings=0", so a single ESLint warning fails the required "Lint" status check, and "pnpm type-check" fails the required "Type Check" check on any TypeScript error. Both are required checks under branch protection, so warnings cannot accumulate on main.

Maximally strict settings are enabled rather than the defaults: TypeScript "strict": true, and typescript-eslint's recommendedTypeChecked ruleset, which needs a full type-checked program and catches classes of bug (unsafe any flow, floating promises, unnecessary conditionals) that non-type-aware linting cannot see. Prettier formatting is separately enforced by a required "Format Check" job.

The maintainer team collectively (@undp/carbon-footprint-program-maintainers — see https://github.com/undp/carbon-footprint-program/blob/main/.github/CODEOWNERS and https://github.com/undp/carbon-footprint-program/blob/main/GOVERNANCE.md) holds and applies the knowledge of how to design secure software; this is asserted for the team rather than for one individual, matching how the project is actually governed and reviewed. The design record is public under docs/security/ https://github.com/undp/carbon-footprint-program/tree/main/docs/security: authentication.md (OIDC/JWKS token verification), rbac.md and route-access-modes.md (role-based authorization applied per route), hardening.md (deployment topologies, TLS enforcement, HTTP security headers, input validation, upload controls), secrets.md (Azure Key Vault with managed identities, no credentials in code), sensitive-data.md, audit-logging.md, and github-actions-security.md. The principles are visible in the code, not just the docs: least privilege via per-route role guards; fail-closed defaults — the API refuses to boot in production unless JWKS_URI, JWKS_ISSUER and JWKS_AUDIENCE are set, rather than silently accepting tokens it cannot bind to this application (apps/api/src/config/environment.ts); defense in depth (helmet headers, then schema validation, then authorization, then audit logging); minimal attack surface; and no trust in client-supplied identity. CONTRIBUTING.md requires an explicit maintainer security review for any change to auth, authorization, file upload or database queries, which is how the knowledge is applied structurally rather than incidentally. Complementary documents are SECURITY.md and PRIVACY.md.

The maintainer team collectively (@undp/carbon-footprint-program-maintainers) holds this knowledge, and the codebase reflects it. Injection: all database access goes through Prisma's parameterized query builder; there is no string-concatenated SQL. Input validation: every request body, query and parameter is validated against a Zod schema at the route boundary (schemas live in packages/types), so unvalidated input never reaches business logic. Broken access control: authorization is enforced server-side by explicit requireAuth / requireRoles / requireOrganizationRole hooks per route, documented in docs/security/rbac.md and route-access-modes.md and covered by integration tests. XSS and header attacks: @fastify/helmet applies secure headers globally and React escapes by default. Insecure direct object references: domain access hooks verify organization membership before returning records. Secrets in code: Azure Key Vault with managed identities, plus GitHub secret scanning with push protection and a betterleaks CI gate over full git history. Race conditions and partial writes: multi-step mutations run inside Prisma transactions. These classes are also checked mechanically by CodeQL's security-and-quality suite on every push and pull request. The team also files its own hardening findings publicly rather than leaving them implicit — see issue #559, which pins an explicit JWT algorithms allowlist to close an algorithm-confusion surface found while preparing this badge.

The project uses only standard, published cryptographic protocols and algorithms: TLS 1.2+ for all transport, RSA/ECDSA signature verification of OIDC JWTs via JWKS (@fastify/jwt with jwks-rsa), SHA-2 family digests, and AES-256 for encryption at rest in Azure Storage. No proprietary or homegrown cryptography is used or implemented.

The project does not implement cryptography itself; it calls established, well-reviewed implementations: Node.js node:crypto (OpenSSL) for random values, @fastify/jwt and jwks-rsa for JWT signature verification and key retrieval, and the platform TLS stacks of Azure Front Door, App Service and Static Web Apps for transport. Password handling is delegated entirely to the external OIDC identity provider.

All cryptographic functionality relies on FLOSS implementations: Node.js and its bundled OpenSSL, @fastify/jwt (MIT), jwks-rsa (MIT), and — in the fully open local/self-hosted configuration — Keycloak as the OIDC provider and MinIO for object storage. No proprietary crypto implementation is required to run the software.

All default key lengths meet or exceed the NIST minimums, and the application never generates its own long-term asymmetric keys — every key it relies on is issued by a platform service or the identity provider. TLS certificates are issued and managed by the Azure services that terminate TLS (Static Web Apps for the frontend and App Service for the API; Azure Front Door additionally where an adopting country chooses to deploy it), using 2048-bit RSA or ECDSA P-256 keys; minTlsVersion is pinned to 1.2 in the Bicep templates, so only suites with 128-bit-or-better symmetric keys are negotiated. OIDC token-signing keys are fetched from the provider's JWKS endpoint: the demo environment uses Microsoft Entra ID, which signs with RSA-2048, and Keycloak — the open-source option documented for self-hosting — also defaults to RSA-2048. Encryption at rest in Azure Storage is AES-256. Symmetric secrets the project does control (cookie signing) are supplied from Azure Key Vault, never from a checked-in default.

The default configuration uses no broken or known-weak cryptographic algorithm or mode. TLS is pinned to a 1.2 minimum at every tier (infra/modules/appService.bicep, storage.bicep, frontDoor.bicep), excluding SSLv3, TLS 1.0 and 1.1 and their weak suites. MD5, SHA-1, DES, 3DES, RC4 and ECB mode are not used anywhere in the codebase; digests are SHA-2 family. Token signatures are verified against asymmetric public keys fetched from the identity provider's JWKS endpoint, and in production the API refuses to boot unless JWKS_URI, JWKS_ISSUER and JWKS_AUDIENCE are all set, so a token whose issuer or audience does not bind to this application is rejected (apps/api/src/config/environment.ts). Stated precisely rather than generously: the verify options pin issuer and audience but do not yet pin an explicit "algorithms" allowlist, so the accepted signature-algorithm set is currently inherited from the JWT library's key-type inference rather than asserted by the project. No broken algorithm is reachable, but that guarantee should be ours and not a dependency default — it is tracked publicly as a hardening item in issue #559 https://github.com/undp/carbon-footprint-program/issues/559.

The default configuration does not depend on cryptographically broken primitives. MD5, SHA-1, DES, 3DES and RC4 are not used for any security purpose; digests are SHA-2 family, and TLS 1.2+ enforcement excludes SHA-1-signed handshake suites. Container base images and dependencies are pinned by SHA-256 digest, and pnpm verifies package integrity with SHA-512 hashes.

Forward secrecy is provided by the Azure platform services that terminate TLS; the application implements no TLS itself and ships no certificate or cipher-suite configuration. In the default topology TLS terminates at Azure Static Web Apps (frontend) and Azure App Service (API, which faces the public internet directly in the demo environment); an adopting country may additionally place Azure Front Door in front, which is optional per deployment rather than required by the platform. All of these negotiate TLS 1.2+ with ECDHE (ephemeral Diffie-Hellman) key exchange, which gives perfect forward secrecy, and the Bicep templates pin minTlsVersion to 1.2 so no non-PFS legacy suite can be selected. Because Front Door is optional, this property does not depend on it — it holds in every supported topology. See docs/security/hardening.md, "Deployment topology" and "Transport Security".

The project does not store passwords for authentication of external users, so there is nothing to hash or salt. Authentication is delegated entirely to an external OpenID Connect identity provider (Microsoft Entra ID in the reference deployment, Keycloak in the open-source/local configuration). The API only verifies signed JWTs against the provider JWKS and never sees, transmits or persists a user credential; there is no local password table, reset flow, or credential column in the Prisma schema. See docs/security/authentication.md.

All security-relevant random values come from a cryptographically secure PRNG: the project uses randomUUID() from Node.js node:crypto (backed by OpenSSL) for request identifiers (apps/api/src/app.ts), chatbot session identifiers, and the opaque UUIDs that name uploaded objects in storage (apps/api/src/features/files/requestUpload/service.ts and the carbon-inventory line-file equivalent). Math.random() is not used for any security purpose. Session and token generation itself is handled by the external OIDC provider.

Distribution channels use HTTPS exclusively. Source is distributed by GitHub over HTTPS or SSH, so the transport is authenticated and integrity-protected. Dependencies are installed from the registry over HTTPS with "pnpm install --frozen-lockfile", and pnpm-lock.yaml records an integrity hash for every package. Container base images are pinned by SHA-256 digest, and all GitHub Actions are pinned to full commit SHAs rather than mutable tags, so the CI supply chain cannot be silently redirected.

No cryptographic hash or signature is retrieved over an unprotected channel. Package integrity hashes are committed in pnpm-lock.yaml inside the repository itself and fetched from the registry only over HTTPS; container base-image digests are committed in the Dockerfiles; GitHub Action versions are committed as full commit SHAs. Nothing in the build downloads a checksum over plain HTTP or from an untrusted mirror.

Known dependency vulnerabilities are surfaced and fixed continuously rather than on a 60-day clock. "pnpm audit --prod --audit-level moderate" runs as the required "Audit" status check on every pull request, so a moderate-or-higher advisory in the production dependency graph blocks merges until it is resolved. Dependabot security updates and alerts are enabled, with weekly version updates across the npm, docker and github-actions ecosystems (.github/dependabot.yml). A Trivy workflow scans dependencies and container images on pushes to main and on pull requests, and CodeQL runs on every push, pull request and weekly. Deliberate, time-boxed deferrals are tracked publicly in a periodic-review issue with an explicit re-check condition for each.

Critical vulnerabilities are addressed promptly because the gates are blocking rather than advisory: the required "Audit" check fails the pull request on any moderate-or-higher advisory in the production dependency graph, so a critical one cannot reach main. Dependabot security updates open fix pull requests automatically, Trivy scans images and dependencies on push and pull request, and CodeQL findings land in GitHub code scanning for triage. Security-relevant issues are additionally labelled type:security and priority:critical in the tracker so they are visible and prioritized.

No valid credential intended to limit public access is present in the repository, and three independent controls enforce that: GitHub secret scanning with push protection is enabled; a betterleaks job (the maintained gitleaks successor) runs on every pull request with fetch-depth 0, scanning the entire git history against .gitleaks.toml, and reports zero findings; and all .env* files are gitignored, with runtime secrets supplied from Azure Key Vault via managed identities (docs/security/secrets.md). Reported precisely: on main, apps/api/src/config/environment.ts still carries one hardcoded literal — a local-development HMAC fallback for JWT_SECRET. It is not a credential for any deployed system, because production fails closed and refuses to boot unless JWKS_URI, JWKS_ISSUER and JWKS_AUDIENCE are set, so the fallback cannot be used to accept forged tokens in a real deployment. It is nonetheless being removed outright for defense in depth: the change deletes the built-in default, makes AUTH_PROVIDER=jwks without JWKS_URI refuse to boot unless JWT_SECRET is set explicitly, and ships a throwaway value in .envrc.template and .env.dockercompose.example so local setup configures one deliberately. This entry will be tightened once that change is merged.

At least one static analysis tool with security relevance is applied to every proposed major production release, and in fact to every pull request. CodeQL runs the "security-and-quality" query suite on every push to main, every pull request, and on a weekly schedule, uploading results to GitHub code scanning (.github/workflows/codeql.yml). Alongside it: ESLint with typescript-eslint recommendedTypeChecked (full type-aware analysis), tsc --strict, zizmor auditing the GitHub Actions workflows for supply-chain and template-injection issues, Trivy scanning dependencies and container images, and betterleaks scanning git history for secrets. All of these are required status checks on pull requests to main. See https://github.com/undp/carbon-footprint-program/actions/workflows/codeql.yml.

CodeQL is configured with the "security-and-quality" query suite, which is explicitly a look for common vulnerability patterns — injection, path traversal, unsafe deserialization, SSRF, hardcoded credentials, prototype pollution and the rest of the JavaScript/TypeScript CWE coverage — rather than style-only checks. Results are uploaded to GitHub code scanning. It is complemented by Trivy for known-CVE scanning of dependencies and images and zizmor for GitHub Actions-specific vulnerability classes.

Findings are fixed rather than accumulated, because the analyzers are blocking gates. "Lint" runs with --max-warnings=0 and "Type Check" fails on any error; both are required checks. The zizmor and Secret Scan jobs fail the build on any finding. CodeQL alerts appear in GitHub code scanning and are triaged by the maintainer team, with security-relevant work tracked as type:security issues. Where a Trivy finding cannot yet be acted on, it is recorded as an explicit, reviewed exception in .trivyignore.yaml rather than silently ignored.

Static analysis runs far more often than at each release: CodeQL on every push to main, every pull request, and weekly on a schedule; ESLint, tsc, zizmor, betterleaks and Trivy on every pull request; and the OpenSSF Scorecard workflow weekly and whenever branch protection changes. So every proposed change is analyzed before it can merge, and the scheduled runs catch newly published advisories against unchanged code.

The project is written in TypeScript running on Node.js (with a small amount of shell and Bicep). These are memory-safe, garbage-collected environments with no manual memory management, no pointer arithmetic and no unchecked buffer access, so the memory-safety checkers this criterion refers to (ASan/valgrind-class tools) do not apply. There is no C, C++ or other unsafe-language code in the codebase.

Runtime checks are enabled during test execution rather than compiled out. Every API request and response is validated against a Zod schema at the route boundary, and a schema violation throws — so the integration suite fails loudly on any contract breach, which is exactly the assertion behaviour this criterion asks for. TypeScript runs in strict mode, and the test environment additionally exercises the fail-closed configuration guards in apps/api/src/config/environment.ts. No assertion or validation layer is disabled in the test configuration.

No dedicated dynamic analysis (fuzzing or DAST) is currently performed — see the dynamic_analysis criterion — so there are no dynamic-analysis findings, of medium severity or otherwise, outstanding to fix. Vulnerabilities discovered by any other route (CodeQL, Trivy, pnpm audit, Dependabot, or a private report under SECURITY.md) are triaged and fixed under the processes described in those criteria.