Every build can be checked before it ships.
Turn on checks per project and they run on the deploy path, not in a separate pipeline. A critical finding can hold the release.
Five checks write into one release record.
Each check writes its result into the deployment record; a check you have not enabled leaves none, so the record shows what ran.
| Check | What it inspects | Where the result shows | Can hold a release |
|---|---|---|---|
| Software bill of materials | Every library in the image, with version and license. | Downloadable from the deployment detail page. | No |
| Vulnerability scan | Known vulnerabilities in system packages and your dependencies. | The project's Security tab. | Yes |
| Secrets scan | Committed tokens and credentials, before the workspace is deleted. | The project's Security tab. A found secret blocks the deploy. | Yes |
| Runtime check | Whether the image's language runtime is still supported. | The project security status, before promotion. | Yes |
| Slim production image | The production layer: no shell or package manager, where the framework supports it. | The image itself. Scan results reflect what ships. | No |
Slim images cover a growing set of frameworks; elsewhere the standard image ships with the same checks.
A failed gate holds the release until someone decides.
Gates are set per environment. A failed one holds the release at the production gate, finding attached, until a person decides.
-
Severity gate
Holds on any vulnerability at or above the severity you set.
-
Runtime gate
Holds when the runtime is past end of life.
-
Approval gate
Requires a person to approve the promotion.
Your source is read once and not retained.
The repository is cloned with read-only GitHub access into a temporary build container, built, and the workspace destroyed.
Kept
- Container image and digest
- Build and runtime logs
- Check results, when enabled
- Deployment record
Not kept
- Source tree
- Write access to your repository
- Build workspace
Controls in place today. Certifications as they are earned.
No third party audit is complete yet. The controls below are in place; the audits will cover the items on the path.
In place today
- TLS 1.3 in transit
- Secrets encrypted at rest in Azure Key Vault
- Tenant isolation at the network and resource level
- SBOM, vulnerability scan, and secrets scan, when enabled per project
- Slim production images where the framework supports them
- Read-only GitHub access
- Source code not retained after the build
On the path
- SOC 2 Type I audit, planned, no auditor engaged yet
- Full audit log persistence, in progress
- Encryption keys managed by the customer
- HIPAA business associate agreement on Enterprise, when there is demand
- Platform penetration test, planned
For procurement reviews, email security@vibsl.com for the documentation we have today.
Ask the security team.
Request documentation or walk us through your requirements. Report vulnerabilities privately to security@vibsl.com first; we confirm receipt within three business days.
Machine readable details, as a plain text file for security researchers (RFC 9116): /.well-known/security.txt