Controls that refuse to run.
Most vendors describe a security posture. This page lists the controls that stop work from shipping, the scanners that run against what gets built, and where your data actually goes.
Controls that enforce themselves.
A guideline is something a careful operator remembers on a good day. Every control below is enforced as a pipeline property. Each one traces to a real failure in Zedlav’s own work.
Deliverables are checked before they leave
Every file that reaches you is verified for accuracy and for material that belongs to another engagement. Not reviewed when someone remembers. Checked as a condition of release.
Work lands where it was scoped to land
A deploy to an environment outside the agreed scope does not happen. There is no confirmation prompt to click through at the end of a long day.
The number in the report is the number that was there
An unsourced claim cannot reach a deliverable. This is a property of the pipeline, not a habit.
One engagement cannot reach another
Client material is isolated by construction. Not by a policy someone is trusted to remember.
A warning gets ignored on a busy Friday. A control wired into the pipeline does not have that option.
This is the reason the security story starts with enforcement instead of with a scanner. Tooling finds problems. Controls decide whether flawed work is allowed to reach a client, and that decision is the one that actually protects you. Every high-blast-radius call still requires explicit human approval.
Scanned before it ships.
Sites and platforms built here get put through two scanners, and the output lands in one merged report instead of two tool dashboards nobody opens.
Two scanners, one pass. Sites built here are scanned before launch against known vulnerabilities, exposed files, and misconfiguration. One scanner handles dynamic application testing: it spiders the running target and reviews the live responses. A second runs known vulnerability templates against that same target. Neither tool sees the whole picture alone, which is why nothing here relies on one of them.
The destructive pass will not start on its own. The standard scan is safe against a live production site: it crawls and reads, and sends nothing an attacker would send. The full pass does send attack payloads, so it refuses to run without an explicit authorization flag and errors out with the reason instead of proceeding. Permission to attack a system is a decision a person makes, never a default a script inherits.
Findings arrive ranked, not dumped. Results from both tools merge into a single report carrying combined critical, high, and medium counts and a flag for whether anything needs attention at all. Template findings come through with severity, CVSS and EPSS scores, the matched location, and the remediation text attached, so triage opens on a priority order rather than a wall of output. Every scan is written to its own timestamped report, which means the next one can be read as a delta instead of a fresh opinion.
| Dynamic testing | Spider and passive review on every pass. Active payload testing only behind an explicit authorization flag. |
|---|---|
| Vulnerability templates | Known CVEs, exposed files, and technology misconfiguration from an actively maintained template set. |
| Standard focus | Critical, high, and medium severity. Platform, exposure, misconfiguration, and technology templates. |
| Finding detail | Severity, CVSS and EPSS scores, matched location, and remediation text on every template hit. |
| Reporting | One merged report per scan, timestamped, with combined severity counts and a needs-attention flag. |
| Source code | Audited separately for hardcoded credentials and dynamic code execution, diffed run over run so only new findings need a decision. |
Scanners find holes. Monitoring finds drift.
A clean scan is a snapshot. What actually breaks a live stack is the change nobody announced: a plugin that auto-updated, a DNS record somebody edited, a permission that got widened for one afternoon and stayed open.
Client stacks are held to a baseline and watched against it. When something moves off that baseline, the change surfaces as an advisory with the before and after attached. That is a different event from an outage, and it arrives earlier. This layer reports. It does not block, and it is not described here as though it did.
Detection is not prevention, and the gap matters. Prompt injection is the clearest example. Content that tries to hijack an AI process gets flagged for a person to look at, and that is where the capability ends. It is advisory. Anyone selling a detector as a wall is describing a product that was only ever watching, and the teams who get hurt are the ones who believed the stronger version.
Where your data actually goes.
Stated plainly, with the gaps named in the same table as the protections.
The training question, answered without hedging. Client work runs on paid enterprise-tier model APIs under commercial terms. On those tiers, the providers’ standard terms do not permit submitted customer data to be used to train their models. That protection comes from the providers’ published terms and applies to every paid account, including this one. Zedlav has not signed a custom data processing agreement on top of it, which is worth knowing before anyone assumes one exists.
| Model access | Paid enterprise-tier model APIs under commercial terms that do not permit submitted customer data to be used for model training. |
|---|---|
| Custom agreements | None signed. The protection above is the providers’ published terms, not a negotiated agreement specific to Zedlav. |
| Credentials | Held in encrypted vaults, or left in your own systems wherever the platform supports it. |
| Shared knowledge | The shared knowledge base holds platform patterns. Client material is blocked from entering it. |
| Deliverables | Scanned for cross-engagement leakage before they reach you. |
| Hosting | Your hardware, your cloud account, or Zedlav’s edge. You own the deploy target, which means you can take the system with you. |
Ask the hard question.
It gets answered in writing.
You get a straight answer about what exists today and what it would take to build, not a roadmap slide.
sales@zedlav.ai →