New: Major version 1.0 officially released
New: Major version 1.0 officially released
New: Major version 1.0 officially released
New: Major version 1.0 officially released
New: Major version 1.0 officially released
Dependencies were scanned, the source code passed analysis, and the build produced valid provenance. The compromised dependency still executed inside the build environment.
October 8, 2026
8 Min Reads
Endura Security
The dependencies were scanned, the source code passed analysis, and the build produced a signed artifact with valid provenance. Every security check came back clean, and the organization had the documentation to demonstrate compliance with its secure development policies. Then a compromised dependency executed inside the build environment, accessed sensitive credentials, and attempted to send them to an external server. Nothing about the software's signature, provenance, or successful security scans necessarily prevented those actions.
This is an uncomfortable reality of modern software supply chain security. Organizations invest heavily in meeting frameworks such as the NIST Secure Software Development Framework (SSDF), Supply-chain Levels for Software Artifacts (SLSA), and broader security standards, yet many build environments still grant software far more access than it needs. The problem isn't the frameworks themselves. It's the gap between documenting how an environment should be secured and enforcing what software is actually allowed to do inside it.
The NIST Secure Software Development Framework (SP 800-218) establishes practices for developing secure software, including protecting the environments and tools used to produce it. While code analysis and vulnerability management receive considerable attention, the security of the build environment is equally important. A compromised dependency executing inside a trusted pipeline can potentially access credentials, modify artifacts, or communicate with unauthorized systems, regardless of how thoroughly the application itself was reviewed.
PO.5, Implement and Maintain Secure Development Environments, is where Endura Security provides its most direct support. Endura's Runtime Sensor operates at the Linux kernel level, using eBPF to observe and enforce restrictions on what build processes can do. Policies govern file access (path.open, path.write), executable invocation (path.execute), and outbound network connections (ip.connect). A build can be permitted to read source files, invoke its compiler, and access approved package registries without automatically receiving permission to read cloud credentials or connect to arbitrary external destinations.
Endura also provides supporting capabilities for other SSDF practices. File-access restrictions contribute to PS.1, protecting source code and artifacts from unauthorized modification during builds, while runtime controls support PO.3 by constraining the behavior of supporting toolchains. For RV.1, policy violations surface unexpected behavior that security teams can investigate, even when conventional scanners report no findings. These capabilities complement existing security tools rather than replacing code review, vulnerability scanning, testing, or release signing.
SLSA addresses software supply chain integrity, including build provenance and the trustworthiness of the infrastructure producing software artifacts. Under SLSA v1.0, Build Level 3 introduces stronger protections against tampering during execution, making build-platform hardening an important part of the security model. These protections matter, but provenance alone cannot establish that every dependency or script entering a legitimate workflow is harmless.
We examined this distinction in The Malware Was Signed. The Hash Was Known. It Still Shipped., where compromised packages passed through legitimate publishing workflows despite established security mechanisms. Endura complements SLSA's protections by restricting the authority available to code executing inside the build environment. If a dependency attempts to access ~/.aws, execute an unexpected binary, or establish an unauthorized network connection, a properly configured enforcement policy can deny those operations before they complete. Endura does not generate or sign provenance, and deploying it does not independently establish or increase an organization's SLSA level.
The same runtime controls supporting software supply chain integrity also have relevance to broader security assurance programs. Endura directly supports technical objectives associated with NIST SP 800-53 SI-7 (Software, Firmware, and Information Integrity) and CM-7 (Least Functionality) through restrictions on unauthorized file modifications and unnecessary executable behavior. Its monitoring, least-privilege enforcement, and policy records additionally support objectives associated with SI-4, AC-6, and CM-5.
For organizations undergoing SOC 2 examinations, Endura provides operational evidence relevant to CC6 (Logical and Physical Access Controls), CC7 (System Operations), and CC8 (Change Management). Rather than relying solely on written assertions that build environments follow least-privilege principles, organizations can examine actual policy configurations and recorded violations. These records contribute to demonstrating specific technical controls, although SOC 2 assurance requires substantially broader organizational processes and independent evaluation.
Endura supports established security frameworks through kernel-level enforcement, runtime monitoring, and operational evidence. The following mappings highlight where Endura directly implements technical controls, supports broader security objectives, or provides evidence for assessments. These capabilities strengthen compliance programs but do not independently establish certification or compliance.
Across these frameworks, Endura provides three valuable forms of operational evidence: what each monitored build did, what its policy permitted, and which operations violated that policy. This gives security teams and assessors a practical way to connect documented requirements with actual runtime behavior. Instead of relying solely on written security policies, organizations can demonstrate how specific controls were configured and applied.
One of the persistent frustrations of compliance is the distance between documenting a security requirement and demonstrating that it is enforced. A policy might state that build processes have restricted access, but an assessor may reasonably ask which restrictions were applied, whether they were active, and what happened when software attempted something unauthorized. Answering those questions requires evidence of actual operations, not simply another architecture diagram or security policy document.
Endura produces three categories of evidence that help close that gap. Activity records show observed file, process, and network operations associated with individual builds and pipelines, providing visibility into what software actually did. Versioned policies document the permissions and restrictions assigned to protected builds, allowing teams to review and compare changes over time. Violation records identify operations that exceeded policy boundaries, including process ancestry that helps investigators understand which execution chain produced an unexpected action.
Together, these records make it easier to connect security expectations with their implementation. A reviewer can examine the intended security boundary, evaluate the activity observed within it, and investigate attempts to cross it. That is more meaningful than simply demonstrating that a security product was installed or that a policy document exists.
Implementing least privilege in a complex CI/CD environment is rarely straightforward. Pipelines execute compilers, package managers, test frameworks, and third-party scripts, often with different filesystem and network requirements. Restricting those operations without understanding legitimate build behavior risks disrupting development, while allowing everything undermines the purpose of the control.
Endura addresses this through a progression from discovery to enforcement. In derive mode, Runtime Sensor observes representative builds and creates a starting policy based on the operations encountered, which teams then review and refine. Observe mode records violations without blocking execution, allowing organizations to evaluate the policy before enabling restrictions. Once validated, enforce mode applies the approved boundaries, denying covered unauthorized operations where direct kernel enforcement is supported.
The result is a practical way to move least privilege from a security objective into an operating control. Engineering teams retain a workflow for understanding and adapting build permissions, while security and compliance teams gain visibility into policy configuration and violations. It also creates a foundation for continuous review as dependencies, build tools, and infrastructure evolve.
Executive Order 14028 helped establish stronger federal expectations around secure software development, with NIST SSDF serving as an important reference. In January 2026, OMB Memorandum M-26-05 rescinded the earlier government-wide software attestation mandates, shifting agencies toward risk-based assurance approaches appropriate to their missions. Agencies may still request software security attestations, SBOMs, and evidence of secure development practices, making it important for suppliers to understand their customers' current requirements.
For software producers serving federal customers, Endura provides supporting technical controls and runtime records relevant to protecting development environments. Those capabilities can contribute to applicable assurance requests without implying that Endura itself confers federal compliance or certification. The underlying question remains whether organizations can demonstrate how their software development environments are protected against unauthorized activity.
Compliance frameworks provide valuable guidance, but their effectiveness ultimately depends on the controls organizations put into practice. A build can have valid provenance and still execute compromised code, while a passing vulnerability scan does not guarantee that a dependency will behave safely. The objective should extend beyond demonstrating that established security practices exist to ensuring those practices create meaningful boundaries when something goes wrong.
Endura Security helps organizations make that distinction tangible. By combining kernel-level runtime enforcement, least-privilege policies, and evidence of actual build behavior, Endura supports the security objectives behind NIST SSDF, SLSA, NIST SP 800-53, and SOC 2 without pretending to replace the broader programs those frameworks require. The next compromised dependency may still make it into your pipeline, but that doesn't mean it should inherit unrestricted access to everything around it.
The question isn't simply whether your build meets the requirements of a framework. It's whether the controls behind those requirements will hold when your build encounters something malicious.
Explore Endura Security's runtime protection capabilities or read our Software Supply Chain Security Whitepaper for detailed compliance mappings.
Ready to put this into practice?
