>_ Engineering
How we ship.
Every release of this website goes through the same kind of pipeline we build for clients: facts checked, code built from recorded source, the live application tested, secrets and dependencies scanned, and the deployment rehearsed before production. These are the real results.
latest run · local-20261025-020856
- Passedresult
- 265 / 265automated checks passed
- 2m 44stotal stage time
- v3.2.0release under test
Oct 25, 2026 · ran on: Engineering workstation · SBOM: 114 components (CycloneDX) · dependency gate: passed
>_ 01 The pipeline
Seven stages, every release
A release can reach production only when every stage passes. Results shown are from the latest published run.
-
01
Facts & claims
Prices, service levels, CMMC dates and NAICS codes are cross-checked against the source documents. Banned or unprovable claims, broken links, weak contrast, page weight and the content security policy are checked too.
NIST 3.4.4
-
02
Build from source
Every change is applied as an exact, counted patch to the recorded application source. Any drift stops the build.
NIST 3.4.1NIST 3.4.3
-
03
Release integrity
Only intended files changed, file encodings are preserved, retired features are fully gone, and no secrets or internal details ship.
NIST 3.4.1NIST 3.4.2
-
04
Live application test
The built application runs in production mode and is driven end to end: public site, forms, client portal, every admin page, data retention and rate limits.
NIST 3.4.4
-
05
Secret scan
The whole repository is scanned for credentials and private keys.
NIST 3.4.2
-
06
Dependencies & SBOM
A CycloneDX software bill of materials is generated from the lockfile, and the release is blocked on any high or critical advisory.
NIST 3.4.1NIST 3.14.1
-
07
Deploy rehearsal
The real deploy, rollback, web-server and backup scripts run against a production look-alike (Ubuntu 24.04, nginx 1.24, Node 24), including injected failures that must roll back on their own.
NIST 3.4.4NIST 3.4.5
>_ 02 Run history
Recent runs
Published automatically from each run’s record: only results, counts and timings, never logs or internal details.
| Date | Ran on | Release | Result | Checks | Time |
|---|---|---|---|---|---|
| Oct 25, 2026 | Engineering workstation | v3.2.0 | passed | 265 / 265 | 2m 44s |
>_ 03 Controls
Mapped to NIST SP 800-171
How this pipeline supports configuration-management and flaw-remediation requirements that defense contractors are assessed against. Requirement text quoted from NIST SP 800-171 Rev. 2.
| Req. | Requirement | How this pipeline supports it |
|---|---|---|
| 3.4.1 | Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles. | Recorded source snapshot, archived release builds with file manifests, and an SBOM per release. |
| 3.4.2 | Establish and enforce security configuration settings for information technology products employed in organizational systems. | Security headers and the web-server configuration are generated and verified; repository-wide secret scan. |
| 3.4.3 | Track, review, approve or disapprove, and log changes to organizational systems. | Every change is a reviewed patch file; the owner approves by running the deploy; deploy logs are kept. |
| 3.4.4 | Analyze the security impact of changes prior to implementation. | The full test chain and a deploy rehearsal must pass before anything reaches production. |
| 3.4.5 | Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems. | Only the owner can deploy, and the admin console is reachable only from PDI’s internal network. |
| 3.14.1 | Identify, report, and correct system flaws in a timely manner. | Dependency advisories are checked on every run and high or critical findings block the release. |
Supporting a requirement is not the same as meeting it for your organization; that is decided in your own assessment.
>_ 04 Architecture
Internal tools stay internal
- Source lives in a private Git server; the build server runs these stages on the internal network.
- Only a sanitized run record leaves the network, inside a release. Nothing on the internet connects in.
- Production changes are approved by a person and applied by scripts that check everything first and roll back on their own.
Want this for your team?
We design and run pipelines like this with Jenkins, Gitea or GitHub, Ansible and Terraform, sized to your team and your compliance needs.