How Lunar helps security, and why your platform team belongs in the room

Your team may already use scanner dashboards, required CI checks, and an application-security posture management (ASPM) platform to track and enforce security requirements. Platform may compile a broader view from those tools and the pipelines it operates.

The work that remains is often specific: extending a requirement to services outside the shared workflow, reconciling results from different tools, or keeping a control in place as teams change how they build and ship.

Earthly Lunar is a guardrails engine that helps security and platform turn those requirements into automated enforcement across engineering.

Security gets its requirements checked across the relevant services, with violations able to block PRs or deployments and evidence produced as the checks run.

Platform gets a centrally managed engine for those checks and its own engineering standards, with collection and normalization built in.

That shared value is why we ask platform to join the evaluation early. Security defines the requirements and acceptable risk; platform owns the engineering workflows where enforcement runs.

Build on the controls you already use

Existing tools can enforce meaningful controls. A scanner can fail a pull request when findings exceed a threshold. Repository rules can require checks before merge. ASPM tools can combine findings and automate responses. Lunar’s value depends on where your current setup still leaves work to do.

Consider a requirement that every in-scope service undergo static analysis and meet your findings threshold before merge. A scanner’s native integration or a centrally required workflow may already enforce it for part of the organization.

Other services may use a different scanner or a custom pipeline. Even teams on the same CI vendor can have different workflows. Those differences can be legitimate; applying the same requirement should not depend on forcing every team onto one template.

To establish coverage, security and platform need to know which services are in scope, whether the required evidence is collected, and where a violation actually prevents a merge. An existing dashboard or platform report may already answer those questions. Where it does not, someone has to connect the missing data and maintain the enforcement.

Lunar centrally collects signals from repositories and CI/CD, normalizes them into structured data, and evaluates that data against your requirements. For example, its built-in SAST presence checks can identify missing scan data and evaluate reported findings against a severity threshold. The findings check needs a collector that supplies the relevant finding data; a record that a scanner ran is not enough.

Platform can configure those checks to report violations or block at the relevant enforcement point. Your scanners continue finding vulnerabilities, while security retains responsibility for triage and risk acceptance.

Lunar also records what was checked, the result, and when. Security can verify how requirements are being enforced and use the resulting evidence without asking platform to reconstruct each check from pipeline logs. A pass establishes that the defined requirement was met against the collected data, not that the software is secure.

One way to apply standards across engineering

For platform, each new requirement can otherwise mean extending an existing integration, adapting a shared workflow, or maintaining another custom check. Lunar supplies the collection, normalization, and enforcement infrastructure so platform can manage standards centrally without a repo-by-repo integration rollout.

The same infrastructure supports work platform already owns. During a runtime migration, it can identify services using an unsupported version and enforce the version requirement. For test coverage, it can evaluate collected results against the agreed threshold. Reliability requirements from an incident can become maintained checks across the affected services.

Platform controls which services a guardrail applies to and how strongly it is enforced. Teams can retain different tools and workflows while being checked against the same organizational requirement. The benefit grows as more standards use the shared engine.

Catch violations while the change is still being made

Lunar evaluates guardrails in AI coding workflows, on pull requests, and at deployment gates. The same policy can give an AI agent feedback during authoring and enforce the requirement later in the delivery process.

Each check needs the appropriate evidence. A rule about code or configuration can provide feedback early; a rule that needs a built image must wait for that image. Earlier feedback gives developers and agents a chance to correct violations before they become release-time surprises.

The evaluation is deterministic: the same policy and input produce the same result. Human-written and AI-generated changes can be checked against the same standards.

If your teams also use AI code reviewers, those reviewers can help identify problems that have not been captured in a rule. Lunar checks the requirements you have already defined. AI Code Reviewers vs. Guardrail Engines explains how the two fit together.

The same guardrails apply across authoring, pull requests, and deployment, as the evidence each check needs becomes available.

Introduce enforcement at a pace engineering can support

Platform can assess a new guardrail before it blocks anyone. Start with visibility into which services meet the requirement and which would fail. Use that view to check the scope, investigate unexpected results, and plan the work needed to close gaps.

From there, platform can introduce feedback in pull requests and move to blocking when ready. Security gets a concrete view of coverage and progress; engineering gets time to understand and address violations before they interrupt delivery. Enforcement levels are managed centrally, so tightening a requirement does not depend on each team updating its own integration.

Start with visibility, assess the impact, and increase enforcement as teams are ready.

Why bring platform into the evaluation?

Security brings the requirements that are difficult to verify and the evidence it needs. Platform brings knowledge of the shared developer infrastructure, existing controls, and workflows that need coverage. AppSec or CI/CD owners should be involved where they operate those systems.

Together, the teams can assess what Lunar would add to the controls already working, how developers would receive feedback, and where enforcement should begin. Platform leads the rollout and operation as a shared engineering capability; security continues to define its requirements and make risk decisions.

Bring one requirement that is difficult to enforce consistently, plus an example of how you check it today. We’ll walk through the data Lunar would need, how enforcement would work, and how the same infrastructure could support platform’s own standards.

Security leaders: Don’t hesitate to Book a demo. And try to drag your platform counterpart along. 😎