What Secure Build guarantees

Secure Build is the set of Build Security features that check what you build before Loha treats it as releasable. This page lists only what the platform enforces, and says plainly where it stops. Each feature is turned on per workspace; ask your Loha contact which ones your workspace has.

What Loha does for each build

Step	What happens	Details
Scan	Loha scans your source and your built image itself, in its own jobs, outside your pipeline. Results are kept as evidence for that build.	Build Security
Decide	Your workspace policy (Off, Observe or Enforce) decides what a finding at or above your threshold does to the build.	Build Security
Track	The same problem across builds is one security issue, with a status, an owner and a fix deadline.	Security issues
Except	A known finding can pass the gate for a limited time, with a reason and a second person's approval.	Security exceptions
Sign	An image that passes the gate in Enforce is signed with your workspace key, with SLSA provenance and an SBOM attached in your registry.	Image signing
Fix	Loha can open a pull request that fixes a vulnerable npm or pnpm dependency, or re-pins a base image digest.	Fix pull requests
Watch push	Every push to a connected repository is scanned for secrets and gets a loha/secret-scan check.	Secret scanning on push

What Loha guarantees

Builds and releases (Enforce)

• A build that fails your policy is marked failed, gets no Release, and is never rolled out by Loha Delivery. Delivery re-checks the active policy before every rollout.
• On protected branches, pipelines that use Loha's own deploy tasks are refused. Deploy with Loha Delivery instead.
• Loha's own deploy credentials (target SSH keys, GitOps connection tokens) are never exposed to your pipeline's code. Automated tests enforce this.
• On the branches your policy protects, a build of a commit with an open secret issue is refused before it runs, with a link to the issue. The one exception is the build started by the same push that leaked the secret, because its scan lands after that build is planned.

People and approvals

• An exception always has a reason, an expiry and an approver who is not the person who asked for it. An exception across builds lasts at most 30 days, ends as soon as the issue is fixed, and never covers a secret.
• Accepting the risk of a CRITICAL issue, or triaging any secret, needs a second administrator. Loosening an Enforce policy needs a second administrator too.
• Every exception request, approval and revocation is recorded in the workspace audit log, and every triage decision in the issue's history.

Issues

• An issue is closed as fixed only by a completed scan of a tracked branch that covered that kind of finding. A failed or partial scan never closes one.
• Issues outlive the scan reports they came from. Deleting the workspace deletes them.
• Email and Teams messages name the CVE or rule, the package and the severity. They never contain file contents or secret values.

Images

• An image the gate blocked is never signed.
• Anyone with your workspace public key can verify the signature and the provenance with standard cosign, without Loha.
• Your signing private key is stored encrypted and used only inside the signing job. It is never shown or downloadable.

Fix pull requests

• Loha never commits to your default branch, never force-pushes and never merges for you.
• It never moves a dependency to a new major version.
• Lockfiles are regenerated with install scripts disabled, in a job that holds no Git credential.

What Loha does not guarantee

• A clean scan is not proof of no vulnerabilities. It means the scanner found nothing at or above your threshold, with the vulnerability data it had at the time.
• Observe never blocks and never signs. Only Enforce changes what happens to a build.
• Enforce decides after your pipeline's steps have run. It cannot stop a step from contacting an external system with credentials you supplied, and it does not hold back image pushes. A target that pulls a mutable tag such as :latest can still pick up a blocked image.
• Loha does not stop a cluster from running an unsigned image. Use an admission controller with your workspace public key for that. Images pushed to a registry Loha does not scan, or without a registry credential in Loha, are not signed.
• Secret scanning does not reject the push, scans only the newest commit of each push, and does not rotate or revoke anything.
• Fix pull requests cover npm, pnpm and Dockerfile base images only. Private npm registries and major-version upgrades are out of scope.

What stays your job

1. Deploy through Loha Delivery, or by image digest. Don't store deploy credentials as pipeline secrets if you rely on Enforce.
2. Rotate any leaked secret first. Removing it from the code does not undo the leak.
3. Work your issues within their deadlines. The defaults are CRITICAL 7 days, HIGH 30 days and MEDIUM 90 days.
4. Review and merge fix pull requests like any other change.
5. Enforce signatures where your images run, if you need only signed images in your cluster.