Kinotic OS
Supply Chain Security
How Kinotic inventories, scans and gates the container images it publishes, and where the evidence for each control is kept.
Overview
Every Kinotic service image is inventoried and scanned for known vulnerabilities before it is published. An image with a Critical vulnerability that has a published fix is never promoted to Docker Hub. Every control on this page runs automatically in the Build and Publish workflow (.github/workflows/gradle-build.yml), and each one leaves evidence in GitHub.
Scope
| Image | Published as |
|---|---|
| Kinotic management server | kinoticai/kinotic-server-management |
| Kinotic system server | kinoticai/kinotic-server-system |
| Kinotic app server | kinoticai/kinotic-server-app |
| Kinotic migration | kinoticai/kinotic-migration |
Controls
Software inventory (SBOM)
| Control | Each build produces a software bill of materials for each image. It lists every operating-system package and application library in the image, with its version. |
| Format | CycloneDX JSON, generated with Syft from the built image, not from source manifests. The inventory therefore matches what runs. |
| Frequency | Every build of the images: each pull request into develop or main, each push to them that changes application code, and nightly. |
| Evidence | Workflow run artifacts named sbom-kinotic-server-management.cdx.json, sbom-kinotic-server-system.cdx.json, sbom-kinotic-server-app.cdx.json and sbom-kinotic-migration.cdx.json. |
| Retention | 90 days. |
Vulnerability scanning
| Control | Grype scans each image's SBOM against current vulnerability advisories: GitHub Security Advisories, the National Vulnerability Database, and operating-system vendor feeds. The scan covers the same artifact the inventory records. |
| Frequency | Every build, including each pull request, and nightly. The nightly run checks newly published advisories against the current images. |
| Evidence | Findings of every severity are recorded as GitHub code scanning alerts in the categories image-kinotic-server-management, image-kinotic-server-system, image-kinotic-server-app and image-kinotic-migration, with open and fixed history per finding. Each workflow run's summary lists the fixable findings for each image. |
Release gate
| Control | A build fails when either image has a Critical vulnerability with a published fix. On a pull request, the failure is reported on the change before it merges. Only an image from a fully passing build of develop or main is promoted from the staging registry (ghcr.io) to Docker Hub. |
| Effect | An image is published only when, at build time, it has no known Critical vulnerability with an available fix. |
| Evidence | The SBOM and Vulnerability Scan jobs and the Build Result job of each workflow run. Build Result performs the promotion and records which job withheld it. |
Integrity of the scanning tools
| Control | Third-party actions in the scan job are pinned to full commit SHAs rather than version tags, so a repointed tag cannot change the code that runs. The scan job has read-only access to repository contents and holds no publishing, signing or deployment credentials. |
| Maintenance | Dependabot proposes updates to every workflow action weekly, including the pinned SHAs (.github/dependabot.yml). |
Source code analysis
| Control | CodeQL static analysis of the Java and TypeScript source. |
| Frequency | Every push to develop, and weekly. |
| Evidence | GitHub code scanning alerts from the CodeQL workflow. |
Control mapping
| Control | NIST SP 800-171 Rev 2 | SOC 2 | ISO/IEC 27001:2022 |
|---|---|---|---|
| Software inventory (SBOM) | 3.4.1 | CC7.1 | A.5.9, A.8.9 |
| Vulnerability scanning | 3.11.2 | CC7.1 | A.8.8 |
| Release gate | 3.11.3, 3.14.1 | CC7.1, CC8.1 | A.8.8, A.8.32 |
| Integrity of the scanning tools | 3.4.1, 3.14.1 | CC8.1 | A.8.25, A.8.28 |
| Source code analysis | 3.11.2 | CC7.1 | A.8.28 |
Development Server
A development environment for a few peers on one physical host, what it keeps in Azure, and how their applications move to Kinotic Cloud.
Enterprise License
Which parts of Kinotic are Enterprise Features, what running them in production requires, and how the license treats substitute implementations.