Ask a compliance lead how many times she’s answered “what’s running in your software” this quarter. PCI wants it in one format. SOC 2 wants a different export. The ISO surveillance auditor wants a third version. NIST wants a fourth, for SSDF attestation. Same question, four spreadsheets, and at least one of them is already stale by the time it lands on someone’s desk.
One SBOM scan can satisfy the software inventory requirement in PCI DSS 4.0.1, SOC 2, the proposed HIPAA Security Rule, and NIST’s Secure Software Development Framework (SSDF, SP 800-218). All five are essentially asking the same question: what’s in your software, and is any of it vulnerable?
An SBOM (Software Bill of Materials), a machine-readable list of every component in a piece of software, generated in a standard format like SPDX or CycloneDX can answer that question. The simplest way to start is with our open source scanner, Syft, that generates one from a container image or filesystem in seconds. Then Grype can check that list against known vulnerability databases. The result is a single source of truth that different auditors can query various different ways, instead of generating the same document over and over and drifts apart the moment someone ships a patch.
Here’s what each framework actually requires, as of August 2026, including which deadlines already passed and which are proposals at this moment.
PCI DSS 4.0.1: Requirements 6.3.2 and 11.3.1.1
PCI DSS 4.0.1 replaced 4.0 on December 31, 2024, and requires a maintained inventory of bespoke, custom, and third-party software components under Requirement 6.3.2. Requirement 11.3.1.1 ties that inventory to ongoing vulnerability management. This was scored as a best practice until March 31, 2025. After that date, QSAs treat it as a hard requirement, not a recommendation.
The standard doesn’t mandate SPDX or CycloneDX specifically. It just requires the inventory to exist and stay current, which is the part manual spreadsheets fail at first.
Learn more about the critical role of SBOMs in PCI DSS 4.0 compliance.
The three-year grace period to transition from ISO 27001:2013 to the 2022 revision closed on October 31, 2025. Certificates that didn’t make the switch are no longer valid.
Annex A 5.9 (inventory of information and other associated assets) replaced the old asset management control. Annex A 8.8 (management of technical vulnerabilities) depends on 5.9 being current: you can’t triage a vulnerability in a component you don’t know you’re running.
An SBOM is the mechanism that keeps 5.9 accurate enough for 8.8 to mean anything.
SOC 2: CC7.1 and CC7.2
SOC 2 doesn’t name SBOMs by name, and we won’t pretend it does. Auditors currently treat dependency management as supporting evidence for secure SDLC practices, not a checkbox with its own line item.
That said, CC7.1 and CC7.2 both expect an ongoing process for detecting and monitoring vulnerabilities across your asset inventory. An SBOM is the fastest way we’ve seen teams satisfy that expectation with evidence an auditor can actually verify, rather than a policy document describing a process nobody follows.
HIPAA: where the proposed Security Rule actually stands
This one’s still a proposal, not law, and we want to be precise about that distinction.
The Department of Health and Human Services published a Notice of Proposed Rulemaking on January 6, 2025. The comment period closed March 7, 2025. The draft would make encryption and multi-factor authentication mandatory (currently just “addressable”), and add a 72-hour incident reporting window.
OCR had targeted spring 2026 for a final rule. That date passed with nothing published, and there’s no confirmed timeline for when, or if, a final rule ships. If you’re a covered entity or business associate, none of this is enforceable yet. Build toward it anyway, because the direction of travel is clear even if the date isn’t.
NIST SSDF (SP 800-218): what changed after EO 14306
Federal RFPs increasingly ask vendors for SSDF attestation alongside an SBOM, and the mechanics of that attestation changed in 2025.
Executive Order 14306, signed in June 2025, removed CISA’s role as the central validator of vendor attestations and struck the associated Federal Acquisition Regulation update. The practical effect: the burden shifted to vendors to hold their own audit-ready proof of SSDF conformance, rather than routing it through a central government review.
NIST published a draft of SP 800-218 Revision 1 on December 17, 2025. Its public comment period closed January 30, 2026. Version 1.1 remains the version vendors are actually held to today.
Framework quick reference
Framework
Control(s)
Status as of August 2026
SBOM required?
PCI DSS 4.0.1
6.3.2, 11.3.1.1
Mandatory since March 31, 2025
Effectively yes
ISO/IEC 27001:2022
Annex A 5.9, 8.8
Mandatory since October 31, 2025 transition deadline
Supports the requirement, not named directly
SOC 2
CC7.1, CC7.2
Current, ongoing
Optional, but common evidence
HIPAA Security Rule (proposed)
Encryption, MFA, 72-hr reporting
NPRM only, not finalized
Not required (no final rule yet)
NIST SSDF (SP 800-218)
Full framework, v1.1
Rev 1 draft in comment through Jan 30, 2026
Expected alongside attestation
What this looks like when it’s not a spreadsheet
A few Anchore customers have already put this to the test, in frameworks adjacent to the ones above.
Mattermost builds a secure collaboration platform for defense and critical infrastructure customers. By enforcing NIST 800-53 out of the box through Anchore Enterprise, the team replaced a noisy, manual scanning process with a policy-driven workflow, and is now positioned for the DISA STIG requirements its regulated customers will demand next.
Cisco Umbrella had to hit FedRAMP, FIPS, STIG, and EO 14028 compliance for its entire GovCloud deployment on a deadline measured in weeks, not quarters. Anchore Enterprise met all six FedRAMP vulnerability scanning requirements within that window.
Sabel Systems runs a DevSecOps pipeline for Department of Defense missions, with a team of 10 supporting over 100 developers. Vulnerability review dropped from 2 weeks to 3 days, a 75% reduction, while the team maintained zero critical vulnerabilities across multiple IL5 environments and moved toward ATO.
ModuleQ is an enterprise AI copilot vendor operating inside customer-controlled tenants in financial services, a sector where 25,000 new vulnerabilities landed in 2023 alone. Anchore Secure cut the team’s vulnerability management time by 80%.
None of these four are a direct ISO 27001 or SOC 2 case study but what they show is the same underlying mechanic (one accurate inventory, checked continuously, mapped to whatever control an auditor asks about) working at DoD, federal, and financial-services scale. That’s the mechanic ISO 27001, SOC 2, PCI DSS, and HIPAA all lean on too as well.
FAQ
Does having an SBOM make you PCI DSS compliant? No. It satisfies the inventory piece of Requirements 6.3.2 and 11.3.1.1. PCI DSS 4.0.1 has over 300 other requirements an SBOM doesn’t touch.
Is an SBOM required for SOC 2? Not by name. Auditors accept it as strong evidence for CC7.1 and CC7.2’s vulnerability monitoring expectations, but SOC 2’s own criteria never use the term “SBOM.”
What’s the ISO 27001:2022 transition deadline? October 31, 2025. It already passed. Certificates still on the 2013 version are no longer valid.
Is the HIPAA Security Rule update enforceable right now? No. It’s a proposed rule (NPRM published January 6, 2025) with no confirmed final rule date as of August 2026.
What changed for NIST SSDF attestation in 2025? Executive Order 14306 removed CISA’s central validation role in June 2025. Vendors now hold their own audit-ready proof of SSDF conformance instead of routing attestation through a central government review.
If you’re mapping one inventory across any of these frameworks right now, then talk to us and we are happy to demo our current product capabilities.
This is the first post in a series on the operational problems Anchore’s product quickstarts solve. This one is about what your SBOM inventory is missing if it only covers containers.
Ask most security teams what percentage of their software supply chain has an SBOM, and they’ll answer with a number that describes their container fleet. Ask what percentage of their actual infrastructure that covers, and the number gets a lot smaller. Legacy applications, regulated systems that can’t be containerized yet, hybrid servers that predate the container conversation entirely: none of that shows up in a registry, so none of it shows up in most SBOM programs.
That gap didn’t matter much when an SBOM was mostly a compliance checkbox. It matters a great deal more now and not because of a new regulatory field to check off. It’s because the assumption underneath most SBOM roadmaps, that infrastructure is steadily moving from VMs to containers and the VM problem will eventually just go away, doesn’t hold up. IDC forecasts that nearly 85% of all containers will still be running inside VMs through 2028, because enterprises trust the virtualization layer for the isolation, governance, and operational control containers alone don’t provide. VMs and containers aren’t a transition story. They’re two things that coexist for the long term, which means an SBOM program that only covers one of them isn’t a temporary gap that adoption trends will close on their own.
We see this most often with organizations running a mix of containerized services and long-lived VMs, whether that’s a legacy application nobody’s gotten around to containerizing, a regulated workload that can’t move to containers yet, or infrastructure that’s simply been running fine for years and nobody’s touched it. When a new CVE drops, the team can answer “are we affected” for their container fleet in minutes. For everything else, they’re back to manually checking servers one at a time. That’s the exact gap Anchore Enterprise’s quickstart for creating and storing SBOMs is built to close, by treating a VM filesystem as a legitimate first-class source.
What’s actually different about generating an SBOM from a VM versus a container
Container SBOM tooling matured first because containers made the problem easier: an image is immutable, it has clearly defined layers, and there’s a registry to pull it from. A VM or a bare server has none of that. There’s no registry, no layers, and the filesystem you’re inspecting is often live and changing while you’re looking at it.
Anchore Enterprise handles this by treating a filesystem, not just a container image, as a first-class thing you can generate an SBOM from. You create an app (the software you ship or host) and a version (a point-in-time release), then attach assets to it. An asset can be a container image, an analyzed filesystem, or an SBOM someone handed you, and they all aggregate together under an application version.
For a running VM, install AnchoreCTL inside it and point it at the filesystem you want to analyze. AnchoreCTL walks the directory tree, generates the SBOM locally using Syft, and uploads the result. Pseudo-filesystems like `/proc` and `/sys` are skipped by default, so analyzing `/` is safe, and narrower paths (`/usr`, `/opt`, `/srv`) are faster if you only care about installed software:
For a VM disk image, you don’t boot the VM at all. With the QEMU utilities installed and the NBD kernel module loaded, mount the image read-only and scan the mount point:
No agent gets installed inside the VM, the disk stays read-only throughout, and the same pattern works for forensic workflows and for golden-image templates before they’re cloned out across a fleet.
Container images attach to the same app version the same way (`anchorectl app version asset add container-image`), and so do SBOMs generated by someone else’s tooling (`anchorectl app version asset add sbom`). That’s the mechanism behind everything that follows: containers, VMs, and third-party SBOMs are three asset types in one version.
The format matters
Whichever path generates the SBOM, the format it comes out in matters more than it might seem. Anchore Enterprise stores SBOMs internally in its Syft-native format and imports and exports both dominant open standards, CycloneDX (JSON and XML) and SPDX (JSON and tag-value), and the SBOMs it generates meet the NTIA’s minimum required elements: supplier name, component name, version, a unique identifier such as a `purl`, dependency relationships, SBOM author, and timestamp. The filesystem command even takes `--author` and `--supplier` flags, so authorship gets stamped at generation time instead of backfilled later.
An SBOM missing a unique component identifier or a clear dependency relationship isn’t a smaller SBOM. It’s one that can’t be reliably queried during the exact moment it’s supposed to help, which is when a new vulnerability shows up and someone needs an answer in minutes, not days.
What changes once containers and VMs are one inventory
Go back to where we started: most SBOM programs can answer “are we affected” fast for containers and slowly, manually, or not at all for everything else. That’s the actual risk. Not that VMs are inherently less secure, but that the inventory covering them doesn’t exist in a form anyone can query under pressure. That pressure has a real deadline attached for a lot of organizations: the EU Cyber Resilience Act’s vulnerability reporting requirement takes effect September 11, 2026, and it doesn’t grant an exception for infrastructure that’s harder to inventory.
The technical outcome is a single, queryable inventory that treats a container image and a mounted VM filesystem as two assets feeding the same app version, not two separate problems with two separate processes. Anchore Enterprise’s unified queries work across every asset in a version, so “which parts of this release contain `openssl 3.0.13`?” is one request whether the answer lives in a container or a VM. The business outcome is the same incident response speed for your oldest infrastructure that you already have for your newest.
One of our customers DreamFactory runs a higher percentage of containers rather than VMs, however they serve defense and other highly regulated customers who require on-premises, air-gapped deployments where the usual assumption of always-on cloud connectivity simply doesn’t hold. By integrating automated SBOM generation directly into their build pipeline and running daily scans regardless of network isolation, DreamFactory cut time spent on vulnerability management and compliance work by 75% and now deploys 70% faster with security checks built in, rather than bolted on after the fact. The underlying lesson transfers directly to VM and legacy infrastructure: the moment you stop treating an environment as a special case that gets manual, occasional attention, and start treating it as another source feeding one inventory, the response time problem mostly resolves itself.
This is the same SBOM generation and storage workflow Anchore Enterprise customers use today, whether the source is a container image or a filesystem. If you’re already running Anchore Enterprise, our quickstart for creating SBOMs from virtual machines walks through both paths end to end, including viewing the results alongside your container assets.
If you’re evaluating how this would extend your own inventory, request a demo and bring your actual mix of containers and legacy infrastructure to the conversation.
This is the first post in the series. Next up: what changes once you can see what’s actually running in a Kubernetes cluster, not just what’s declared.
The EU CRA applies to manufacturers, importers, and distributors of products with digital elements sold in the EU. This includes hardware and software products.
The requirements mandate that organizations must identify, document, remediate, and disclose vulnerabilities throughout the product lifecycle, with continuous monitoring across the support period.
Vulnerability and severe-incident reporting obligations begin September 11, 2026, while most remaining requirements become enforceable in December 2027.
Vulnerability management tools like Anchore Enterprise can help automate the process for achieving and maintaining compliance.
The European Union Cyber Resilience Act (EU CRA) is about to change the way organizations think about software security, vulnerability management, and accountability across the software supply chain.
For years, many cybersecurity regulations focused primarily on breach response, data privacy, or critical infrastructure. The CRA shifts the conversation upstream. Instead of asking organizations how they respond after a security issue occurs, the CRA asks a more fundamental question: How are vulnerabilities being prevented, identified, managed, and communicated throughout the entire product lifecycle?
That’s a major shift for manufacturers of products with digital elements, and unlike many past frameworks, the CRA includes explicit vulnerability handling obligations—with timelines, reporting requirements, documentation expectations, and potential financial penalties for non-compliance.
Luckily, much of what the CRA requires aligns with modern software supply chain security best practices that mature engineering and security teams are already adopting. That includes:
…and more. In other words, the CRA may feel new, but the underlying security work shouldn’t.
Navigating the EU CRA: A Blueprint for Secure Software Supply Chains | White Paper
The EU CRA demands a shift from static security reports to continuous Live Telemetry. Learn how to operationalize compliance, enforce deterministic policy gates, and automate your path to an audit-ready software supply chain.
Vulnerability Management and Reporting Requirements Under the EU CRA
The vulnerability management provisions within the CRA are designed to improve transparency, accelerate remediation, and reduce systemic software supply chain risk across the EU ecosystem. While organizations should review the full regulation directly, several requirements stand out:
1. Proactive Vulnerability Management
Manufacturers must identify and address vulnerabilities throughout the supported lifecycle of products with digital elements. This includes:
Monitoring for vulnerabilities continuously
Remediating vulnerabilities without undue delay
Delivering security updates
Minimizing known exploitable weaknesses before products reach the market
The regulation also emphasizes secure-by-default configurations and secure development practices under Annex I. In practice, that puts pressure on organizations to improve visibility across their software supply chains, from open source dependencies and container environments to build pipelines and vulnerability prioritization workflows. Without automation, maintaining that level of visibility across modern software environments quickly becomes difficult to scale.
2. Mandatory Reporting of Actively Exploited Vulnerabilities
The CRA introduces mandatory reporting obligations for actively exploited vulnerabilities and serious incidents. Organizations may need to report:
Actively exploited vulnerabilities
Security incidents impacting products
Mitigation status
Remediation details
CRA Vulnerability Reporting Timeline for Actively Exploited Vulnerabilities
Reporting stage
Deadline
Information required
Early warning
Within 24 hours of awareness
Notice of the actively exploited vulnerability and, where applicable, the EU Member States where the manufacturer knows the product has been made available
Vulnerability notification
Within 72 hours of awareness
Available information about the affected product, the general nature of the exploit and vulnerability, corrective or mitigating measures already taken, measures users can take, and the sensitivity of the submitted information where applicable
Final report
No later than 14 days after a corrective or mitigating measure becomes available
A description of the vulnerability, including its severity and impact; available information about any malicious actor exploiting it; and details of the security update or other corrective or mitigating measures made available
Note: Severe incidents affecting product security follow a separate reporting track. They also require an early warning within 24 hours and a notification within 72 hours, but the final incident report is due within one month of the 72-hour notification. It must include a detailed description of the incident, its severity and impact, the type of threat or likely root cause, and the mitigation measures applied or underway
These timelines are intentionally aggressive, which creates major operational pressure for organizations without centralized vulnerability visibility. Teams that lack complete SBOM coverage, struggle to identify affected products quickly, or still rely heavily on manual vulnerability triage processes may find compliance particularly challenging.
The practical reality is simple: you can’t report what you can’t see.
3. Security Updates and Ongoing Support
The CRA requires manufacturers to provide security updates during a product’s expected support lifecycle. This has important downstream implications:
Vulnerability monitoring cannot stop after release
Legacy products may remain in scope
Engineering teams need long-term component visibility
Product lifecycle management becomes tightly linked to security operations
For organizations with large portfolios of connected products, maintaining ongoing vulnerability intelligence becomes a significant scaling challenge.
4. Software Bill of Materials (SBOM) Readiness
The CRA does not universally mandate public SBOM distribution in every scenario, but SBOMs are rapidly becoming foundational to compliance readiness. That’s because SBOMs help organizations:
That increase isn’t happening because SBOMs are trendy. It’s happening because organizations increasingly need machine-readable visibility into software composition.
5. Coordinated Vulnerability Disclosure
The CRA requires manufacturers to establish and enforce a coordinated vulnerability disclosure policy and process. Organizations need a clear way for researchers, customers, suppliers, and other third parties to report potential vulnerabilities affecting their products or incorporated components.
In practice, manufacturers should:
Publish a coordinated vulnerability disclosure policy
Provide a monitored contact point for vulnerability reports
Establish processes for validating, triaging, and tracking reports
Coordinate remediation and public disclosure
Share relevant vulnerability information with upstream suppliers and downstream users
Maintain records of investigation, remediation, and communication activities
These responsibilities are often coordinated by a Product Security Incident Response Team (PSIRT) or an equivalent cross-functional group spanning product security, engineering, legal, compliance, and incident response.
Achieving EU CRA Compliance
Who Is Impacted?
The CRA applies primarily to manufacturers, importers, and distributors of products with digital elements made available on the EU market. Depending on the product and the organization’s role, impacted groups may include…
Software manufacturers
Hardware manufacturers
IoT vendors
SaaS providers
Embedded systems vendors
Open source software maintainers in certain contexts
Importers
Distributors
Even organizations headquartered outside the EU may fall within scope if products are sold into EU markets. This is one reason the CRA matters globally, not just regionally.
When Do EU CRA Vulnerability Management Requirements Take Effect?
There are two key deadlines you need to know about:
September 11, 2026: Requirements for reporting actively exploited vulnerabilities and severe incidents affecting product security take effect.
December 11, 2027: The CRA’s broader vulnerability-handling requirements become applicable, including continuous vulnerability monitoring, remediation, coordinated vulnerability disclosure, security updates, SBOM maintenance, and lifecycle support.
Organizations should not interpret the December 2027 deadline as a reason to wait—not only because requirements related to vulnerability and incident reporting are set to begin in September 2026, but also because large-scale compliance transformations involving vulnerability governance, policy automation, software lifecycle monitoring, and more can take years to mature operationally.
What Are the Consequences of Non-Compliance?
The CRA introduces potentially significant consequences for non-compliance, including financial penalties, regulatory enforcement actions, and restrictions on selling products within the EU market. But focusing only on the penalties misses the bigger point.
The organizations most likely to struggle under the CRA are often the same organizations already struggling operationally with software visibility, remediation coordination, and vulnerability response. In many cases, the real problem is discovering too late that a critical vulnerability exists, not knowing which products are affected, or scrambling during a customer audit or active incident to piece together incomplete software inventory data.
That’s one reason vulnerability management shouldn’t be approached purely as a compliance exercise. The practices the CRA pushes organizations toward—continuous monitoring, SBOM generation, faster remediation workflows, and better software supply chain visibility—are fundamentally good security practices regardless of regulation. Compliance may be the forcing function, but the operational benefits are often much broader.
Common Vulnerability Management Challenges Under the EU CRA (and How to Prepare)
1. Incomplete Software Visibility
Many organizations still struggle to maintain a complete inventory of the software components inside their products, especially across open source dependencies, containers, embedded systems, and transitive packages. Under the CRA, that lack of visibility quickly becomes a compliance and operational problem.
How to prepare:
Standardize continuous SBOM generation across development pipelines
Maintain centralized inventories of software components and dependencies
Continuously scan container images and registries for newly disclosed vulnerabilities
Automate vulnerability correlation against deployed artifacts
How Anchore helps: Anchore Enterprise helps organizations continuously generate SBOMs, monitor vulnerabilities over time, and maintain visibility across modern software supply chains.
2. Vulnerability Prioritization Overload
Most organizations don’t suffer from a lack of vulnerability data—they suffer from too much of it. Security teams are overwhelmed with alerts, many of which pose little practical risk.
The CRA increases pressure to identify and respond to meaningful vulnerabilities quickly, especially actively exploited vulnerabilities.
How to prepare:
Prioritize vulnerabilities based on exploitability and real-world exposure
Reduce duplicate or fragmented scanning workflows
Integrate vulnerability data directly into development pipelines
Establish remediation SLAs tied to severity and exploit status
A component’s presence in an SBOM does not necessarily mean that every vulnerability associated with that component affects the finished product. Vulnerability Exploitability eXchange, or VEX, provides a standardized way to document whether a product is affected, not affected, fixed, or still under investigation.
VEX can help security and product teams preserve the reasoning behind vulnerability decisions, reduce repeated investigation of non-applicable findings, communicate status downstream, and maintain evidence supporting remediation and disclosure workflows. VEX does not replace CRA regulatory reporting, but it can provide valuable context for determining which findings require action.
How Anchore helps: Good vulnerability management isn’t about chasing every CVE equally. Anchore Secure helps organizations prioritize remediation efforts by reducing vulnerability noise and surfacing the risks most likely to matter. Prioritize vulnerabilities using signals like CVSS severity, EPSS, and CISA KEV data to help security teams focus more quickly on actively exploited vulnerabilities, high-risk components, and vulnerabilities with available fixes. It also enables teams to annotate vulnerability findings with VEX statuses—such as affected, not affected, fixed, or under investigation—and export VEX documents for downstream use.
3. Manual Compliance and Reporting Processes
Many organizations still rely on spreadsheets, disconnected tools, or manual reporting workflows to manage vulnerability data. That approach becomes increasingly difficult under aggressive CRA reporting timelines.
You can’t move quickly during an active incident if teams are manually piecing together product inventories and remediation status across multiple systems.
How to prepare:
Centralize vulnerability and SBOM data
Automate compliance reporting workflows where possible
Maintain historical records of remediation activity and security updates
Integrate security tooling into CI/CD pipelines early
Document the 24-hour, 72-hour, and final-report workflow before reporting obligations begin
Assign ownership for investigation, regulatory reporting, and customer communication
How Anchore helps: Solutions like Anchore Enforce help organizations operationalize policy enforcement and automate security gates throughout the software development lifecycle.
4. Long-Term Product Lifecycle Management
The CRA treats vulnerability management as an ongoing lifecycle responsibility, not a one-time release activity. That creates challenges for organizations managing long-lived products, legacy software, or complex hardware/software ecosystems.
How to prepare:
Continuously monitor released products for newly disclosed vulnerabilities
Track end-of-life dependencies and unsupported components
Establish clear product support and update policies
Retain historical SBOMs and artifact metadata for future investigations
The organizations that will handle CRA compliance most effectively are typically the ones already treating software supply chain security as an operational discipline rather than a periodic compliance project.
Preparing for the EU CRA Requires More Than Point-in-Time Scanning
The EU CRA raises the bar for vulnerability management by treating software security as a continuous lifecycle responsibility rather than a one-time compliance exercise. For organizations managing modern software supply chains, that creates new pressure to maintain visibility across open source dependencies, prioritize meaningful vulnerabilities quickly, automate reporting workflows, and continuously monitor products long after release.
That’s difficult to accomplish with fragmented tooling and manual processes alone.
How Anchore Supports EU CRA Vulnerability Management
CRA vulnerability-management need
Anchore capability
Identify software components
Generate, ingest, organize, and manage SBOMs, including externally supplied SBOMs from third-party vendors and open source suppliers
Monitor products over time
Continuously re-evaluate stored SBOMs against updated vulnerability data and monitor deployed workloads through runtime inventory
VEX annotations and exports in CycloneDX and OpenVEX formats
Enforce security and compliance requirements
Customizable policy-as-code with pass, warn, or fail results that can gate CI/CD pipelines and block non-compliant deployments
Produce and retain compliance evidence
SBOM, vulnerability, VEX, VDR, policy-compliance, and time-stamped reporting outputs
Support vulnerability-response workflows
Centralized SBOM, vulnerability, policy, and runtime data for security, engineering, compliance, and product-security teams
Platforms like Anchore Enterprise help organizations operationalize many of the core practices the CRA increasingly demands, including continuous SBOM generation, vulnerability scanning, policy enforcement, remediation prioritization, and long-term software supply chain visibility. By integrating security and compliance workflows directly into the software development lifecycle, organizations can reduce operational overhead while improving their ability to respond to newly disclosed and actively exploited vulnerabilities.
Mitigate vulnerability noise. Deploy our 6-step execution plan to automate continuous compliance and enforce mandatory 24-hour incident notifications.
If you’ve been in the security and compliance universe for the last few decades, you know historically FedRAMP authorization is like a very long, very difficult marathon. It seemed like endless paperwork, manual screenshots, hours of talking with auditors, and expensive delays. It was common to wait 12 to 18 months just to get approved. But there is some hope that things are starting to change and that agonizing compliance marathon is finally coming to an end.
In our recent webinar, Josh Bressers (VP of Security, Anchore) sat down with Tanner Bailey (20X Compliance Lead, InfusionPoints) and Alex Erhart (20X Engineering Lead, InfusionPoints) to break down the highly anticipated FedRAMP 20X changes. Together, they discussed how organizations can trade the traditionally heavy compliance paperwork for automated provenance. Watch the video recap.
The “Chicken and Egg” Problem
Let’s step back and look at why this change is happening. One of the most persistent hurdles in the federal space has been the “chicken and egg” problem of securing agency sponsorship, coupled with an unsustainable time-to-market and high entry costs. You needed to find a sponsor before you could start the FedRAMP journey, but then that sponsor might not become a customer until after that journey is complete. The fundamental driver behind FedRAMP 20X is fixing a broken system without lowering the security bar.
By shifting toward Key Security Indicators (KSIs), the FedRAMP Program Management Office (PMO) aims to eliminate unnecessary red tape. KSIs allow organizations to build a cohesive security story by leveraging existing cloud-native security practices they already have in place rather than forcing their architecture to fit rigid, outdated checkboxes. And the best part? The new process is designed to be faster, and CSPs can even achieve their program certification up through the Moderate level without an agency sponsor.
Automated Provenance Over Static Documents
Relying purely on static, document-heavy processes to measure compliance is a systemic problem. The days of spending hours taking manual screenshots of AWS consoles and packaging them into massive folders for a 3PAO audit are coming to an end. The panelists discussed how 20X shifts the focus from these static, document-heavy processes to machine-readable authorization packages and continuous validation.
“How can you automate your compliance for your system, as opposed to taking the compliance framework and adapting your system to fit it? You’re taking your compliance framework and saying, ‘How are we doing these things in this system we already have?'”— Tanner Bailey, 20X Compliance Lead, InfusionPoints
Instead of an annual review where controls might slip through the cracks, KSIs can be automated to run continuously. This shift to automated provenance means that assessors validate the automation code and its output rather than manually verifying individual settings, drastically reducing audit stress. This provides real-time visibility into the health of the system via a modern “Trust Center,” allowing agencies and customers to view the continuous status of the product’s security indicators.
The Vulnerability Intelligence Gap
Traditionally we have had a heavy focus on technical security control. Things like security vulnerabilities or firewall settings. There’s more to FedRAMP 20x than just technical controls overhaul. Do you know what happens if your credit card paying the AWS bill just expired? FedRAMP 20X challenges traditional thinking by bringing critical “out-of-boundary” business metrics into the fold. The webinar highlights how organizations must now prove the effectiveness of their operations—from incident response tabletops and security training to ensuring that AWS billing credit card is valid.
Furthermore, the discussion debates the radical shift coming to vulnerability management. Prioritization under 20X is no longer dictated solely by a traditional CVSS score matrix. Instead, it utilizes a context-aware approach that evaluates factors like Known Exploited Vulnerability (KEV) status and internet reachability. This allows engineering teams to focus remediation efforts on actual business impact rather than wasting cycles on low-level noise isolated deep within unexposed systems.
Watch the full webinar
Ready to stop guessing about your compliance?
It’s easy to be a cynic about federal compliance, but the truth is you can’t secure what you can’t continuously validate. If your team is navigating the complexities of federal compliance, looking to move away from Rev 5, or simply wanting to streamline GRC operations with cloud-native automation, this discussion provides a pragmatic framework for the future of FedRAMP.
As security engineers, we know the “vulnerability treadmill” isn’t just about patching—it’s about the massive “security tax” paid in manual evidence collection and triaging noise that doesn’t impact real-world risk.
Our collaboration with Red Hat Hardened Images is designed to eliminate this tax at the source. Combining a minimalist infrastructure foundation with a policy-driven supply chain gave us:
Shifting the focus from “patching everything” to an automated, risk-based posture
Satisfying engineering velocity and regulatory mandates like EU Cyber Resilience Act (CRA), PCI DSS 4.0, and FedRAMP
Start with the Hardened Images and keep them that way
Scanning alone cannot fix a bloated foundation. Red Hat Hardened Images attacks CVE fatigue where it is cheapest and fastest: before the findings exist.
Red Hat partnered with Anchore to help identify new vulnerabilities in the creation of the Hardened Image catalog, and be an integral part of the required (often daily) evolution of the images as they are curated by Red Hat. Anchore provides the most up to date and accurate assessment of new upstream CVEs as they appear. These then feed into the build process of Red Hat as they publish new images to deliver low to zero CVEs to customers at the point of download. Anchore collaborated with Red Hat to ensure that the data published for the Hardened Images themselves via the Red Hat Security feeds is accurate and produces no false positives when users start the scanning process in their own environments.
To sum it up, Red Hat’s Hardened Images focus on:
Minimal by Construction: Shipping only what production needs, which means fewer packages, fewer transitive dependencies, and fewer scanner findings.
SLSA 3 Standards: All images are produced to SLSA 3 build standards, providing a verifiable chain of custody from the start.
Accurate vulnerability data: security feeds represent the correct state of the Hardened Images as a unique catalog.
This effort would have not been possible without Anchore’s leading SBOM generation and management capabilities and compliance operations engine. It allows customers to automate vulnerability analysis, and enforce compliance with policy across the lifecycle and ultimately control your supply chain risk and stay compliant by default.
Stay compliant by default as we automate the burden of proof
While hardened images reduce the volume of vulnerabilities, Anchore Enterprise provides the continuous, SBOM-based visibility required. Depending on the source of the vulnerability, the response for any issues in the Red Hat Hardened Images is tailored. An issue in the Red Hat Hardened Image triggers an alert to pull the latest image. A vulnerability in developer-added content sends an alert to the developer’s toolchain. Only the appropriate team or tool receives the relevant notice.
As global regulations shift the “burden of proof” to the manufacturer, security teams need more than just a list of CVEs; they also need a unified compliance engine.
Unified Asset Visibility:Anchore moves beyond simple image scanning to a continuous scan throughout the SDLC. By tracking digital assets and dependencies as mandated by CRA Annex I, teams can generate unified SBOMs for both containerized and non-containerized assets.
Precision Triage & VEX: Anchore utilizes VEX (Vulnerability Exploitability eXchange) and risk scoring. This allows engineers to suppress findings tied to unreachable paths or non-exploitable components, focusing human attention only on what materially changes the risk profile.
POA&M-as-Code:The manual process of producing a Plan of Action and Milestones (POA&M) is replaced by automated remediation plans and allowlists managed directly within the CI/CD toolchain.
The goal of the Red Hat and Anchore partnership is to make compliance the “default” state rather than a point-in-time audit. Together we can build a secure foundation with a SBOM-native policy engine, so organizations can automate the evidence collection needed to satisfy regulatory pressure while focusing on shipping code, not triaging noise.
For security and platform engineers, the term “End-of-Life” (EOL) often seems like background noise — a compliance checkbox or a distant roadmap item. However, as supply chain attacks become more sophisticated, it’s becoming clear that the greatest risk isn’t always a malicious zero day; often, it’s the forgotten, unpatched library sitting deep in your dependency tree.
In our recent webinar, “The EOL Trap: Why Supply Chain Risk is Often Born of Neglect, Not Malice,” Josh Bressers (VP of Security, Anchore) and Mike Morgan (Senior Solutions Engineer, HeroDevs) break down the technical reality of managing aging software stacks.
Why “Done” Software is a Myth
One of the most persistent misconceptions in engineering is that a piece of software can be “complete.” The reality is that the ecosystem around your code is constantly shifting. A library that was secure four years ago may now be incompatible with modern compilers (like GCC updates) or vulnerable to exploits that didn’t exist when it was written. If a package hasn’t seen a commit in years, it isn’t “stable”— it’s a liability.
The Complexity of Transitive Dependencies
The webinar dives into the data behind the 12.1 million open-source packages currently tracked. A significant portion of these have not seen an update in over four years, yet they continue to garner millions of downloads. As engineers, we often lack visibility into these transitive dependencies. You might be running the latest version of your primary framework, but six layers deep, you’re still tethered to an EOL library that no one is maintaining.
Moving Beyond CVSS
While vulnerability scanners are essential, they often fail to flag EOL status unless a specific CVE is assigned. Josh and Mike discuss how to use heuristics—such as repository archiving, README deprecation notices, and stale release lines—to identify risk before it becomes a critical incident.
Watch the full recording
If you’re tasked with maintaining legacy systems or securing complex CI/CD pipelines, this discussion provides a pragmatic framework for identifying and remediating EOL risks.
If you’ve been in the security universe for the last few decades, you know we love a good vulnerability scanner. We’re great at finding known bads. We have very mature practices to hunt for CVEs, malware, and leaked secrets. But here’s the thing about modern software development: the trend continues, where deployed applications are composed mostly of open-source software.
We treat our own proprietary code like a prized possession. We run QA, we enforce secure development practices, we fuzz it, we review it before it ever hits production. But what about the rest of the application? We just sort of trust it. Sure, we check the specific version of an open source dependency to see if it has a CVE, but we rarely look deeply at the qualities of the open-source project itself through the lens of security.
Relying purely on vulnerability databases to measure risk is a systemic problem. A lack of CVEs doesn’t mean a piece of software is safe to use; it just means it doesn’t have a known CVE registered against it.
The Threat Intelligence Gap
Let’s step back and see what the state of threat intelligence actually is. A solid threat hunting practice relies on high-quality data. But if you’re only looking at whether FUBAR version 1.0 has a known CVE or leaked credentials, you’re missing the bigger picture.
What if the project itself has been abandoned by its maintainers for three years? What if it’s End of Life? What if the project does have vulnerabilities, but the maintainers take an average of six months to actually ship a fix?
Or worse, what if the project doesn’t even exist? We’re seeing a fascinating and terrifying new threat vector right now: AI code generators hallucinating dependencies. An AI might write a script and confidently suggest import YAML instead of the actual, real-world project, PyYAML. A malicious actor sees that hallucination, creates a fake project named YAML loaded with malicious code, and waits for a developer to blindly copy-paste the AI’s output.
These aren’t theoretical problems. This is the new reality of the software supply chain. But traditional scanners won’t catch these issues because there’s no CVE for “project was created yesterday by a name-squatter.”
What is Anchore doing?
Our Chief Research Officer, Daniel Nurmi, recently gave a fantastic presentation with the goal to figure out how to evaluate open-source projects using the same rigorous criteria we apply to our own applications.
At Anchore, we’ve been building a data-gathering pipeline to solve this. It starts with a Software Bill of Materials (SBOM). We take that list of ingredients, go out into the messy reality of the internet, and find the canonical source of truth for those projects (like their GitHub repository).
From there, we can normalize the data and extract some really useful insights:
Boolean metrics: Does the project actually exist (DNE)? Is it End of Life (EOL)?
Time-based metrics: How old is the project? When was the last release? What’s the cadence for fixing security issues?
Qualitative metrics: Are there active maintainers, or is it a ghost town?
But throwing more data at developers doesn’t fix systemic problems, it’s just an increasing amount of noise. Therefore we here at Anchore gather the metrics and apply a flexible scoring technique. A project that “Does Not Exist” or is EOL bubbles right to the top of the risk list, because those are massive red flags that need immediate attention.
It’s easy to be a cynic about supply chain security, but the truth is you can’t secure what you don’t understand. If you’re ready to stop wondering what’s lurking in your dependencies, we are here to help. Anchore’s SBOM-powered platform gives you the comprehensive visibility you need to actually manage your software supply chain risk.
From automatically generating accurate SBOMs to continuous vulnerability scanning and advanced policy enforcement, we give you the actionable data to find hidden threats and achieve compliance by default. Whether you need to rapidly detect zero-days, manage imported third-party SBOMs, or automate policy checks for frameworks like NIST and FedRAMP, we have you covered.
Reach out to our team and request a demo to get started.
Modern software supply chains are increasingly complex, spanning a multitude of operating systems, architectures, and external vendor dependencies. As organizations mature their DevSecOps practices, the challenge has shifted from simply generating Software Bills of Materials (SBOMs) to managing them at scale and extracting actionable security insights across every environment.
With the release of Anchore Enterprise 5.26, we are reinforcing our commitment to:
comprehensive supply chain visibility,
scalable SBOM operations, and
frictionless shift-left security tooling.
This release brings deeper vulnerability insights into diverse operating systems, enhanced tools for managing massive SBOM inventories, and improved reporting capabilities placed directly at the developer’s fingertips.
Here is a closer look at what is new in Anchore Enterprise 5.26:
Expanded Ecosystem Visibility: Fedora and VMware PhotonOS Feeds
As organizations diversify their infrastructure, their security tools must keep pace with highly specialized operating systems that do not operate under standard rules. Relying on generic vulnerability matching for these environments often leads to noisy, inaccurate reporting. For example, Fedora’s rapid release cycle and bleeding-edge packages mean standard enterprise feeds frequently lag behind, leading to mismatched package states. Conversely, VMware PhotonOS is a minimalist OS optimized for container infrastructure; generic feeds often assume a full Linux footprint, resulting in a flood of false positives for its stripped-down environment.
To solve this, Anchore Enterprise 5.26 introduces native, dedicated vulnerability data feeds specifically tailored to the unique lifecycles of the Fedora and VMware PhotonOS ecosystems. By pulling directly from these authoritative native feeds, Anchore deeply understands the specific composition and patch states of these distinct distributions. Customers generating SBOMs with these packages will now receive highly accurate security vulnerability reporting that cuts through the noise, minimizes false positives, and aligns with the actual patch management realities of their infrastructure.
Vulnerability Matching for Arch Linux and SecureOS
Much like the need for dedicated feeds for Fedora and PhotonOS, securing other open source operating systems requires a tailored approach. Arch Linux, for instance, operates on a continuous rolling release model, completely lacking the discrete version numbers that generic scanners rely on to track CVEs. Similarly, SecureOS utilizes hardened, custom package architectures that standard matching rules frequently misinterpret, leaving critical security blind spots.
To solve these unique structural challenges, Anchore Enterprise 5.26 adds new data sources and introduces novel vulnerability matching algorithms for these environments. Rather than trying to force rolling releases or custom architectures into a traditional mold, Anchore has engineered specific logic to track Arch’s continuous updates and SecureOS’s strict configurations. This ensures that generated SBOMs are analyzed accurately and allows teams to utilize these secure distributions with the exact same automated governance as they are accustomed to.
Annotation Filtering for Imported SBOMs (BYOS)
For the past few years, the industry has been learning to walk. The focus has been on installing SBOM generators, fulfilling basic compliance requirements, and creating baseline software inventories. Now, organizations are poised to take the next step in software supply chain security: actively managing, organizing, and governing those SBOMs at an enterprise scale. As the sheer volume of external “Bring Your Own SBOMs” (BYOS) imported into Anchore Enterprise grows (originating from upstream vendors, open-source projects, and other SCA tools), identifying specific SBOMs of interest becomes a needle in a haystack.
To support this next phase of SBOM maturity, Anchore Enterprise 5.26 introduces annotation filtering. Users can now define filters based on imported SBOM annotations using custom key-value pairs. This allows platform engineers and security teams to use custom metadata as criteria to instantly locate, organize, and govern imported SBOMs (e.g., team=backend, environment=production, or vendor=acmecorp). By applying these filters, you can seamlessly integrate 3rd-party SBOMs into your active compliance and risk management workflows without getting buried in data.
Shift-Left Frictionless Reporting: HTML Output for AnchoreCTL
Integrating security into CI/CD pipelines requires tooling that serves both automated systems and the humans who evaluate them. Anchore Enterprise 5.26 introduces a new human-readable HTML output option for the anchorectl image check, image vuln, and image one-time scan commands.
Modern compliance frameworks standardly require reports that serve as official attestations of compliance. To satisfy auditors when they certify an organization, teams need a user-friendly format that can be easily stashed alongside a build as a reliable record of compliance checks. This ensures that clear documentation is always available for review, eliminating the need to translate machine-readable pipeline data (like JSON) through complex scripting, manual intervention, or entirely separate workflow steps.
Now, developers can generate an intuitive, easily shareable HTML compliance report directly from the CLI. This update pushes Anchore further toward the CompOps ideal of continuous, automated compliance throughout the entire development lifecycle. By seamlessly generating both automated policy gates and human-auditable attestations within the exact same workflow step, organizations can reduce friction and satisfy auditor requirements without slowing down engineering.
anchorectl image check my-image:latest --output html >compliance-report.html
Take Control of Your Supply Chain
Anchore Enterprise 5.26 equips teams with the broader ecosystem support, scalable SBOM management, and developer-friendly reporting needed to secure modern software supply chains.
Ready to get started?
Upgrade to Anchore Enterprise 5.26 today to take advantage of these new capabilities. For detailed instructions, API updates, and full release notes, please visit our documentation or reach out to your account team to schedule a demo.
Organizations today are shipping code faster than ever, but speed often masks a critical vulnerability. Many engineering teams mistakenly believe their applications are secure simply because their standard AppSec tools gave them a green light. In reality, they are blindly shipping unpatched, operating system-level vulnerabilities hidden deep inside their containers.
We recently hosted Eva Sarafianou, Senior Engineering Lead of Product Security & Release at Mattermost, and Chadd Owen, Solutions Architect at Anchore. The 60-minute discussion covered exactly how Mattermost successfully transformed its fragmented, manual scanning process into an automated, closed-loop security flywheel.
TL;DR:Traditional SCA tools miss critical infrastructure layer threats wrapped inside container images, making automated, closed-loop container scanning an absolute baseline requirement for modern DevSecOps.Watch the webinar >
Knowing what’s in your container isn’t enough. Learn how Mattermost turns visibility into automated, actionable security at scale with Anchore Enterprise.
Not ready to commit to a full webinar? Keep reading to get a taste for the discussion and how it will change your perspective on securing your software supply chain.
Don’t forget the OS in your containers
Developers frequently treat containers like standard binaries, focusing solely on the security of their application code and first-order dependencies. However, pulling a base image to build an application actually pulls in a sprawling tree of system libraries, package managers, and utilities.
“With containers, you aren’t only shipping an app. You’re shipping an entire OS. SCA’s don’t have OS vulnerability visibility.” —Eva Sarafianou, Senior Engineering Lead of Product Security & Release, Mattermost
Relying exclusively on standard software composition analysis (SCA) tools leaves massive blind spots in your infrastructure. Security teams need purpose-built container visibility to catch and remediate these underlying operating system-level threats before they ever reach a production environment.
A security flywheel for vulnerabilities
Manual security processes create disconnected silos. For example, requiring security professionals to pull images locally to run CLI scanners. These manual audits force teams into a firefighting posture that completely bottlenecks high-velocity CI/CD pipelines.
“Anchore Enterprise finds vulnerabilities, creates tickets, coordinates vulnerability fixes, and scans again. The great thing is that it creates an automated loop.” —Eva Sarafianou, Senior Engineering Lead of Product Security & Release, Mattermost
Integrating native scanning directly into your deployment pipelines (like GitHub Actions) fundamentally transforms development workflows. By automating the entire discovery-to-ticketing cycle, organizations can turn security from a disruptive, manual roadblock into an invisible guardrail that accelerates delivery.
Start safe, stay secure
Implementing a continuous scanning is vital, but shrinking the attack surface at its origin acts as a massive force multiplier. Full Linux distributions carry hundreds of vulnerabilities out of the box, before a single line of proprietary code is even written.
“With Anchore Enterprise and distroless images, we’re not just scanning better…we are starting from a cleaner foundation.” —Eva Sarafianou, Senior Engineering Lead of Product Security & Release, Mattermost
Swapping to minimal, “distroless” base images removes unnecessary shells and package managers that applications don’t actually need to run. This architectural shift inherently neutralizes entire classes of security threats and drastically reduces the baseline vulnerability count, making continuous monitoring far more precise.
Better data == less noise
Alert fatigue is the primary enemy of DevSecOps adoption. Legacy scanners often guess what software is installed based solely on package manager manifests, which routinely buries engineers under an avalanche of false positives and degrades trust in the security pipeline.
“At Anchore, we don’t make assumptions. We look at what’s on disk, what’s in the file system. This result is extremely accurate data.” —Chadd Owen, Solutions Architect, Anchore
Deterministic, on-disk file scanning provides actionable intelligence rather than noise. By eliminating assumptions and looking at exactly what is compiled within the image, teams can drastically improve scan accuracy. This precision restores developer time, allowing engineers to focus exclusively on true positive vulnerabilities that represent genuine risk.
What Else You’ll Discover in the Full Webinar
This container security evolution represents just one thread in a comprehensive discussion that tackles the most pressing operational challenges facing DevSecOps teams today.
The panelists also explore:
The Distroless Transition Barrier: How to ensure necessary system libraries are properly ported over when migrating to distroless images so application functionality doesn’t break.
Policy-as-Code Enforcement: The exact CLI commands used to automatically halt a CI/CD pipeline if non-compliant images violate NIST 800-53 regulatory standards.
Managing the Exceptions: How to implement automated allow-lists to safely manage temporary, business-critical exceptions without disrupting high-velocity deployments.
Manual, fragmented vulnerability scanning is no longer a viable strategy for organizations shipping mission-critical software.
The technical demonstrations and strategic insights in this webinar show exactly how automated container scanning and minimal base images transform security operations from reactive firefighting into strategic threat management.
The one-and-done approach to cybersecurity compliance has been obsolete for more than a decade. Even periodic, audit-driven assessments of an organization’s compliance posture are no longer sufficient in modern environments.
In recent years, this urgency has only intensified. The pace of technological change, the expansion of the software supply chain, and escalating regulatory scrutiny have made automation and continuous compliance not just best practices, but operational necessities. Here’s why:
Constantly Evolving Threat Landscape
New vulnerabilities are discovered every day, from zero-day exploits to newly disclosed CVEs in widely used software. A system that met compliance requirements last quarter may already contain exploitable weaknesses today. At the same time, attackers are increasingly using automation and AI to scan for vulnerabilities at scale, dramatically shortening the window between disclosure and exploitation. In this environment, static controls quickly become outdated.
Dynamic Infrastructure (Cloud & Containers)
Modern infrastructure is no longer static. Cloud resources, containers, and serverless functions are constantly spinning up and down, meaning the environment you audited last month may not even exist today. Infrastructure as Code enables rapid changes, but a single misconfiguration pushed through a CI/CD pipeline can introduce compliance violations across an entire environment in minutes. Continuous visibility is required to maintain control.
Software Supply Chain Complexity
Today’s applications are built on layers of open source dependencies, many of which include nested, transitive components. A newly discovered vulnerability in any one of those dependencies can introduce risk long after your software is deployed. Additionally, organizations increasingly rely on third-party vendors and SaaS providers, expanding the compliance boundary beyond internal systems and requiring ongoing vendor risk management rather than one-time assessments.
The Shifting Sands of Regulatory Requirements
Compliance frameworks are not static documents. Standards such as SOC 2, ISO 27001, FedRAMP, PCI DSS, and NIST regularly update their guidance to reflect emerging threats and best practices. At the same time, new regulations—particularly around data privacy and cybersecurity reporting—continue to emerge across different jurisdictions. Organizations must continuously adapt to remain compliant.
Rapid DevOps & CI/CD Pipelines
Development cycles have accelerated dramatically. Code is deployed weekly, daily, or even multiple times per day, meaning compliance controls must operate at the same speed. Security can no longer be a checkpoint at the end of a release cycle; it must be integrated into development workflows from the beginning. Without automation and embedded validation, compliance quickly falls behind deployment velocity.
What is Continuous Compliance Monitoring?
Continuous compliance monitoring is the practice of validating security and regulatory controls on an ongoing basis across the software lifecycle—not just at audit time. Rather than relying on static reports or periodic assessments, it embeds automated policy enforcement, vulnerability detection, and configuration checks directly into CI/CD pipelines and runtime environments. The objective is to maintain real-time evidence that controls are functioning as intended as code, dependencies, and infrastructure evolve.
Continuous compliance doesn’t happen by accident. It requires intentional design: systems that can scale with modern software delivery, surface meaningful signals from noise, and reduce dependency on manual oversight. Those capabilities rest on three foundational pillars.
The 3 Key Pillars of Continuous Compliance
At its core, continuous compliance monitoring rests on three foundational pillars:
Compliance automation: Manual processes are slow, prone to human error, and simply can’t keep up with the pace of change. Automation is the engine that drives continuous monitoring, gathering data, checking configurations, and identifying deviations without constant human intervention.
Real-time visibility: This isn’t about looking at yesterday’s reports. It’s about having an immediate view into your compliance posture. If a critical system’s configuration drifts out of compliance, you know about it now, not next week. This visibility allows for immediate corrective action.
Actionable insights: Raw data isn’t enough. Continuous monitoring systems don’t just collect information; they analyze it, correlate events, and present you with clear, actionable insights. This means distinguishing between minor anomalies and critical violations, empowering security teams to prioritize remediation while providing clear reporting and evidence to key stakeholders.
Together, these pillars create a robust defense that constantly checks your systems, networks, and data against your defined compliance standards, ensuring deviations are caught and addressed promptly.
How to Implement Continuous Compliance Monitoring: A Step-by-Step Approach
Embarking on continuous compliance monitoring might seem daunting, but like any significant journey, it becomes manageable when broken down into clear, actionable steps.
Step 1: Define Your Compliance Scope and Objectives
Before you can monitor anything, you need to know what you’re monitoring for and why. Begin by clearly identifying all relevant regulatory frameworks, industry standards, and internal policies that apply to your organization. This might include FedRAMP, NIST 800-53, GDPR, HIPAA (for healthcare organizations), PCI DSS, ISO 27001, or a combination thereof. For each, articulate specific, measurable compliance objectives. What does “compliant” look like for each requirement? This foundational step ensures your efforts are focused and aligned with your organizational goals.
Step 2: Identify Key Controls and Metrics
Once your scope is defined, translate those compliance requirements into specific technical and administrative controls. For example, if a requirement is “data must be encrypted at rest,” your control might be “ensure all database storage volumes are encrypted using AES-256.” For each control, establish clear metrics that indicate its health and compliance status. How will you measure if encryption is enabled? What defines “successful” patch management? These metrics will be the data points your monitoring system relies on.
Step 3: Select the Right Technology and Tools
Continuous compliance is only as strong as the systems enforcing it. If your controls depend on manual reviews, disconnected scanners, or point-in-time reporting, you’re not operating a continuous model—you’re layering automation onto a compliance audit workflow. The right tooling must integrate directly into how software is built, delivered, and run.
To operationalize continuous compliance effectively, organizations should look for automated tools that provide:
Software composition visibility & SBOM management: Modern applications are built on complex open source ecosystems, and compliance requirements increasingly demand traceability across dependencies. Tools should generate accurate, reproducible Software Bills of Materials (SBOMs) and allow teams to manage and evaluate them over time.
Policy-driven vulnerability & compliance enforcement: Detecting CVEs is table stakes. The real requirement is the ability to codify compliance frameworks (whether federal, internal, or otherwise) into enforceable policies that run automatically in CI/CD pipelines and registries.
🛡️ How Anchore helps: Anchore allows you to deploy a ready-to-use policy to achieve compliance with a variety of federal standards. Each rule is mapped to the specific control version for easy report and evidence generation.
Lifecycle-wide risk evaluation:Cybersecurity compliance cannot stop at build time. The risk profile of deployed software changes as new vulnerabilities are disclosed. Tools should continuously re-evaluate existing artifacts against updated vulnerability intelligence to identify newly introduced risk.
🛡️ How Anchore helps: Anchore continuously analyzes stored SBOMs against fresh vulnerability feeds, ensuring you’re alerted when previously compliant software becomes non-compliant.
Actionable, context-rich intelligence: Security teams don’t need more dashboards—they need prioritization. Tools should correlate vulnerabilities with severity, exploitability, and policy impact so teams can focus on meaningful remediation.
🛡️ How Anchore helps: Anchore makes it easy to prioritize vulnerability rating based on CVSS Score and Severity, EPSS, and CISA KEV data, reduce noise and drastically improve triage time.
Developer-aligned, automation-first integration: Continuous compliance only works when it integrates seamlessly into CI/CD pipelines, artifact registries, and cloud-native workflows without slowing delivery.
In short, continuous compliance isn’t achieved by running more scans—it’s achieved by embedding enforceable, automated policy controls into the fabric of software delivery. The right tools don’t just help you pass an audit; they help you maintain provable compliance as your software and threat landscape evolve.
Step 4: Establish Automated Monitoring and Alerting
With your tools in place, set up continuous data collection and automated checks against your defined controls and metrics. This means configuring your systems to constantly scan for misconfigurations, policy violations, unauthorized access attempts, and other deviations from your compliance baselines. Crucially, establish a robust alerting system. Who needs to be notified when a critical control fails? How are alerts prioritized? Define clear thresholds and escalation paths so that issues are promptly brought to the attention of the right personnel.
Step 5: Integrate with Incident Response and Remediation
Monitoring is only useful if detected issues are addressed. Integrate your continuous compliance system with your existing incident response and remediation processes. When an alert fires, it should trigger a predefined workflow. This might involve automatically creating a ticket in your service desk system, notifying a specific security or operations team, or even triggering automated remediation actions (e.g., reverting a misconfigured setting). The goal is to move seamlessly from detection to resolution, minimizing the window of non-compliance.
Step 6: Regularly Review and Refine Your Program
Compliance isn’t a one-time project; it’s an ongoing journey. Regularly review the effectiveness of your continuous compliance monitoring program. Are your controls still relevant? Are your metrics accurate? Are there new regulations or threats that require adjustments? Conduct periodic internal audits of your monitoring system itself. Gather feedback from the teams responsible for responding to alerts. This iterative process of review and refinement ensures your program remains robust, relevant, and continuously improves over time.
Getting Started with Continuous Compliance Monitoring
In a world where software changes daily and regulatory expectations evolve just as quickly, continuous compliance is no longer optional. Anchore Enterprise helps organizations move beyond audit-driven security by embedding automated, policy-based enforcement directly into the software supply chain. Contact us today for a personalized demo.
Watch our customer Dreamfactory explain how Anchore Enterprise simplifies and automates their compliance needs.
For a decade, the security industry’s rallying cry was “you can’t secure, what you can’t see.” We demanded to know what was in our software. But now that we have it, we are discovering a harsh truth: visibility without context is just noise. Security teams are currently drowning in a flood of disjointed manifests and static spreadsheets, creating a paradox where we have more data than ever, yet remain unable to answer the fundamental question: “Are we safe?”
This paradox, where more artifacts lead to less clarity, is what we term “SBOM Sprawl.” In our recent webinar, How to Identify and Tackle SBOM Sprawl, Alex Rybak (Anchore) and Russ Eling (OSS Consultants) dissected this growing challenge, outlining how organizations can move from simple compliance generation to intelligent orchestration.
Key takeaways from their discussion include:
The Assembly Paradox: Why modern software development mirrors the tiered supply chain of Boeing’s aerospace manufacturing
The Map vs. The Territory: Why a static SBOM is merely a roadmap, and how its value depends entirely on the tools that consume it
The 4-Day Clock: How SEC material event regulations are forcing security teams to prioritize query speed over data volume
Realistic Scope: Understanding that SBOMs are tools for managing known vulnerabilities, not magic wands for unforeseen threats
The Complexity Trap: Lessons from Aerospace
Alex Rybak, Director of Product Management at Anchore, notes a critical parallel between physical and digital supply chains.
An airplane has 10s of millions of parts, and Boeing ultimately builds the tail fin, rear fuselage and wing fairings…that’s it.
This observation highlights a fundamental reality: modern engineering is an assembly challenge, not a fabrication challenge. In the software world, dependency trees have exploded from dozens of libraries to thousands of direct and transitive components.
This complexity is fundamentally different from the monolithic applications of the past. Where traditional software was written in-house with a few trusted libraries, modern cloud-native applications are assembled from global, open source supply chains. When an organization generates SBOMs without a strategy for this complexity, they don’t gain visibility; they simply generate noise.
The Evolution of SBOM Sprawl
This isn’t the first time the industry has faced a visibility crisis. The pattern we’re seeing with SBOM regulation is remarkably similar to the early days of open source adoption. First came the explosion of usage, followed by the scramble for governance.
From Static Files to Dynamic Systems
Phase 1: The Artifact Era (Pre-2021) was characterized by sporadic, manual inventory tracking. Organizations viewed SBOMs as “nice-to-have” documentation. Security reviews were manual because release cadences were slower. Visibility was limited, but so was the volume of data.
Phase 2: The Regulatory Explosion (2021-2024) brought transformation via EO 14028 and the EU Cyber Resilience Act. Requirements exploded, leading to “SBOM Sprawl.” Every customer demanded different formats (SPDX 2.3 vs. CycloneDX), fields, and delivery mechanisms. This led to data conflicts, where the SBOM generated by engineering didn’t match the one scanned in production, complicating response to incidents like Log4j.
Phase 3: The Systemization Era (2025-Present) emerged as standards like SPDX 3.0 and ISO 5230 provided structure. Organizations realized that generation is a commodity; the value lies in ingestion, analysis, and VEX (Vulnerability Exploitability eXchange) implementation.
We are now seeing this evolution compressed into a much shorter timeframe, driven by aggressive regulatory deadlines.
Learn how to transform your SBOMs from a compliance checkbox into a strategic asset, with the controls needed to prevent sprawl and maximize value.
The presence of an SBOM file does not equate to security posture. As Rybak emphasizes:
“Just having an SBOM doesn’t fix problems, it gives you a roadmap on your parts…an SBOM is only as good as the tools or people that built it.”
A static SBOM is fundamentally different from a managed software supply chain. A file on a disk ages the moment it is generated. If that roadmap is inaccurate, outdated, or disconnected from vulnerability intelligence, it becomes a liability rather than an asset.
Effective governance requires moving from “having an SBOM” to maintaining a dynamic inventory that maps assets to risks. This means integrating SBOM generation into the CI/CD pipeline, ensuring that every build produces a high-fidelity record that can be queried when the next zero-day hits.
The Financial Imperative: The 4-Day Clock
The stakes for accurate data have shifted from technical debt to legal liability. Rybak points out the specific pressure created by the SEC:
“If you look at SEC regulations, if there has been a material security event, the clock starts. You have four days to create an 8K report.”
This requirement fundamentally alters the role of the security team. Incident response is no longer just a technical triage; it is a financial disclosure workflow.
When a material event occurs, organizations cannot afford to spend days grep-ing through repositories or emailing engineering leads to ask, “Do we use this library?” The 4-day window requires instant, queryable visibility. Sprawl the enemy of speed.
Pragmatism and Scope
While SBOMs are essential, Russ Eling, Founder of OSS Consultants, offers a necessary reality check regarding their capabilities:
“SBOMs are not a cybersecurity cure-all. They’re effective at managing known vulnerabilities. They don’t necessarily extend to detecting unforeseen threats.”
An SBOM provides transparency into known components and allows organizations to map them against known vulnerabilities (CVEs). It does not inherently detect zero-day exploits or behavioral anomalies in runtime.
However, the key insight is that without an SBOM, you cannot effectively manage the knowns, which leaves zero bandwidth to hunt for the unknowns. By automating the management of known vulnerabilities through high-quality SBOMs and VEX, security teams free up human capital to focus on advanced threat hunting and architectural security.
Where Do We Go From Here?
To tame SBOM sprawl and turn compliance artifacts into security assets, organizations must adopt a phased approach.
Crawl: Standardization and Governance
Define the Standard: Select a primary internal format (e.g., SPDX 2.3 or 3.0) for storage, regardless of what customers request. Use converters for export only.
Establish Ownership: As Eling suggests, define whether the OSPO, Product Security, or Engineering owns the SBOM process.
Align with ISO 5230: Use the OpenChain standard to establish the foundational governance required to produce trusted data.
Walk: Automation and Context
Automate Generation: Integrate tools like Syft or Anchore Enterprise into the build pipeline. No manual generation.
Centralize Ingestion: Feed all SBOMs into a central management platform. A dispersed inventory is a useless inventory.
Implement VEX: Stop chasing false positives. Use VEX to communicate which vulnerabilities are not exploitable, reducing noise for downstream consumers.
The Strategic Imperative
The window of opportunity to establish these systems is open, but it won’t remain that way indefinitely. Just as organizations that ignored open source governance paid a heavy price during the Log4j crisis, those who ignore SBOM sprawl will face compounding technical debt and regulatory friction.
Organizations that transition from generating files to managing systems will gain significant agility. They will turn the 4-day SEC mandate from a crisis into a standard operating procedure, demonstrating resilience to customers and regulators alike.
Learn how to transform your SBOMs from a compliance checkbox into a strategic asset, with the controls needed to prevent sprawl and maximize value.
Sabel Systems, a managed DevSecOps pipeline platform provider for the defense industry, reduced vulnerability review from 2 weeks to 3 days using Anchore Enterprise while maintaining zero critical vulnerabilities in multiple IL5 environments. The Code Foundry platform enables DoD missions to achieve both platform and vehicle ATO through automated security scanning and compliance workflows that provide real-time transparency to government auditors.
Problems
Manual vulnerability review cannot scale with application growth
DoD customers required cloud-agnostic, IL5-compliant DevSecOps solutions for accelerated ATO
Complex environment demanded seamless integration across multiple Cl/ CD tools and cloud providers
Solutions
Anchore Enterprise delivered:
Automated vulnerability scanning and SBOM generation integrated into Cl/CD pipelines
On-premise IL5-ready deployment with DoD policy packs for automated compliance
API-first architecture enabling flexible integration across GitLab, Jenkins, and Kubernetes
Results
75% reduction in vulnerability review time (from 1-2 weeks to 3 days)
Scaled zero critical vulnerabilities policy across 100+ applications
Real-time audit transparency through compliance evidence dashboards
Introduction
Sabel Systems provides a managed DevSecOps pipeline-as-a-service for Department of Defense (DoD) missions and defense contractors developing mission-critical vehicle systems. The company’s Code Foundry platform fills a crucial gap in the marketplace by offering a comprehensive software development platform specifically designed for applications that must run on air-gapped, field systems rather than traditional, cloud-dependent, web deployments.
Code Foundry operates as a platform-agnostic solution that is designed to operate across different infrastructure environments (e.g., AWS GovCloud, private DoD-approved cloud, and on-premise infrastructure). With a lean team of 10 supporting 100+ active developers, the platform manages hundreds of applications for next-generation military vehicles.
Problems
Sabel Systems faced three critical challenges in delivering a DevSecOps platform that could meet the demanding requirements of DoD vehicle development programs:
Manual vulnerability review cannot scale with growth
As Sabel Systems supported Army, Air Force, and Navy Digital Engineering initiatives, a common challenge emerged within their software acquisition pathway. The DoD security teams were unable to adequately support the 100+ developers they served. The manual review process—time¬consuming, labor-intensive, and prone to error—became a bottleneck that threatened the platform’s ability to fulfill its mandate of producing secure applications. This inefficiency underscored the urgent need for a scalable solution. What had worked in the early days was now buckling under the pressure of scaling a successful business.
To address this, Sabel Systems designed its Code Foundry architecture to eliminate the need for the DoD’s standard manual vulnerability review process and ensure the software acquisition pathway could scale to support enterprise-level functionality.
DoD customer demanded exacting compliance and deployment capabilities
Code Foundry customers operate in one of the most demanding technical environments in software development: DoD vehicle systems that must achieve Authority to Operate (ATO) before field deployment. The DoD software acquisition pathway mandates modern DevSecOps practices but within fully air-gapped environments; a challenge for many traditional cloud-based security tools.
Beyond technical requirements, Code Foundry needed to support the complex organizational structure within the DoD. Different military branches have distinct preferences for cloud environments and security protocols, requiring a truly agnostic solution that can be deployed anywhere while maintaining consistent security standards.
Technical architecture required seamless multi-tool integration in controlled environments
Code Foundry’s technical architecture presented unique integration challenges. Operating in IL5 (controlled unclassified) environments on NIPR networks means that the security software must run without external connectivity. Additional requirements are seamless integration with diverse Cl/CD toolchains such as GitLab, Jenkins, Bitbucket, GitHub, and various Kubernetes distributions without requiring extensive per-environment configuration.
Solutions
Sabel Systems selected Anchore Enterprise to scale their vulnerability management across hundreds of applications with limited resources, streamline compliance workflows, and leverage a platform purpose-built for DoD environments.
Automated vulnerability scanning enables scale without additional headcount
Sabel Systems’ lean security was able to remove manual review bottlenecks with Anchore Enterprise and is now able to support their growing customer base and applications without adding personnel. Anchore Enterprise’s automated approach allows the same 10-person security team to effectively support 100s of applications across multiple DoD contractors. Anchore Enterprise integrates directly into Code Foundry’s Cl/CD pipelines, automatically scanning every container image as soon as it’s built and providing immediate feedback on security posture. Rather than security reviews becoming a constraint on business growth, they now happen seamlessly in the background.
On-premises deployment meets DoD security and compliance requirements
Anchore Enterprise’s DoD-tailored on-premise and IL5-compliant deployment capabilities deliver comprehensive security entirely within government-approved infrastructure.
Anchore Enterprise includes pre-built policy packs specifically designed for DoD requirements, including FedRAMP, NIST, and STIG compliance frameworks. Through automated compliance enforcement, Code Foundry customers receive real-time notifications of compliance issues, enabling them to address problems early in development rather than discovering them during costly ATO audits. This proactive approach helps customers build their ATO packages with confidence while avoiding the time-consuming remediation cycles that typically delay program timelines.
Anchore Enterprise’s native compliance dashboards and reporting offer the DoD auditors real-time transparency into the compliance state of all parties. Instead of waiting weeks for static compliance reports, auditors access live security data directly, creating dynamic review meetings and building trust through transparency.
API-first architecture enables flexible integration across diverse environments
Anchore Enterprise’s API-first architecture deploys via Helm charts into Kubernetes clusters and integrates seamlessly with GitLab CI, Jenkins, and other Cl/CD tools that different military branches prefer.
Anchore CTL, the vulnerability scanner for Anchore Enterprise, executes scans directly within the Kubernetes cluster, a critical security advantage for modern infrastructure teams. By baking AnchoreCTL directly into Code Foundry, Sabel Systems created a secure approach that eliminates the need to open network connections to external systems. This addresses a common security concern where external security tools create potential attack vectors.
“We include AnchoreCTL in an image and use that image to run the scanning and analysis steps. We do that so we can keep all the connections inside of the cluster without having to SSH into an already running pod.”
—Robert McKay, Digital Solutions Architect, Code Foundry, Sabel Systems
Results
The implementation of Anchore Enterprise transformed Sabel Systems’ operational efficiency and positioned Code Foundry as the premier DoD DevSecOps platform:
Zero critical vulnerabilities maintained across 100+ applications
Anchore Enterprise enables Code Foundry to maintain their strict security policy of zero critical or high vulnerabilities at scale. This level of security assurance is essential for applications that will eventually deploy to mission-critical vehicle systems.
75% reduction in vulnerability review time
Code Foundry’s now automated vulnerability review process was cut from 1-2 weeks to 3-days leading to faster platform updates and more responsive customer support.
“Before Anchore, it would take us a week to two weeks to go through everything that an image could have—we’d have to first build the actual software on the image and then go through all the different connection points and dependencies. Using Anchore has brought that down to a 3-day review time.”
—Robert McKay, Digital Solutions Architect, Code Foundry, Sabel Systems
Code Foundry now provides government reviewers with live access to security dashboards and compliance data. This transparency accelerates the review process and builds trust between contractors and government oversight teams.
“The idea is that you can replace your static contract deliverables with dynamic ones -doing review meetings based on Anchore’s live data instead of ‘here’s my written report that took me a week to write up on what we found last week,’ and by the time the government gets it, it’s now 2-3 weeks old.”
—Joe Bern, Senior Manager, Code Foundry, Sabel Systems
By leveraging Anchore Enterprise, Sabel Systems has established Code Foundry as the trusted platform for DoD contractors requiring the highest levels of security, compliance, and operational efficiency in their software development workflows.
Download the PDF version of this case study for a complete look at how Sabel Systems leverages Anchore SBOM and Secure to scale compliance while reducing vulnerability review time by 75%.
ModuleQ, an AI-powered enterprise knowledgean AI-powered enterprise knowledgesolution, reduced vulnerability managementsolution, reduced vulnerability management time by 80% with Anchore Enterprise whiletime by 80% with Anchore Enterprise while meeting regulatory compliance for the financialmeeting regulatory compliance for the financial services industry. Anchore Enterprise integratedservices industry. Anchore Enterprise integrated seamlessly into ModuleQ’s existing DevSecOpsseamlessly into ModuleQ’s existing DevSecOps workflow supporting enterprise deployments andworkflow supporting enterprise deployments and now automates previously manual vulnerabilitynow automates previously manual vulnerability processesprocesses.
Challenges
Identify, triage and analyze constant flood of new vulnerabilities with limited resources
Ensure critical vulnerabilities never reach production without disrupting developer workflow
Address regulatory compliance demands for strict container security requirements
Solutions
Anchore Enterprise secures the software supply chain with:
Turnkey container vulnerability scanning, triage and analysis
Cloud native integration enabling proactive vulnerability notification and remediation workflow
Support for enterprise deployments to meet uncompromising compliance requirements
Results
80% reduction on time spent managing vulnerabilities
50% less time on security tasks for production deployments
Built immediate trust with financial services customer base
Introduction
ModuleQ’s enterprise AI software delivers timely, proactive customer insights by anticipating user needs, helping organizations streamline their decision-making processes. Operating in the highly regulated financial services industry, ModuleQ deploys its solutions directly within customer-controlled tenants, ensuring data security and compliance.
The software is built using a robust development stack that includes .NET and C#, with Azure DevOps Pipelines driving the build environment. The platform consists of a single application made up of dozens of microservices, utilizing a multi-stage pipeline to ensure stability and security. As code progresses from nightly builds to production, container scans are automatically run to identify vulnerabilities, ensuring secure and seamless deployments
Challenges
Managing constant flood of new vulnerabilities with limited resources
With a small but dedicated team, ModuleQ was straining under the weight of the constant flood of new vulnerabilities released. High-profile security incidents like the Log4j supply chain attack and Crowdstrike incident only served to highlight the importance of vigilant vulnerability management. The sheer volume of new vulnerabilities—25,000 in 2023 alone—was overwhelming ModuleQ’s manual processes.
ModuleQ quickly recognized their current systems were no longer scaling with the resources on hand and started researching a turnkey vulnerability management solution that automated vulnerability scanning, management and analysis.
Ensure crictial vulnerabilities never reach production without disrupting developer workflow
In the high-stakes threat environment that ModuleQ operates in they found that requiring engineers to break out of their workflow and manually review vulnerabilities didn’t meet the security posture they needed. Each time their developers switched to a traditional, passive vulnerability management dashboard, they would lose context. This led to concerns around potentially missing critical vulnerabilities. With limited resources and the constant pressure to secure sensitive data, a natively integrated DevSecOps solution was needed to retain the high velocity of their software delivery and maintain the highest possible security guarantees.
This called for a vulnerability management platform that embedded into their existing DevSecOps ecosystem. By directly integrating vulnerability scanning and management into their existing automation tooling they could remove all manual intervention from vulnerability scanning, triage and reporting.
Address regulatory compliance demands for strict container security requirements
ModuleQ specializes in deploying its enterprise AI software into customer environments operating in the highly regulated financial service sector. To meet the expectations of clients, ModuleQ needed a partner capable of supporting enterprise deployments while guaranteeing airtight security. These institutions operate in high-stakes environments where even a minor security lapse can have catastrophic consequences, especially with sensitive content like Microsoft 365 and Salesforce data.
Deployments are often conducted directly by the financial institutions themselves, meaning no data can leave the client’s secure environment. This created the need for a security solution that could operate effectively without external network access, delivering bulletproof protection against sophisticated threats from state-sponsored actors and cybercriminals.
“Anyone can push out code quickly. Can they push secure code with the highest confidence that it fits the risk profiles of critical national infrastructure like financial services?.“
—Joseph Zuromski, VP of Engineering, ModuleQ
Solutions
ModuleQ selected Anchore Enterprise as their container vulnerability solution to solve the challenges presented by their customer base:
Turnkey container vulnerability scanning, triage and analysis
Anchore’s container vulnerability scanning and analysis platform helped ModuleQ automate and streamline its security processes. Previously manual security reviews of software builds heavily taxed the engineering team. With Anchore Enterprise, ModuleQ now automatically scans all software builds nightly, stores the reports for reference and analyzes the identified vulnerabilities to determine prioritization in the development cycle.
Anchore Enterprise automates each step of this process and provides the analysis tooling to quickly derive actionable security insights. ModuleQ is now able to de-risk their software deliverables and free up their developer’s time for new features rather than hunting down low- signal vulnerabilities.
“Anchore was one of the first tools that we brought on. It was recommended by our CISO who has been deeply involved in the security community for decades.“
—Joseph Zuromski, VP of Engineering, ModuleQ
Cloud native integration enabling proactive vulnerability notification and remediation workflow
Anchore Enterprise was designed to be integrated directly into any modern, cloud native DevSecOps pipeline to help organizations shift security left from release time earlier into the development cycle. By embedding vulnerability scanning and reporting directly into their CI/CD pipeline, ModuleQ stops crucial vulnerabilities from slipping into production with the reliability guarantees of a fully automated system.
Anchore Enterprise automatically reports all HIGH and CRITICAL vulnerabilities directly to the build runner which immediately breaks to prevent these vulnerabilities from being promoted to production. This provides immediate feedback to the engineering team and initiates the remediation process. This proactive security posture prevents any potential disastrous vulnerabilities from being missed and reduces time wasted by developers context switching out of their existing workflow.
On top of this, Anchore’s support for ModuleQ’s existing developer toolchain—including Azure DevOps Pipelines, .NET, and C#—was paramount. The benefits that Anchore Enterprise brings to ModuleQ are possible because of Anchore’s support for the Microsoft ecosystem of development tooling.
Support for enterprise deployments to meet uncompromising compliance requirements
ModuleQ selected Anchore Enterprise for its support for on-prem deployments. Given that ModuleQ’s customers expected on-prem deployments to safeguard their data, Anchore was able to reinforce ModuleQ’s commitment to meeting and exceeding these security expectations.
Anchore’s platform was designed from the ground up to operate in on-prem and even air-gapped environments, ensuring that no external connectivity is required. These design choices gave ModuleQ the confidence that Anchore was the trusted partner to support container security needs of their demanding customer base.
Results
The implementation of Anchore Enterprise transformed ModuleQ’s security posture and business operations:
80% reduction on time spent managing vulnerabilities
By leveraging Anchore’s automated scanning and reporting capabilities, ModuleQ reduced the time spent managing vulnerabilities. This unlocked efficiency gains allowing the team to focus on developing new features and improving customer satisfaction.
50% less time on security tasks for production deployments
Anchore Enterprise’s cloud native integration and proactive vulnerability management system streamlined ModuleQ’s production deployment process, cutting security task time in half. This allowed ModuleQ to maintain its rapid cadence of software delivery while maintaining the highest level of security.
Sinificantly increased confidence that newly shipped customer releases will meet the highest security requirements
Anchore’s experience with on-prem deployments gave ModuleQ the confidence that their software releases would meet the rigorous security standards of their financial services clients. This confidence translated into stronger customer relationships and trust in ModuleQ’s security posture.
“I can’t emphasize enough, there is a ton of scrutiny around security—especially around our containers. We deploy into large banks and financial institutions worldwide. You can imagine the security involved with these types of deployments. Anchore is a key component in making these deployments successful.”
—Joseph Zuromski, VP of Engineering, ModuleQ
By leveraging Anchore Enterprise, ModuleQ has positioned itself as the trusted partner with the expertise to meet the highest levels of security and regulatory compliance.
Download the PDF version of this case study for a complete look at how ModuleQ reduces vulnerability management time by 80% while meeting the highest regulatory compliance standards.
PEO Digital’s DevSecOps Platform “Black Pearl” enables US Navy programs to build and deploy software rapidly while maintaining the most stringent government security and compliance requirements.
Compliance reporting and maintenance are time intensive and so are managing vulnerabilities and risks through open- source software.
Challenges
Achieve RMF security and compliance requirements
Maintaining continuous compliance
Managing the risk of open-source software
Vulnerability overload for developers
Solutions
Anchore automates security and compliance to reduce risks in the software supply chain:
Policy packs to meet RMF security controls
Automated and continuous ATO compliance
Managing OSS risks with continuous monitoring (ConMon)
Automated prioritization of vulnerabilities
Results
Achieve authority to operate (ATO) for software under RMF framework:
Deploy a ready to be assessed DSOP in 3-5 days
Significantly reduced time spent on compliance reporting
Proactive OSS risk management
Reduced vulnerability overload with prioritized vulnerability reporting
Introduction
Black Pearl is a PEO Digital Enterprise DevSecOps Platform comprised of two offerings, Party Barge and Lighthouse. Lighthouse is a resilient, production-grade DevSecOps Platform, tailored to meet specific Mission Owner requirements whether it be on-prem or in a custom cloud deployment.
Party Barge is built from the Lighthouse baseline, designed as a Multi-tenant Development and Test environment (IL2/5) offering DevSecOps Tools as a Service using a simple per user licensing model, and is fully managed by the Black Pearl Party Barge Team
Challenges
For any software to be built, deployed and used by the warfighter it has to achieve ATO. To achieve ATO, all software developed for a DoD mission has to be built on a software development platform that meets the DoD DevSecOps Enterprise Reference Design.
Sigma Defense, a technology company that specializes in networking, security and software engineering for the public sector, faced a number of challenges while architecting the Black Pearl platform such as securing the software supply chain, ATO-compliance, open- source software (OSS) risk management and vulnerability management.
Achieving RMF security and compliance for both DSOP and customers
Not only does Black Pearl need to achieve ATO for itself, it has to help its customers achieve ATO for the applications that are built on it. In order to achieve both of these goals, they required a software supply chain security platform that could both scan the Black Pearl platform for compliance and all applications built by its customers.
Maintaining continuous compliance
With the advent of the RAISE 2.0 memo jointly signed by the Senior Information Security Officers of the Navy and Marine Corps in November 2022, continuous ATO-compliance is now a priority for all DON missions. Given the amount of time and effort that goes into achieving an ATO in the first place, automating the bulk of the compliance tasks is crucial.
Managing the risk of open-source software
The average application contains 500+ open- source components; this is a powerful source of leverage for developers when building applications but creates risk. Black Pearl has the dual problem of having to manage the risk of open-source dependencies in its own platform and provide tools to help its customers manage the OSS risk in their own applications. Finding a solution to manage this risk is not only a security prerogative for Black Pearl but a compliance requirement.
Vulnerability overload for developers
Identifying vulnerabilities is the first step to ATO but given the number of vulnerabilities that exist in typical open-source components, triaging vulnerabilities can rapidly consume all of a developer’s time and resources. This degrades the developer velocity gains that were achieved by adopting a DevSecOps practice. Being able to filter which vulnerabilities are priorities rather than noise is a key challenge to overcome in order to achieve compliance without sacrificing velocity.
Solutions
To address these challenges, Sigma Defense chose Anchore to protect Black Pearl’s software supply chain.
Policy packs to meet RMF security controls
Sigma Defense chose Anchore to secure both Black Pearl’s software supply chain and all DON applications that are built on Black Pearl. Anchore can identify, evaluate, prioritize, enforce and report on whether security controls meet the compliance requirements of the Risk Management Framework (RMF). Each software development platform must meet stringent security requirements such as RA-5 (Vulnerability Management), SI-3 (Malware Protection), and IA-5 (Credential Management). This process can be daunting and resource-intensive, requiring continuous attention to detail and expertise in compliance review. Anchore and Sigma Defense have demonstrated their expertise to help various DoD missions, including Platform One’s Big Bang and PEO IWS The Forge, pass their authorizing official (AO) reviews and achieve ATO, mitigating this typically massive undertaking.
“By using the Anchore and the Black Pearl platform, applications inherit 80 percent of RMF security controls…You can avoid all of the boring stuff and just get down to what everyone does well, which is write code.”
—Christopher Rennie, Black Pearl Product Growth Lead
Automated and continuous ATO compliance
Achieving ATO is just the beginning; maintaining continuous compliance is an ongoing challenge. This involves managing security findings, tracking plan of action and milestones (POA&Ms), and ensuring that all necessary security controls are continuously met. Manual processes for maintaining compliance can be error-prone and resource-intensive. Anchore offers automated ATO compliance, continuously managing findings and POA&Ms. This automation ensures that compliance is maintained with minimal manual intervention, reducing the risk of non-compliance and the associated penalties.
“The DoD has four different layers of authorizing officials in order to achieve ATO. You have to figure out how to make all of them happy. We want to innovate by automating the compliance process. Anchore helps us achieve this, so that we can build a full ATO package in an afternoon rather than taking a month or more.“
—Josiah Ritchie, DevSecOps Staff Engineer
Managing OSS risks with continuous monitoring (ConMon)
Open-source software is widely used in modern software development, but it comes with inherent risks, including potential security vulnerabilities. Anchore mitigates this risk by integrating a vulnerability scanner, policy enforcer and reporting system to continuously monitor OSS vulnerabilities and risk in any software supply chain. This enables proactive management and active defense of OSS risk ensuring that vulnerabilities are detected and addressed promptly; reducing the risk of security breaches.
Automated prioritization of vulnerabilities
Black Pearl integrates the Anchore Developer Bundle which automatically flags vulnerabilities that developers are able to address and move their application to ATO quicker. This shift-left security practice creates actionable feedback for developers to overcome compliance hurdles before the review process. The power of DevSecOps is developer velocity. By embedding security directly into the development process DON missions get access to rapid and secure deployments.
Results
Platform ATO in 3-5 days
The main advantage of adopting the Black Pearl platform is the accelerated timeline of having a fully operational DSOP. While DIY builds can take up to 6 months or longer, Black Pearl users are able to access a fully operational DSOP within 3-5 days. With Anchore fully integrated into Black Pearl and its pre-built RMF policy pack running, all software built on Black Pearl will dramatically reduce the time to application ATO. Non-compliant software design decisions can be identified in development which prevents unnecessary engineering cycles from being wasted. Security is not the only practice that can benefit from a shift left approach to software development.
Significantly reduced time spent on compliance reporting
Anchore automates compliance checks and compliance artifacts:
Reduces hours spent manually reviewing vulnerability reports and creating the compliance artifacts that will then be delivered to the authorizing officials (AOs).
Ensures that all of the data exists in the reports and is formatted in the way expected by the reviewer. This prevents delays due to the inconsistencies that inevitably occur as part of any manual process.
“Working alongside Anchore, we have customized the compliance artifacts that come from the Anchore API to look exactly how the AOs are expecting them to. This has created a good foundation for us to start building the POA&Ms that they’re expecting”.
—Josiah Ritchie, DevSecOps Staff Engineer
Proactive OSS risk management
By shifting security and compliance left, Black Pearl enables its customers to identify and remediate open-source vulnerabilities that would block an ATO as early as the development phase of the software development lifecycle (SDLC). This proactive approach to security and compliance ensures that OSS risk is mitigated, compliance is smooth and the benefits of composable software are available to the developers of the US Navy. The downstream benefit is that time to ATO is reduced.
Reduced vulnerability overload with prioritized vulnerability reporting
The less time developer’s spend remediating vulnerabilities that have no tangible security value, the more time they can spend writing software to help the warfighter. Anchore automatically prioritizes actionable vulnerabilities and alerts developers. This prevents vulnerability overload and accelerates the time to delivery of critical software and features.
Download the PDF version of this case study for a complete look at US Navy achieves ATO in days with continuous compliance and OSS risk management.
DreamFactory, an API generation platform serving highly regulated organizations required an air-gapped vulnerability scanning and management solution that didn’t slow down their productivity. Avoiding security breaches and compliance failures are non-negotiables for the team to maintain customer satisfaction.
Challenges
Secure deployments without cloud connectivity
Air-gapped vulnerability scans for highly regulated industries
Highly regulated industries require high trust partnerships
Solutions
Anchore Enterprise secures the software supply chain with:
Support for on-premises and air-gapped deployments
Comprehensive vulnerability scanning integrated into CI/CD pipeline
Automated SBOM generation to build trust fast
Results
75% reduction in time spent on vulnerability management and compliance requirements
70% faster production deployments with integrated security checks
Rapid trust development through transparency
Introduction
DreamFactory is an API generation platform that puts a REST API endpoint in front of every table, view, or stored procedure in a database. It then wraps every endpoint in enterprise-grade security, including role-based access control (RBAC), key management, authentication, and rate limiting. With industry estimates reporting that 70% of APIs are internal or private, DreamFactory’s solution is critical for organizations looking to streamline their API development process securely. Built on a Laravel (PHP) web application with Redis and MySQL, DreamFactory releases a new major version quarterly while running daily security scans. The DreamFactory product is designed for on-premises deployment. Anchore Enterprise is deployed in AWS and GitHub actions make callbacks to Anchore for security checks.
Challenges
DreamFactory faced several critical challenges in meeting the needs of its customers, particularly those in the defense community and other highly regulated industries:
Secure deployments without cloud connectivity
With the ascent of the cloud deployment pattern, always-on internet connectivity became a foundational assumption for customer deployments. Modern software supply chain security took this to heart by adopting continuous scanning strategies that required direct access to production services.
DreamFactory works with the DoD and other highly regulated organizations, such as Oil and Gas. The data that is processed by these organizations have the highest national security implications. The assumption of always-on connectivity no longer holds. On-premises deployments are mandatory, and air-gapping is almost always required. This broke the assumptions of modern software supply chain security strategies and required new solutions to deliver bulletproof security without cloud connectivity.
Air-gapped vulnerability scans for highly regulated industries
Typically, if software is run on-prem and air-gapped the need for vulnerability scanning is not required. If vulnerabilities do exist they are not considered a priority due to the fact that they have no external connectivity that gives an adversary remote access to the service.
While this is common practice in the enterprise world, this is not the case in highly regulated environments. Both air-gapping and vulnerability reporting are mandatory to protect the data that these organizations process.
Highly regulated industries demand high trust partnerships
In highly regulated industries, particularly those involved with national security or critical infrastructure trust is a necessity rather than a nice-to-have. Organizations like the DoD and critical infrastructure providers operate in high-stakes environments where security breaches or compliance failures can have catastrophic consequences. The potential to compromise national security, endangering lives, or cause severe financial damage is ever present.
These entities face constant, sophisticated threats from state-sponsored actors, cybercriminals, and other malicious entities. In this context, every software component, partnership, and integration point represents a potential vulnerability that adversaries could exploit, making rapid establishment of trust crucial.
Solutions
DreamFactory implemented Anchore Enterprise to address these challenges:
Comprehensive Vulnerability Scanning
In order to generate vulnerability reports without having access to the air-gapped deployments, Dreamfactory integrated Anchore Enterprise into its own build pipeline and ran daily vulnerability scans on all deployment versions. Dreamfactory then notifies their customer’s of urgent vulnerability updates, fulfilling their commitment to continuous vulnerability scanning and compliance.
By catching the vulnerabilities in our build pipeline, we can then inform our customers and prevent any of the APIs created by a Dreamfactory install from being leveraged to exploit our customer’s network. Anchore has helped us achieve this massive value-add for our customers.
—Terence Bennet, CEO, Dreamfactory
Automatic SBOM Generation
Anchore’s automated SBOM generation is directly integrated into Dreamfactory’s build pipeline so that every build is cataloged and stored for reference. An SBOM serves as a trust accelerator in a high-threat environment. It provides immediate transparency into the software’s ingredients which enables fast risk assessment and compliance verification.
Since the publication of Executive Order 14028, “Improving the Nation’s Cybersecurity” in 2021 all branches of the federal government have taken the “suggestion” that SBOMs are a necessary element of software supply chain security seriously.
We’re seeing a lot of traction with data warehousing use-cases. Security is absolutely critical for these environments. Being able to bring an SBOM to the conversation at the very beginning completely changes the conversation and allows CISOs to say, ‘let’s give this a go’.
—Terence Bennet, CEO, Dreamfactory
Results
The implementation of Anchore Enterprise transformed Dreamfactory’s security posture and business operations:
75% reduction in time spent on vulnerability management and compliance requirements:
Automated vulnerability scanning and reporting, even for air-gapped deployments frees up engineering cycles for mission critical work.
70% faster production deployments:
With vulnerability scans integrated into the CI/CD pipeline, Dreamfactory can deploy updates more rapidly without compromising security.
Rapid trust development through transparency:
An automated and complete SBOM record accelerates trust development in an environment where the stakes are unparalleled.
“Anchore has not only helped us meet the stringent requirements of organizations like the DoD,” concludes Bennet, “but it has also given us a competitive edge in the market. We’re now able to provide a level of transparency and security that our customers in highly regulated industries demand, all while maintaining the efficiency of our development and deployment processes.”
By leveraging Anchore Enterprise, Dreamfactory has positioned itself as a trusted partner for organizations requiring the highest levels of security and compliance in their API management solutions.
Download the PDF version of this case study for DreamFactory.
Infoblox, a leader in Enterprise DDI (DNS, DHCP, IPAM), required a reliable container vulnerability scanning and management solution to scale the program to 150 applications developed by 600+ engineers. Product security and compliance are critical business functions at Infoblox. The trust created by these teams are foundational to business success and continuity.
Challenges
Shift left security at scale; vulnerability detection & management to prevent vulnerabilities from entering production
Resourcing challenge; Automation needed to scale 15 Security FTEs to meet output of 600+ Engineering FTEs
Meet and maintain compliance certifications (FedRAMP moderate, SOC 2, StateRAMP, ISO 27001)
Enterprise integration into existing pipeline and infrastructure (e.g., Amazon EKS, Harbor registry, Jenkins CI, etc.)
Solutions
Anchore Enterprise secures the software supply chain with:
Container image scanning with low false positives
Vulnerability and CVE Management
Native integrations with Amazon EKS, Harbor and Jenkins
FedRAMP, SOC 2, StateRAMP, and ISO compliant platform
Results
75% reduction in time for manual vulnerability detection tasks
55% reduction in hours allocated to retroactive remediation of vulnerabilities
60% reduction in hours spent on compliance tasks
Empowered product security team to adopt proactive—shift left—security posture
Introduction
Infoblox, a leading provider in the enterprise DDI (DNS, DHCP, and IP Address Management) space, has been pioneering the DDI segment for over 25 years. The enterprise DDI space is crucial for managing and automating network services, ensuring seamless and secure network operations. Infoblox manages over 150 applications in production environments. With multiple deployments per day, this leads to 1000s of containers per month that need to be scanned for vulnerabilities; On top of that, they operate both a commercial and high compliance environment (e.g., FedRAMP, etc).
The Infoblox Product Security team faced a significant challenge due to the lack of an existing vulnerability detection and management program. Previously, apps were deployed to production without any knowledge of potential vulnerabilities or manually reviewed after the deployment.
Scaling security with low false positive rate
Given the scale of the software development program at Infoblox (i.e., 1000s of containers built monthly), manual scanning and review was not a viable strategy. Furthermore, the product security team, consisting of only 15 full-time employees (FTE), was vastly outnumbered by the 600 FTEs in engineering, resulting in a 40:1 ratio. This disparity made it essential to have a vulnerability scanning tool with a low false-positive rate to scale the vulnerability management program effectively.
Scaled security without friction
The existing development tools and infrastructure, such as Amazon EKS, Harbor registry, and Jenkins CI, required a solution that could seamlessly integrate without disrupting the current DevOps workflows.
“When I first started, I was manually searching GitHub repos for references to vulnerable libraries but it was impossible to tell whether the codebase was a test repo, staging or not even in use. Anchore’s SBOM inventory gave us certainty that a vulnerability was actually in production and needed to be fixed.”
—Sukhmani Sandhu, Product Security Engineer
Automation was necessary to manage the high volume of applications and deployments, ensuring vulnerabilities were detected and managed efficiently.
Compliance at scale
Another layer of complexity was added by the need to acquire and maintain multiple compliance certifications, including FedRAMP Moderate, SOC 2, StateRAMP, and ISO 27001. Infoblox required a secure and compliant vulnerability management system to meet existing compliance requirements and facilitate the attainment of new certifications. Not only did the organization prioritize these business critical certifications but the security team was charged with meeting these new requirements without dropping any of their existing responsibilities. They needed a solution that could not only meet compliance but allow the team to scale their efforts.
Solutions
To address these challenges, Infoblox chose Anchore Enterprise as their container vulnerability scanning and management solution.
Save time – more signal and less noise
Anchore Enterprise’s low false-positive rate was a critical factor in this decision, enabling the product security team to scale their efforts effectively despite the 1000s of containers being deployed every week. Every false positive eliminated means less time wasted by the Product Security team and more time dedicated to remediating actual threats to the organization
Less fire fighting in production
Centralized vulnerability and CVE management, allowed the Product Security team to proactively remediate vulnerabilities when a container image is checked-in to the container registry, Harbor. This early detection was a significant step in Infoblox’s shift-left strategy for product security. On top of this, developers from the engineering organization began to self-serve AnchoreCTL in order to scan their source code for vulnerabilities while they were authoring it. This helped Infoblox catch vulnerabilities even before the source code was sent to Jenkins for the build process.
Enterprise integration with DevOps speed
Anchore Enterprise seamlessly integrated with Infoblox’s existing software development infrastructure and tooling, including Amazon EKS, Jenkins CI, and Harbor. This integration ensured that the new vulnerability management processes did not disrupt the current workflows and still allowed the product security team to scale their vulnerability detection and management efforts in the high-output DevOps engineering environment.
FedRAMP, SOC 2 and ISO compliance in rapid deployment environment
Additionally, Anchore Enterprise helped Infoblox achieve and maintain compliance certifications, such as FedRAMP Moderate, SOC 2, StateRAMP, and ISO 27001. Not only does Anchore Enterprise meet existing compliance standards, it helps Infoblox meet compliance controls, specifically the NIST 800-53 control family (RA-5). Infoblox was able to take advantage of both of these benefits by choosing Anchore Enterprise for vulnerability scanning and compliance certification. All of this while not adding friction to the high-speed development cadence and speeding up the compliance process.
“We’re not trying to waste our team or other team’s time. We don’t want to report vulnerabilities that don’t exist. A low false-positive rate is paramount. FedRAMP is very stringent and we don’t want to create more work for ourselves given our limited resources.”
Anchore Enterprise transformed Infoblox’s product security program by enabling the team to scale their efforts, automate compliance and maintain the speed of deployments.
75% reduction in time for manual vulnerability detection tasks
55% reduction in hours allocated to retroactive remediation of vulnerabilities
60% reduction in hours spent on compliance tasks
By reducing the amount of time spent on manual security and compliance tasks, Infoblox opened the product security team up to focus on higher value initiatives like automating policy and remediation.
Developers self-adopted scanning tools during development, removing vulnerabilities before they entered the build pipeline. This proactive approach led to a 55% reduction in hours allocated to retroactive remediation. Both teams could now manage risk collaboratively, knowing about vulnerabilities before applications were pushed to production.
During incident response, a centralized inventory of all SBOMs enabled quick searches in Anchore Enterprise, reducing the need for extensive codebase searches. This automation reduced manual vulnerability detection time by 75%.
Additionally, the automation of compliance reporting artifacts resulted in a 60% reduction in hours spent on compliance tasks, dramatically improving how quickly compliance could be certified and the number of hours needed to meet the compliance requirements.
“We effectively had no tooling before Anchore. Everything was manual. We reduced the amount of time on vulnerability detection tasks by 75%.”
Iron Bank is a program within the Department of Defense (DoD) that enables easier adoption of DevSecOps solutions and provides transparency into containerized software throughout the DoD. It provides Platform One and any DoD agency with a hardened and centralized container image repository that supports the end-to-end lifecycle needed for secure and dynamic software development.
Challenges
Provide DoD agencies with hardened components for downstream software applications
Fulfill extremely rigorous security standards that ensure the safety and integrity of military systems
Low deployment frequency and policy compliance due to constantly changing security threats
High toil on false positives
Solutions
Anchore Enterprise secures the software supply chain of Iron Bank with:
An on premise and distributed container image scanner
A turnkey SBOM generation and management solution
Automated policy engine that evaluates and enforces security standards and compliance
Results
Reduced false positives on customer deployments without requiring administration changes or software updates
Delivered accurate SBOMs with improved mapping to vulnerabilities for hardening of downstream applications
Jointly developed a codified custom policy to enforce the DoD Container Hardening requirements
Enabled the systematic distribution of an always up-to-date Iron Bank DoD policy bundle to downstream users and projects
Introduction
Iron Bank is Platform One’s hardened container image repository that supports the end-to-end lifecycle needed for modern software development. Iron Bank runs on Cloud One, a DoD multi-cloud ecosystem, which runs in AWS GovCloud.
Iron Bank centralizes infrastructure tools and standardizes application hardening throughout the DoD to create a proactive security stance that protects modern military infrastructure, equipment, and the military workforce.
AWS Services: GovCloud
Challenges
Iron Bank faces the complex task of balancing deployment velocity, software, and policy compliance (according to the DoD Container Hardening Guide), all while maintaining rigorous security standards and adapting to new security threats. The Iron Bank development team is responsible for the integrity and security of 1,800 base images that are provided to build and create software applications across the DoD.
Iron Bank not only provides all software components that are used for Platform One but also distributes them across the DoD. It’s imperative that they can efficiently scan images and simultaneously adhere to rigorous security standards that guarantee the safety and integrity of military systems. Another challenge is addressing false positives effectively. Due to the high volume of images and vulnerability management the team needs to process, false positives are time intensive and can cause significant toil.
“Even though security is important for all organizations, the stakes are higher for the DoD. What we need is a repeatable development process. It’s imperative that we have a standardized way of building secure software across our military agencies.”
Camdon Cady Chief Technology Officer at Platform One
Solutions
Anchore’s engineering team was deeply embedded with the Iron Bank infrastructure and development team to improve and maintain critical components in the DevSecOps pipeline. This supported the Iron Bank team in getting hardened containers into the Iron Bank.
Custom policy for app checks and open source containers
Since the IronBank inception in 2020, Anchore Enterprise has been the software supply chain security tool of choice. After the first iteration of Iron Bank infrastructure, Anchore started scanning container images and implemented a custom policy pack to check all images for compliance against DoD’s Container Hardening Guide requirements. This custom policy encompasses general security best practices within containers as well as application specific checks for a set of open source containers maintained by the Iron Bank team.
Lower false positives with the exclusion feed
In collaboration with the Iron Bank team, Anchore developed the exclusions feed to remove findings that were known false positives. The exclusion feed reduces the security assessment load on the Iron Bank team while addressing false positives seamlessly. At the writing of this case study, the exclusion feed captured over 12,000 known false positives. Since 2020 the following joint engineering efforts between Iron Bank and Anchore resulted in:
Time-based Allowlisting – expire allowlisted findings after a defined period of time using Anchore policy
Content Hints – add or override container software content to improve vulnerability scanning coverage for Platform One
Binary Content Type – install checks for software binaries outside of a package manager to increase coverage of scans
False Positive Management – correct false positives through a fast-feedback mechanism
Clamav Support – more thorough container scanning of all artifacts through integrated malware scanning
Image Ancestry Comparison – provide rich content while determining image ancestry, informing vulnerabilities and policy evaluations inherited from previous layers
Windows Image Scanning – scan Windows based container images
“People want to be security minded, and they want to do the right thing. And what they really want is tooling that helps them to do that with all the necessary information in one place. That’s why we looked to Anchore for help.”
Camdon Cady Chief Technology Officer at Platform One
Results
Anchore Enterprise provided Iron Bank with quality vulnerability and compliance findings to ensure that container images go through a standardized and efficient process that adheres to the DoD’s Container Hardening Guide.
Streamlines process for accurate vulnerability scanning and compliance
Anchore Enterprise empowered Iron Bank to create a standardized and efficient process for container scanning that adheres to the DoD’s Container Hardening Guide and delivers quality vulnerability and compliance findings.
SBOM Hints and Corrections to increase accuracy
To address false positives and misidentified components in a streamlined and repeatable workflow, Anchore developed and delivered two custom capabilities, SBOM Hints and SBOM Corrections. SBOM Hints and SBOM Corrections allow Iron Bank customers to adjust metadata in order to create a more accurate generation of SBOMs and improved mapping to vulnerabilities.
Time savings and reduced overhead with exclusion feed
The Anchore Vulnerability Feed enabled the Iron Bank team to reduce the occurrence of false positives and incomplete data in public feeds. To launch the vulnerability feed, the Iron Bank team handed Anchore a list of 10,000 false positives for analysis and inclusion. Iron Bank customers now benefit from live updates that immediately reduce false positives without any need for administration changes or software updates. This is made possible through the continuous monitoring and updating of the data feed. For example, all Iron Bank customers can request an assessment of potential false positives through the Anchore support portal to add new data to the feed.
In addition, Anchore enabled support for time-based allowlisting, now Iron Bank can expire allowlisted findings after a defined period of time using the Anchore policy engine.
From 2020 until today Anchore has provided ongoing support to the engineering team at Iron Bank, like providing them with custom DoD policy packs. The collaboration between Iron Bank and Anchore continues to expand and advance towards the shared goal of protecting modern military infrastructure, equipment and workforce.
Download the PDF version of this case study for Iron Bank.
Cisco Umbrella for Government is a cloud-native security solution tailored to meet the unique security and compliance needs of government agencies. It integrates multiple security functions into a single, easy-to-manage solution, ensuring comprehensive protection across various environments, including remote work settings.
Challenges
Meet all 6 FedRAMP vulnerability scanning requirements
Maintain and automate STIG & FIPS compliance for Amazon EC2 virtual machines
Meet SBOM requirement for White House Executive Order (EO 14028)
Solutions
Anchore Enterprise secures the software supply chain with:
Distributed container security scanner
Automated policy engine (security & compliance evaluation and enforcement)
Turnkey SBOM generation and management
On-prem cloud deployment model
Results
Achieved FedRAMP, FIPS and STIG compliance in weeks versus months
Reduced implementation time
Improved developer experience by integrating directly into existing workflow
Future-proofed compliance against anticipated requirements
Introduction
Cisco Umbrella is an AI powered cloud security platform that delivers a holistic security suite for enterprises. This includes security service edge (SSE), cloud application security, endpoint protection and incident response services to defend organizations from internal and external threats. Cisco Umbrella manages a complex environment with a number of different compliance requirements. They utilize AWS GovCloud to provide their services to federal agencies and need to meet FedRAMP, FIPS, STIG and EO 14028 compliance for their entire GovCloud deployment.
Build and deployment environment:
AWS Code Pipeline
AWS Elastic Container Registry (ECR)
Amazon Elastic Kubernetes Service (EKS)
Amazon Elastic Container Service (ECS)
Challenges
FedRAMP compliance is table stakes for the Cisco Umbrella organization in order to serve their customer base. Over the past decade FedRAMP has become more complex and comprehensive—its high impact level has over 400 controls alone.
The challenge was ensuring Cisco Umbrella’s complex cloud infrastructure met all of the relevant compliance objectives and maintained compliance over time. Of particular concern was securing the software supply chain for container vulnerabilities that could potentially leak into their applications via 3rd-party dependencies.
In order to achieve FedRAMP compliance, Cisco had to meet the following 6 vulnerability scanning requirements for containers:
Hardened and compliant container images
Automated build pipeline with policy enforcement
Vulnerability scanning in the build pipeline and container registry
Security sensors to prevent malware in the pipeline, registry, and in production
Container registry monitoring with notifications on non-compliant images
Asset management with a full inventory of containers in production
Additional high-security requirements
Furthermore to meeting FedRAMP compliance, Cisco Umbrella’s container vulnerability scanning solution is also required to be deployed into a High-Security environment. This came with the additional requirements that:
STIG compliance for compute infrastructure
FIPS compliance for compute infrastructure
EO 14028 compliance for software supply chain
Solutions
Cisco Umbrella selected Anchore, the leading software supply chain security platform specializing in container security, vulnerability management and the automation of compliance standards to solve their challenge. Anchore Enterprise integrated seamlessly with Cisco’s existing infrastructure and empowered them to meet all six FedRAMP requirements for vulnerability scanning and the additional STIG, FIPS and EO 14028 compliance within the project deadline that was only weeks out.
Proactive vulnerability detection
After Cisco Umbrella integrated Anchore Enterprise into its developer’s workflows, engineers were able to proactively uncover vulnerabilities at the time of development. This saved hours of developer time by alerting them to problematic dependencies before they began writing application code that would need to be remediated at deployment time.
Save time with built-in policy packs
Cisco Umbrella takes advantage of Anchore Enterprise’s built-in FedRAMP compliance policy pack to evaluate each scanned container for FedRAMP compliance. With the pre-build policies the Cisco Umbrella team can focus on resolving the non-compliance rather than translating NIST documentation into software checks. Anchore’s policy engine manages the process of evaluating a container against these policies and returning a PASS or FAIL signal back to the CI/CD process that then either gates the deployment or allows it to continue through the pipeline.
Automated security data management
As with many modern DevSecOps platforms, Cisco Umbrella also generates hundreds or even thousands of containers daily. Complying with EO 14028 requires an SBOM for each container. This quickly becomes a data management nightmare. As a turnkey solution, Anchore Enterprise includes a complete SBOM management solution to store and analyze this security data. This saves the security team time from having to manually collect and manage the data.
Simplified compliance via inheritance
Different from most cloud-based security solutions, Anchore Enterprise is deployed on-prem within a customer’s own cloud environment. The key advantage is that customers have full control over the system and can inherit the underlying compliance standards that the cloud provider has achieved. This is how Cisco Umbrella was able to take advantage of the FedRAMP compliance aspects of Anchore Enterprise without jeopardizing the FIPS compliance that their cloud infrastructure provider had achieved. This isn’t possible with traditional SaaS-based cloud security providers and is a unique advantage that is valued by Anchore’s enterprise and public sector customers worldwide.
Outcome
Cisco Umbrella was able to significantly reduce implementation time of FedRAMP compliance requirements. The time to compliance was reduced to weeks versus the more typical months. The team was able to overcome 4 compliance hurdles in parallel; FedRAMP, STIG, FIPS and EO 14028. The security team improved developer experience for container security vulnerability by integrating directly into existing development workflows. This both reduced the friction of security testing and enabled developers to discover vulnerabilities in development rather than production. Finally, Cisco Umbrella has ensured compliance with anticipated requirements. This increased confidence that there won’t be unexpected compliance work in the future.
With the clock ticking on new vulnerability scanning rules, organizations must adhere to a number of FedRAMP requirements. Prepare containerized applications for FedRAMP authorization with this checklist.
Preparing your containers and navigating your way through the STIG approval process can be daunting. This white paper will help your organization align for STIG readiness.
The Security Technical Implementation Guide (STIG) is a Department of Defense (DoD) technical guidance standard that captures the cybersecurity requirements for a specific product, such as a cloud application going into production to support the warfighter. System integrators (SIs), government contractors, and independent software vendors know the STIG process as a well-governed process that all of their technology products must pass. The Defense Information Systems Agency (DISA) released the Container Platform Security Requirements Guide (SRG) in December 2020 to direct how software containers go through the STIG process.
STIGs are notorious for their complexity and the hurdle that STIG compliance poses for technology project success in the DoD. Here are some tips to help your team prepare for your first STIG or to fine-tune your existing internal STIG processes.
4 Ways to Prepare for the STIG Process for Containers
Here are four ways to prepare your teams for containers entering the STIG process:
1. Provide your Team with Container and STIG Cross-Training
DevSecOps and containers, in particular, are still gaining ground in DoD programs. You may very well find your team in a situation where your cybersecurity/STIG experts may not have much container experience. Likewise, your programmers and solution architects may not have much STIG experience. Such a situation calls for some manner of formal or informal cross-training for your team on at least the basics of containers and STIGs.
Look for ways to provide your cybersecurity specialists involved in the STIG process with training about containers if necessary. There are several commercial and free training options available. Check with your corporate training department to see what resources they might have available such as seats for online training vendors like A Cloud Guru and Cloud Academy.
There’s a lot of out-of-date and conflicting information about the STIG process on the web today. System integrators and government contractors need to build STIG expertise across their DoD project teams to cut through such noise.
Including STIG expertise as an essential part of your cybersecurity team is the first step. While contract requirements dictate this proficiency, it only helps if your organization can build a “bench” of STIG experts.
Here are three tips for building up your STIG talent base:
Make STIG experience a “plus” or “bonus” in your cybersecurity job requirements for roles, even if they may not be directly billable to projects with STIG work (at least in the beginning)
Develop internal training around STIG practices led by your internal experts and make it part of employee onboarding and DoD project kickoffs
Create a “reach back” channel from your project teams to get STIG expertise from other parts of your company, such as corporate and other project teams with STIG expertise, to get support for any issues and challenges with the STIG process
Depending on the size of your company, clearance requirements of the project, and other situational factors, the temptation might be there to bring in outside contractors to shore up your STIG expertise internally. For example, the Container Platform Security Resource Guide (SRG) is still new. It makes sense to bring in an outside contractor with some experience managing containers through the STIG process. If you go this route, prioritize the knowledge transfer from the contractor to your internal team. Otherwise, their container and STIG knowledge walk out the door at the end of the contract term.
2. Validate your STIG Source Materials
When researching the latest STIG requirements, you need to validate the source materials. There are many vendors and educational sites that publish STIG content. Some of that content is outdated and incomplete. It’s always best to go straight to the source. DISA provides authoritative and up-to-date STIG content online that you should consider as your single source of truth on the STIG process for containers.
3. Make the STIG Viewer part of your Approved Desktop
Working on DoD and other public sector projects requires secure environments for developers, solution architects, cybersecurity specialists, and other team members. The STIG Viewer should become a part of your DoD project team’s secure desktop environment. Save the extra step of your DoD security teams putting in a service desk ticket to request the STIG Viewer installation.
4. Look for Tools that Automate time-intensive Steps in the STIG process
The STIG process is time-intensive, primarily documenting policy controls. Look for tools that’ll help you automate compliance checks before you proceed into an audit of your STIG controls. The right tool can save you from audit surprises and rework that’ll slow down your application going live.
Parting Thought
The STIG process for containers is still very new to DoD programs. Being proactive and preparing your teams upfront in tandem with ongoing collaboration are the keys to navigating the STIG process for containers.
The NVIDIA Product Security organization transitioned from Anchore open source to Anchore Enterprise for continuous container security, driving increased scalability and productivity, policy-based compliance, and role-based reporting for business units and security teams.
Challenges
Significant container use with thousands of containerized apps, and hundreds of thousands of containers
Provide a scalable security process to support growing container adoption with diverse requirements across business units, including large containers of up to 25 GB+
Address the critical security requirements of NVIDIA GPU Cloud (NGC), a curated catalog of GPU-optimized software containers for NVIDIA customers
Current security scanning tools for traditional software didn’t work for containers. They were complicated to use, time consuming to run, and generated too many false positives
Automate security checks across multiple CI/CD toolchains, registries, and Kubernetes platforms used by different business units
Solutions
Anchore Enterprise
Anchore Syft
Results
Improved developer and security team productivity with a centrally-hosted version of Anchore Enterprise
Ability to ramp up scanning and speed CI/ CD pipelines due to scalable architecture of Anchore
Robust, fully-documented APIs for Anchore made it quick and easy to integrate with multiple CI/CD tools and registries as well as existing product security processes
Improved inline scanning for CI/CD pipelines to enable vulnerabilities to be identified early in the cycle, avoiding delays
Reduced number of false positives due to Anchore’s optimized use of vendor-specific vulnerability feeds
Utilized Anchore’s flexible policy engine to allow each business unit to create and run their own compliance checks
Centralized metrics for the security team on container scans and results
Introduction
NVIDIA is an organization known for its GPUs utilized in computing tasks as diverse as computer graphics rendering and cryptocurrency mining. The most important new use case that GPUs have been utilized to solve is artificial intelligence (AI) and machine learning (ML) tasks. NVIDIA has invested in this segment from both a hardware and software perspective. In 2017 they launched NVIDIA GPU Cloud (NGC) a cloud platform that is specifically designed to power AI/ML workloads. NGC brings together NVIDIA managed GPU infrastructure as well as the AI/ML software components that are industry standard to create a platform that makes it simple to train generative large language models, object detection models, text-to-speech models, and more.
“Our goal was to integrate DevSecOps principles into our SDLC and build an “easy button” for developers to get their code scanned and secured.”
The NGC platform is a curated container catalog that hosts a broad range of software including generative AI models, deep learning frameworks, high performance computing (HPC) and visualization applications that maximize the utilization of NVIDIA’s GPU environments. Given that NGC is publicly available for NVIDIA users and customers, software hosted on NGC must undergo scans by Anchore against an aggregated set of common vulnerabilities and exposures (CVEs), as well as secrets and private keys.
“We were able to actually scale our container security program while saving money.”
The results of security scans from Anchore Enterprise are housed in nSpect, an enterprise- wide reporting platform where the product security team collects data from each software development team about known vulnerabilities and dependencies in their applications. Anchore Enterprise will be used across development teams to enable inline scanning of containers during the CI/CD process, providing vulnerability reports to nSpect via API. The nSPect data is used to deliver security reports to the VPs of each business unit showing their risk profile.
The NVIDIA Product Security organization — an arm of the Software GPU division that reports directly to NVIDIA’s CEO — transitioned from Anchore open source to Anchore Enterprise to provide scalable inline container scanning in their CI/CD pipeline, centralized container security reporting, and an API-friendly solution that would integrate into the myriad of different DevOps tools used across their business units.
Previously, NVIDIA was using Anchore open source. However, NVIDIA had not set up a centrally-hosted version of Anchore, creating overhead for each development team. By deploying a centrally-hosted version of Anchore Enterprise, the NVIDIA product security team created a scalable solution, a better experience for development teams, with a goal for providing each business unit VP visibility into their risk profile.
Challenges
As container adoption accelerated, NVIDIA needed a way to implement security scans for containerized apps throughout the development process. NVIDIA uses containers at a large scale with thousands of containerized apps, and hundreds of thousands of containers. One of their larger teams pushes tens of thousands of containers a day through the development pipeline. NVIDIA also faced a unique challenge because of the large container image sizes they must scan in their pipelines. It was critical that they choose a container security solution that they could easily embed in their development process and scale effectively to avoid creating any bottlenecks.
“Anchore gives us a centralized point with logging and metrics for a complete picture of our container security. We know exactly how many teams are scanning and what sort of images are failing.”
Each application team at NVIDIA selects their own tools. This constraint focused the product security team on sourcing a container scanning tool that could easily integrate via APIs with a broad range of CI/CD pipelines including TeamCity, GitLab, Jenkins, Azure, Google Cloud and homegrown solutions. The tool also had to integrate with registries including Docker Hub, Quay, GitLab, and NGC.
“We are API-driven so our end users do not use the UI. The Anchore API is completely documented and provides nice REST response codes that are much more obvious to the developers.”
While NVIDIA already had security scanning tools for traditional software, these tools didn’t work for containers. They were complicated to use, time consuming to run, and generated too many false positives. Reducing false positives was an important requirement for the NVIDIA product security team and the developers they support. While almost every scanning solution can identify a Python package and provide a list of vulnerabilities, NVIDIA needed the ability to identify vendor-specific variants (such as Ubuntu with OpenSSL patches) and then to include only vulnerabilities that had not been patched in the version that was being used. Without granular identification, developers receive too many false positives, leading them to ignore the security team.
Solutions
The NVIDIA team got Anchore Enterprise up and running within an hour using the Helm charts and documentation provided by Anchore. With a scalable architecture, Anchore Enterprise can scan high volumes of containers without causing large delays in development pipelines
“Almost anyone can identify a pipeline package, but if you can’t tie it back to a vendor’s versions, you get a huge list of false positives. Anchore is way ahead of the game, leveraging vendor-specific vulnerability feeds which results in fewer false positives.”
NVIDIA is API-driven and developers use the Anchore Enterprise API to integrate directly into their CI/CD pipelines. NVIDIA was able to leverage Anchore’s robust, fully-documented APIs and REST response codes that are meaningful to developers.
NVIDIA wanted to decentralize security policies, allowing each business unit to set their own policies. Teams can define policy documents tied to the SHA of individual files, and if teams choose to bypass a vulnerability, they can adjust their policy and document the exception.
Anchore Enterprise provides NVIDIA with a centralized point where the security team can get logs and metrics that show how many people are conducting scans, what images are failing, and related information. NVIDIA uses the Anchore’s command line tool, AnchoreCTL (based on the open source project Syft), to generate SBOMs from the pipeline and then post them in Anchore Enterprise.
“Anchore’s architecture has worker threads that can scale up and scan quickly, keeping the development pipeline moving as the number of containers increases.”
Results
By implementing Anchore Enterprise, NVIDIA teams can scan containers during the development process before they ship to internal and external customers. This ensures a high level of security and empowers development teams with the responsibility of resolving security issues prior to release time.
Moving to a hosted solution and Anchore Enterprise enables the NVIDIA product security team to provide a scalable solution that addresses the scanning challenges that the large containers in the NGC pose without a loss in developer or security team productivity. The move also lets them get their false positive challenges under control, saving developers and the security team time.
“I was able to get up and running in an hour with Anchore Enterprise using just the documentation and the Helm charts provided by Anchore. When I found areas for improvement in the docs, I was able to submit merge requests and they were quickly approved.”
Download the PDF version of this case study for NVIDIA Secures Containers with Anchore.
Today the OpenSSL project released an advisory for two new vulnerabilities that were rated as having a critical severity, but have been lowered to having a high severity. These vulnerabilities only affect OpenSSL versions 3.0.0 to 3.0.6. As OpenSSL version 3 was released in September of 2021, it is not expected to be widely deployed at this time. OpenSSL is one of those libraries that isn’t a simple upgrade. OpenSSL version 1 is much more common at the time of this writing and is not affected by CVE-2022-3786 or CVE-2022-3602.
The issues in question are not expected to be exploitable beyond a crash by a malicious actor due to the vulnerabilities being stack buffer overflows. Stack buffer overflows result in crashes on modern systems due to a security feature known as stack canaries which have become commonplace in recent times.
Detecting OpenSSL with Anchore Enterprise
Anchore Enterprise easily detects OpenSSL as it is commonly packaged within Linux distributions. These are packaged versions of OpenSSL in which a package manager installs a pre-built binary package, commonly referred to as APK, DEB, or RPM packages. Below is an example of searching a Fedora image for OpenSSL and determining it has OpenSSL 3.0.2 installed:
This is the most common way OpenSSL is shipped in container images today.
That’s not the entire story though. It is possible to include OpenSSL when shipping a binary application. For example the Node.js upstream binary statically links the OpenSSL library into the executable. That means OpenSSL is present in Node.js, but there are no OpenSSL files on disk for a scanner to detect. In such an instance it is necessary to review which applications will include OpenSSL and look for those.
In the case of Node.js it is necessary to look for the node binary located somewhere on the disk. We can examine the files contained in the SBOM to identify /usr/local/bin/node, for example:
If Node.js is installed as a package, it will get picked up without issue. If Node.js is installed as a binary, either from source or from Node.js itself, it’s slightly more work to detect as it is necessary to review all of the installed files, not just a package named “node”.
We have an update coming in Anchore Enterprise 4.2 that will be able to identify Node.js as a binary install, you can read more about how this will work below where we explain detecting OpenSSL with Syft.
Detecting OpenSSL with Syft
Anchore has an open source SBOM scanner called Syft. It is part of the core technology in Anchore Enterprise. It’s possible to use Syft to detect instances of OpenSSL in your applications and containers. Syft has no issues detecting OpenSSL packages installed by operating systems. Running it against a container image or application directory works as expected.
There’s also a new trick Syft just learned, that’s detecting a version of Node.js installed as a binary. This is a brand new feature you can read about in a Syft blog post. You can expect this detection in Anchore Enterprise very soon.
Using Anchore policy to automatically alert on CVE-2022-3786 and CVE-2022-3602
Anchore Enterprise has a robust policy and reporting engine that can be used to ease the burden of finding instances of CVE-2022-3786 and CVE-2022-3602. There is a “Quick Report” feature that allows you to search for a CVE. Part of what makes a report such as this so powerful is that you can search back in time. Any SBOM stored in Anchore Enterprise ever can be queries. This means even if you don’t have old containers available to scan, if you have the SBOM stored, you can know if that image or application was ever affected by this issue without the need to rescan anything.
It should be noted that you may want to search for the CVE and also the GitHub GHSA IDs. While the GHSA does refer to the CVE, at this time Anchore Enterprise treats them differently when creating policy and reports.
Planning for the future
We will probably see CVE-2022-3786 and CVE-2022-3602 showing up in container images for years to come. It’s OK to spend some time at the beginning manually looking for OpenSSL in our applications and images, but this isn’t a long term strategy. Long term it will be important to rely on automation to detect, alert, and prevent vulnerable OpenSSL usage. Even if you aren’t using OpenSSL version 3 today, it could be accidentally included at a future date. And while we’re all busy looking for OpenSSL today, it will be something else tomorrow. Automation can help detect past, present, and future issues.
The extensive use of OpenSSL means security professionals and development teams are going to be dealing with the issue for many months to come. Getting immediate visibility into your risk using open source tools is the fastest way to get going. But as we get ready for the long haul, prepare for the next inevitable issue that surfaces. Perhaps you’ve already found some as you’ve addressed OpenSSL. Anchore Enterprise can get you ready for a quick and full assessment of the impact, immediate controls to prevent vulnerable versions from moving further toward production, and streamlined remediation processes. Please contact us if you want to know how we can help you get started on your SBOM journey.
It’s no secret that SBOM scanners have primarily put a focus on returning results from packaging managers and struggle with binary applications installed via a side channel. If you’re installing software from a Linux distribution, NPM, or PyPI those packages are tracked with package manager data. Syft picks those packages up without any problems because it finds evidence in the package manager metadata to determine what was installed. However, if we install a binary, such as Node.js without a package manager, Syft won’t pick it up. Until now!
There’s a new update to Syft, version 0.60.1, that now gives us the ability to look for binaries installed outside of a package manager. The initial focus is on Node.js because the latest version of Node.js includes OpenSSL 3, which is affected by recently released security vulnerabilities. Node.js is an application that includes this latest version of OpenSSL 3, which makes it important to be able to find it at this time.
In the future we will be adding many other binary types to detect, check back to see all the new capabilities of Syft soon.
We can show this behavior using the node container image. If we scan the container with Syft version 0.59.0, we can see that the Node.js binary is not detected. We are filtering the results to only show us things with ‘node’ in their name. The official node container is quite large and contains many packages, if we don’t filter the output it would be several pages long.
There is no binary named ‘node’ in that list. However, we know this binary is installed, it is the official node container. Now if we try again using Syft version 0.60.1 the node binary is in the output of Syft with a type of binary.
Syft detecting the node binary
How does this work?
The changes to Syft are very specific and apply only to the Node.js binary. We added the ability for Syft to look for binaries that could be node, this begins by looking at the names of the binary files on disk. This was done to avoid trying to scan through every single binary file on the system which would be very slow and consume a great deal of resources.
Once we find something that might be a Node.js binary, we extract the plaintext strings data from it. This is comparable to running the ‘strings’ command from a UNIX environment. Basically what happens is we look for strings of plain text and ignore the binary data. In our case we are looking for a string of text that contains version information in a Node.js binary. If we determine the binary is indeed Node.js, we then extract the version details.
The output of Syft is of ‘binary’ format. If you look at Syft output you will see the different types of packages that were detected. These could be npm, deb, or python for example. Now you will also see a new type which is binary. As mentioned, the only binary type that can be found today is node, but more are coming soon.
Final Thoughts
Given how new this feature is, there is a known drawback. This patch could cause the Node.js binary to show up twice in an SBOM. If Node.js is installed via a package manager, such as rpm, the RPM classifier will find ‘node’ and so will the binary classifier. The same node binary will be listed twice. We know this is a bug and we are going to fix it soon. Given the importance of being able to detect Node.js, we believe this addition is too important to not include even with this drawback.
As already mentioned, this update only detects the Node.js binary. We are also working on binary classifiers for Python and Go in the short term, and long term we expect many binary classifiers to exist. This is an example of not letting perfect get in the way of good enough.
Please keep in mind this is the first step in a very long journey. There will be bugs in the binary classifiers as they are written. There are many new things to classify in the future, we don’t yet know what sort of things we will be looking for, which is exciting. Syft is an open source project – we love bug reports, pull requests, and questions. We would love you to join our community!
It is essential that we all remain vigilant and proactive in our software supply chain security as new vulnerabilities like OpenSSL and malicious code are inevitable. Please contact us if you want to know how we can help you get started on your SBOM journey and detect OpenSSL in your environment.
When Docker was first introduced, Docker container security best practices primarily consisted of scanning Docker container images for vulnerabilities. Now that container use is widespread and container orchestration platforms have matured, a much more comprehensive approach to security is standard practice.
This post covers best practices for three foundational pillars of Docker container security and the best practices within each pillar:
Containers are a method of operating system virtualization that enable you to run an application and its dependencies in resource-isolated processes. These isolated processes can run on a single host without visibility into each others’ processes, files, and network. Typically each container instance provides a single service or discrete functionality (called a microservice) that constitutes one component of the application.
Containers, themselves, are immutable, which means that any changes made to a running container instance will be made on the container image and then deployed. This capability allows for more streamlined development and a higher degree of confidence when deploying containerized applications.
Learn how to automate container vulnerability scanning in Harbor registry with Anchore Enterprise. A webinar with the experts from Anchore.
Container security starts at the infrastructure layer and is only as strong as this layer. If attackers compromise the host operating system (OS), they may compromise all processes on the OS, including the container runtime. For the most secure infrastructure, you should design the base OS to run the container engine only, with no other processes that could be compromised.
For the vast majority of container users, the preferred host operating system is a Linux distribution. Using a container-specific host OS to reduce the surface area for attack is generally a best practice. Modern container platforms like Red Hat OpenShift run on Red Hat Enterprise Linux CoreOS, which is hardened with SELinux and offers process, network, and storage separation. To further strengthen the infrastructure layer of your container stack and improve your overall security posture, you should always keep the host operating system patched and updated.
Best Practices for Securing the Host OS
The following list outlines some best practices to consider when securing the host OS:
1. Choosing an OS
If you are running containers on a general-purpose operating system, you should instead consider using a container-specific operating system because they typically include by default such security features as enabled SELinux, automated updates, and image hardening. Bottlerocket from AWS is one such OS designed for hosting containers that is free, open source, and Linux based.
With a general-purpose OS, you will need to manage every security feature independently. Hosts that run containers should not run any unnecessary system services or non-containerized applications. And you should consistently scan and monitor your host operating system for vulnerabilities. If you find vulnerabilities, apply patches and update the OS.
2. OS Vulnerabilities and Updates
Once you choose an operating system, it’s important to standardize on best practices and tooling to validate the versioning of packages and components contained within the base OS. Note that if you choose to use a container-specific OS, it will contain components that may become vulnerable and require remediation. You should use tools provided by the OS vendor or other trusted organizations to regularly scan and check for updates to components.
Even though security vulnerabilities may not be present in a particular OS package, you should update components if the vendor recommends an update. If it’s simpler for you to redeploy an up-to-date OS, that is also an option. With containerized applications, the host should remain immutable in the same manner containers should be. You should not be persisting data uniquely within the OS. Following this best practice will greatly reduce the attack surface and avoid drift. Lastly, container runtime engines such as Docker frequently update their software with fixes and features. You can mitigate vulnerabilities by applying the latest updates.
3. User Access Rights
All authentication directly to the OS should be audited and logged. You should only grant access to the appropriate users and use keys for remote logins. And you should implement firewalls and allow access only on trusted networks. You should also implement a robust log monitoring and management process that terminates in a dedicated log storage host with restricted access.
Additionally, the Docker daemon requires ‘root’ privileges. You must explicitly add a user to the ‘docker’ group to grant that user access rights. Remove any users from the ‘docker’ group who are not trusted or do not need privileges.
4. Host File System
Make sure containers are run with the minimal required set of file system permissions. Containers should not be able to mount sensitive directories on a host’s file system, especially when they contain configuration settings for the OS. This is a bad practice that you should avoid because an attacker would be able to execute any command that the Docker service can run and potentially gain access to the entire host system because the Docker service runs as root.
5. Audit Considerations for Docker Runtime Environments
You should conduct audits on the following:
Container daemon activities
These files and directories:
/var/lib/docker
/etc/docker
docker.service
docker.socket
/etc/default/docker
/etc/docker/daemon.json
/usr/bin/docker-containerd
/usr/bin/docker-runc
Securing Docker Images
You should know exactly what’s inside a Docker container before deploying it. Many of the challenges associated with ensuring Docker image security can be addressed simply by following best practices for securing Docker images.
What Are Docker Images?
So first of all, what are Docker images? Simply put, a Docker container image is a collection of data that includes all files, software packages, and metadata needed to create a running instance of a container. In essence, an image is a template from which a container can be instantiated. Images are immutable, which means that once they’ve been built, they cannot be changed. If someone were to make a change, a new image would be built as a result.
Container images are built in layers. The base layer contains the core components of an image and is the foundation upon which all other components and layers are added. Commonly, base layers are minimal and typically representative of common OSes.
Container images are most often stored in a central location called a registry. With registries like Docker Hub, developers can store their own images or find and download images that have already been created.
Docker Image Security
Incorporating the mechanisms to conduct static analysis on your container images provides insight into any potential vulnerable OS and non-OS packages. You can use an automated tool like Anchore to control whether you would like to promote non-compliant images into trusted registries through policy checks within a secure container build pipeline.
Policy enforcement is essential because vulnerable images that make their way into production environments pose significant threats that can be costly to remediate and can damage your organization’s reputation. Within these images, focus on the security of the applications that will run.
Explore the benefits of containerization and how they extend to security in our latest whitepaper.
The following list outlines some best practices to consider when implementing Docker image security:
1. Continuous Approach
A fundamental approach to securing container images is to automate building and testing. You should set up the tooling to analyze images continuously. For container image-specific pipelines, you should employ tools that are purpose-built to uncover vulnerabilities and configuration defects. Your tooling should give developers the option to create governance around the images being scanned so that based on your configurable policy rules, images can pass or fail the image scan step in the pipeline and not progress further. In short, development teams need a structured and reliable process for building and testing the container images that are built.
Here’s how this process might look:
Developer commits code changes to source control
CI platform builds container image
CI platform pushes container image to staging registry
CI platform calls a tool to scan the image
The tool passes or fails the images based on the policy mapped to the image
If the image passes the policy evaluation and all other tests defined in the pipeline, the image is pushed to a production registry
2. Image Vulnerabilities
As part of a continuous approach to securing container images, you should scan packages and components within the image for common and known vulnerabilities. Image scanning should be able to uncover vulnerabilities contained within all layers of the image, not just the base layer.
Moreover, because vulnerable third-party libraries are often part of the application code, image inspection and analysis must be able to detect vulnerabilities for OS and non-OS packages contained within the images. Should a new vulnerability for a package be published after the image has been scanned, the tool should retrieve new vulnerability info for the applicable component and alert the developers so that remediation can begin.
3. Policy Enforcement
You should create and enforce policy rules based on the severity of the vulnerability as defined by the Common Vulnerability Scoring System.
Example policy rule: If the image contains any vulnerable packages with a severity greater than medium, stop this build.
4. Create a User for the Container Image
Containers should be run as a non-root user whenever possible. The USER instruction within the Dockerfile defines this.
5. Use Trusted Base Images for Container Images
Ensure that the container image is based on another established and trusted base image downloaded over a secure channel. Official repositories are Docker images curated and optimized by the Docker community or associated vendor. Developers should be connecting and downloading images from secure, trusted, private registries. These trusted images should be selected from minimalistic technologies whenever possible to reduce attack surface areas.
Docker Content Trust and Notary can be configured to give developers the ability to verify images tags and enforce client-side signing for data sent to and received from remote Docker registries. Content trust is disabled by default.
6. Do Not Install Unnecessary Packages in the Container
To reduce container size and minimize the attack surface, do not install packages outside the scope and purpose of the container.
7. Add the HEALTHCHECK Instruction to the Container Image
The HEALTHCHECK instructions directive tells Docker how to determine if the state of the container is normal. Add this instruction to Dockerfiles, and based on the result of the healthcheck (unhealthy), Docker could exit a non-working container and instantiate a new one.
8. Do Not Use Update Instructions Alone in the Dockerfile
To help avoid duplication of packages and make updates easier, do not use update instructions such as apt-get update alone or in a single line in the Dockerfile. Instead, run the following:
Also, see leveraging the build cache for insight on how to reduce the number of layers and for other Dockerfile best practices.
9. Use COPY Instead of ADD When Writing Dockerfiles
The COPY instruction copies files from the local host machine to the container file system. The ADD instruction can potentially retrieve files from remote URLs and perform unpacking operations. Since ADD could bring in files remotely, the risk of malicious packages and vulnerabilities from remote URLs is increased.
10. Do Not Store Secrets in Dockerfiles
Do not store any secrets within container images. Developers may sometimes leave AWS keys, API keys, or other secrets inside of images. If attackers were to grab these keys, they could be exploited. Secrets should always be stored outside of images and provided dynamically at runtime as needed.
11. Only Install Verified Packages in Containers
Download and install verified packages from trusted sources, such as those available via apt-get from official Debian repositories. To verify Debian packages within a Dockerfile, see Redis Dockerfile.
Implementing Container Image Security
One way to implement Docker image security best practices is with Anchore, a solution that conducts static analysis on container images and evaluates these images against user-defined checks. With Anchore, you can identify vulnerabilities within packages for OS and non-OS components and use policy rules to enforce the image configuration best practices described above.
With Anchore, you can configure policies to check for the following:
Vulnerabilities
Packages
Secrets
Image metadata
Exposed ports
Effective users
Dockerfile instructions
Password files
Files
A popular implementation is to use the open source Jenkins CI tool along with Anchore for scanning and policy checks to build secure and compliant container images in a CI pipeline.
Securing Docker Container Runtime
Docker runtime security is critical to your overall container security strategy. It’s important to set up tooling to monitor the containers that are running. If new vulnerabilities get published that are impactful to a particular container, the alerting mechanisms need to be in place to stop and replace the vulnerable container quickly.
The first step in securing the container runtime is securing the registries where the images reside. It’s considered best practice to pull and run images only from trusted container registries. For an added layer of security, you should only promote trusted and signed images into production registries. Vulnerable, non-compliant images should not live in container registries where images are staged for production deployments.
The container engine hosts and runs containers built from container images that are pulled from registries. Namespaces and Control Groups are two critical aspects of container runtime security:
Namespaces provide the first and most straightforward form of isolation: Processes running within a container cannot see and affect processes running in another container or in the host system. You should always activate Namespaces.
Control Groups implement resource accounting and limiting. Always set resource limits for each container so that the single container does not hog all resources and bring down the system.
Only trusted users should control the container engine. For example, if Docker is the container runtime, root privileges are required to run Docker commands, and you should exercise caution when changing the Docker group.
You should deploy cloud-native security tools to detect such network traffic anomalies as unexpected traffic flows within the network, scanning of ports, or outbound access retrieving information from questionable locations. In addition, your security tools should monitor for invalid process execution or system calls as well as for writes and changes to protected configuration locations and file types. Typically, you should run containers with their root filesystems in read-only mode to isolate writes to specific directories.
If you are using Kubernetes to manage containers, your workload configurations are declarative and described as code in YAML files. These files can describe insecure configurations that can potentially be exploited by an attacker. It is generally good practice to incorporate Infrastructure as Code (IaC) scanning as part of a deployment and configuration workflow prior to applying the configuration in a live environment.
Why Is Docker Container Runtime Security So Important?
One of the last stages of a container’s lifecycle is deployment to production. For many organizations, this stage is the most critical. Often a production deployment is the longest period of a container’s lifecycle, and therefore it needs to be consistently monitored for threats, misconfigurations, and other weaknesses. Once your containers are live and running, it is vital to be able to take action quickly and in real time to mitigate potential attacks. Simply put, production deployments must be protected because they are valuable assets for organizations whose existence depends on them.
Docker Container Runtime Best Practices
The following list outlines some best practices to follow when implementing Docker container runtime security:
1. Consider AppArmor and Docker
From the Docker documentation:
AppArmor (Application Armor) is a Linux security module that protects an operating system and its applications from security threats. To use it, a system administrator associates an AppArmor security profile with each program. Docker expects to find an AppArmor policy loaded and enforced.
AppArmor is available on Debian and Ubuntu by default. In short, it is important that you do not disable Docker’s default AppArmor profile or create your own customer security profile for containers specific to your organization. Once this profile is used, the container has a certain set of restrictions and capabilities such as network access or file read/write/execute permissions. Read the official Docker documentation on AppArmor.
2. Consider SELinux and Docker
SELinux is an application security system that provides an access control system that greatly augments the Discretionary Access Control model. If it’s available on the Linux host OS that you are using, you can start Docker in daemon mode with SELinux enabled. The container would then have a set of restrictions as defined in the SELinux policy. Read more about SELinux.
3. Seccomp and Docker
Seccomp (secure computing mode) is a Linux kernel feature that you can use to restrict the actions available within a container. The default seccomp profile disables about 44 system calls out of more than 300. At a minimum, you should ensure that containers are run with the default seccomp profile. Get more information on seccomp.
4. Do Not Use Privileged Containers
Do not allow containers to be run with the –privileged flag because it gives all capabilities to the container and also lifts all the limitations enforced by the device cgroup controller. In short, the container can then do nearly everything the host can do.
5. Do Not Expose Unused Ports
The Dockerfile defines which ports will be opened by default on a running container. Only the ports that are needed and relevant to the application should be open. Look for the EXPOSE instruction to determine if there is access to the Dockerfile.
When the networking mode on a container is set to --net=host, the container will not be placed inside a separate network stack. In other words, this flag tells Docker not to containerize the container’s networking. This is potentially dangerous because it allows the container to open low-numbered ports like any other root process. Additionally, a container could potentially do unexpected things such as terminate the Docker host. Bottom line: Do not add the --net=host option when running a container.
8. Manage Memory and CPU Usage of Containers
By default, a container has no resource constraints and can use as much of a given resource as the host’s kernel allows. Additionally, all containers on a Docker host share the resources equally and non-memory limits are enforced. A running container begins to consume too much memory on the host machine is a major risk. For Linux hosts, if the kernel detects that there is not enough memory to perform important system functions, it will kill processes to free up memory, which could potentially bring down an entire system if the wrong process is killed.
Docker can enforce hard memory limits, which allow the container to use no more than a given amount of user or system memory. Docker can also enforce soft memory limits, which allow the container to use as much memory as needed unless certain conditions are met. For a running container, the --memory flag is what defines the maximum amount of memory the container can use. When managing container CPU, the --cpu flags give you more control over the container’s access to the host machine’s CPU cycles.
9. Set On-Failure Container Restart Policy
By using the --restart flag when running a container, you can specify how a container should or should not be restarted on exit. If a container keeps exiting and attempting to restart, it could possibly lead to a denial of service on the host. Additionally, ignoring the exit status of a container and always attempting to restart the container can lead to a non-investigation of the root cause behind the termination. You should always investigate when a container attempts to be restarted on exit. Configure the --on-failure restart policy to limit the number of retries.
10. Mount Containers’ Root Filesystems as Read-Only
You should run containers with their root filesystems in read-only mode to isolate writes to specifically defined directories, which you can easily monitor. Using read-only filesystems makes containers more resilient to being compromised. Additionally, because containers are immutable, you should not write data within them. Instead, designate an explicitly defined volume for writes.
11. Vulnerabilities in Running Containers
You should monitor containers for existing vulnerabilities, and when problems are detected, patch or remediate them. If vulnerabilities exist, container scanning should find an inventory of vulnerable packages (CVEs) at the operating system and application layers. You should also implement container-aware tools designed to operate at the same elasticity and agility of containers.
Checks you should be looking for include:
Invalid or unexpected process execution
Invalid or unexpected system calls
Changes to protected configs
Writes to unexpected locations or file types
Malware execution
Traffic sent to unexpected network destinations
12. Unbounded Network Access from Containers
Controlling the egress network traffic sent by containers is critical. Tools for monitoring the inter-container traffic should at the very least accomplish the following:
Automated determination of proper container networking surfaces, including inbound and process-port bindings
Detection of traffic flow both between containers and other network entities
Detection of network anomalies, such as port scanning and unexpected traffic flows within your organization’s network
A Final Word on Container Security Best Practices
Containerized applications and environments present additional security concerns not present with non-containerized applications. But by adhering to the fundamentally basic concepts for host and application security outlined here, you can achieve a stronger security posture for your cloud-native environment.
And while host security, container image scanning, and runtime monitoring are great places to start, adopting additional security best practices like scanning application source code (both open source and proprietary) for vulnerabilities and coding errors along with following a policy-based compliance approach can vastly improve your container security. To see how continuous security embedded at each step in the software lifecycle can help you improve your container security, request a demo of Anchore.
It’s no secret that software supply chain attacks are on the rise. Hackers are targeting developers and software providers to distribute malware and leverage zero-days that can affect hundreds, sometimes even thousands, of victims downstream. In this webinar, we’ll take a deep dive into four different attack methods, and most importantly, how to stop them.
Join an open source security leader and a former DoD DevSecOps engineer for actionable tips on successfully aligning your leadership, culture, and process to comply with federal cybersecurity directives.
Source code is the cornerstone of software development and if not stored and managed securely, could lead to the collapse of your entire pipeline. In this webinar we’ll look at the top four best practices for securing your source code repositories.
The software bill or materials, or SBOM, is foundational for end-to-end software supply chain management and security. Knowing what’s in software is the first step to securing it. Think of an SBOM like an ingredients label on packaged food: If there’s a toxic chemical in your can of soup, you’d want to know before eating it.
SBOMs are critical not only for identifying security vulnerabilities and risks in software but also for understanding how that software changes over time and potentially becomes vulnerable to new threats. In Innovation Insight for SBOMs, Gartner recommends integrating SBOMs throughout the software development lifecycle to improve the visibility, transparency, security, and integrity of proprietary and open-source code in software supply chains.
The Role of SBOMs in Securing Software Supply Chains
Gartner estimates that by 2025, 60 percent of organizations building or procuring critical infrastructure software will mandate and standardize SBOMs in their software engineering practice — a significant increase from less than 20 percent in 2022. However, organizations that are using open-source software and reusable components to simplify and accelerate software development are challenged with gaining visibility into the software they consume, build, and operate. And without visibility, they become vulnerable to the security and licensing compliance risks associated with software components.
SBOMs are an essential tool in your security and compliance toolbox. They help continuously verify software integrity and alert stakeholders to security vulnerabilities and policy violations.
To achieve software supply chain security at scale, Gartner recommends that software engineering leaders integrate SBOMs into their DevSecOps pipelines to:
Automatically generate SBOMs for all software produced
Automatically verify SBOMs for all open source and proprietary software consumed
Continuously assess security and compliance risks using SBOM data before and after deployment
Gartner underscores the importance of integrating SBOM workflows across the software development lifecycle, noting that “SBOMs are an essential tool in your security and compliance toolbox. They help continuously verify software integrity and alert stakeholders to security vulnerabilities and policy violations.”
Who Should Use SBOMs
Citing U.S. National Telecommunications and Information Administration (NTIA) recommendations, Gartner identifies three primary entities that benefit from SBOM adoption:
Software producers: Use SBOMs to assist in the building and maintenance of their supplied software
Software procurers: Use SBOMs to inform pre-purchase assurance, negotiate discounts, and plan implementation strategies
Software operators: Use SBOMs to inform vulnerability management and asset management, to manage licensing and compliance, and to quickly identify software and component dependencies and supply chain risks
SBOM Tools Evaluation
Gartner cautions that SBOMs are not intended to be static documents and that every new release of a component should include a new SBOM. When evaluating open-source and commercial SBOM tools for SBOM generation and management, Gartner advises organizations to select tools that provide the following capabilities:
Create SBOMs during the build process
Analyze source code and binaries (like container images)
Generate SBOMs for those artifacts
Edit SBOMs
View, compare, import, and validate SBOMs in a human-readable format
Merge and translate SBOM contents from one format or file type to another
Support use of SBOM manipulation in other tools via APIs and libraries
By generating SBOMs in the build phase, developers and security teams can identify and manage the software in their supply chains and catch bad actors early before they reach runtime and wreak havoc.
If you are tasked with implementing FedRAMP security controls for containerized workloads, this webinar is for you. We’ll walk you through a step-by-step process to explain how Anchore Enterprise can help you prepare a response for each of the six scanning requirements outlined in the FedRAMP Vulnerability Scanning Requirements for Containers.
SBOMs are quickly becoming the foundational element of software supply chain security. With the release of Anchore Enterprise 4.0, we are building on our existing SBOM capabilities to create the first SBOM-powered software supply chain management solution.
With significant attacks against the software supply chain over the last year, securing the software supply chain is top of mind for organizations of all sizes. Anchore Enterprise 4.0 is designed specifically to meet this growing need, delivering the first SBOM-powered software supply chain management tool.
Powered By SBOMs
Anchore Enterprise 4.0 builds on Anchore’s existing SBOM capabilities, placing comprehensive SBOMs as the foundational element to protect against threats that can arise at every step in the software development lifecycle. Anchore can now spot risks in source code dependencies and watch for suspicious SBOM drift in each software build, as well as monitor applications for new vulnerabilities that arise post-deployment.
New Key Features:
Track SBOM drift to detect suspicious activity, new malware, or compromised software
Anchore Enterprise 4.0 introduces an innovative new capability to detect SBOM drift in the build process, alerting users to changes in SBOMs so they can be assessed for new risks or malicious activity. With SBOM drift detection, security teams can now set policy rules that alert them when components are added, changed, or removed so that they can quickly identify new vulnerabilities, developer errors, or malicious efforts to infiltrate builds.
Building on Anchore’s existing SBOM-centric design, Anchore Enterprise 4.0 now leverages SBOMs as the foundational element for end-to-end software supply chain management and security. Anchore automatically generates and analyzes comprehensive SBOMs at each step of the development lifecycle. SBOMS are stored in a repository to provide visibility into your components and dependencies as well as continuous monitoring for new vulnerabilities and risks, even post-deployment. Additionally, users can now meet customer or federal compliance requirements such as those described in the Executive Order On Improving the Nation’s Cybersecurity by producing application-level SBOMs to be shared with downstream users.
Track the security profile of open source dependencies in source code repositories and throughout the development process
With the ever-expanding use of open source software by developers, it has become imperative to identify and track the many dependencies that come with each piece of open source at every step of the development cycle to ensure the security of your software supply chain. Anchore Enterprise 4.0 extends scanning for dependencies to include source code repositories on top of existing support for CI/CD systems and container registries. Anchore Enterprise can now generate comprehensive SBOMs that include both direct and transitive dependencies from source code repositories to pinpoint relevant open source vulnerabilities, and enforce policy rules.
Gain an application-level view of software supply chain risk
Securing the software supply chain requires visibility into risk for each and every application. With Anchore Enterprise 4.0, users can tag and group all of the artifacts associated with a particular application, release, or service. This enables users to report on vulnerabilities and risks at an application level and monitor each application release for new vulnerabilities that arise. In the case of a new vulnerability or zero-day, users can quickly identify impacted applications solely from the SBOM repository and respond quickly to protect and remediate those applications.
Looking Forward
Anchore believes that SBOMs are the foundation of software supply chain management and security. The Anchore team will continue to build on these capabilities and advance the use of SBOMs to secure and manage the ever-evolving software supply chain landscape.
Policies are an integral part of ensuring security and compliance, but what does “policy-based compliance” mean in the world of cloud-native software development? How can policies be automated to ensure the security of your container images?
The Kindness Campaign, inspired by Anchore’s core values, focuses on spreading kindness throughout our local communities. With Anchorenauts distributed across the US and UK, our quarterly volunteer program enables and encourages Anchorenauts to connect with local organizations and give back. In addition to direct support for various causes throughout the year, Anchore empowers team members to get involved with eight (8) paid volunteer hours per quarter.
This month, we are excited to partner with Ashley Goldstein from the Santa Barbara based organization, Women’s Economic Ventures (WEV). WEV, in partnership with Mixteco Indigena Community Organization Project (‘MICOP”), programatically supports aspiring entrepreneurs within the Indigenous and Latinx community in Santa Barbara and Ventura Counties.
Through the Los Emprendedores Program, Ashley firmly believes in the WEV’s and MICOP’s ability to empower members with the skills they need to launch their own businesses and to effect change in the most marginalized populations.
As part of the Kindness Campaign, Anchore has donated gently used Apple MacBooks to support budding entrepreneurs with the tools needed to kick start their businesses and enable their tremendous entrepreneurship training in the Los Emprendedores Program. In the program, participants develop highly valuable business skills ranging from business planning, grant writing, digital marketing, and key ESG (Environmental, Social, & Governance) practices.
As a tech company, we deeply believe in the responsibility to give back a piece of the industry to our community through widening access to both basic technology, but also business and career opportunities in the technology sector. At Anchore, we feel a great sense of pride in playing a part in contributing to that in our community, and are grateful for the opportunity to support Ashley, WEV, and MICOP.
How You Can Take Action
If your company has gently used computer equipment that is ready to be donated, we encourage you to reach out to WEV, and other organizations doing amazing work in their communities such as Boys & Girls Clubs of America (that have local chapters nationwide) to learn more about the ways you can help.
Be sure to check back next quarter to hear about new activity with Anchore’s Kindness Campaign.
Open source software is everywhere, and it’s here to stay. Yet 45% of respondents to Anchore’s 2022 Software Supply Chain Security Report still cite securing OSS as their top container security challenge.
Anchore surveyed hundreds of security and DevOps leaders at large enterprises on their software supply chain security practices. Their answers reveal that a top trend in 2022 is a focus on securing software supply chains as the use of software containers continues to rise.
In January 2022, Anchore published its Software Supply Chain Security Survey of the latest security trends, with a focus on the platforms, tools, and processes used by large enterprises to secure their software supply chains, including the growing volume of software containers.
The Anchore Software Supply Chain Security Survey is the first survey of respondents exclusively from large enterprises rather than solely from open source and developer communities or smaller organizations. The survey asked 428 executives, directors, and managers in IT, security, development, and DevOps functions about their security practices and concerns and use of technologies for securing containerized applications. Their answers provide a comprehensive perspective on the state of software supply chain security with a focus on the impact of increased use of software containers.
1. Supply chain attacks impacted 62% of organizations
Such widespread attacks as SolarWinds, MIMECAST, and HAFNIUM as well as the recent Log4j vulnerability have brought the realities of the risk associated with software supply chains to the forefront. As a result, organizations are quickly mobilizing to understand and reduce software supply chain security risk.
A combined 62 percent of respondents were impacted by at least one software supply chain attack during 2021, with 6 percent reporting the attacks as having a significant impact and 25 percent indicating a moderate impact.
2. Organizations focus on securing the software supply chain
More than half of survey respondents (54 percent) indicate that securing the software supply chain is a top or significant focus, while an additional 29 percent report that it is somewhat of a focus. This indicates that recent, high-profile attacks have put software supply chain security on the radar for the vast majority of organizations. Very few (3 percent) indicate that it is not a priority at all.
3. SBOM practices must mature to improve supply chain security
The software bill-of-materials (SBOM) is a key part of President Biden’s executive order on improving national cybersecurity because it is the foundation for many security and compliance regulations and best practices. Despite the foundational role of SBOMs in providing visibility into the software supply chain, fewer than a third of organizations are following SBOM best practices. In fact, only 18 percent of respondents have a complete SBOM for all applications.
Despite these low numbers, respondents do report, however, that they plan to increase their SBOM usage in 2022, so these trends may change as adoption continues to grow.
4. The shift to containers continues unabated
Enterprises plan to continue expanding container adoption over the next 24 months with 88 percent planning to increase container use and 31 percent planning to increase use significantly.
A related trend of note is that more than half of organizations are now running employee- and customer-facing applications in containers.
5. Securing containers focuses on supply chain and open source
Developers incorporate a significant amount of open source software (OSS) in the containerized applications they build. As a result, the Security of OSS containers is ranked as the number one challenge by 24 percent of respondents with almost half (45 percent) ranking it among their top three challenges. Ranked next was Security of the code we write with 18 percent of respondents choosing that as their top container security challenge and Understanding full SBOM with 17 percent.
6. Organizations face challenges in scanning containers
As organizations continue to expand their container use, a large majority face critical challenges related to identifying and remediating security issues within containers. Top challenges include identifying vulnerabilities in containers (89 percent), the time it takes to remediate issues (72 percent), and identifying secrets in containers (78 percent). Organizations will need to adopt more accurate container scanning tools that can accurately pinpoint vulnerabilities and provide recommendations for quick remediation.
7. Organizations must secure across diverse environments
Survey respondents use a median of 5 container platforms.The most popular method of deployment is standalone Kubernetes clusters based on the open source package, which 75 percent of respondents use. These environments are run on-premises, via hosting providers, or on infrastructure-as-a-service from a cloud provider. The second most popular container platform is Azure Kubernetes Service (AKS) with 53 percent of respondents using, and Red Hat OpenShift ranks third at 50 percent. Respondents leverage the top container platforms in both their production and development environments.
You may copy and redistribute the report content according to the terms of the license, but you must provide attribution to the Anchore 2022 Software Supply Chain Security Report.
Join us Jan 12th @ 2pm EST/11am PST to learn how to plan your “Day 2” for Log4j and future zero-day vulnerabilities, leverage SBOMs as a foundation for supply chain security, and expand automation against malware, cryptomining, and leaked secrets.
This blog post has been archived and replaced with the support pillar page here: https://anchore.com/wp-admin/post.php?post=987473316&action=edit
The blog post is meant to remain “public” so that it will continue to show on the /blog feed. This will help discoverability for people browsing the blog and potentially help SEO. If it is clicked on it will automatically redirect to the pillar page.
This tutorial video shows how to identify and triage the Log4j vulnerability using Anchore Enterprise. It details how to validate in runtime, the CISA policy bundle, automated policy function, automated enforcement function, and visibility to see if Log4j was inherited from a base image.
This tutorial video shows how to identify the Log4j vulnerability using Anchore CTL. AnchoreCTL is a command line client for Anchore Enterprise that makes it easy to automate
This tutorial video shows a walkthrough of how to generate an SBOM using Syft and how to scan that SBOM with Grype to identify any instances of the Log4j vulnerability.
Federal compliance requirements are constantly evolving to meet the growing challenges and complexities of securing the software supply chain. The task of meeting these compliance standards for cloud-native applications and containers can be overwhelming, but it doesn’t have to be.
Visibility into cloud-native software applications is essential for securing the software supply chain. Today’s applications include code and components from many different sources, including internal developers, open source projects, and commercial software. With the release of 3.3, Anchore Enterprise now provides richer insight into your software components to identify more vulnerabilities and security risks along with UI enhancements to streamline the management of your container image analysis.
Discover and Mitigate Vulnerabilities and Security Risks Found in Rocky Linux Containers
Anchore Enterprise 3.3 can now scan and continuously monitor Rocky Linux container images for any security issues present in installed Rocky Linux packages to improve their security posture and reduce threats. Rocky Linux packages are now also included in SBOMs. Additionally, customers can apply Anchore’s customizable policy enforcement to Rocky Linux packages and vulnerabilities.
Create Customizable Login Messages to Share Info with Your Team
A customizable banner can now be added to the login page. This can be used to provide Anchore Enterprise users with information such as instructions on how to login (i.e. SSO or email address) or which administrator to contact in the event of an issue. Both end-users and administrators will benefit from this new feature as it will enable collaboration and communication between internal teams that are using Anchore Enterprise.
Delete Multiple Items at Once in the Repository View Through the UI
Anchore Enterprise UI users can now select and delete multiple repo tags and “failed” images from the Repository View. When an image is analyzed, a list of repo tags are generated. These tags are alphanumeric identifiers that are attached to an image name. Depending on the content of the image, hundreds of these tags can be generated, many of which are superfluous to the user. Now, rather than having to click on and delete each tag individually, users can delete these unnecessary tags in bulk. Additionally, users can delete multiple images at once that have failed analysis either due to policy requirements or a misconfiguration as well.
Evaluate Policy Bundle Changes Without Having to Leave the Edit Screen
Anchore Enterprise UI users will now be able to view their policy evaluation as they edit their policy bundles without having to leave the edit screen in the UI. Policy bundle evaluations provide users with a pass or fail status for their images based on user-defined allowlists and blocklists. The ability to view the evaluation while editing the policy bundle enables users to see how their changes are affecting the evaluation without having to leave the screen they are working in.
With an increased focus on vulnerability scanning, it’s becoming more common to see a backlog of findings start to pile up. This creates a burden for multiple teams, slows down the development lifecycle, and increases the chances of major vulnerabilities sneaking through and infiltrating the software supply chain.
As software supply chains continue to grow in complexity, securing them is becoming an ever more daunting task. With components coming from so many possible origins, it is becoming increasingly important to establish “trust” and prevent tampering. One of the most secure ways to do this is with a signed SBOM.
You have choices in container security tools that range from open source to enterprise-grade platforms. Get the details on Anchore’s open source and enterprise solutions so that you can determine which option is right for you.
Creating a FedRAMP compliance checklist can be vital to approaching compliance methodically. While government contracting is full of FedRAMP challenges stories, the move to cloud-native development grants us new tools, technologies, and methodologies to better set your projects up for FedRAMP compliance success. It’s up to you to capture these best practices in a checklist or process flow for your teams to follow.
Considerations for your FedRAMP Compliance Checklist
Here are some concerns to include in your checklist:
1. Shift Security Left
Shifting left describes using tools and practices to improve and encourage more rapid feedback from security stakeholders about security and compliance into the early development stages. However, the objective is always to hand bugs and fixes back to developers as part of a smooth, ongoing, continuous development process.
Unit testing is a familiar example of shifting left by delivering early, user-experience feedback on functionality. Shifting unit testing left ensures that most problems are caught early, during the development stage, where it is quicker and simpler to remedy them.
By shifting security left, the handling of each vulnerability becomes an integral part of the CI/CD pipeline. This prevents a mass of vulnerabilities from appearing as a single irritating blockage before your team admits a system into production. More frequent vulnerability scanning during development ensures bugs and other issues can be dealt with quickly and efficiently as they arise, and security becomes a part of the development process.
With the primary focus of CI/CD environments on fast, efficient development and innovation, security has to work efficiently as part of this process. Anchore advises that DoD and federal security teams use tools that can deliver rapid feedback into development. Security tools must integrate with typical CI/CD and container orchestration tools. The tools you choose should also promote early-stage interaction with developers.
2. Follow the 30/60/90 rule to keep Images Secure
Anchore recommends following the 30/60/90 rule to satisfy the guidance outlined in the DoD Cloud Computing Security Requirements Guide. This rule sets out the number of days to fix security issues:
30 days to fix critical vulnerabilities
60 days to fix high vulnerabilities
90 days to fix moderate vulnerabilities
In support of this, it is also strongly recommended to use a tool that allows security teams to update and validate vulnerability databases with new security data frequently. Not only is this necessary to satisfy Security Controls RA-5(2), but using such a tool is a best practice to ensure your security data is timely and relevant.
By following the 30/60/90 rule and ensuring that you update your vulnerability databases and feeds promptly, you empower your security teams to remediate new security challenges quickly and efficiently.
3. Make use of Tools that Support Container Image Allow/Deny Listing
Federal agencies should leverage container security tools that can enforce allowlisting and denylisting of container images. Maintaining allow and denylists are common methods of securing networks and software dependencies. However, they are less common in a containerized environment.
This capability is crucial, as attackers can potentially use containers to deploy denylisted software into secure areas such as your DevOps toolchain. The elements and dependencies of a container may not always appear in a software bill of materials (SBOM) from existing scanning tools. Therefore it’s crucial that the tools used can examine the contents of a container and can enforce allowlist and denylist safeguards.
Anchore advises that container image denylisting should occur at the CI/CD stage to allow rapid feedback. By shifting the security feedback to the developers, they receive immediate feedback on issues. This technique allows for faster remediation, as denylisted container images or the software contained within them are immediately flagged to the developer.
4. Deploy a Container Security Tool that Maintains Strong Configuration Management over Container Images
Software delivery and security operations teams should maintain an accurate inventory of all software they deploy on any federal information system. This inventory gives both teams accurate situational awareness of their systems and enables more precise decisionmaking.
Anchore advises federal agencies to implement a container-native security tool that can systematically deconstruct and inspect container images for all known software packages and display findings for information security personnel in an organized and timely manner.
5. Use a Container Scanning Tool that runs on IL-2 through IL-6
The DoD and federal agencies must leverage tools that keep any vulnerability data regarding the information system within their authorization boundaries. However, many FedRAMP vulnerability scanning tools require an agent that connects to the vendor’s external cloud environment. The DoD designates this as interconnectivity between DoD/federal systems and the tool vendor and would rule out the use of any agent/cloud-based tool within an IL-6 classified environment.
Where organizations still choose to implement an agent-based container security tool, they are then responsible for ensuring that the security vendor maintains an up-to-date accreditation for their cloud environment. The environment must also have the relevant RMF/FedRAMP security controls that the federal information system can inherit during the ATO process. In addition, any DoD or federal agency should ensure the agent-based tool can run in both classified/unclassified environments.
Where possible, select tools that enable your teams to define security policy as code. These tools enable security teams to establish and automate best practices that they can push to tools, either across the network or in more secure environments.
Expressing security policy as code also enables your ops teams to manage systems using existing software development life cycle (SDLC) techniques. For example, policy as code enables the versioning of security policies. Now teams can compare policy versions for configuration drift or other unexpected changes.
In essence, it will enable the policies themselves to be subjected to the same level as rigorous as the code they are applied against.
The onus of implementing new security policies shifts security left onto developers. It can be important not to tighten container security policies too far in one step. Versioning also enables any agencies to improve and tighten security policy over time.
This iterative approach towards improving security stops over-intrusive security policies from stalling development in the CI/CD pipeline. It prevents the emergence of any culture clash between developers and security operations. Security teams can begin with a policy base that delivers on minimum compliance standards and develop this over time towards evolving best practices.
Conclusion
Think of a FedRAMP Compliance Checklist as more than just a documented list of activities your teams need to perform to get your application FedRAMPed. Rather, think of it as a methodical and strategic approach for your developers and security teams to follow as part of holistic and proactive strategies for secure software development and government compliance.
False positives in security scans are a costly headache for both DevOps and security teams. They can slow down, or even stop the development process dead in its tracks while issues are researched to determine if they are truly issues or not. Loosen your security controls too much and you can potentially open the door for legitimate vulnerabilities to infiltrate your systems.
DevSecOps open source convergence isn’t always apparent to business stakeholders. Here at Anchore, we’re believers in the open sourcing of DevSecOps because open source software (OSS) is foundational to cloud-native software development.
The Relationship between DevSecOps and Open Source
Open source technologies play a decisive role in how businesses and government agencies build their DevOps toolchains and capabilities. Entire companies have grown around open source DevOps and DevSecOps tools, offering enterprise-grade services and support for corporate and government customers.
DevSecOps Adoption IRL
The adoption of DevSecOps across the public sector and industries such as financial services and healthcare has been full of challenges. Some may even call DevSecOps adoption aspirational.
Adopting DevSecOps starts with shifting left with security. Work on minimizing software code vulnerabilities begins day 1 of the project, not as the last step before release. You also need to ensure that all your team members, including developers and operations teams, share responsibility for following security practices as part of their daily work. Then you must integrate security controls, processes, and tools at the start of your current DevOps workflow to enable automated security checks at each stage of your delivery pipeline.
Software containers and Kubernetes are perhaps the best-known examples of open source tools advancing DevSecOps. Containers represent a growing open source movement representing some essential principles of DevSecOps, especially collaboration and automation. These tools can also help mitigate common threats such as outdated images, embedded malware, and insecure software or libraries.
The advantages of open source for DevSecOps include:
No dependency on proprietary formats like you would get with vendor-developed applications
Access to a vibrant open source community of developers and advocates trying to solve real-world problems
An inclusive meritocracy where good ideas can come from anywhere, not just a product manager or sales rep who’s a few layers removed from the problems users encounter every day during their work.
Creating a DevSecOps Open Source Strategy
Here are some tips about how to set a DevSecOps open source strategy:
1. Presenting Open Source to your Organization’s Leadership
While open source technologies are gaining popularity across commercial and federal enterprises, it doesn’t always mean that your management are open source advocates. Here are some tips for presenting open source DevSecOps solutions to your leadership team:
Open source technologies for a DevSecOps toolchain offer a low entry barrier to build a proof of concept to show the value of DevSecOps to your leadership team. Presenting a live demo of a toolchain carries much more weight than another PowerPoint presentation over another Zoom call.
Proper DevSecOps transformation requires a roadmap that moves your enterprise from the waterfall software development life cycle (SDLC) or DevOps to DevSecOps. Open source tools have a place on that roadmap.
Know the strengths and weaknesses of the open source tools you’re proposing for your DevSecOps toolchain, especially for compliance reporting.
Remember, there are costs for implementing open source tools in your DevSecOps toolchain to work hours, implementation costs, operations, and security.
2. Establish OSS Governance Standards as an Organization
There can be many ways that OSS enters your DevSecOps pipeline that break from normal software procurement norms. Since OSS doesn’t come with a price tag, it’s easy for OSS to bypass your standard software procurement processes and even your expense reports, for that matter. If you’re building cloud-native applications at any sort of scale, you need to start wrapping some ownership and accountability around OSS.
Smaller organizations could assign a developer ownership and accountability over the OSS in their portion of the project. This developer would be responsible for generating the software bill of materials (SBOM) for the OSS under their responsibility.
Depending on the size of your development organization and use of OSS, it may make more sense to establish a centralized OSS tools team inside your development organization.
3. Place Collaboration before Bureaucracy
The mere words “software procurement” invoke images of bureaucracy and red tape in developers’ eyes, primarily if they work for a large corporation or government agency. You don’t want to repeat that experience with OSS procurement. DevSecOps offers you culture change, best practices, and new tools to improve collaboration.
Here are some ways to message how open source procurement will be different for your developers from the usual enterprise software procurement process:
Count your developers and cybersecurity teams as entire stakeholders and tap into their open source experience
Open and maintain communication channels between developers, legal, and business stakeholders through the establishment of an OSS CoEOSPO or similar working group
Communicate with your developers through appropriate channels such as Slack or Zoom when you need input and feedback
4. Educate Your Stakeholders About the Role of OSS in DevSecOps
While your development teams may be all about OSS, that doesn’t mean the rest of your business stakeholders are. Use stakeholder concerns about the current security climate as an opportunity to discuss how OSS helps improve the security of your software development efforts, including:
OSS means more visibility into the code for your cybersecurity team, unlike proprietary software code
OSS tools serve as the foundation of the DevSecOps toolchain, whether its code and vulnerability scanning, automation, testing, or container orchestration
DevSecOps and OSS procurement processes enable you to create security practices
5. Upgrade Your OSS Procurement Function
Your OSS procurement may still be entirely ad hoc, and there’s no judgment if that’s served your organization well thus far. However, we’re entering a new era of security and accountability as the software supply chain becomes an attack vector. While there’s no conclusive evidence that OSS played a role in recent software supply chain breaches, OSS procurement can set an example for the rest of your organization. A well-executed OSS procurement cycle intakes OSS directly into your DevSecOps toolchain.
Here are some upgrades you can make to OSS procurement:
Establish an OSS center of excellence or go one step further and establish an open source program office to bring together OSS expertise inside your organization and drive OSS procurement priorities.
Seek out an executive sponsor for OSS because it’s safe to say OSS adoption and procurement inside some enterprises aren’t easy. You are going to be navigating internal challenges, politics, and bureaucracy. Seek out an executive sponsor for OSS procurement in your organization. A chief technology officer or VP of development are natural candidates for this role. Your procurement effort needs an executive-level sponsor to champion your efforts and provide high-level support to ensure that OSS becomes a priority for your development organization.
Encourage developer involvement in the OSS community, not only because it’s good for their career, your organization benefits from the ideas they bring back to in-house projects.
6. Make Risk Management Your Co-Pilot
Your development team assumes responsibility for the OSS to keep it secure and ensure your teams run the latest version and security updates. Such work can take developers away from client-facing and billable projects. There are corporate cultures, especially in professional services and system integration, where developers must meet quotas for the billable work. Maintaining OSS behind the scenes — when a customer isn’t necessarily paying — is a hard sell to management sensitive to their profit & loss.
A more cavalier approach is to move fast and assume the OSS in question is being kept up to date and secure by a robust volunteer effort.
Another option is outsourcing your OSS security and maintenance and paying for somebody else to worry about it. This solution can be expensive, even if you can find a vendor with the appropriate skills and experience.
7. Bring Together Developers + Business for DevSecOps Open Source Success
Software procurement in the enterprise world is an area of expertise all unto itself. When you take steps toward creating a more formalized OSS procurement cycle, it takes a cross-functional team to succeed with OSS procurement and later governance. An Open Source Program Office can be the ideal home for just such a cross-functional team.
Your contracts and legal teams often don’t understand technology, much less OSS. Likewise, your developers won’t be knowledgeable about the latest in software licensing.
Such a coming together won’t happen without leadership support and maybe even a little culture change in some organizations.
DevSecOps: Open Source to Enterprise Software
Compliance, whether it’s the United States government’s FedRAMP or commercial compliance programs such as Sarbanes Oxley (SOX) in the healthcare industry and Payment Card Industry Data Security Standard (PCI DSS) in the financial services industry, brings high stakes. For example, mission-critical government cloud applications can’t go live without passing an authority to operate (ATO). Financial and healthcare institutions face stiff fines and penalties if their applications fail compliance audits.
Beyond that, the breach of the week making headlines in mainstream and technology media is also driving DevSecOps decisions. Companies and federal agencies are doing what they can to becoming another cybersecurity news story.
Such high stakes present a challenge for organizations moving to DevSecOps. Relying on open source solutions solely for a DevSecOps toolchain puts the onus of maintenance and patching on internal teams. There’s also a point for tools such as container scanning your organization needs to look at enterprise offerings. Most often, the reason to move to an enterprise offering is that of compliance audits. For example, you require enterprise-class reporting and a real-time feed of the latest vulnerability data to satisfy internal and external compliance requirements. Vendor backing and support also become a necessity.
Final Thought
A DevSecOps open source strategy comes from melding procurement, people, and DevSecOps practices together. Doing so lets your organization benefit from the innovation and security that open source offers while relying on DevSecOps practices to ensure collaboration throughout the whole development lifecycle to successful product launch.
Software supply chain attacks are on the rise. Threat actors are targeting software developers and suppliers to infiltrate source code and distribute malware to hundreds, sometimes even thousands, of victims globally… and they’re getting better at it everyday. Take a deep dive into supply chain attacks. Find out what they are, how they work, and most importantly, how to stop them.
Policies are an integral part of ensuring security and compliance, but what does “policy-based compliance” mean in the world of cloud-native software development? How can policies be automated to ensure the security of your container images?
As we put away our beach chairs and pool toys, now that Labor Day is past us, it’s time to refresh your DevSecOps best practices if your organization is moving employees back to the office on a part-time basis. While your developers should capitalize on their remote work wins, hybrid work can require different approaches than what has been in place during the past 18+ months.
Here are some DevSecOps practices to consider if your development teams are moving to a hybrid work model:
1. Reinforce Trust and Relationships
The pandemic-forced remote work we’ve all been through has provided invaluable collaboration, empathy, and trust lessons. Your work to continuously improve trust and relationships on your teams doesn’t stop when some team members begin to make their way back to the office.
A challenge to be wary of with hybrid DevSecOps teams is the reality that some team members have face time with managers and executives in the office. Remote employees don’t get this time. A common employee concern is that two (or more) classes of employees develop in your organization.
There can be cultural issues at play here. Then again, work from home (WFH) anxiety and paranoia can be real for some people. Pay close attention and keep your communication between team members open as you venture into remote work. Provide parity for your meetings by allowing onsite and remote participants an equal platform. Another good rule is to communicate calmly and with candor. Such acts will help reinforce trust across your teams.
2. Review your DevOps/DevSecOps Toolchain Security
The move to remote work opened up commercial and public sector enterprises to new attacks as remote work grew endpoints outside the traditional network perimeter. Commercial and public sector organization endpoint security in pre-pandemic times was very much centralized.
Securing the DevSecOps pipeline is an underserved security discussion in some ways. The DevOps and DevSecOps communities spend so much time on discussions about delivery velocity and shifting security left. The actual security of the toolchain, such as the value of identity access management (IAM), zero trust architecture (ZTA), and other security measures. The benefit here is only authorized employees can access your toolchain.
Use the move to hybrid work to review and refresh your toolchain security against “man in the middle” and other attackers lurking for hybrid teams to target.
3. Improve your DevSecOps Tools and Security Reporting
End-to-end traceability gains added importance as more of your executives and stakeholders return to a new state of normalcy. Use your organization’s move to hybrid work to improve security and development tools reporting across your pipelines. There are some reasons for this refresher:
Deliver additional data to your management and stakeholders about project progress through your pipelines regarding your hybrid work move. Be proactive and work with stakeholders during your hybrid work transition to see if they have additional reporting requirements for their management.
Update your security reporting to reflect the new hybrid working environment that spans both inside and outside your traditional endpoints and network perimeter.
Give your team the most accurate picture using data of the current state of software development and security over your projects.
4. Standardize on a Dev Platform
Hybrid work reinforces the need for your developers to work on a standardized platform such as GitLab or GitHub. The platform can serve as a centralized, secure hub for software code and project artifacts accessible to your developers, whether they are working from home or in the office. Each platform also includes reporting tools that can help you further communicate with your management about the progress and security of your projects.
If your developers are already standardized on a platform, use the move to hybrid work to learn and implement new features. For example, GitLab now integrates Grype with GitLab 14 for container security. GitHub includes GitHub Actions which makes it easy to automate CI/CD workflows.
5. Refine your Automation Practices
DevSecOps automation isn’t meant to be a one-and-done process. It requires constant analysis and feedback from your developers. With automation, look for areas to improve, such as change management and other tasks that you need to adapt to hybrid work. Make it a rule if hybrid work changes a workflow for your teams, it’s a new opportunity to automate!
Final thoughts
If you view DevOps and, in turn, DevSecOps as opportunities for continuous improvement, then DevSecOps best practices for hybrid work are another step in your DevSecOps journey. Treat it as the same learning experience as when your organization sent your team home in the early days of COVID-19.
Shifting security left reduces the cost to fix problems and avoids last minute delays. But to achieve continuous security and compliance, you also need to check container images in the registry and in Kubernetes at runtime.
DevOps supply chain security is becoming another use case for DevSecOps as enterprises seek innovative solutions to secure this attack vector. 60% of the 2021 Anchore Software Supply Chain Report considers securing the software supply chain as a top or significant focus area. DevSecOps gives enterprises the foundational tools and processes to support this security focus.
Anatomy of a Software Supply Chain Attack
A software supply chain is analogous to a manufacturing supply chain in the auto industry. It includes anything that impacts your software, especially open source and custom software components. The sources for these components come from outside an organization such as an open source software (OSS) project, third-party vendor, contractor, or partner.
The National Institute of Standards and Technology (NIST) has a concise and easy-to-understand definition of software supply chain attack:
A software supply chain attack occurs when a cyber threat actor infiltrates a software vendor’s network and employs malicious code to compromise the software before the vendor sends it to their customers.
Many organizations see increased value from in-house software development by adopting open source technology and containers to build and package software for the cloud quickly. Usually branded as Digital Transformation, this shift comes with trade-offs rarely highlighted by vendors and boutique consulting firms selling the solutions. You can get past these trade-offs with OSS by establishing an open source program office (OSPO) to manage your OSS governance.
They do not limit these risks to criminal hacking, and fragility in your supply chain comes in many forms. One type of risk comes from single contributors that could object morally to the use of their software, like what happened when one developer decided he didn’t like President Trump’s support of ICE and pulled his package from NPM. Or unbeknownst to your legal team, you could distribute software without a proper license, as with any container that uses Alpine Linux as the base image.
Why DevSecOps for Software Supply Chain Security?
DevSecOps practices focus on breaking down silos, improving collaboration, and of course, shifting security left to integrate it early in the development process before production. These and other DevSecOps practices are foundational to secure cloud-native software development.
Software supply chain security in the post SolarWinds and Codecov world is continuously evolving. Some of the brightest minds in commercial and public sector cybersecurity are stepping up to mitigate the risks of potential software supply chain attacks. It’s a nearly impossible task currently.
Here are some reasons why DevSecOps is a must for software supply chain security:
Unify your CI/CD Pipeline
The sooner you can unify your CI/CD pipeline, the sooner you can implement controls, allowing your security controls to shift left, according to InfoWorld. Implementing multiple controls across multiple systems is a recipe for disaster.
Unifying your CI/CD pipeline also gives you another opportunity to level set current tool standards, but you can upgrade tools as necessary to improve security and compliance.
Target Dependencies in Software Code
A DevSecOps toolchain gives you the tools, processes, and analytics to target dependencies in the software code coursing through your software supply chain. Less than half of our software supply chain survey respondents report scanning open source software (OSS) containers and using private repositories for dependencies.
Unfortunately, there’s no perfect solution to detecting your software dependencies. Thus, you need to resort to multiple solutions across your DevSecOps toolchain and software supply chain. Here are some traditional solutions:
Implement software container scanning using a tool such as Anchore Enterprise (of course!) at critical points across your supply chain, such as before checking containers into your private repository
Analyze code dependencies specified in the manifest file or lock files
Track and analyze dependencies that your build process pulls into the release candidate
Examine build artifacts before they enter your registry via tools and processes
The appropriate targeting of software dependencies raises the stature of the software bill of materials (SBOM) as a potent software supply chain security measure.
Use DevSecOps Collaboration to Break Down DevOps Supply Chain Barriers
DevSecOps isn’t just about tools and processes. It also instills improvements in culture, especially for cross-team collaboration. While DevSecOps culture is a work in progress for the average enterprise, and it should be that way, focusing a renewed focus on software supply chain security is cause for you to extend your DevSecOps culture to your contractors and third-party suppliers that make up your software supply chain.
DevSecOps frees your security team from being the last stop before production. They are free to be more proactive at earlier stages of the software supply chain through frameworks, automated testing, and improved processes. Collaborating with the security team takes on some extra dimensions with software supply security because they’ll deal with some additional considerations:
Onboarding OSS securely to their supply chain
Intaking third-party vendor technologies while maintaining security and compliance
Collaborating with contractor and partner security teams as a player-coach to integrate their code into their final product
Structure DevSecOps with a Framework and Processes
As companies continue to move to the cloud, it’s becoming increasingly apparent they should integrate DevSecOps into their cloud infrastructure. Some pain points will likely arise, but their duration will be short and their payoffs large, according to InfoQ.
A DevSecOps framework brings accountability and standardization leading to an improved security posture. It should encompass the following:
Automation of CI/CD pipelines through the use of AI/ML tools and other emerging technologies
Mastery over the data that your pipelines generate gives your technology and cybersecurity stakeholders the actionable intelligence they require to respond effectively to technical issues in the build lifecycle and cybersecurity incidents
Final Thoughts
As more commercial and public sector enterprises focus on improving the security posture of their software supply chains, DevSecOps provides the framework, tools, and culture change that can serve as a foundation for software supply chain security. Just as important, DevSecOps also provides the means to pivot and iterate on your software supply chain security in the interests of continuous improvement.
What security risks are DevOps teams facing in their software supply chain as the use of software containers continues to rise? Anchore has released its 2021 Software Supply Chain Security Report, which compiles survey results from hundreds of enterprise IT, Security and DevOps leaders about the latest trends in how their organizations are adapting to new security challenges.
As the US Federal government seeks to accelerate software development and improve its cybersecurity posture, the DoD and many civilian agencies are now using DISA STIGs to check the security of cloud-native and containerized applications, which introduces some new challenges.
As we explore the various roles and responsibilities at Anchore, one of the critical areas is building the roadmap for our enterprise product. Anchore Enterprise is a continuous security and compliance platform for cloud-native applications. Our technology helps secure the software development process and is in use by enterprises like NVIDIA and eBay as well as government agencies like the U.S. Air Force and Space Force.
As news of software supply chain breaches continue to make headlines and impact software builds across industries, the team at Anchore works each day to innovate and refine new technology to support secure and compliant software builds.
With this, Anchore is thrilled to announce an opening for the role of Principal Product Manager. Our Vice President of Product, Neil Levine, weighs in on what he sees as key elements to this role:
“Product managers are lucky in that we get to work with almost every part of an organization and are able to use both our commercial and technical skills. In larger organizations, a role like this often gets more proscribed and the ability to exercise a variety of functions is limited. Anchore is a great opportunity for any PM who wants to enjoy roaming across a diverse range of projects and teams. In addition to that, you get to work in one of the most important and relevant parts of the cybersecurity market that is addressing literal front-page news.”
Are you passionate about security, cloud infrastructure or open-source markets? Then apply for this role on our job board.
As the public sector and businesses face unprecedented security challenges in light of software supply chain breaches and the move to remote, and now hybrid work, means the time for policy-as-code is now.
Here’s a look at the current and future states of policy-as-code and the potential it holds for security and compliance in the public sector:
What is Policy-as-Code?
Policy-as-code is the act of writing code to manage the policies you create to help with container security and other related security policies. Your IT staff can automate those policies to support policy compliance throughout your DevSecOps toolchain and production systems. Programmers express policy-as-code in a high-level language and store them in text files.
Your agency is most likely getting exposure to policy-as-code through cloud services providers (CSPs). Amazon Web Services (AWS) offers policy-as-code via the AWS Cloud Development Kit. Microsoft Azure supports policy-as-code through Azure Policy, a service that provides both built-in and user-defined policies across categories that map the various Azure services such as Compute, Storage, and Azure Kubernetes Services (AKS).
Benefits of Policy-as-Code
Here are some benefits your agency can realize from policy-as-code:
Information and logic about your security and compliance policies as code remove the risks of “oral history” when sysadmins may or may not pass down policy information to their successors during a contract transition.
When you render security and compliance policies as code in plain text files, you can use various DevSecOps and cloud management tools to automate the deployment of policies into your systems.
Guardrails for your automated systems because as your agency moves to the cloud, your number of automated systems only grows. A responsible growth strategy is to protect your automated systems from performing dangerous actions. Policy-as-code is a more suitable method to verify the activities of your automated systems.
A longer-term goal would be to manage your compliance and security policies in your version control system of choice with all the benefits of history, diffs, and pull requests for managing software code.
You can now test policies with automated tools in your DevSecOps toolchain.
Public Sector Policy Challenges
As your agency moves to the cloud, it faces new challenges with policy compliance while adjusting to novel ways of managing and securing IT infrastructure:
Keeping Pace with Government-Wide Compliance & Cloud Initiatives
FedRAMP compliance has become a domain specialty unto itself. While the United States federal government maintains control over the policies behind FedRAMP, and the next updates and changes, FedRAMP compliance has become its own industry with specialized consultants and toolsets that promise to get an agency’s cloud application through the FedRAMP approval process.
As government cloud initiatives such as Cloud Smart become more important, the more your agency can automate the management and testing of security policies, the better. Automation reduces human error because it does away with the manual and tedious management and testing of security policies.
Automating Cloud Migration and Management
Large cloud initiatives bring with them the automation of cloud migration and management. Cloud-native development projects that accompany cloud initiatives need to consider continuous compliance and security solutions to protect their software containers.
Maintaining Continuous Transparency and Accountability
Continuous transparency is fundamental to FedRAMP and other government compliance programs. Automation and reporting are two fundamental building blocks. The stakes for reporting are only going to increase as the mandates of the Executive Order on Improving the Nation’s Cybersecurity become reality for agencies.
Achieving continuous transparency and accountability requires that an enterprise have the right tools, processes, and frameworks in place to monitor, report, and manage employee behaviors throughout the application delivery life cycle.
Securing the Agency Software Supply Chain
Government agencies are multi-vendor environments with homogenous IT infrastructure, including cloud services, proprietary tools, and open source technologies. The recent release of the Container Platform SRG is going to drive more requirements for the automation of container security across Department of Defense (DoD) projects
Looking to learn more about how to utilizing a policy-based security posture to meet DoD compliance standards like cATO or CMMC? One of the most popular technology shortcuts is to utilize a DoD software factory. Anchore has been helping organizations and agencies put the Sec in DevSecOps by securing traditional software factories, transforming them into DoD software factories. Get caught up with the content below:
The future of policy-as-code in government could go in two directions. The same technology principles of policy-as-code that apply to technology and security policies can also render any government policy-as-code. An example of that is the work that 18F is prototyping for SNAP (Supplemental Nutrition Assistance Program) food stamp program eligibility.
Compliance and security are integral elements of federal agency working life, whether it’s the DoD supporting warfighters worldwide or civilian government agencies managing constituent data to serve the American public better.
The concept of policy-as-code brings to mind being able to modify policy bundles on the fly and pushing changes into your DevSecOps toolchain via automation. While theoretically possible with policy-as-code in a DevSecOps toolchain, the reality is much different. Industry standards and CISO directives govern policy management at a much slower and measured cadence than the current technology stack enables.
API integration also enables you to integrate your policy-as-code solution into third-party tools such as Splunk and other operational support systems that your organization may already use as your standards.
Automation
It’s best to avoid manual intervention for managing and testing compliance policies. Automation should be a top requirement for any policy-as-code solution, especially if your agency is pursuing FedRAMP or NIST certification for its cloud applications.
Enterprise Reporting
Internal and external compliance auditors bring with them varying degrees of reporting requirements. It’s essential to have a policy-as-code solution that can support a full range of reporting requirements that your auditors and other stakeholders may present to your team.
Enterprise reporting requirements range from customizable GUI reporting dashboards to APIs that enable your developers to integrate policy-as-code tools into your DevSecOps team’s toolchain.
Vendor Backing and Support
As your programs venture into policy compliance, failing a compliance audit can be a costly mistake. You want to choose a policy-as-code solution for your enterprise compliance requirements with a vendor behind it for technical support, service level agreements (SLAs), software updates, and security patches.
You also want vendor backing and support also for technical support. Policy-as-code isn’t a technology to support using your own internal IT staff (at least in the beginning).
With policy-as-code being a newer technology option, a fee-based solution backed by a vendor also gets you access to their product management. As a customer, you want a vendor that will let you access their product roadmap and see the future.
As container adoption grew, NVIDIA’s Product Security team needed to provide a scalable security process that would support diverse requirements across business units. They found that traditional security scanning tools didn’t work for containers — they were complicated to use, time consuming to run, and generated too many false positives.
The broad impact of software supply chain attacks is clear in the findings of our recent 2021 Anchore Supply Chain Security Report. As malicious actors continue to advance the threat landscape in creative and alarming ways, Anchore commissioned a survey of 400+ enterprises with at least 1,000 employees to find out how real the impact is.
A whopping 64% of respondents to our survey reported that a supply chain attack had affected them in the last year. Furthermore, a third of those respondents report that the impact on their organizations was moderate or significant.
Scanning Challenges Abound
Enterprises facing these supply chain attacks also have to work through container scanning challenges. 86% of respondents reported challenges in identifying vulnerabilities. Too many false positives are a challenge for 77% of the respondents. On average, respondents estimate that 44% of vulnerabilities found are false positives. Getting developers to spend time on remediating issues was a challenge for 77% of respondents.
Corporate and government agency moves to DevOps and DevSecOps mean collaboration among development, security, and operations teams is more important than ever before. 77% of organizations are designating Security Champions within Dev teams to facilitate tighter collaboration.
Enterprise Security Focus: The Software Supply Chain
Against a backdrop of recent high-profile software supply chain attacks, 46 percent of respondents indicated that they have a significant focus on securing the software supply chain while an additional 14 percent have prioritized it as a top focus.
Very few (3%) of the respondents showed that software supply chain security isn’t a priority at all.
The DevOps Toolchain: An Enterprise Blind Spot
Experts have identified development platforms and DevOps toolchains as a significant risk point for software supply chain security. When attackers compromise a toolchain or development platform, they gain access to all the different applications that move through your development pipeline. This opens the door for bad actors to insert malicious code or backdoors that can be exploited once the developer deploys the software in production or (even worse) shipped to customers.
A critical best practice is to leverage infrastructure-as-code (IaC) to secure each platform or tool in the development process to ensure they are secured properly. Just over half of respondents are using IaC to secure these various platforms.
One of the most vulnerable segments of software is the build process. Everything from open source projects to third party software vendors, learn best security practices for cloud-native application development.
With recent high profile supply chain attacks, the software-bill-of-materials (SBOM) is becoming a critical foundation for cybersecurity. Organizations must understand all of the components in the applications they build so that they can properly secure them.
Blake Hearn (he/him) joined Anchore in February 2020 as a DevSecOps Engineer on the Customer Success team, marking the start of both Blake’s professional career and entry into DevSecOps. In this Humans of Anchore profile, we sat down with Blake to talk about learning new skill sets, a culture of kindness, and lessons from leadership.
From his start at Anchore, Blake has been immersed in a team of kind and supportive people offering him the mentorship, resources, and encouragement needed to be successful.
“The whole team really helped me learn at a fast rate. They created training materials and testing environments for me to learn, checked in with me frequently, and even recommended some certifications which played a huge role in building a foundational knowledge of DevSecOps. A year and a half ago I didn’t know anything about Docker, Jenkins or Kubernetes and now I’m using them every day.”
Blake’s support system reaches far beyond his direct team, extending all the way to the executives and co-founders of the company.
“I’ve had a really great experience with my managers and the leadership team. Being able to reach out to the CEO or CTO is amazing. Dan Nurmi (CTO/Co-Founder) has open office hours each week where I can bring my technical questions and feel comfortable doing so. Everyone at Anchore is really collaborative. I can ask anyone a question and they are more than willing to help.”
In his role, Blake spends most of his day working on the Platform One team at the Department of Defense (DoD) partnering with engineers from companies across the industry to help deliver software solutions faster and more securely across the DoD.
“It’s been a really good opportunity for me to learn from both my Anchore team and my Platform One team. My role requires a lot of custom Helm templating and testing updates on various Kubernetes clusters. We are putting our minds together to come up with solutions and do groundbreaking work.”
Looking ahead, Blake is eager to continue his learning journey. “I’m excited to continue learning from others and get into new skill sets. Recently, I’ve learned a little bit about the operational side of Machine Learning (ML) and how ML could be used in cybersecurity. Next, I would like to get into penetration testing to help improve the security posture of products and services. I think that would provide a huge benefit to our customers – especially with the supply chain attacks we’ve seen recently in the news.”
In summarizing his time at Anchore, Blake is grateful for the support system he has found: “I didn’t think companies like Anchore existed – where the company’s culture is so kind, everyone is really smart, works well together, and you have direct access to leadership. No other company I’ve seen compares to Anchore.”
Interested in turning your dreams into reality? Check out our careers page for our open roles anchore.com/careers.
Anchore’s management program is founded on passionate people leaders who are kind, open, and invest in their team’s success. Finding passionate leaders means opening the door to opportunities for all employees. We empower Anchorenauts to apply for management roles and participate in a cross-functional interview process.
A few months into Dan Luhring’s (he/him) time at Anchore, a management role opened up in the Engineering organization. When the Director of Engineering asked if anyone on the team was interested in pursuing the role, Dan immediately raised his hand.
“When I interviewed for the manager position with the leadership team, I was glad that I was going through a formal process because it made me realize that Anchore understands how vitally important great managers are to the success of the company.”
Upon joining the Anchore management team, all leaders go through a robust training program where they learn more about different communication and working styles, coaching conversations, and the guiding principle of Anchore’s management philosophy: building trusting relationships.
“I love our manager training series. I thought the role-playing exercises were really thoughtfully done and have been missing from manager training I’ve done in the past. Between the training sessions, ongoing employee programs, and overall partnership, I feel really supported by our People Operations team in my role.”
Anchore’s continuous performance model enables our managers to set a strong foundation of trust and clear communication from day one. Although Dan had already been working with his team before becoming a manager, the Stay Interviews gave Dan even more insight into his new direct reports.
“I got a ton of value out of the Stay Interviews with my direct reports. It’s really useful to know what motivates people, how they like to receive recognition and feedback, and what their long-term career goals are. It made me more aware of their professional interests outside of their day-to-day responsibilities. Because I know the motivators of my direct reports, I can assign special projects based on individual interest, even if it’s not something they do in their core role.”
Reflecting on his opportunity to join the management team, Dan is excited to be part of making Anchore a great place to work and continuing to lead his team based on trust.
“There are things that Anchore gets right that I find to be really unique. We are thoughtful about who we promote into the management team. We have great support and autonomy with helpful programs and tools to facilitate trusting relationships, really caring about the people who report to us and wanting to help them achieve their career goals.”
Interested in becoming a team leader like Dan? View Anchore’s current openings here.
DevOps lets developers innovate faster. But some normal DevOps processes can create the opportunity for bad actors or dangerous code to enter your DevOps pipeline and your software applications.
The United States Department of Defense (DoD) is taking a completely new approach to building, deploying, and operating software.
On the way out: slow-moving, waterfall-driven development processes that result in monolithic, hard to manage applications. They have come to the conclusion that the traditional way of delivering software is expensive and inflexible, and the situation for today’s warfighters demands maximum efficiency. There are too many lives at risk if the DoD fails to innovate, and too much geopolitical competition.
Advanced enterprises solve this problem through the implementation of cloud-native technologies such as Kubernetes and the implementation of DevOps practices. Using this combination of tools and tactics, software can be delivered in much smaller components and updated frequently. This results in a very quick pace of development, and allows for frictionless reuse of components between teams and communities. Automated build, integration, and deployment can reduce the lead time to deliver warfighter capabilities from months to minutes.
The DoD needs to deliver software to the warfighter at the speed of operations, so they have built a new platform and software supply chain to remove bottlenecks on their cloud-native journey. The foundation of this platform is an automated DevSecOps pipeline that bakes in automated security and compliance checks before delivering to a CNCF compliant Kubernetes cluster. This allows them to build and consume software at the pace required to maintain their competitive edge. However, even though security is important for all enterprises, the stakes are higher for the DoD. So while they could build on commercial best practices, there are several additional steps required to meet security standards. There is also a need to deploy in a standardized way across various disparate environments, from traditional on-premise environments to special regions of public cloud and even small footprints at the tactical edge.
Over the past 12-months, Anchore and Red Hat have worked side by side to develop and implement an automated process for hardening and securing containerized software within the United States Air Force. Anchore is the only container security vendor providing hands-on support as part of the U.S. Department of Defense DevSecOps Platform (DSOP) initiative. The beating heart of the DSOP initiative is a powerful Kubernetes cluster that can run on any infrastructure. In many cases, including this one, the Kubernetes cluster is powered by Red Hat OpenShift. This paper, based on hands-on experience working with our government partners in the U.S. Department of Defense and United States Air Force, provides valuable insight and guidance on best practices for secure, high-velocity software delivery.
Automated build, integration, and deployment can reduce the time from invention to production – from months to minutes.
Audience
This paper is for security teams, DevSecOps engineers, and information system security leaders who would like to learn from the steps the DoD has taken to establish high-velocity development and deployment of new services in a context where security can have life-or-death consequences. Over the past decade, the Federal Government has issued numerous executive orders and memorandums that task IT leaders to efficiently transform software development using DevOps and DevSecOps deployment models at their various agencies. We aim to provide an overview of this transformation, showing how it can be done at scale within large enterprises.
Purpose
The purpose of this paper is to understand the importance of adopting and utilizing approved hardened containers in the US Government. This paper will describe the hazards of historical DoD software deployment lifecycles and how the United States Air Force migrated away from risky development practices, relying on hardened containers running on Kubernetes as the backbone to the success of its DevSecOps Platform. Our goal is to document the USAF DevSecOps model, describe the container-hardening process currently used by USAF, and demonstrate to federal audiences how they can instantiate or augment their own DevSecOps pipelines using DoD-approved, hardened containers.
Problem Statement
The DoD, similar to other large enterprises, faces the complex task of balancing deployment velocity, compliance and security. However, they are unique from other large enterprises in that the applications they build and maintain are military systems where human lives are at stake 24/7/365.
In the past, software development at the DoD used a traditional “waterfall” development methodology with a heavy emphasis on planning and requirements gathering. As a result, the pace of innovation was slow. Both private and public industries have moved to more iterative, agile development models due to several factors. Not only are these new methodologies quicker, they also incorporate end-user buy-in from an early stage. Often, the waterfall methodology can result in a product that does not adapt to rapidly-changing requirements and operational conditions.
For those who use traditional waterfall processes, compliance often becomes a game of catch-up. When development moves slowly, security teams often rush to validate software within contract deadlines. Additionally, once a program has exhausted its budget in the development phase, it is faced with the burden of obtaining a DoD Authority to Operate (ATO). This can take at least 9 months, causing the technology that was leading-edge at the inception of the program to become out of date.
For those who use traditional waterfall processes, compliance often becomes a game of catch-up.
The economic and programmatic risks of the waterfall delivery lifecycle are clear, but the cybersecurity risks are even more detrimental. By following the model prescribed above, software teams are locked into older, often deprecated software that can’t be effectively hardened or protected. As a result, they are leaving systems open to hundreds – or even thousands – of vulnerabilities within outdated software that is no longer being maintained. Worse, these teams are often locked into contracts with third parties who deliver software slowly and make it extraordinarily challenging to stay on top of emerging vulnerabilities.
As security teams work to protect government systems, they lack the full breadth of options within the marketplace that can help them gain the upper hand against adversaries. Software designed and consumed by the DoD needs to be developed at a higher velocity, with greater efficiency, and with a focus on security in order to maintain dominance in the current cybersecurity landscape.
DevSecOps at the Department of Defense
DevSecOps is quickly becoming an optimal mode of operation for consumers of container-based technologies, from early adopters to long-time users. As enterprises move towards more agile development by implementing modern DevOps, the rate of change increases and attack surfaces become more fragmented and dynamic. The integration of security into each stage of the software development life cycle, a practice known as DevSecOps, is now critical for organizations operating in today’s cloud-native environments.
The DoD codified their new approach to software creation and management in the DevSecOps Reference Design. This document, hosted at software.af.mil and linked from the Anchore Federal web page, contains a roadmap for various defense agencies and programs to dramatically overhaul the traditional waterfall software development practices in common use. It has resulted in the creation of a new platform for DevSecOps known as Platform One.
In their DevSecOps Reference Design, the DoD defines DevSecOps as “a collection of software-integrated tools, services, and standards that enable partners and programs to develop, deploy, and operate applications in a secure, flexible and interoperable fashion”. Championed by Nicolas Chaillan, Chief Software Officer of the United States Air Force (USAF), the DoD DevSecOps Initiative is charged with creating a platform that can be easily reused and implemented across all branches of the DoD.
For more information on the mission of Platform One, view this video created by members of the Platform One team.
Separating itself from DoD operational systems of the past, this new Reference Design prescribes comprehensive use of industry standards such as Open Container Initiative (OCI) containers and Kubernetes to develop and deploy software. The use of containers deployed on Red Hat OpenShift is familiar to the teams at Anchore and Red Hat, as it is the same approach taken by many of the Fortune 500 enterprises we support. Containers offer multiple advantages of particular interest to the Department of Defense. These include:
Velocity: Provisioning containers is extremely fast when compared to virtual machines or bare-metal systems. An operator can deploy, scale up, scale down, and destroy a container workload easily, and each operation takes a matter of seconds.
Cost-efficiency: Containers allow for better allocation of computing resources for specific workloads with minimal overhead. They run on readily-available, standard hardware that can be sized to support a variety of requirements and are lower cost than traditional scale-up systems.
Immutability: Once a container image is created, a hash is created that ensures it can be uniquely identified and cannot be altered as it proceeds through the development and deployment process.
Scalability: Containerized applications and environments horizontally scale with ease, reducing the costs associated with discrete hardware. Individual services can be managed and scaled separately, helping to realize a core benefit of microservices architectures.
Consistency: Platforms like Kubernetes offer a consistent control plane for applications, reducing operational costs and increasing agility. Applications are defined, deployed, and managed using a single operational toolset.
Control: Container images are layered, building upon base images that provide basic environments for applications to run within. This allows the DoD to approve and reject base images based on security best practices, providing fine-grained control over the software that is deployed.
Establishing Continuous Security
Platform One includes a prescribed set of software and capabilities known as the Sidecar Container Security Stack (SCSS), which ensures a high level of runtime security. The SCSS model offers the ability to deliver correlated and centralized logs, fully-integrated container security, whitelisting, Role-Based Access Control (RBAC), continuous monitoring, signature-based scanning based on Common Vulnerabilities and Exposures (CVEs), and policy enforcement.
Continuous monitoring and scanning of runtime systems is a critical part of a comprehensive security strategy, but it is not enough. After all, a vulnerability discovered in a running application has already created an opportunity for an opponent to inflict damage. That’s why Platform One includes processes that harden software containers before they are deployed in a mission setting. These hardening steps are integrated into the development pipeline and performed by Anchore and the Platform One team. Platform One will ultimately make hundreds of approved, hardened containers available for use.
Working in collaboration with the USAF, Anchore has developed custom policy checks for all images in the pipeline to harden them to meet the security and compliance baselines of the DoD. These policies were implemented by Anchore engineers, who work within the Platform One team to validate new images and deliver them into the DoD Centralized Artifact Registry, also known as “Iron Bank”.
The DevSecOps Reference Design specifies three main categories of container images that will be hardened and maintained:
Container images used to power the DevSecOps platform, including: CI/CD systems, code and artifact repository platforms, and tools for developers and operators
Sidecar Container Security Stack containers to be used in runtime environments for continuous monitoring and scanning of container security
Common containers to be used as a baselines for software development by engaged agencies and programs
The container hardening process also applies to common containers from third party Independent Software Vendors (ISVs) looking to provide software to the DoD. In order to do so, ISVs will be required to interact with several key infrastructure services: Repo One and Iron Bank. More information about these services can be found in the following sections.
Continuous monitoring and scanning of runtime systems is a critical part of a comprehensive security strategy, but it is not enough.
The Container Hardening Process
The container hardening process is initiated with a code push into the DoD Centralized Container Source Code Repository, also known as Repo One.
Above: Example ISV project in Repo One
This repository is used to store the instruction files required to build container images (the “Dockerfiles”), along with their associated checksums and various forms of documentation. Anchore and Red Hat work together closely within the Platform One team to manage Repo One, with the ultimate goal of bringing over 170+ container images into the hardening pipeline. Anchore is a key contributor on the Platform One Container Hardening Team, which validates containers for use.
As part of the onboarding process, the Platform One team grants permissions which will allow an ISV to create a project and submit merge requests for review. Once a merge request has been submitted containing a new container image, the Container Hardening Team performs build, test, and validation steps specified in the DoD Container Hardening Guidelines document.
ISVs can find detailed information in the vendor contributors guide that can help them understand the process and get started.
A hardened container image is one that adheres to the container format published by the OCI and is made compliant with the DoD Container Hardening Security Requirements Guide. The container hardening process consists of a Jenkins job that pulls the Dockerfile from Repo One, builds an OCI-compliant container image, and pushes that image to the Repo One image registry. This automatically triggers the container scanning pipeline. The DSOP team validates that the ISV has staged their files correctly in Repo One by following the contributor onboarding process. Once validated and merged into the proper branch, an automatic pipeline job is triggered to kick off the image build and scanning processes.
The Container Hardening Team uses Anchore and OSCAP to automatically review the compliance and security baseline of the container image following the build process. Anchore performs a series of policy specific and best-practice checks on every image built in our pipeline which is explored further below. The container hardening pipeline consists of Anchore and OpenSCAP. These tools each perform different functions, and enforce container image security best practices in unique ways.
Anchore is a policy-based container workflow platform that analyzes container images, maintains a centralized bill of materials, and continuously scans for known vulnerabilities and policy violations. One of the key purposes of Anchore is to mitigate insider threat within the DevSecOps lifecycle by detecting unapproved changes to Dockerfiles.
One of the key purposes of Anchore is the mitigation of insider threat within the DevSecOps lifecycle by detecting unapproved changes to Dockerfiles.
It is important to detect when a developer intentionally makes changes to a Dockerfile that are erroneous or malicious.
For example, an insider could edit a Dockerfile and cause it to make an external call to a malicious database, or download and execute a malicious Java archive. These examples can be automatically detected and stopped with Anchore using a set of flexible policies that govern the contents of Dockerfiles. This prevents malicious Dockerfiles from becoming deployable images inside an operational environment.
Once an image is built, it can contain a large amount of third party operating system packages and language artifacts like Ruby GEMs, Java JARs, Python packages, and npm modules. Anchore also performs policy checks on the contents of container images after they have been built, providing automatic application-level enforcement. Compliance requirements on software configuration, such as those required by various Security Technical Implementation Guides (STIGs), can be enforced using Anchore’s policies. For example, the STIG that provides guidance on using a PostgreSQL database requires specific lines to exist in the configuration file. Anchore can validate configuration files through policy rules that, in the case of this example, ensure that certain lines exist. If they don’t, it can prevent the image from proceeding to the next stage of the development pipeline.
OpenSCAP serves two distinct purposes. First, it performs scanning to ensure that the application that runs within a container is configured in accordance with published policy. Second, it evaluates container images against the Red Hat OVAL feed to ensure that it does not contain vulnerabilities without corresponding patches installed. The OVAL feed from Red Hat provides information on every known vulnerability that affects Red Hat Enterprise Linux, including UBI containers, as well as any mitigations or patches that are available to address exploits. OpenSCAP generates reports that reflect the overall health of the container in which an application will be run or developed.
One container hardening has been successfully completed, all scanning results and the images themselves are uploaded to the Iron Bank.
Above: the Iron Bank login screen
Iron Bank: A Stronghold For Hardened Container Images
The Iron Bank is an artifact repository that holds all hardened container images produced by the Platform One software factory. These container images have all been validated against DoD security and compliance policies defined in the DoD Container Hardening Security Requirements Guide. They have also been comprehensively analyzed by Anchore, which identifies known vulnerabilities and unsafe practices in OS & non-OS packages, libraries, licenses, binaries, credentials, secrets, and metadata.
For end users, creating an account with Iron Bank to download hardened container images is a quick and painless process that takes only a few seconds. Once authenticated, Iron Bank displays a dashboard that contains the images available for use, their approval status, and the scanning reports generated by Anchore, OpenSCAP, and the runtime scanning tools within the SCSS.
Iron Bank also shows a list of vendors whose container images are available, which grows daily as new software is hardened to the DoD standard
Above: the list of vendors in the Iron Bank, as of this writing
By drilling down on a particular container image, users can view specific instructions for downloading and sideloading the image into their own repository.
Above: the detail provided by Iron Bank for a particular image
Users can also inspect the scanning artifacts produced as a part of the container hardening process. These are formatted as a collection of CSV files with detailed pass/fail status for specific policy gates. This gives end users the ability to validate compliance in detail before downloading and deploying images.
Current Status
The images are already available for use. By following the steps above, a DoD end user can begin setting up their own DevSecOps pipeline. The scanning artifacts generated by Anchore serve as a critical component for the program achieving and maintaining Continuous ATO. As a result, this allows the program to overcome the 9-12 month timelines it takes to receive authorization to operate as it was in the past. The increased time to production greatly reduces financial burden and ultimately allows the developers to focus on increasing automation and building out new features quicker than before.
The repository already has numerous different products for programs to begin using and building their own pipelines using already approved and hardened containers. Ranging from service mesh products such as Istio, logging tools such as Elasticsearch/FluentD/Kibana (EFK), configuration management tools such as Ansible or Chef, continuous integration and source code management in Gitlab, and container security in Anchore Federal. Vendors will continue to be on-boarded into Repo1 and Iron Bank, providing the best software available for immediate use by DoD programs.
Conclusion
The Iron Bank alleviates a huge burden for developers on DoD systems, allowing them to abandon lengthy software development lifecycles of the past. By taking advantage of the DoD DevSecOps Platform and using hardened images from Iron Bank, users gain the following:
Speed: Signing up for the Iron Bank and consuming images is an easy process, and can result in hardened containers running in an end-user cluster within minutes.
Security: All images have already been hardened based on guidelines and requirements that establish a baseline of security and prevent bad practices during the build stage.
Flexibility: Iron Bank contains software from over 100 vendors, allowing users to avoid being locked-in and reliant on a single vendor in their stack. This allows end users across various DoD programs to choose the best vendor software for their own environment.
Compliance: The Iron Bank provides a record of all scans, along with a complete set of scanning artifacts for each image. Additionally, the USAF reviews vulnerability findings for each image in the Iron Bank. For images that fail to meet certain requirements, justifications with specific plan of action in order for software to remain available.
Download the PDF version of this case study for a complete look at How Anchore and Red Hat teamed up to build a DevSecOps pipeline for the Department of Defense.
We’re hiring a Product Marketing Manager! In this week’s Be Yourself, With Us, SVP of Marketing Kim Weins shares the exciting opportunities within the role.
“Product marketing at a startup like Anchore provides a lot of room to leave your stamp, since our product is evolving quickly based on problems our customers need to solve,” said Kim.
Anchore’s customer base ranges from large enterprises like NVIDIA and eBay to government agencies like the U.S. Space Force and the U.S. Air Force. Being nimble to create custom solutions is critical for our expanding software security products.
“On top of that, we’re in a rapidly growing industry with a solution at the nexus of cloud, containers and security. There’s immense potential for what Anchore can provide for customers and the Product Marketing Manager is going to have a huge impact on how these solutions are communicated to the rest of the industry,” she continued.
Are you passionate about the future of software security and curious about the next innovation that will help secure data and prevent cyberattacks? Then consider joining our marketing team. Visit this link to apply.
Getting FedRAMP authorization for your containerized applications can be daunting. You must comply with new requirements detailed in the recent FedRAMP Vulnerability Scanning Requirements for Containers.
Begin exploring the strategic nature of containerization, its benefits and how many of them can be extended to security, while examining some of the unique challenges presented by full-speed container-based development.
Startups come with many opportunities – the ability to partner directly with leadership, to move quickly with decision making, and to work on a variety of projects across the organization. At Anchore, we have intentionally designed our internal programs to provide employees with equitable opportunities for mentorship and career growth.
Through our continuous performance model, we built opportunity into the foundation of our company culture. We do this by ensuring every employee (regardless of background, tenure, or level) feels empowered to raise their hand with an idea, question, or express interest in a new project. Anchorenauts have ample opportunity to expand their skills as they work towards short-term and long-term career goals.
Instead of focusing solely on linear career paths, we give employees the opportunity to pursue other roles or career aspirations.
Andre Neufville (he/him) joined Anchore in November 2019 on the Customer Success team, with a focus on designing solutions that integrate container security best practices into customer DevSecOps workflows. “My role was to interface with customers and prospects, help them understand how to operate Anchore in containerized environments and integrate container scanning in their development workflows, but there was also an added sales aspect that I hadn’t done before.”
Client service wasn’t always the focus for Andre. Prior to Anchore, he worked on systems administration and network security.
“Early on I developed an interest in understanding the components of a secure enterprise network and used that knowledge to design better security around systems and network architectures. At the same time, cloud adoption grew and companies began developing modernization strategies for enterprise infrastructure. I transitioned to the role of a Cloud Security Architect in which I was able to apply my previous experience to advise customers on how to secure their cloud infrastructure and workloads.”
When Anchore’s InfoSecurity and IT team was expanding, Andre expressed interest in the role during a continuous performance discussion and was supported by his manager to pursue the opportunity. The IT Security Engineer role proved to be the perfect opportunity to combine his past experiences and current interests (as Andre is also in the process of getting his Masters degree in Cybersecurity Technology).
“In the past, I partnered with and advised customers on architecting solutions without the ownership of seeing it through. The InfoSec role has given me an opportunity to apply the same principles internally, but rather than just advising how it should be implemented, I get to follow through and look for areas of improvement. The whole end-to-end approach really intrigued me and my general affinity towards security that I’ve had in all my roles. I’m grateful for the opportunity to be a part of our internal IT Security initiatives and look forward to learning and growing in the role.”
Supporting employees to pursue alternative career opportunities within our organization is an integral part of Anchore’s culture – truly embodying our core values of kindness, openness, ownership. For more on our open roles, check out our careers page here.
Organizations are increasingly developing cloud-native software to serve the needs of customers, partners, and employees. They must ensure the security of these applications that are delivered using container technologies.
Established in 2010, CloudBees is a provider of continuous integration/continuous delivery (CI/CD) tools for customers in the commercial and public sectors. Based on Jenkins open source, CloudBees CI is considered an industry-standard in the DevOps community.
CloudBees has about 500 employees worldwide, most of whom work remotely. The product development (engineering and product management) organization is about 167 employees. Product security and Jenkins security are two separate teams in this organization.
The product security team builds libraries or tools for other teams to consume and easily integrate into their pipelines. By lowering the effort needed to integrate scanning in their environment, teams could incorporate it easily into their toolchains and development life cycles.
Summary
Challenges
Industry concerns around container security in Docker images
Wanted a solution that enabled their security team to resolve Docker container security issues proactively
CloudBees allows their teams to be flexible in their choice of parent Docker images, thus wanted more governance to ensure security
Solutions
Provide container governance across projects
Lower the effort to integrate container scanning in the DevOps toolchain
All CloudBees products that generate Docker container images have to use
Anchore Enterprise as per internal corporate policy
Results
New container governance model for the company born from a greenfield project
Improved transparency into container security and compliance issues in their container supply chains corporate-wide
Capability to support customers who work in government, financial services, healthcare, and other industries with compliance mandates
Challenges
Several CloudBees customers raised concerns about the dire state of security within their Docker container images. Thus it became essential for them to have a policy feature to secure their container images. During this time, CloudBees began working with the United States Department of Defense (DoD), which currently uses Anchore Enterprise. The DoD requested CloudBees to validate their solutions against their policies proactively.
At a corporate level, CloudBees wanted to implement consistent standards for Docker container security across different products. Teams had been choosing their own parent Docker images, which had the potential to grow into a security challenge of its own.
The team decided that a best-in-class solution was necessary because CloudBees engineering management wanted to keep the product development organization focused on delivering innovation for CloudBees customers – not reinventing a wheel that was already well-made. This consideration made their “build vs. buy” decision easy.
“Scanning at scale can surface issues and help to identify things such as prioritizing specific scans over others for immediate examination.”
Solutions
Many on the CloudBees team were Anchore open source users and knew of its efficacy. These engineers advocated for an Anchore Enterprise solution. Their positive Anchore open source experience, the product’s ease of use, and a common customer in the US DoD made Anchore Enterprise a natural choice. The Anchore Policy Engine was also attractive to the CloudBees team.
The key criteria for selecting Anchore Enterprise was its policy engine and the role-based access control (RBAC) provided within the solution. Additionally, CloudBees requires that all software vendors possess a well-made API to integrate third-party tools into software pipelines.
CloudBees considered a solution from Twistlock before selecting Anchore Enterprise. However, Anchore Enterprise made better sense and was more suited to the use-cases at hand.
Results
All CloudBees software delivery pipelines that generate Docker container images now have to use Anchore Enterprise, per internal product security policy. Findings are consolidated in a central vulnerability repository for teams to triage, review, and fix within internal SLA time.
Both security and policy findings that Anchore identifies are automatically uploaded with the help of CloudBees internal tooling to DefectDojo, an open-source application vulnerability management tool in which CloudBees is actively involved.
CloudBees experienced a rise in the number of scan findings, showing the power of deep scanning using Anchore Enterprise. This new level of transparency into their container security positions allows them to remediate critical issues more quickly than before using Anchore Enterprise.
Implementing Anchore Enterprise was a Greenfield project for CloudBees. It led to a new Docker image governance model that reduced base images to better secure products that their developers build with containers.
CloudBees is now using Anchore Enterprise to bake in the right policies to support their customer needs across many different industries and government.
Download the PDF version of this case study for CloudBees.
Pitney Bowes is a global technology company providing commerce solutions that power billions of transactions in the United States and internationally. The company operates through Global Ecommerce, Presort Services, and SendTech Solutions segments. In providing such solutions, Pitney Bowes must comply with all applicable regulations and standards, including the Payment Card Industry Data Security Standard (PCI DSS).
The Pitney Bowes Product Security Team supports compliance programs across the company, starting with standard operating procedure (SOP) compliance. As part of these compliance programs, Pitney Bowes conducts PCI DSS audits. As a corporation, Pitney Bowes also supports the National Institute of Standards and Technology (NIST) Cyber Security Framework (CSF). Pitney Bowes is looking at Anchore’s suite of products, including Anchore Enterprise, for scanning their cloud environment to ensure their cloud meets International Standards Organization (ISO) standards.
Quick summary
Challenges
Implementing whitelisting for open source analysis and software composition analysis
Container deployments across a hybrid and multi-solution environment
Solutions
Anchore Enterprise enables Pitney Bowes Product Security Teams to support container compliance best practices
Results
Generate reports for review by Pitney Bowes auditors
Patch detection for Docker Containers
Customer requirements satisfied
Challenges
Pitney Bowes runs various container deployments across their enterprise, including AWS EC2 instances for Docker Containers. They are also running Amazon Elastic Container Service (ECS), Google Kubernetes Engine (GKE), and other deployments.
Solutions
The Pitney Bowes Product Security Team has been using Anchore Enterprise for two years now. They spent the first year evaluating the various enterprise features while looking internally at the best ways to implement Anchore Enterprise across teams considering using containers in their cloud environment. In year 2 of their Anchore Enterprise usage, Pitney Bowes teams have increased their use of runtime container architectures. Their teams are also using ECS and EKS more effectively than before their Anchore Enterprise implementation.
Pitney Bowes is looking at Anchore Enterprise to clarify their software composition analysis of their containers’ layers. Anchore Enterprise also helps Pitney Bowes IT leaders understand their DevOps teams’ maturity and understanding of containers. For example, the Anchore Engine provided DevOps team leads with actionable data that prompted them to review container best practices with their teams. While in the past leadership spoke to their development teams about containerization approaches, they now have the data to understand what their teams are doing with containers across their CI/CD toolchain. As a result, the development teams have the actionable insights from Anchore’s reporting tool to streamline delivery and improve security.
Results
Pitney Bowes makes use of Anchore scanning and reporting inside their security organization.
They also use Anchore Enterprise as a patch detection tool for their Docker container deployments. The Product Security Team saves these reports for auditor review.
Pitney Bowes is leveraging the new Anchore policy for malware scans and is seeing the value in the new policy as part of their container security checks.
About Pitney Bowes
Pitney Bowes (NYSE:PBI) is a global technology company providing commerce solutions that power billions of transactions. Clients around the world, including 90 percent of the Fortune 500, rely on the accuracy and precision delivered by Pitney Bowes solutions, analytics, and APIs in the areas of ecommerce fulfillment, shipping and returns; cross-border ecommerce; office mailing and shipping; presort services; and financing. For 100 years Pitney Bowes has been innovating and delivering technologies that remove the complexity of getting commerce transactions precisely right. For additional information visit Pitney Bowes, the Craftsmen of Commerce, at www.pitneybowes.com.
Download the PDF version of this case study for Pitney Bowes.
Software applications today include components from many sources, including open source, commercial components, and proprietary code. As software supply chain attacks have increased over the past several years, organizations must embed continuous security and compliance checks in every step of their software development process, from sourcing to CI/CD pipelines to production.
Shifting security left can lead to massive productivity gains that extend beyond development teams. As a significant force multiplier, it allows organizations to be more productive and improve collaboration.
SolarWinds and now Codecov point to the need for enterprises to better manage how they procure and intake open source software (OSS) into their DevOps life-cycle. While OSS is “free” it’s not without internal costs as you procure the software and bring it to bear in your enterprise software.
Here are five open source procurement best practices to consider:
1. Establish Ownership over OSS for your organization
Just as OSS is becoming foundational to your software development efforts, shouldn’t it also be to your org chart?
We’re lucky at Anchore to have an open source tools team as part of our engineering group. Our CTO and product management team also have deep roots in the OSS world. Having OSS expertise in our development organization means there is ownership over open source software. These teams serve our overall organization plus current and prospective customers.
You have a couple of options for establishing ownership over OSS for your organization:
Develop strong relationships with the OSS communities behind the software you plan to integrate into your enterprise software. For example, support can take the form of paying your developers to contribute to the code base. You can also choose to be a corporate sponsor of initiatives and community events.
Task an appropriate developer or development team to “own” the OSS components they’re integrating into the software they’re developing.
Stand up a centralized open source team if you have the budget and the business need, and they can serve as your internal OSS experts on security and integration.
These are just a few of the options for establishing ownership. Ultimately, your organization needs to commit the management and developer support to ensure you have the proper tools and frameworks in place to procure OSS securely.
2. Do your research and ask the right questions
Due diligence and research are a necessity when procuring OSS for your enterprise projects. Either your developers or open source team have to take the lead in asking the right questions about OSS projects you plan to include in your enterprise software. Procuring enterprise software requires a lot of work on the part of legal, contracts, and procurement teams to work through the intricacies of contracts, licensing, support, and other related business matters. There’s none of that when you procure OSS. However, it doesn’t mean you shouldn’t put in guard rails to protect your enterprise because sometimes you may not even realize what OSS your developers are deploying to production. Here are some questions that might arise:
Who’s maintaining the code?
Will they continue to maintain it as long as we need it?
Who do we contact if something goes wrong?
It’s not about your developers becoming a shadow procurement department. Rather, it’s putting their skills and experience to work a little differently to perform due diligence they might do when researching enterprise software. The only difference here is your developers need to find out some of the “what ifs” that come if an OSS project goes stagnant or may not deliver on the potential of their project.
3. Set up a Standard OSS Procurement Process
A key step is to set up and document a standard OSS process that’s replicable across your organization to set a standard for the onboarding process. Be sure to tap into the expertise of your IT, DevOps, cybersecurity, risk management, and procurement teams when creating the process.
You also should catalog all OSS that meet the approval process set by your cross-functional team in a database or other central repository. This is a common best practice in some large enterprises, but keeping it up to date comes at an expense.
4. Generate an SBOM for your OSS
OSS doesn’t include a software bill of materials (SBOM), a necessary element for conducting vulnerability scans. It’s up to you to adjust your DevOps processes and put the tools in place for whomever owns OSS in your development organization. Generating an SBOM for OSS can take place at one or more phases in your DevOps toolchain.
5. Put OSS Maintenance in Place
When you’ve adopted an OSS component and integrated it into your software, you still need to have a method in place to maintain that source code. It’s a logical role if you have a dedicated open source team in-house and such work is accounted for in their budget, charter, and staffing. If you don’t have such a team, then the maintenance work would fall to a developer and that risks shifting priorities, especially if your developers are billable to client projects. The last option is to outsource the OSS maintenance to a third party firm or contractor, and that can be easier said than done, as the expertise can be hard to find (and sometimes costly!).
Then again, you can always roll the dice and hope that the OSS project remains on top of maintaining their source code and software with the necessary security updates and patches well into the future.
OSS Procurement and your Enterprise
The time is now to review and improve how your enterprise procures and maintains OSS. Doing the job right requires relationship building with the OSS community plus building internal processes and governance over OSS.
Do you want to generate SBOMs on the OSS in your development projects? Download Syft, our open source CLI tool for generating a Software Bill of Materials (SBOM) from container images and filesystems.
With software supply chain attacks making headlines, it’s important to know how to secure containers at all phases of the software development lifecycle. You need to prevent security problems from reaching production and ensure that security issues are found earlier and fixed at a lower cost.
Prioritizing security as a design principle built into your development flow doesn’t happen overnight. Explore what a DevOps to DevSecOps transformation looks like in this white paper.
As the tech industry continues to gather lessons learned from the SolarWinds and now Codecov breaches, it’s safe to say that artificial intelligence and machine learning are going to play a role in the future of DevSecOps. Enterprises are already experimenting with AI and ML with the hopes of reaping future security and developer productivity investments.
While even DevSecOps teams with the budget and time to be early adopters are still figuring out how to implement AI and ML at the scale, it’s time more teams look to the future:
1. Cloud-Native DevSecOps tools and the Data they Generate
As enterprises rely more on cloud-native platforms for their DevSecOps toolchains, they also need to put the tools, frameworks, and processes to make the best use of the backend data that their platforms generate. Artificial intelligence and machine learning will enable DevSecOps teams to get their data under management faster while making it actionable for technology and business stakeholders alike.
There’s also the prospect that AI and machine learning offer DevOps teams a different view of development tasks and enable organizations to create a new set of metrics
Wins and losses in the cloud-native application market may very well be decided by which development teams and independent software vendors (ISVs) turn their data into actionable intelligence. Creating actionable intelligence gives their stakeholders and developers views into what their developers and sysadmins are doing right security and operations wise.
2. Data-Backed Support for the Automation of Container Scanning
As the automation of container scanning becomes a standard requirement for commercial and public sector enterprises, so will the requirements to capture and analyze the security data and the software bill of materials (SBOM) that come with containers advancing through your toolchains.
The DevSecOps teams of the future are going to require next-generation tools to capture and analyze the data that comes from the automation of vulnerability scanning of containers in their DevSecOps toolchains. AI and ML support for container vulnerability scanning offer a delicate balance of autonomy and speed to help capture and communicate incident and trends data for analysis and action by developers and security teams.
3. Support for Advanced DevSecOps Automation
It’s a safe assumption that automation is only going to mature and advance in the future with no stopping. It’s quite possible that AI and ML will take on the repetitive legwork that powers some operations tasks such as software management and some other rote management tasks that fill up the schedules of present-day operations teams.
While AI and ML won’t completely replace their operations teams, these technologies may certainly shape the future of operations team duties. While there’s always the fear that automation may replace human workers, the reality is going to be closer to ops teams becoming more about automation management.
4. DevOps to DevSecOps Transformation
The SolarWinds and Codecov breaches are the perfect prompts for enterprises to make the transformation from DevOps to DevSecOps to protect their toolchains and software supply chain. Not to mention, cloud migrations by commercial and government enterprises are going to require better analytics over development and operational data their teams and projects currently produce for on-premise applications.
5. DevSecOps to NoOps Transformation
Beyond DevSecOps lies NoOps, a state where an enterprise automates so much that they no longer need an operations team, While the NoOps trend has been around for the past ten years, it still ranks as a forward-looking trend for the average enterprise.
However, there are lessons you can learn now from NoOps in how it conceptualizes the future of operations automation that you can start applying to your DevOps and DevSecOps pipelines, even today.
Final thoughts
For the mature DevSecOps shop of the future to remain competitive, it must make the best use of data from the backend systems in its toolchain; SBOMs; and container vulnerability scanning. Artificial intelligence and machine learning are becoming the ideal technology solutions for enterprises to reach their future DevSecOps potential.
Lark extends the concepts of smart health and lifestyle hacking beyond a traditional consumer fitness tracker to significantly improve patient outcomes in clinical medicine. By combining smart, connected-health devices with a powerful artificial intelligence (AI) platform, Lark provides personalized, interactive health coaching for pre-diabetes and hypertension patients. The health tech market, mostly having to maintain compliance, temper Lark’s need for agility. Alongside the usual challenges of creating a superlative product, medical startups also have to operate within a harsh regulatory environment, with long lead-times to market and some of the highest testing and security standards.
In the United States, state and federal regulations govern medical products. Health Tech firms such as Lark must consider The Health Insurance Portability and Accountability Act (HIPAA) at every development stage. Failure to comply with HIPAA is a serious offense, carrying a maximum of a $50,000 fine per violation. In 2019, the average cost of a data breach in the US medical industry was $6.45 million.
For health tech startups, a security breach can be an existential threat. Even without the risk of substantial fines, the public views medical data as being sacrosanct. Losing any medical data risks irrecoverable reputational impact.
At a glance
Challenges
An explosion of containers and tags.
Each additional container and tag had the possibility of introducing new common vulnerabilities and exposures (CVEs) and security issues into their system, either from a directly installed application.
Scanning Lark images in production.
Solutions
Implement Anchore Enterprise in Passive Analysis Trigger Mode in their development environment to allow continuous container deployment and. scanning of only the images in production.
Results
Utilizing Anchore, Lark was able to replace a manual and labor-intensive task with an automated, developer-friendly workflow.
With Anchore Enterprise and its reporting, the company connected the security team to the application development lifecycle without burdening them with additional manual work or slowing down development.
Challenges
Lark faced a common problem many container-first development teams face: an explosion of both containers and container tags to manage.
Most container workflows will naturally produce a constant stream of new containers. After passing through a CI pipeline, it is common practice for every application or service to have a container created, tagged, and then pushed to a container repository. They exacerbate this challenge in platforms that have adopted a microservices pattern, where many components contribute to the overall scale and pace of container sprawl.
The judicious use of automated life cycle policies (where these exist) can reduce container sprawl. However, it is still commonplace for companies to have hundreds, if not thousands, of images and tags.
For Lark, the real problem was that each additional container and tag had the possibility of introducing new common vulnerabilities and exposures (CVEs) and security issues into their system, either from a directly installed application dependency or from an inherited base container.
“With Anchore Enterprise and its powerful reporting, Lark connected their security team to the application development lifecycle without burdening them with additional manual work or slowing down development.”
Solutions
The team’s approach to implementing Anchore was to minimize the disruption of introducing a new tool. Rather than re-writing the many CI/CD pipelines in use at Lark, Tyler took the approach of leveraging the Kubernetes admission controller together with a tiered approach to policies, getting more permissive with each step further left:
Production: The DevOps team implements Anchore in production to scan all images in production. Anchore provides reports of the vulnerabilities that are in production allowing the Security and Eng teams to review and remediate them.
Result
With Anchore Enterprise and its powerful reporting, Lark connected their security team to the application development lifecycle without burdening them with additional manual work or slowing down development.
Anchore has allowed Lark to substantially increase visibility into potential security issues without requiring massive amounts of operational effort. It is integrated into existing workflows without necessitating a change of procedures and offered valuable insights into how containers are being used.
“By adopting a graduated application of modes, the Lark DevOps team could guarantee Lark’s platform’s operational safety while ensuring that development cadence was uninterrupted.”
Download the PDF version of this case study for Lark.
This report contains dozens of charts highlighting the latest enterprise trends in securing the software supply chain with a special focus on cloud-native applications. In this report, you’ll gain insights to help you reduce risk of software supply chain attacks. ok
Supporting container scanning in a compliance environment takes more than a standard DevSecOps approach. Choose the right combination of tools for automated security and compliance across toolchains.
Containers introduce unique security challenges for enterprises and federal agencies alike. Get simple and manageable DevSecOps best practices for federal organizations that deploy containers at scale.
Hypothekarbank Lenzburg (HBL) was founded in 1868, and while the bank is deeply rooted in Swiss banking history, it is definitely not stuck there.
HBL delivers cutting edge-products and services to its customers, from hybrid banking offices to block chain accounts. The bank’s technology team also operates as a growing technology service provider in its own right, and is widely recognized as a pioneer of open banking within the Swiss financial sector.
HBL is constantly looking to support its development team, embracing technological progress and smoothing processes to increase the pace of innovation. One example is the adoption of a language agnostic approach, with multiple programming languages in use throughout its own infrastructure. And HBL has also jumped at the opportunities presented by containerization, implementing Red Hat’s OpenShift platform to run containerized workloads in Kubernetes.
HBL has jumped at the opportunities presented by containerization
However, the bank’s progressive attitude to technology has brought with it significant new challenges for the internal security team. In common with many banks, HBL formerly maintained a firm framework around the auditing, automation and scanning of servers for security issues. Aspects such as user permissions, service accounts and which software packages are installed, were all monitored and tightly controlled within the bank’s traditional infrastructure.
Containerization can deliver massive benefits for any organization, dramatically speeding development, encouraging reuse and standardization, and often forming the core of an effective DevOps strategy. However, containers can also be challenging for organizations that have existing and mature processes around server management. The ease with which containers can be both built and distributed makes it impossible to manually keep track of what software is being introduced into your environment.
“More and more of our software, from both internal and external developers, is now delivered as containers. This made it very hard for our traditional vulnerability management solution to keep up because it couldn’t scan containers efficiently,” said Sascha Kaufmann, Head of IT Security at HBL. “We also needed a way to ensure a level of compliance on container deployment – such as enforcing certain base images or ensuring that no root user was allowed.”
More and more of our software, from both internal and external developers, is now delivered as containers
Traditional asset registries were built for a time of ‘fixed’ servers. They ‘fixed’ servers. They on custom agents or, at least, an SSH connection tobe present. And neither of these are likely to be available within a container. Even where teams have the considerable resources needed to manually audit containers with existing tools, most will struggle to keep pace with the rapid rate of change inherent in containerized workflows. This leads to these legacy systems delivering a view that is outdated at best, and at worst, wildly misleading.
Together, these challenges presented a major issue for HBL. Especially, since one of the many rules of the Swiss Financial Market Supervisory Authority (FINMA) requires regular, and accurate, security auditing of all software running in production.
It was obvious that HBL’s existing software scanning tools and processes could no longer offer a secure solution, so the bank started by considering the larger security suites including Aquasec and Twistlock.
“At the beginning of our container journey, we were looking for a suite of tools that would cover firewalling, intrusion prevention, policy enforcement, and vulnerability management across our whole environment.” Kaufmann explains, “But for a team like ours, the problem with this approach was human resourcing. Even where a vendor can offer you an all-in-one solution, it takes a lot of time to plan, deploy, maintain and monitor all these aspects.”
A search into newer, more agile, open source solutions led HBL to Anchore. This offered a focused solution for HBL’s main concern: container security.
“Anchore didn’t try to solve all of our security problems at once. It has a clear focus on a core aspect: vulnerability management and policy enforcement in containerized software,” Kaufmann continues. “If you have a small team, pick your biggest pain point and then focus on fixing this. It’s a lot faster and more straightforward to deploy a focused solution.”
Anchore’s focus on solving one core requirement allowed HBL to implement container scanning almost immediately.
After a short evaluation of Anchore’s open source solution to get a feel for things, the team at HBL were convinced. The software offered a lot more than just a quick win, giving Kaufmann the missing visibility into any vulnerabilities within HBL’s container environment. In contrast to other tools offering container scanning, Anchore seemed to be tailor made to fit a container-focused development workflow and to foster a workable DevSecOps process.
“Anchore is a real ally for our developers. With any security solution, it’s important that we are not just ‘shifting an additional burden left’ and dumping it on them,” explains Valeriano Piromalli, senior software engineer at HBL. “Our developers have always been responsible for resolving security issues. But with Anchore they are in control of the process and the timing. It removes the irritation.”
“Security is no longer an afterthought: with a pile of vulnerabilities getting dumped on some developer who thought they had finished the job. Anchore makes security part of a smooth, ongoing DevSecOps process that starts from the earliest stages of design and development.”
Impressed from the outset, HBL quickly realised the potential value of some of the additional features offered by Anchore Enterprise. These included the integration into the bank’s existing authentication systems (LDAP), the intuitive enterprise UI and the enhanced vulnerability database.
But by far the biggest benefit of Anchore Enterprise was the dedicated policy interface for HBL’s security team. This has allowed Kaufmann and his team to create policies that ensure compliance in the tightly regulated Swiss finance industry. It has allowed the team to create and implement a workable baseline for container security, from where they can iterate and advance policy over time towards an evolving best practice approach.
As an implementation strategy, HBL took a two pronged approach. Firstly, Anchore has been pushed left to developers, allowing them to run ad-hoc, local scans on containers prior to deploying them. This now provides the developers with a view of any fixes needed without compelling instant action and interrupting the development process. It has helped turn security into a collaborative effort that both spreads the workload, and also engages developers to be part of the security efforts. The approach also provided the HBL security team with some immediate, valuable insights, while the work of amending the CI/CD pipelines took place in the background.
As a second part of the approach, HBL applied greater central control by adding Anchore into their CI/CD pipelines. HBL applied strict pass/fail gating to new containers as part of the publishing process. This gave developers instant feedback if their container had a high impact CVE.
“For the developers the major impact is the required change in mindset, to think of security from the outset as a part of our software development process. It is DevSecOps at work. Security is now a seamless part of our fast, smooth container-based development process,” Piromalli reflects. “We are fostering a healthy attitude that security is an ongoing issue for everyone, not a problem that the security team dumps on developers as an afterthought.”
“It is DevSecOps at work. Security is now a seamless part of our fast, smooth container-based development process”
For HBL, Anchore has been an invaluable tool on its container security journey. “Without Anchore we would still be completely in the dark about our container environment. We wouldn’t know what kind of vulnerabilities we’re facing or if a developer is running the container as root. Having a blind spot in an important part of our network wasn’t a risk we were willing to take,” Kaufmann admits.
Anchore’s focused approach on delivering a solution around container scanning and compliance, has provided HBL with a rapid fix for what had initially seemed an almost overwhelming challenge. It also allowed Kaufmann to demonstrate the criticality of security to a wider audience.
“A more focused solution is a lot faster to deploy, you’ll get your first wins, and you can show both management and developers that security in a container environment is as important as on a virtual machine in a datacenter.”
Moreover, Anchore has provided a security solution that is more in-tune with HBL’s development processes, delivering smooth, almost painless DevSecOps.
HBL is still at the start of its journey to create a full set of systems and policies around container security. Anchore has given them a running start, ensuring that the bank complies with legislation and guidance in one of the most tightly regulated industries. The work of Kaufmann and his team will underpin HBL’s container landscape for a considerable time to come, and provide them with a platform to progress their container security from compliance to industry-leading best practice.
Download the PDF version of this case study for a complete look at Hypothekarbank Lenzburg.
At Anchore we’re passionate about our products and our industry, but we’re equally committed to building a company with amazing people, incredible career opportunities, and an ability to make a difference. We’re thrilled to start sharing more about who we are and what matters to us through the launch of our culture-first series.
On Fridays, you can expect to learn more about who Anchore is. We’ll give you a closer look at:
The Humans of Anchore: The people (including pets and little ones!) who help shape our company.
Be Yourself. With Us: A highlight reel of new jobs and a glimpse into the people you could be working with at Anchore.
Mission: Impact: This is where we show you our programs and initiatives and how they enable us to live out our core values every day.
So, come learn more about why we’re excited to work here. And maybe a little about how you can make that a reality for you, too, someday. Come be yourself. With us.
Curious what it’s like in a startup? As we continue our culture-first series, today we’re diving into the jobs and people at Anchore. All startups are different, at Anchore we focus on ensuring all employees, from individual contributors to the exec team, are given the opportunity to challenge themselves and explore new skillsets.
We talked to Support Engineer Tyran H. in the UK about his time on the team.
“Anchore is my first encounter working at an actual startup and is an amazing place to experience the real deal. Plus, I also have the opportunity to learn and develop technologies at the forefront of the tech world.”
Not only is Tyran part of our growing customer success team, but he was also Anchore’s first UK-based employee.
“As the first overseas hire, being welcomed as part of the family to help Anchore grow from the ground up has made settling in easy. It feels more like working on a passion-project with a group of friends than ACTUAL work, which is a massive bonus!”
Want to join Tyran and our team? Check out our latest job listings here.
INDUSTRY FinTech | Infrastructure | Data Intelligence
Introduction
Named the 30th fastest-growing private software company in America on the Inc. 5000, Ocrolus’ fintech intelligence automation platform analyzes financial documents with more than 99 percent accuracy for customers in the banking and financial services sector, while transforming documents into actionable data.
Since its founding in 2014, Ocrolus has experienced impressive growth and revenue gains, which have allowed it to expand service offerings to include built-in fraud detection and analytics, that enable its customers to make smarter and faster business decisions with unprecedented precision.
At a glance
Challenges
Organization compliance policies
Default-deny whitelisting process
Lack of insight for audit & non-technical teams
Container vulnerability scanning
Solutions
Automate whitelisting
Complete vulnerability & compliance reporting
Improve stakeholder accessibility
Results
Transparent communication around compliance
Visibility on reporting for auditors
Increased productivity through automation
Customer requirements satisfied
Challenges
Ocrolus’ site reliability engineering (SRE) team is responsible for adhering to the organization’s compliance policies to ensure specific security and auditable controls around the software development lifecycle. This encompasses code review, security scanning as part of development and continuous monitoring of production.
Observing strict compliance protocols to secure personal and financial identifiable information, as well as provide visibility to the internal compliance department on security outputs was imperative. Equally important was the ability to provide transparency around the SRE team’s whitelisting process, while maintaining visibility to other Ocrolus business groups that weren’t directly involved with solution implementation. And lastly, needing continuous scanning on newly published vulnerabilities for deployed applications was critical.
“Anchore has brought a tremendous amount of value to Ocrolus.”
Solutions
A longtime open-source Anchore Engine user, the Ocrolus SRE team recognized the tremendous value that Anchore Engine brought to the organization early on. The team’s decision to upgrade to Anchore Enterprise was spurred by the need for transparent communication with organizational stakeholders around compliance; and by the importance to increase productivity and streamline other processes, such as whitelisting, among others.
Adding the full-service capabilities of Anchore Enterprise to the Ocrolus environment was an effortless and seamless process. The simplicity of implementation was based on:
Easy access to documentation, which resulted in effortless onboarding.
Product communication served in familiar language for DevOps teams.
Zero custom tooling requirements needed for system setup.
Anchore’s straightforward user interface gave auditors instant access to information when they needed it. By clicking the compliance tab, compliance data was presented that was digestible and timely. For non-technical users at Ocrolus, this solution established confidence in the SRE team and the system.
Results
Post-implementation, the SRE team was able to empower audit team members by inviting and training them with the Anchore Enterprise platform for on-demand access to security and vulnerability reporting. Through the Anchore user-interface, non-technical colleagues have greater insight into projects, which built trust with the overall system.
SRE team resource constraints were lifted and productivity dramatically improved by reducing dependencies on a single individual to provide answers to audit questions. Furthermore, other processes, like whitelisting, were made more efficient. In particular, Anchore Enterprise made image whitelisting easier helping the SRE team improve its operational efficiency.
In addition, Anchore Enterprise prevented false-negatives from vulnerability scans, which saved the SRE team time and money. Without false negatives, the focus was shifted to fixing true vulnerabilities to improve its enterprise performance and application security architecture.
With Anchore Enterprise, the organization was able to meet and exceed customer container security requirements to win new logos and business. Having Anchore Enterprise in place allowed Ocrolus to achieve customer expectations around container security scanners and demonstrate a strong security posture in the fintech space.
“Based on the amount of time our team has saved, Anchore Enterprise has paid for itself 20 times over.”
~10
Hours
Average Time Saved (Monthly) Responding to Audit Requests
5
Hours
Average Time Saved (Monthly) Whitelisting Applications
10
Minutes
Start to Finish Configuration ACL SAML
“Implementing application-specific whitelists take less time to implement with Anchore Enterprise user interface than a global whitelist manually in Anchore Engine.”
Download the PDF version of this case study for a complete look at Ocrolus.
Given the recent attacks on the supply chain, security is the most essential aspect of software development, particularly when it comes to government and critical infrastructure. Anchore’s DoD-approved container scanning capabilities can help you speed up compliance and vulnerability scanning–expediting the ATO process and helping you go live with applications faster.
Toolkits and orchestrators such as Docker and Kubernetes have been increasingly popular for companies wishing to containerize their applications and microservices. However, they also come with a responsibility for making sure these containers are secure. Whether your company builds web apps or deploys mission-critical software on jets, you should be thinking about ways to minimize your attack surface.
Aside from vandalizing and destroying company property, hackers can inflict massive damage simply by stealing data. In 2017, Equifax was fined over $500 million after customer data was stolen. British Airways and Uber have also been victims of data breaches and were fined hundreds of millions of dollars in recent years. With an average of 75 records being exploited every second, preventing bad actors from gaining access to your containers, pipelines, registries, databases, clusters and services is extremely important. Compliance isn’t just busywork, it keeps people (and their data) safe.
In this post, we’d like to discuss the unique approach Anchore takes to solving this problem. But before we get into that, let’s take a moment to define the buzzword that is probably the reason you’re reading this post: DevSecOps.
In a nutshell, DevSecOps is a modernized agile methodology that combines the efforts of development, operation and security teams. Working together to integrate security into every step of the development process, teams can deliver applications safely, at massive scale, without burdening them with heavyweight audits. DevSecOps helps teams catch issues early, before they cause damage and while they are still easy to fix. By making security a shared responsibility and shifting it left (towards developers and DevOps engineers), your company can deal with vulnerabilities before they enter production, saving time and reducing costs drastically.
In the following sections, we’ll cover a few unique reasons why organizations such as eBay, Cisco and the US Department of Defense have made Anchore a requirement in their software development lifecycle to help implement security with DevSecOps.
Lightweight Yet Powerful
At Anchore, we believe that everyone should know what’s inside the container images they build and consume. That is why the core of our solution is an open source tool, Anchore Engine, which performs deep image inspection and vulnerability scanning across all layers. When users scan an image, Anchore Engine generates a software bill of materials (SBOM) that consists of files, operating system packages, and software artifacts (including Node.JS NPM modules, Ruby GEMs, Java archives and Python packages). Anchore Engine also allows users to check for CVEs, secrets, exposed ports and many others, but more on that later!
Anchore Engine was designed to be flexible, so you can implement it anywhere:
If you’re a developer and want to do a one-time scan of a container image for vulnerabilities before pushing any code to version control, you can use our CLI or API
If you’re a DevOps engineer and wish to scan container images before pushing to or after pulling from a registry, you can easily integrate with your preferred CI/CD tool (CircleCI, Jenkins, GitHub Actions, GitLab) or perform inline scanning and analysis
If you’re a security engineer responsible for locking-down clusters, you can use our Kubernetes Admission Controller to prevent any pods from running vulnerable containers
Anchore Engine can be configured on any cloud platform or on-premises, as well as with any Docker V2 compatible registry (public or private). Regardless of where you’re using Anchore Engine or how you’re using it, it’s important to know the exact contents of your containers so appropriate security measures can be taken.
Strict But Adaptable
Anchore Engine enables users to create custom security rules that can be adapted to align with company policy. For example, users can create and define checks for vulnerabilities, package whitelists and blacklists, configuration file contents, leaked credentials, image manifest changes, exposed ports and more. These rules allow you to enforce strict security gates like Dockerfile gates, license gates and metadata gates (check out our docs for more info!) before running any risky containers.
You may have heard of Infrastructure-as-Code, but have you heard of Security-as-Code or Policy-as-Code? Because Anchore policies are standard text files, they can be managed like source code and versioned over time as the software supply chain evolves and best practices are developed.
In addition to Anchore Engine, we offer Anchore Enterprise, which includes many enhanced features such as an easy-to-use interface, an air-gapped feed service, and notifications with Slack, Jira, GitHub or Microsoft Teams. There are many more features and capabilities of both Anchore Engine and Anchore Enterprise, but that is a topic for a later post.
Compliant And Growing
Just days away from becoming a CNCF Kubernetes Certified Service Provider, Anchore has been working hard to help companies fulfill their security requirements. Oftentimes, we receive calls from security teams who were asked to make their software adhere to certain compliance standards. Anchore is proud to help organizations achieve NIST SP 800-190 compliance, CIS Benchmarks for Docker and Kubernetes, and best practices for building secure Docker Images.
If you work with government agencies and are interested in another level of compliance, please check out our newest product, Anchore Federal! It includes a bundle of policies created in collaboration with the United States Department of Defense that can provide out-of-the-box compliance with the required standards.
In this post, we’ve listed a few key reasons why organizations choose to use Anchore. You may have noticed we also interchangeably used the words “you” and “your company”. That’s because – in today’s world of containers – you, as the reader, have the responsibility of talking with your company about what it’s doing to prevent threats, why it should be implementing DevSecOps processes, and how Anchore can help through container security. We are here to help.
When I began here at Anchore, I realized I would need to create a quick and offline way to be able to test installation in a way that would better approximate the most common way it is deployed—on Kubernetes.
We have guides to stand up anchore with docker-compose, and how to launch into Amazon EKS, but we didn’t have a quick way to test our helm chart, and other aspects of our application, locally on a laptop in a way that used K3s instead of minikube.
I also wanted to stand up a quick approximation not just on my local laptop, but against various other projects I have. So I created a K3s project base that automatically deploys K3s in vagrant and VirtualBox locally on my laptop. Also, if I need to stand up a Kubernetes cluster on external hosts to my laptop, I can run the playbook against those hosts to stand up a K3s cluster and deploy the anchore engine helm chart.
To get started, you can check out my project page on Github. It’s not a feature-complete project yet, but pull requests are always welcome.
Scenario 1: Standing this Up on your Local Laptop
Step 1: Install dependencies
To use this, just make sure you’ve met the requirements for your laptop, which is to say: make sure you have Ansible, Vagrant and VirtualBox installed. Clone the repo, change directories into that repo and issue the command “vagrant up”. There are more details on the readme file to help get you started.
First, you’ll need to be running a Linux or macOS laptop and have the following things installed:
First, install Virtualbox per the link instructions above. Once that is in place, install Ansible and Vagrant per the links above also. To install the Vagrant VirtualBox Guest Additions Plugin, you issue the following command:vagrant plugin install vagrant-vbguest
We are now ready to clone the repository and get this running. The following three commands will pull the repository and stand up the K3s cluster: git clone https://github.com/dfederlein/k3s_project_base.git cd k3s_project_base vagrant up
Scenario 2: Run this Playbook Against Hosts External to your Laptop
In this scenario, you have ansible installed on a control host, and you will be building a k3s cluster of hosts you already control. I will assume this scenario is utilized by people already familiar with Ansible and give some shortcut notes.
First, clone the repository with the following command: git clone https://github.com/dfederlein/k3s_project_base.git
Next, we’ll modify the hosts.ini file to reflect the hosts you want to create this cluster on. Once you’ve added those, the following command should get you what you need: ansible-playbook -i hosts.ini site.yml -u (user)
Add the become password and connection password or private key flags to that command as needed. More information on how to do that in the Ansible documentation.
The end of the processes detailed above should have a working K3s cluster running on your laptop, or on the external hosts you’ve pointed the playbook at, and a helm chart of anchore deployed to that cluster. Please note that the Vagrant/local deploy scenario may need some patience after being created, as it will operate with limited ram and resources.
“When I interviewed for the manager position with the leadership team, I was glad that I was going through a formal process because it made me realize that Anchore understands how vitally important great managers are to the success of the company.”
