> ## Documentation Index
> Fetch the complete documentation index at: https://help.propops.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Software Supply Chain Transparency

> How PropOps Technologies Ltd builds, verifies, and distributes PropOps Web — covering source control, build pipelines, container attestation, dependency management, and artifact integrity.

<Info>
  **Effective date:** 8 April 2026\
  **Last updated:** 8 April 2026
</Info>

## 1. Introduction

PropOps Technologies Ltd ("PropOps", "we", "us") is committed to transparent, verifiable software delivery practices. This page describes how PropOps Web is built, packaged, and distributed — giving customers, auditors, and partners confidence in the integrity of every release.

Our supply chain practices are aligned with the <Tooltip tip="A security framework that helps organisations protect against supply chain attacks by verifying how software is built and distributed" headline="SLSA Framework">SLSA</Tooltip> (Supply-chain Levels for Software Artifacts) framework and follow industry guidance from the [NCSC](https://www.ncsc.gov.uk/).

***

## 2. Source Control

| Practice              | Detail                                                                                                                                                                                                                                                                                  |
| --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Version control**   | All source code is managed in a private, secure <Tooltip tip="A hosted platform for managing source code with built-in access controls, audit logs, and automated workflows" headline="Code Hosting Platform">code repository</Tooltip> under the PropOps Technologies Ltd organisation |
| **Branch protection** | Development and production branches are protected with required reviews and status checks                                                                                                                                                                                               |
| **Commit signing**    | Commits from automated pipelines are cryptographically signed using a verified bot identity                                                                                                                                                                                             |
| **Access control**    | Repository access is restricted to authorised personnel with <Tooltip tip="Permissions are assigned based on a person's role (e.g. developer, reviewer, administrator) rather than individually" headline="Role-Based Access">role-based permissions</Tooltip>                          |

***

## 3. Release Pipeline

PropOps Web follows a strict, multi-gate promotion model. Code is never deployed directly from development to production. Every release must pass through each gate in sequence before it can reach a customer environment.

### 3.1 Source Code Deployment

Every update is tracked via a transparent digital "Paper Trail," linking every feature and security patch to a unique, auditable commit. No change enters the pipeline without a full version-controlled history.

### 3.2 Code Quality Check

Automated <Tooltip tip="Tools that read your code without running it, checking for bugs, security issues, and style violations" headline="Static Analysis">Static Analysis</Tooltip> and <Tooltip tip="Automated checks that enforce coding standards and catch common mistakes" headline="Linting">Linting</Tooltip> ensure the codebase meets strict professional standards, eliminating logic flaws before they reach your server. This includes PHP syntax validation across all application files and verification that upload endpoints are properly hardened against dangerous file types.

### 3.3 Vulnerability Scan

Deep scans identify and flag supply chain risks in third-party libraries, ensuring no compromised dependency is ever integrated into a release.

### 3.4 Malware Scan

Every build artefact is scanned for malicious signatures to guarantee the software is neutralised and safe for your corporate network.

### 3.5 Snyk AI Vulnerability Scan

PropOps integrates industry-leading Snyk AI to perform real-time code analysis. This ensures that every line of logic is screened for <Tooltip tip="A previously unknown security flaw that attackers can exploit before a fix is available" headline="Zero-Day Exploit">zero-day exploits</Tooltip> and regulatory non-compliance before it ever touches your data, providing a continuous safety net that legacy systems cannot offer.

### 3.6 Staging & Human Testing

Every build is first deployed to an isolated staging environment for manual <Tooltip tip="Testing performed by real people to confirm the software works correctly from a user's perspective before it goes live" headline="User Acceptance Testing">User Acceptance Testing (UAT)</Tooltip> to ensure flawless UI/UX performance. The staging environment is rebuilt from scratch on every deployment — not incrementally patched — eliminating configuration drift.

### 3.7 Approve System Changes

No code reaches production without a manual <Tooltip tip="A qualified colleague reviews every line of changed code to catch mistakes, security issues, or design problems" headline="Peer Review">Peer Review</Tooltip> and Senior Sign-off, serving as a final human guard gate for stability. A <Tooltip tip="A formal request to merge code changes that must be reviewed and approved before it takes effect" headline="Pull Request">pull request</Tooltip> is opened for review, and the merge must be explicitly approved before any code is promoted.

### 3.8 Pre-Package Clean-up

All development tools, test suites, build manifests, and non-essential files are stripped from the deployable artefact, creating a lean, hardened production asset with a reduced attack surface. The following are removed:

* Development configuration and IDE files
* Test suites and documentation
* Build manifests and lock files
* Source control metadata

### 3.9 Cryptographic Signing

We use <Tooltip tip="A digital certificate attached to a software release that proves who built it and that it hasn't been modified since" headline="Artifact Attestation">Artifact Attestations</Tooltip> to digitally sign every release with <Tooltip tip="A security standard that creates a verifiable record of how software was built, proving it came from a trusted source" headline="SLSA Build Provenance">**SLSA Build Provenance**</Tooltip>, providing a seal of authenticity that guarantees the code is untampered. This cryptographic attestation proves what was built, where it was built, how it was built, and who triggered the build.

### 3.10 Docker Release

The verified code is delivered in a <Tooltip tip="A self-contained package that includes the application and everything it needs to run, ensuring identical behaviour everywhere it's deployed" headline="Docker Container">Docker Container</Tooltip>, ensuring the environment you host is identical to the one we secured and tested. Container images are published to a secure, private <Tooltip tip="A secure storage service for Docker container images, similar to a private app store for server software" headline="Container Registry">container registry</Tooltip>.

***

## 4. Container Image Details

Production releases are distributed as Docker container images.

### 4.1 Image Construction

| Property         | Value                                                                                                                                                                                      |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Base image**   | `php:8.5-apache` (official Docker Hub image)                                                                                                                                               |
| **Registry**     | Private <Tooltip tip="A secure storage service for Docker container images, similar to a private app store for server software" headline="Container Registry">container registry</Tooltip> |
| **Build runner** | Cloud-hosted build environment                                                                                                                                                             |
| **Build tool**   | <Tooltip tip="An advanced Docker build engine that supports caching for faster builds" headline="Docker Buildx">Docker Buildx</Tooltip> with build cache                                   |
| **Trigger**      | Automatic when a release PR is approved and merged                                                                                                                                         |

### 4.2 Image Tags

Each image is published with three tags for traceability:

| Tag                                         | Purpose                           |
| ------------------------------------------- | --------------------------------- |
| `latest` or custom version (e.g., `v1.2.3`) | Human-readable release identifier |
| Short SHA (e.g., `a1b2c3d`)                 | Exact commit traceability         |
| Build date (e.g., `build-20260408`)         | Temporal reference                |

### 4.3 Image Labels

Every image carries <Tooltip tip="A set of industry-standard metadata fields defined by the Open Container Initiative that describe what's inside a container image" headline="OCI Labels">OCI-standard labels</Tooltip> including:

* Source repository link
* Full <Tooltip tip="A unique fingerprint that identifies the exact version of code used to build the image" headline="Commit SHA">commit SHA</Tooltip>
* Vendor identification (PropOps Technologies Ltd)

***

## 5. Verifying a Release

Customers and auditors can independently verify any PropOps Web container image to confirm it was built by our <Tooltip tip="A set of automated steps that build, test, and deliver software without manual intervention" headline="CI/CD Pipeline">CI/CD pipeline</Tooltip> from the expected source code and has not been tampered with.

### 5.1 How to Verify

You can verify any release using the <Tooltip tip="A command-line tool that lets you interact with your code repository, including verifying cryptographic attestations on container images" headline="CLI Verification Tool">`gh` CLI tool</Tooltip>. Run the following command, replacing the tag with the version you want to check:

```bash theme={null}
gh attestation verify oci://ghcr.io/propops-technologies-ltd/propops-web:<TAG> \
  --owner PropOps-Technologies-Ltd
```

A successful result confirms:

* The image was built by the PropOps automated pipeline
* It was built from the expected source repository
* It has not been modified since it was signed

If verification fails, do not deploy the image and contact [security@propops.co.uk](mailto:security@propops.co.uk) immediately.

### 5.2 Release Log

The table below is automatically updated each time a new production release is built and attested.

| Date              | Version | Commit | Digest | Attested |
| ----------------- | ------- | ------ | ------ | -------- |
| *No releases yet* | —       | —      | —      | —        |

***

## 6. Dependency Management

### 6.1 PHP Dependencies

| Practice               | Detail                                                                                                               |
| ---------------------- | -------------------------------------------------------------------------------------------------------------------- |
| **Package manager**    | Composer                                                                                                             |
| **Lock file**          | `composer.lock` is committed to source control, ensuring reproducible installs                                       |
| **Production install** | `composer install --no-dev --optimize-autoloader` — development dependencies are never included in deployable builds |

### 6.2 JavaScript Dependencies

| Practice             | Detail                                                                                          |
| -------------------- | ----------------------------------------------------------------------------------------------- |
| **Package manager**  | npm                                                                                             |
| **Lock file**        | `package-lock.json` is committed to source control                                              |
| **Production build** | `npm ci` for deterministic installs; `node_modules` is removed after build assets are generated |

### 6.3 Automated Dependency Updates

Automated dependency monitoring scans all third-party libraries for known <Tooltip tip="A weakness in software that could be exploited by attackers — tracked in public databases like CVE" headline="Vulnerability">vulnerabilities</Tooltip> and automatically proposes updates when security patches are available.

***

## 7. File Integrity & Checksums

### 7.1 Build-Time Checksums

During every production Docker image build, <Tooltip tip="A unique digital fingerprint generated from a file's contents — if even one byte changes, the fingerprint is completely different" headline="SHA-256 Checksum">SHA-256 checksums</Tooltip> are generated for all application files. These checksums are:

* Computed at build time from the exact files included in the image
* Structured as a JSON payload containing the file path and corresponding hash for each file
* Published to the PropOps integrity verification endpoint for later comparison

### 7.2 Runtime Integrity Monitoring

PropOps Web includes runtime file integrity checks via scheduled cron tasks. These compare the deployed file state against known-good checksums and alert administrators if unexpected modifications are detected.

***

## 8. Environment & Secrets Management

| Practice              | Detail                                                                                                                                                                                                                                                                                                   |
| --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Secrets storage**   | All deployment credentials and API keys are stored in encrypted secret vaults within the build platform — never committed to source code                                                                                                                                                                 |
| **Environment files** | Configuration files are excluded from the Docker image. On first container start, the entrypoint script generates a secure configuration from a template with auto-generated encryption keys                                                                                                             |
| **Encryption keys**   | Encryption and authentication keys are automatically generated on first boot if not provided, using <Tooltip tip="Random values generated by a secure algorithm that cannot be predicted or reproduced" headline="Cryptographically Secure Random Bytes">cryptographically secure random bytes</Tooltip> |
| **File permissions**  | Sensitive configuration files are restricted to owner read/write only inside the container                                                                                                                                                                                                               |

***

## 9. Persistent Data

User uploads, configuration, and database data are stored on host-mounted volumes outside the container. Container rebuilds and updates do not affect persistent data.

***

## 10. Incident Response

If a supply chain compromise is suspected:

1. We revoke and rotate all affected credentials and signing keys
2. We rebuild and re-attest affected images from verified source
3. We notify affected customers through our standard communication channels
4. We publish a post-incident summary describing the scope, impact, and remediation

***

## 11. Contact

For questions about our software supply chain practices, or to report a security concern:

* **Email:** [security@propops.co.uk](mailto:security@propops.co.uk)
* **Website:** [propops.co.uk](https://propops.co.uk)

***

## 12. Changes to This Page

We may update this page as our build and delivery practices evolve. Material changes will be reflected in the "Last updated" date at the top of this page.