# Anchore > Software supply chain security solutions ## Posts ### Meeting 2025's SBOM Compliance Deadlines: A Practical Implementation Guide Pt. 2 If you're just joining us, this is part 2 of a series on practical implementation of software supply chain security to meet the most recent SBOM compliance requirements. In Part 1, we covered the fundamentals of automated SBOM generation—from deployment options to registry integration to vulnerability analysis across any container infrastructure. With your SBOMs now flowing into Anchore Enterprise, the real compliance value begins to emerge. Part 2 focuses on the operational aspects that turn SBOM data into actionable compliance outcomes:  automated policy evaluation,  custom rule creation for your specific regulatory requirements, and  comprehensive reporting that satisfies auditors while providing actionable insights for development teams. Whether you're pursuing PCI DSS 4.0 compliance, preparing for the EU Cyber Resilience Act, or building frameworks for future regulatory requirements, these capabilities transform compliance from overhead into competitive advantage. Learn about the role that SBOMs for the security of your organization in this white paper. Download Now Checking your container SBOMs (for compliance) With high fidelity SBOMs now present in Anchore Enterprise, the system will automatically perform policy evaluations against them. This is important in order to establish a baseline for container image compliance with checks against various policies. NOTE: When a container image is added, policy compliance checks are automatically applied against the SBOM in accordance with the default policy. In the Anchore Enterprise UI, navigate to an image. The first page visible will be the policy and compliance evaluation summary.  From here you can inspect the policy evaluation results and the recommended action by the policy, for example the rule which was triggered and the resultant action (such as STOP or WARN): You may wish to export a compliance report to deliver feedback to application teams or other stakeholders, asking them to please fix or remediate these items. You can get this report from the UI at the click of a button: NOTE: A compliance report can be downloaded in either json or csv format. With application teams busy taking remedial action, they can build a new image and Anchore Enterprise can generate an SBOM from this and conduct another policy evaluation.  NOTE: It’s possible to watch a given tag which will ensure whenever a new version is pushed, it will be automatically scanned by Anchore Enterprise.  You can also use the CLI and API (via AnchoreCTL) for checking your container SBOM (for compliance). This is particularly useful when working with Anchore Enterprise and SBOMS in the development pipeline. To conduct a policy check on a newly built image, run the following command to compare with the default policy: $ anchorectl image check aws_account_id.dkr.ecr.region.amazonaws.com/repository:tag –detail$ anchorectl image check aws_account_id.dkr.ecr.region.amazonaws.com/repository:tag –detail You can also fail based on the results of this evaluation with the following -f flag: $ anchorectl image check -f aws_account_id.dkr.ecr.region.amazonaws.com/repository:tag$ anchorectl image check -f aws_account_id.dkr.ecr.region.amazonaws.com/repository:tag NOTE: The pass/fail evaluation result is useful for integration into CI/CD pipelines as it sets the exit code to “1” on a fail to halt the pipeline. You can also export the compliance report using the CLI: $ anchorectl image check aws_account_id.dkr.ecr.region.amazonaws.com/repository:tag -o json > $ anchorectl image check aws_account_id.dkr.ecr.region.amazonaws.com/repository:tag -o json > NOTE: The AnchoreCTL utility supports exporting the results in various formats (i.e., json, text, csv, json-raw, and id) with the -o flag. Text is the default format. Both UI and CLI (AnchoreCTL) compliance management are described in further detail here. Customising Policy (for compliance posture) Using Anchore Enterprise’s policy engine, you can build a set of custom rules which map to your own organizational policy. Alternatively, if you are pursuing FedRAMP compliance, you can use optional policy packs which are available as addons for the product.  NOTE: Multiple policies are supported by Anchore Enterprise. However, only one policy can be set as active/default at any time.  In order to build or customize your own policy, you can navigate to the desired policy and begin editing the rulesets. From the Policies (UI) page, you can view any policies listed under Policy Manager and select a given policy for editing. When editing a policy, you can then view all rulesets associated with it and select a ruleset for editing. When editing a ruleset, the recommended actions (STOP/WARN/GO) can be modified when a ruleset is triggered on policy evaluation. The ruleset parameters can also be modified to change the existing values. You can also use CLI tooling to gather certain aspects related to a policy. To list all policies both active and inactive: $ anchorectl policy list$ anchorectl policy list To list the rulesets associated with a policy (including names and actions): $ anchorectl policy get $ anchorectl policy get Downloading Account-Wide Compliance Reports Sometimes you need to demonstrate your compliance with policy at the account-level or across multiple accounts. Anchore Enterprise allows you to do just that with its Reporting feature. Anchore Enterprise Reports as it's known aggregates data across all accounts to:  Maintain a summary of all current and historical images/tags, and  Maintain vulnerability reports and policy evaluations for these respective images and tags. From the Reports (UI) page, you can generate a “New Report” based on pre-defined system templates and filters. The first dropdown allows you to select one of the included templates for generating a report. In turn, the second dropdown allows you to select one or more report filters. After selecting your template and report filter(s), you can also toggle between generating a report for the account you’re logged into or for all accounts. From the “Templates” tab, you can view all the current system templates or even any custom templates as you have the capability to create your own (templates). Once you’re ready to generate a report, it can either be downloaded in csv or json (native/raw) format or saved for later reference and run later either ad-hoc or on a schedule. NOTE: Reporting is described in further detail here. Wrap-Up The journey from SBOM generation to automated compliance demonstrates how regulatory requirements can drive meaningful security improvements rather than just administrative overhead. Organizations that embrace this automated approach aren't just meeting current compliance deadlines—they're building resilient supply chain security practices that scale with their business growth. Throughout this two-part series, we've seen how Anchore Enterprise transforms complex regulatory requirements into manageable, automated workflows. From initial SBOM generation across diverse container registries to sophisticated policy enforcement and comprehensive reporting, the platform provides continuous visibility into security risks while streamlining compliance processes. The strategic advantage becomes clear when comparing manual approaches to automated SBOM management. Manual processes create bottlenecks that slow development cycles and generate compliance debt that compounds over time. Automated approaches integrate compliance checking into existing workflows, providing real-time feedback that helps development teams build more secure applications from the start. As regulatory requirements continue expanding globally, organizations with robust SBOM management capabilities will find themselves better positioned to adapt quickly to new requirements. The foundation built for PCI DSS 4.0 and EU Cyber Resilience Act compliance provides the framework needed for whatever regulatory changes emerge next. The choice facing organizations today isn't whether to implement SBOM management—it's whether to build sustainable, automated practices that turn compliance into competitive advantage or to continue with manual approaches that become more unsustainable with each new regulatory requirement. The 2025 compliance deadlines mark the beginning of this new reality, not the end. Explore SBOM use-cases for almost any department of the enterprise and learn how to unlock enterprise value to make the most of your software supply chain. Download Now ### Minutes vs. Months: The SBOM Advantage in Zero-Day Response When Log4Shell hit, one Anchore Enterprise customer faced the same nightmare scenario as thousands of organizations worldwide: Where is log4j hiding in our infrastructure? The difference? While most organizations spent weeks manually hunting through systems, this customer ran a single API command and identified every instance of log4j across their entire environment in five minutes. That's the transformation Josh Bressers (VP of Security, Anchore) and Brian Thomason (Solutions Engineering Manager, Anchore) demonstrated in their recent webinar on rapid incident response to zero-day vulnerabilities—and it represents a fundamental shift in how security teams can respond to critical threats. TL;DR: Traditional vulnerability management treats SBOMs as compliance artifacts, but modern incident response requires treating them as operational intelligence. This technical deep-dive covers three critical scenarios that every security team will face: Proactive Threat Hunting: How to identify vulnerable components before CVE disclosure using SBOM archaeology Runtime Vulnerability Prioritization: Real-time identification of critical vulnerabilities in production Kubernetes environments CI/CD Security Blindness: The massive attack surface hiding in build environments that most teams never scan Ready to see the difference between reactive firefighting and strategic preparation? Keep reading for the technical insights that will change how you approach zero-day response. The CUPS Case Study: Getting Ahead of Zero-Day Disclosure In September 2024, security researchers began dropping hints on Twitter about a critical Linux vulnerability affecting systems "by default." No CVE. No technical details. Just cryptic warnings about a two-week disclosure timeline. The security community mobilized to solve the puzzle, eventually identifying CUPS as the target. But here's where most organizations hit a wall: How do you prepare for a vulnerability when you don't know what systems contain the affected component? Traditional approaches require manual system audits—a process that scales poorly and often misses transitive dependencies buried deep in container layers. The SBOM-centric approach inverts this narrative. "One of the examples I like to use is when log4j happened, we have an Anchore enterprise customer that had all of their infrastructure stored inside of Anchore Enterprise as SBOMs. Log4Shell happens and they're like, holy crap, we need to search for log4Shell. And so we're like, ah, you can do that here, run this command. And literally in five minutes they knew where every instance of log4j was in all of their environments." —Josh Bressers, VP of Security, Anchore The Technical Implementation What was the command they used? The webinar demonstrates this live against thousands of stored SBOMs to locate CUPS across an entire infrastructure: $ curl -u admin:password \   "https://enterprise.example.com/v1/images/by_package?name=cups" \ | jq '.results[] | .tag_history[0].tag'$ curl -u admin:password \   "https://enterprise.example.com/v1/images/by_package?name=cups" \ | jq '.results[] | .tag_history[0].tag' This single command returns every container image containing CUPS, complete with version information, registry details, and deployment metadata. The query executes against historical and current SBOMs, providing comprehensive coverage across the entire software supply chain. Security teams can begin impact assessment and remediation planning before vulnerability details become public, transforming reactive incident response into proactive threat management. What Else You'll Discover This proactive discovery capability represents just the foundation of a comprehensive demonstration that tackles the blind spots plaguing modern security operations. Runtime Vulnerability Management: The Infrastructure You Don't Control Josh revealed a critical oversight in most security programs; vulnerabilities in Kubernetes infrastructure components that application teams never see. The demonstration focused on a critical CVE in the nginx ingress controller—infrastructure deployed by SRE teams but invisible to application security scans. Using Anchore Enterprise's Kubernetes runtime capabilities, the team showed how to: Identify running containers with critical vulnerabilities in real-time Prioritize remediation based on production deployment status Bridge the visibility gap between application and infrastructure security “I could have all of my software tracked in Anchore Enterprise and I wouldn’t have any insight into this — because it wasn’t my code. It was someone else’s problem. But it’s still my risk.” —Josh Bressers, VP of Security, Anchore CI/CD Archaeology: When the Past Comes Back The most eye-opening demonstration involved scanning a GitHub Actions runner environment—revealing 13,000 vulnerabilities across thousands of packages in a standard build environment. The technical process showcased how organizations can: Generate comprehensive SBOMs of build environments using filesystem scanning Maintain historical records of CI/CD dependencies for incident investigation Identify potentially compromised build tools (like the TJ Actions backdoor incident) “This is literally someone else’s computer building our software, and we might not know what’s in it. That’s why SBOM archaeology matters.” —Josh Bressers, VP of Security, Anchore Why SBOMs Are the Strategic Differentiator Four truths stood out: Speed is critical: Minutes, not months, decide outcomes. Visibility gaps are real: Runtime and CI/CD are blind spots for most teams. History matters: SBOMs are lightweight evidence when past build logs are gone. Automation is essential: Manual tracking doesn’t scale to millions of dependencies. Or as Josh put it: “Storing images forever is expensive. Storing SBOMs? Easy. They’re just JSON documents—and we’re really good at searching JSON.” The Bottom Line: Minutes vs. Months When the next zero-day hits your infrastructure, will you spend five minutes identifying affected systems or five months hunting through manual inventories? The technical demonstrations in this webinar show exactly how SBOM-driven incident response transforms security operations from reactive firefighting into strategic threat management. This is the difference between organizations that contain breaches and those that make headlines. Stay ahead of the next disclosure: 👉 Watch the full webinar on-demand Follow Anchore on LinkedIn and X for zero-day analysis and SBOM best practices. Subscribe to our newsletter for exclusive insights into supply chain security, automation, and compliance. Zero-day vulnerabilities aren’t slowing down. But with SBOM-driven response, your timeline doesn’t have to be measured in months. Learn how SBOMs enable organizations to react to zero-day disclosures in minutes rather than days or weeks. Watch Now ### Streamline Vulnerability Management: From Minimal Images to Comprehensive SBOM Analysis ### OpenSSF SBOM Coffee Club is exactly what you think it is For the last 7 years CISA has been one of the major public stewards of SBOMs - publishing many whitepapers, hosting a multitude of meetings, and evangelizing the term so nearly everyone in the industry now recognizes. For those of us who have been working in the SBOM community over the years, one of the best meetings was a Monday morning SBOM community call (morning if you’re in the US, not morning most everywhere else on the planet). The agenda usually started with an informal discussion about news and events and moved to a semi formal presentation about a tool or idea that was being worked on. Occasionally the discussions lasted the entire hour and the topics were always informative and interesting.   As the world of SBOMs has grown, one of the biggest challenges is just keeping track of everything; There are too many events, tools and talks and it is impossible for one person to be on top of it all. And that’s why the Monday community meeting was so useful to its attendees. Even if you weren’t trying to actively keep track of the SBOM universe, the SBOM universe would come to you!  Unfortunately the Monday community meeting has recently been discontinued. It’s tough to keep a meeting like this going, especially for many years, so hats off to CISA for all the hard work! That meeting shall be missed, but we can all respect the need to focus the existing resources to better align with the CISA mission. But given how valuable the CISA meeting has been, a few of us at the OpenSSF have decided we miss the meeting and would like to keep it going. So the OpenSSF SBOM Coffee Club has been started! Same time on Monday as the CISA meeting (11am Eastern). The format is going to be exactly the same: Show up, discuss the latest news and happenings and share interesting SBOM related events. Just like the CISA list of SBOM events, this one will be pretty flexible and only need to be vaguely SBOM related to deserve a mention. One of the often overlooked aspects of building a community are the little things that bring everyone together. I’ve been part of many communities over the years, I am honored to be part of the SBOM community now. While our community is built on top of SBOMs, that’s not enough to keep everyone connected. We need a place to discuss topics, share experiences, and talk about new things and ideas, and most importantly, let new people find us. That was the Monday SBOM call. It’s important to me and others to keep a place going that can help the existing community thrive and bring in new people in a safe and welcoming way. Everyone is welcome, it doesn’t matter if you’re not an OpenSSF member. The invite is available on the OpenSSF public calendar (it’s pretty full of events, look for “OpenSSF SBOM Coffee Club” on Monday. You are welcome to check out the notes document. This will be updated before and during the meeting each week. Even if you don’t attend you are welcome to keep track of what’s happening from the meeting notes. We’ve quite literally copied the events list from the last CISA call and we are going to keep it updated. I hope to see you at a future meeting to learn, to share and evangelize. I promise you will learn something. And if you have an idea to present, or a tool, or anything really, reach out to the group. See you next Monday! ### Meeting 2025's SBOM Compliance Deadlines: A Practical Implementation Guide 2025 has become the year of SBOM compliance deadlines. March 31st marked PCI DSS 4.0's enforcement date, requiring payment processors to maintain comprehensive inventories of all software components. Meanwhile, the EU's Cyber Resilience Act takes full effect in August 2027, but organizations selling products with digital elements in Europe must start preparing now—meaning SBOM implementation can't wait. These aren't isolated regulatory experiments—they're the latest milestones in a global trend that shows no signs of slowing. As regulatory bodies worldwide continue to steadily drive SBOM adoption, organizations face a stark choice: accept this new reality and commit to comprehensive software supply chain security, or get left behind by competitors who embrace transparency as a competitive advantage. The urgency is real, but so is the solution. Anchore Enterprise serves as the "easy button" for organizations looking to comply with both newly updated frameworks while building a foundation for whatever regulatory requirements come next. Rather than scrambling to manually catalog software components or piece together makeshift compliance solutions, organizations can automate SBOM generation and analysis across their entire container portfolio. Explore SBOM use-cases for almost any department of the enterprise and learn how to unlock enterprise value to make the most of your software supply chain. Download Now Solution Overview Anchore Enterprise is a self-hosted SBOM management solution that can be deployed across various cloud and on-premises environments. It's available as cloud images for appliance-like experiences or in container form for deployment to Kubernetes clusters. For organizations using cloud platforms, this might mean deploying on Amazon EC2, Azure VMs, or Google Compute Engine. For Kubernetes users, deployment options include hyper-scaler Kubernetes engines or on-premises Kubernetes distributions. Deployment Options: Cloud Image Deployment: Available as AMIs for AWS EC2, similar images for other cloud providers Container Deployment: Helm charts for any Kubernetes cluster (cloud or on-premises) On-Premises & Air-Gapped: Flexible architecture supports secure, disconnected environments requiring complete internal deployment Above: A typical Cloud Image-based deployment Above: A typical Container Image deployment on Amazon EKS With Anchore Enterprise deployed in your environment, you can immediately start generating SBOMs for software in your repositories by scanning container registries or uploading SBOMs directly via API, CLI and UI import mechanisms. With stored SBOMs, Anchore Enterprise provides a comprehensive view into your software contents, issuing alerts to developers or security teams on vulnerabilities or content drift. Policy-based enforcement allows you to act on vulnerabilities in content or content from unapproved sources and vendors. Searches can be performed on any metadata contained within the SBOM to enable fast response during zero day situations such as the infamous Log4j. Full details on how to deploy the solution can be found here. SBOM Generation Methods Anchore Enterprise supports two primary SBOM generation approaches that work with any container registry: Distributed Scanning: The SBOM is generated using a command line tool, AnchoreCTL (based on the Syft open source project). This tool is typically invoked in CI/CD pipelines but can also be run on developer workstations. The resulting SBOM is then uploaded to the Anchore Enterprise API for processing. This approach works regardless of your registry provider. Centralized Scanning: Anchore Enterprise retrieves container images from registries either as one-time operations or on an ongoing basis using repository or tag subscriptions. The SBOM is then generated from the retrieved image within the Anchore Enterprise deployment itself. This method supports all major container registries with appropriate authentication. For this walkthrough, we'll demonstrate centralized scanning using Amazon ECR as an example, but the same principles apply to other container registries. Connecting to Container Registries Before importing images for SBOM generation, Anchore Enterprise requires access to your container registries. The authentication method varies by registry type: For Cloud Registries: AWS ECR: IAM roles, access keys, or service account integration Azure ACR: Service principals, managed identity, or access tokens Google GCR/Artifact Registry: Service accounts or workload identity Docker Hub: Username/password or access tokens For Private Registries: Harbor, Quay, Nexus: Username/password, certificates, or token-based authentication Example: Configuring Amazon ECR Access For cloud Kubernetes deployments, Anchore Enterprise can leverage cloud-native authentication. For AWS, this might involve IAM roles presented to Kubernetes Service Accounts. Other cloud providers offer similar mechanisms (Azure managed identity, Google workload identity). With appropriate permissions configured, add your registry: $ anchorectl image stig write-profiles [--include-experimental]# For AWS ECR $ ANCHORECTL_REGISTRY_PASSWORD=awsauto anchorectl registry add \   your_account_id.dkr.ecr.region.amazonaws.com \   --username awsauto --type awsecr # For other registries, authentication varies: # Docker Hub $ anchorectl registry add docker.io --username your_username # Harbor $ anchorectl registry add your-harbor.company.com --username harbor_user # Confirm the registry has been added: $ anchorectl registry list The Anchore Enterprise UI also provides a visual interface for managing registry credentials across all supported registry types. Generating SBOMs from Container Images With registry access configured, you can begin adding container images for SBOM generation. This process is consistent regardless of your registry provider: $ anchorectl image stig write-profiles [--include-experimental]# Add images from any supported registry $ anchorectl image add registry_url/repository:tag # Examples for different registries: # AWS ECR $ anchorectl image add aws_account_id.dkr.ecr.region.amazonaws.com/repository:tag # Azure ACR   $ anchorectl image add myregistry.azurecr.io/myapp:v1.0 # Google GCR $ anchorectl image add gcr.io/my-project/myapp:v1.0 # Harbor $ anchorectl image add harbor.company.com/project/myapp:v1.0 Anchore Enterprise will download the image from your registry, unpack and analyze it, then store the comprehensive SBOM in its database. You can also add annotations during scanning for better organization: $ anchorectl image stig write-profiles [--include-experimental]$ anchorectl image add registry_url/repository:tag --annotation owner=team-alpha # Verify images have been added: $ anchorectl image list Both UI and CLI (AnchoreCTL) image analysis are described in further detail here. Inspecting Container SBOMs for Vulnerabilities Once SBOMs are stored in Anchore Enterprise, you can analyze their contents through both UI and CLI interfaces. The analysis capabilities remain consistent regardless of the source registry. With your SBOMs now stored in Anchore Enterprise, you can view the respective contents through the UI by clicking on the image digest: Next, click on the Vulnerabilities (UI) tab to see a list of vulnerabilities present in this image. From here you can toggle on/off severity or OS/non-OS CVEs. You can also download the vulnerability report for both the entire image or a particular vulnerability itself. Doing the latter will allow you to find all other images impacted by this vulnerability! You can also use the CLI tooling for this purpose, using the flag for all vulnerability types: $ anchorectl image stig write-profiles [--include-experimental]# View all vulnerabilities in an image $ anchorectl image vulnerabilities registry_url/repository:tag -t all # Export vulnerability data for further processing $ anchorectl image vulnerabilities registry_url/repository:tag -o json > vuln_report.json NOTE: You can also reference the unique digest in your CLI commands. The vulnerability data includes detailed information about affected packages, severity scores, available fixes, and impact assessments that help prioritize remediation efforts. Inspecting Container SBOMs for Additional Content You can also use the SBOM as a mechanism to inspect the image for other contents, such as files, malware or secrets: NOTE: SBOMs can be exported in either Native JSON (Syft), SPDX, or CycloneDX format. Alternatively, you can use the CLI and API (via AnchoreCTL) for inspecting your container SBOM (for vulnerabilities). To view all available content types cataloged in the SBOM, use the -a flag: $ anchorectl image stig write-profiles [--include-experimental]$ anchorectl image content aws_account_id.dkr.ecr.region.amazonaws.com/repository:tag -a To list secrets which may have been located in the image: $ anchorectl image stig write-profiles [--include-experimental]$ anchorectl image content aws_account_id.dkr.ecr.region.amazonaws.com/repository:tag -t secret_search For malware (which is available via centralized analysis) you can use: $ anchorectl image stig write-profiles [--include-experimental]$ anchorectl image content aws_account_id.dkr.ecr.region.amazonaws.com/repository:tag -t malware NOTE: SBOM content search patterns are described in further detail here. SBOM: $ anchorectl image stig write-profiles [--include-experimental]$ anchorectl image sbom aws_account_id.dkr.ecr.region.amazonaws.com/repository:tag -f NOTE: SBOMs can be exported via the UI or AnchoreCTL for external use. What's Next In Part 2 of this series, we'll explore how to leverage these SBOMs for automated compliance checking, policy enforcement, and comprehensive reporting across your entire container portfolio. We'll cover how to customize policies for your organization's specific compliance requirements and generate the reports needed for audit and governance purposes. This is Part 1 of a 2-part series on automated SBOM management. [Continue to Part 2: Compliance and Policy Management →] Learn about the role that SBOMs for the security of your organization in this white paper. Download Now ###  Accelerate & Secure: Optimizing Your Software Supply Chain with DevSecOps ### Anchore is Excited to Announce it's Inclusion in the IBM PDE Factory: An Open Source-Powered Secure Software Development Platform Powered by Anchore's Syft & Grype, IBM's Platform Development Environment Factory delivers DevSecOps-as-a-Service for federal agencies seeking operational readiness without the integration nightmare. Federal agencies are navigating a complex landscape: while DevOps has delivered on its promise of increased velocity, modern compliance frameworks like EO 14028 and continuous Authority to Operate (cATO) requirements introduce new challenges that demand sophisticated DevSecOps practices across civilian agencies and the Defense Industrial Base (DIB). For many teams, maintaining both speed and compliance requires careful orchestration of security tools, visibility platforms, and audit processes that can impact development resources. The challenge often lies in implementation complexity. Software development platforms built from disparate components that should integrate seamlessly often require significant customization work. Teams can find themselves spending valuable time on integration tasks—configuring YAML files, writing connectivity code, and troubleshooting compatibility issues—rather than focusing on mission-critical capabilities. Building and managing a standards-compliant DevSecOps platform requires specialized expertise to deliver the reliability that developers need, while compliance audit processes add operational overhead that can slow time to production. Net effect: Projects stall in glue-code purgatory long before a single security control is satisfied. IBM Federal's PDE Factory changes this equation entirely. This isn't another pick-your-own-modules starter repository—it's a fully composed DevSecOps platform you can deploy in hours, not months, with SBOM-powered supply chain security baked into every layer. Challenge: Tool Sprawl Meets Compliance Deadlines An application stack destined for federal deployment might need a vulnerability scanner, SBOM generator, signing service, policy engine, and runtime monitoring—each potentially from different vendors. Development teams burn entire sprints wiring these modules together, patching configuration files, and writing custom integration code to resolve subtle interoperability issues that surface during testing. Every integration introduces fresh risk. Versions drift between environments. APIs break without warning. Documentation assumes knowledge that exists nowhere in your organization. Meanwhile, compliance frameworks like NIST's Secure Software Development Framework (SSDF) demand comprehensive coverage across software bill of materials (SBOM) generation, continuous vulnerability management, and policy enforcement. Miss one pillar, and the entire compliance review fails. DIY Integration PainMission ImpactFragmented visibilityVulnerability scanners can't correlate with registry contents; audit trails become patchwork documentation spread across multiple systems.Context-switching overheadEngineers toggle between six different UIs and CLI tools to trace a single CVE from detection through remediation.Late-stage discoveryCritical security issues surface after artifacts are already staged for production, triggering war-room incidents that halt deployments.Compliance scrambleEvidence collection requires manual log parsing and screenshot gathering—none of it standardized, signed, or audit-ready. The US Air Force Platform One learned the lessons above early. Their container ecosystem, now secured with Anchore Enterprise, required extensive tooling integration to achieve the operational readiness standards demanded by mission-critical workloads. Similarly, Iron Bank—the DoD's hardened container repository—relies on Anchore Enterprise to maintain the security posture that defense contractors and military units depend on for operational continuity. Solution: A Pre-Wired Factory, No Yak-Shaving Required IBM Federal's PDE Factory eliminates the integration nightmare by delivering a fully composed DevSecOps platform deployable in hours rather than months. This isn't about faster setup—it's about operational readiness from day one. Architecture at a glance: GitLab CI orchestrates every build with security gates enforced at each stage Harbor registry stores signed container images with embedded SBOMs Argo CD drives GitOps-based deployments into production Kubernetes clusters Terraform automation executes the entire stack deployment with enterprise-grade reliability Syft & Grype by Anchore: comes integrated with the PDE Factory giving users SBOM-powered vulnerability scanning "out of the box" Outcome: A production-ready DevSecOps environment that supports the code-to-cloud kill chain federal agencies need, deployable in hours instead of the weeks-to-months typical of greenfield builds. Anchore Inside: The SBOM Backbone Before any container image reaches your registry, Anchore's battle-tested supply chain tools attach comprehensive security and compliance metadata that travels through your entire deployment pipeline. How the integration works: Syft performs deep software composition analysis, cataloging every component down to transitive dependencies and generating standards-compliant SBOMs Grype ingests those SBOMs and enriches them with current vulnerability data from multiple threat intelligence feeds Policy enforcement blocks non-compliant builds before they can compromise downstream systems Evidence collection happens automatically—when auditors arrive, you hand them signed JSON artifacts instead of manually compiled documentation SBOM = portable mission truth. Because SBOMs are machine-readable and cryptographically signed, PDE Factory can automate both rapid "shift-left" feedback loops and comprehensive audit trail generation. This aligns directly with CISA's Secure by Design initiative—preventing insecure builds from entering the pipeline rather than detecting problems after deployment. The US Navy's Black Pearl Factory exemplifies this approach in action. Working with Sigma Defense, they reduced audit preparation time from three days of manual evidence gathering to two minutes of automated report generation—a force multiplier that redirects valuable engineering resources from compliance overhead back to mission delivery. Day-in-the-Life: From Commit to Compliant Deploy Here's how operational readiness looks in practice: Developer commits code to GitLab, triggering the automated security pipeline Container build includes Syft SBOM generation and cryptographic signing Grype vulnerability scanning correlates SBOM components against current threat data Policy gates enforce NIST SSDF requirements before allowing registry promotion Argo CD deployment validates runtime security posture against DoD standards Kubernetes admission controller performs final compliance verification using stored SBOM and vulnerability data Result: A hardened deployment pipeline that maintains operational readiness without sacrificing development velocity. For agencies requiring enhanced security posture, upgrading to Anchore Enterprise unlocks Compliance-as-a-Service capabilities: Open Source FoundationAnchore Enterprise UpgradeOperational AdvantageSyft & GrypeAnchore Secure with centralized vulnerability managementHours saved on manual CVE triage and false positive eliminationBasic policy enforcementAnchore Enforce with pre-built SSDF, DISA, and NIST policy packsAccelerated ATO timelines through automated compliance validationManual evidence collectionAutomated audit trail generationWeeks removed from compliance preparation cycles Operational Payoff: Mission Metrics That Matter Capability MetricDIY Integration ApproachIBM PDE FactoryPlatform deployment time45-120 days< 8 hoursSecurity rework percentage per sprint~20%< 5%Critical vulnerability MTTR~4 hours< 1 hourAudit preparation effortWeeks of manual workAutomated nightly exports This isn't just about developer productivity—it's about mission continuity. When federal agencies can deploy secure software faster and maintain compliance posture without operational overhead, they can focus resources on capabilities that directly serve citizens and national security objectives. Your Operational Readiness Path Forward Federal agencies have an opportunity to streamline their development processes by adopting proven infrastructure that the DoD already trusts. IBM Federal's PDE Factory, powered by Anchore's SBOM-first approach, delivers the operational readiness federal agencies need while reducing the integration complexity that often challenges DevSecOps initiatives. Start with the open source foundation—Syft and Grype provide immediate value. Scale to Anchore Enterprise when you need Compliance-as-a-Service capabilities that accelerate your Authority to Operate timeline. Ready to see proven DoD software factory security in action? Anchore brings deep expertise in securing mission-critical software factories across the Department of Defense, from Platform One to Iron Bank to the Navy's Black Pearl Factory. Our battle-tested SBOM-powered approach has enabled DoD organizations to achieve operational readiness while maintaining the security standards required for defense environments. Book an Anchore Enterprise demo to see how our proven software supply chain security integrates with IBM's PDE Factory to deliver "no SBOM, no deploy" enforcement without compromising development velocity. Fortify your pipeline. Harden your releases. Accelerate your operational readiness. The mission demands secure software. Your developers deserve tools that deliver it. Learn how to harden your containers and make them "STIG-Ready" with our definitive guide. Download Now ### Container Drift, Base Images, & CMMC: Solving Public Sector Security Challenges ### From Cost Center to Revenue Driver: How Compliance Became Security's Best Friend An exclusive look at insights from the ITGRC Forum's latest webinar on demonstrating the value of cybersecurity investments. Three cybersecurity veterans with a combined 80+ years of experience recently gathered for a Forum webinar that challenged everything we thought we knew about the funding of enterprise security investments.  Colin Whitaker (30+ years, Informed Risk Decisions),  Paulo Amarol (Senior Director GRC, Diligent),  Dirk Shrader (25+ years, Netwrix), and  Josh Bressers (VP Security, Anchore) delivered insights that explain why some organizations effortlessly secure millions for security initiatives while others struggle for basic tool budgets. The central revelation? Compliance isn't just regulatory burden—it's become the primary pathway for security investment in modern enterprises. The 75-minute discussion covered critical territory for any security or GRC professional trying to demonstrate value to leadership: When Compliance Became the Gateway to Security Investment: How regulatory requirements transformed from cost centers to business enablers The Software Supply Chain Compliance Revolution: Why SBOM mandates are forcing visibility that security teams have wanted for decades Death by a Thousand Cuts: The Hidden Costs of Fragmented Compliance: The true operational impact of manual compliance processes The Future of Compliance-Driven Security Investment: Where emerging regulations are heading and how to get ahead 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 the relationship between cybersecurity and regulatory compliance. ⏱️ Can't wait till the end?📥 Watch the full webinar now 👇👇👇 Watch Now When Compliance Became the Gateway to Security Investment For decades, security professionals have faced an uphill battle for executive attention and funding. While IT budgets grew and development teams expanded, security often fought for scraps—forced to justify theoretical risks against concrete revenue opportunities. Traditional security arguments relied on preventing abstract future threats. Leadership heard endless presentations about potential breaches, theoretical vulnerabilities, and statistical possibilities. When the business is deciding between allocating resources toward revenue-generating features that will generate an ROI in months versus product security features that will reduce—BUT never eliminate—the possibility of a breach; it's not difficult to figure out how we got into this situation. Meanwhile, regulatory compliance offered something security never could: immediate business necessity. Modern compliance frameworks (e.g., EU CRA, DORA, NIS2) invert this narrative by making penalties certain, quantifiable, and time-sensitive. Annual non-compliance penalties and the threat of losing access to sell into European markets shift the story from "possible future breach" to "definite revenue loss." "I think now that there's regulators saying you have to do this stuff or you can't sell your product here now we have business incentive right because just from a purely practical perspective if a business can't sell into one of the largest markets on the planet that has enormous consequences for the business."—Josh Bressers, VP of Security, Anchore Not only does modern regulatory compliance create the "financial teeth" needed to align business incentives but it has also evolved the security requirements to be at parity with current DevSecOps best practices. The days of laughable security controls and checkbox compliance are past. Modern laws are now delivering on the promise of "Trust, but verify." The Strategic Partnership Opportunity These two fundamental changes—business-aligned incentives and technically sound requirements—create an unprecedented opportunity for security and compliance teams to partner in reducing organizational risk. Rather than working in silos with competing priorities, both functions can now pursue shared objectives that directly support business goals. Security teams gain access to executive attention and budget allocation through compliance mandates. Compliance teams benefit from security expertise and automation capabilities that reduce manual audit overhead. Together, they can implement comprehensive risk management programs that satisfy regulatory requirements while building genuine security capabilities. The result transforms both functions from cost centers into strategic business enablers—compliance ensures market access while security protects the operations that generate revenue. "However when security and compliance work together now security has a story they can start to tell that gets you the funding you need that get you the support you need from your leadership."—Josh Bressers, VP of Security, Anchore What Else You'll Discover in the Full Webinar This transformation in security funding represents just one thread in a comprehensive discussion that tackles the most pressing challenges facing security and GRC professionals today. The Software Supply Chain Compliance Revolution Josh Bressers reveals why organizations with proper SBOM capabilities identified Log4j vulnerabilities in 10 minutes while others needed 3 months—and how compliance mandates are finally forcing the software supply chain visibility security teams have wanted for decades. "Between 70-90% of all code is open source [and] … 95% of products have open source inside of them. The numbers are just absolutely staggering."—Josh Bressers, VP of Security, Anchore Death by a Thousand Cuts: The Hidden Costs of Fragmented Compliance Dirk Shrader breaks down the operational disruption costs that 54% of organizations recognize but haven't calculated, including the "mangled effort" of manual compliance processes that diverts skilled staff from strategic initiatives. "Security and IT teams spend excessive time pulling data from disparate systems: correlating activities, generating audit reports … chasing that individual rabbit."—Dirk Shrader, Global VP Security Research, Netwrix The Future of Compliance-Driven Security Investment Paulo Amarol demonstrates how GRC platforms are evolving from "evidence lockers" into strategic business intelligence systems that translate technical security data into executive-ready risk assessments. "We're able to slice and combine data from various sources—apps, operational security tooling, awareness training, even identity provider data—in ways that our leaders can bring this risk data into their decision-making. You can really automate the process of bringing data in, normalizing it, and mapping it to bigger picture strategic risks."—Paulo Amarol, Senior Director GRC, Diligent Corporation The panelists also explore: Poll insights revealing where most organizations stand on compliance cost calculations Regulatory proliferation across global markets and how to find common ground Automation imperatives for continuous compliance monitoring Cultural transformation as security and GRC functions converge Implementation strategies for aligning security programs with business objectives Ready to Transform Your Security Investment Strategy? This isn't another theoretical discussion about security ROI. It's a practical guide from practitioners who've solved the funding challenge by repositioning security as a compliance-driven business enabler. Watch the full ITGRC Forum webinar on-demand to access all 75 minutes of expert insights, poll results, and audience Q&A. Stay ahead of the compliance-security convergence: Follow Anchore on LinkedIn and Bluesky for ongoing analysis of emerging regulations, industry trends, and practical implementation guidance from software supply chain security experts. Subscribe to our newsletter for exclusive insights on SBOM requirements, compliance automation, and the strategic intersection of security and regulatory requirements. The convergence of security and compliance isn't just happening—it's accelerating. Don't get left behind. Explore SBOM use-cases for almost any department of the enterprise and learn how to unlock enterprise value to make the most of your software supply chain. Download Now ### Beyond Compliance: Neil Levine Reveals How Anchore is Revolutionizing SBOM Management ### Carahsoft DevSecOps Conference ### Beyond Software Dependencies: The Data Supply Chain Security Challenge of AI-Native Applications Just as the open source software revolution fundamentally transformed software development in the 2000s—bringing massive productivity gains alongside unprecedented supply chain complexity—we're witnessing history repeat itself with Large Language Models (LLMs). The same pattern that caused organizations to lose visibility into their software dependencies is now playing out with LLMs, creating an entirely new category of supply chain risk. Not to worry though, The Linux Foundation has been preparing for this eventuality. SPDX 3.0 provides the foundational metadata standard needed to extend proven DevSecOps practices to applications that integrate LLMs.  By introducing AI and Dataset Profiles, it enables organizations to apply the same supply chain security practices that have proven effective for software dependencies to the emerging world of AI supply chains. History may be repeating itself but this time, we have the opportunity to get ahead of it. LLMs Create New Supply Chain Vulnerabilities That Traditional Security Tools Can't Grok The integration of LLMs into software applications has fundamentally altered the threat landscape. Unlike traditional software vulnerabilities that exploit code weaknesses, LLM-era attacks target the unique characteristics of AI systems:  their training data is both data and code, and their behavior (i.e., both data and code) can be manipulated by users. This represents a paradigm shift that requires security teams to think beyond traditional application security. LLMs merge data and code + a second supply chain to secure LLMs are fundamentally different from traditional software components. Where conventional code follows deterministic logic paths. LLMs operate on statistical patterns learned from "training" on datasets. This fundamental difference creates a new category of "code" that needs to be secured—not just the model weights and architecture, but the training data, fine-tuning datasets, and even the prompts that guide model behavior. When organizations integrate LLMs into their applications, they're not just adding another software dependency. They're creating an entire second supply chain—the LLM data supply chain—that operates alongside their traditional software supply chain.  The challenge is that this new supply chain operates with fundamentally different risk patterns. Where software vulnerabilities are typically discrete and patchable, AI risks can be subtle, emergent, and difficult to detect.  A single compromised dataset can introduce bias that affects all downstream applications.  A prompt injection attack can manipulate model behavior without touching any traditional code.  Model theft can occur through API interactions that leave no trace in traditional security logs. Data poisoning and model theft: Novel attack vectors The emergence of LLMs has introduced attack vectors that simply didn't exist in traditional software systems, requiring security teams to expand their threat models and defensive strategies. Data Poisoning Attacks represent one of the most intractable new threat categories. Training data manipulation can occur at multiple points in the AI supply chain.Consider this: what's stopping a threat actor from modifying a public dataset that's regularly used to train foundational LLM models? Popular datasets hosted on platforms like Hugging Face or GitHub can be edited by contributors, and if these poisoned datasets are used in model training, the resulting models inherit the malicious behavior.RAG poisoning attacks take this concept further by targeting the retrieval systems that many production LLM applications rely on. Attackers can create SEO-optimized content and embed hidden text with instructions designed to manipulate the model's behavior.When RAG systems retrieve this content as context for user queries, the hidden instructions can override the model's original alignment, leading to unauthorized actions or information disclosure. Recent research has demonstrated that attackers can inject as few as five poisoned documents into datasets of millions and achieve over 90% success rates in manipulating model outputs. Model Theft and Extraction attacks exploit the API-accessible nature of modern LLM deployments. Through carefully crafted queries, attackers can extract valuable intellectual property without ever accessing the underlying model files. API-based extraction attacks involve sending thousands of strategically chosen prompts to a target model and using the responses to train a "shadow model" that replicates much of the original's functionality.Self-instruct model replication takes this further by using the target model to generate synthetic training data, effectively teaching a competitor model to mimic the original's capabilities. These attacks create new categories of business risk that organizations must consider. Beyond traditional concerns about data breaches or system availability, LLM-integrated applications face risks of intellectual property theft, reputational damage from biased or inappropriate outputs, and regulatory compliance violations in increasingly complex AI governance environments. Enterprises are losing supply chain visibility as AI-native applications grow Organizations are mostly unaware of the fact that the data supply chain for LLMs is equally as important to track as their software supply chain. As teams integrate foundation model APIs, deploy RAG systems, and fine-tune models for specific use cases, the complexity of LLM data supply chains is exploding.  Traditional security tools that excel at scanning software dependencies for known vulnerabilities are blind to LLM-specific risks like bias, data provenance, or model licensing complications. This growing attack surface extends far beyond what traditional application security can address. When a software component has a vulnerability, it can typically be patched or replaced. When an AI model exhibits bias or has been trained on problematic data, the remediation may require retraining, which can cost millions of dollars and months of time. The stakes are fundamentally different, and the traditional reactive approach to security simply doesn't scale. So how do we deal with this fundamental shift in how we secure supply chains? Next-Gen SBOM Formats Extend Proven Supply Chain Security to AI-Native Applications The answer is—unsurprisingly—SBOMs. But more specifically, next-generation SBOM formats like SPDX 3.0. While Anchore doesn't have an official tagline, if we did, there's a strong chance it would be "you can't secure your supply chain without knowing what is in it." SPDX 3.0 has updated the SBOM standard to store AI model and dataset metadata, extending the proven principles of software supply chain security to the world of LLMs. AI Bill of Materials: machine-readable security metadata for LLMs SPDX 3.0 introduces AI and Dataset Profiles that create machine-readable metadata for LLM system components. These profiles provide comprehensive tracking of models, datasets, and their relationships, creating what's essentially an "LLM Bill of Materials" that documents every component in an AI-powered application. The breakthrough is that SPDX 3.0 increases visibility into AI systems by defining the key AI model metadata—read: security signals—that are needed to track risk and define enterprise-specific security policies. This isn't just documentation for documentation's sake; it's about creating structured data that existing DevSecOps infrastructure can consume and act upon.  The bonus is that this works with existing tooling: SBOMs, CI/CD pipelines, vulnerability scanners, and policy-as-code evaluation engines can all be extended to handle AI profile metadata without requiring organizations to rebuild their security infrastructure from scratch. Learn about how SBOMs have adapted to the world of micro-services architecture with the co-founder of SPDX and SBOMs. Watch Now 3 novel security use-cases for AI-native apps enabled by SPDX 3.0 Bias Detection & Policy Enforcement becomes automated through the knownBias field, which allows organizations to scan AI BOMs for enterprise-defined bias policies just like they scan software SBOMs for vulnerable components.Traditional vulnerability scanners can be enhanced to flag models or datasets that contain documented biases that violate organizational policies. Policy-as-code frameworks can enforce bias thresholds automatically, preventing deployment of AI systems that don't meet enterprise standards. Risk-Based Deployment Gates leverage the safetyRiskAssessment field, which follows EU risk assessment methodology to categorize AI systems as serious, high, medium, or low risk.This enables automated risk scoring in CI/CD pipelines, where deployment gates can block high-risk models from reaching production or require additional approvals based on risk levels. Organizations can set policy thresholds that align with their risk tolerance and regulatory requirements. Data Provenance Validation uses fields like dataCollectionProcess and suppliedBy to track the complete lineage of training data and models. This enables allowlist and blocklist enforcement for data sources, ensuring that models are only trained on approved datasets.Supply chain integrity verification becomes possible by tracking the complete chain of custody for AI components, from original data collection through model training and deployment. An SPDX 3.0 SBOM hierarchy for an AI-native application might look like this: The key insight is that SPDX 3.0 makes AI systems legible to existing DevSecOps infrastructure. Rather than requiring organizations to build parallel security processes for AI workflows and components, it extends current security investments to cover the new AI supply chain. This approach reduces adoption friction by leveraging familiar tooling and processes that security teams already understand and trust. History Repeats Itself: The Supply Chain Security Story This isn't the first time we've been through a transition where software development evolution increases productivity while also creating supply chain opacity. The pattern we're seeing with LLM data supply chains is remarkably similar to what happened with the open source software explosion of the 2000s. Software supply chains evolution: From trusted vendors to open source complexity to automated security Phase 1: The Trusted World (Pre-2000s) was characterized by 1st-party code and trusted commercial vendors. Organizations primarily wrote their own software or purchased it from established vendors with clear support relationships.Manual security reviews were feasible because dependency trees were small and well-understood. There was high visibility into what components were being used and controlled dependencies that could be thoroughly vetted. Phase 2: Open Source Software Explosion (2000s-2010s) brought massive productivity gains from open source libraries and frameworks. Package managers like npm, Maven, and PyPI made it trivial to incorporate thousands of 3rd-party components into applications.Dependency trees exploded from dozens to thousands of components, creating a visibility crisis where organizations could no longer answer the basic question: "What's actually in my application?"This led to major security incidents like the Equifax breach (Apache Struts vulnerability), the SolarWinds supply chain attack, and the event-stream npm package compromise that affected millions of applications. Phase 3: Industry Response (2010s-2020s) emerged as the security industry developed solutions to restore visibility and control.SBOM standards like SPDX and CycloneDX provided standardized ways to document software components. Software Composition Analysis (SCA) tools proliferated, offering automated scanning and vulnerability detection for open source dependencies. DevSecOps integration and "shift-left" security practices made supply chain security a standard part of the development workflow. LLM supply chains evolution: Same same—just faster We're now seeing this exact pattern repeat with AI systems, just compressed into a much shorter timeframe. Phase 1: Model Gardens (2020-2023) featured trusted foundation models from established providers like OpenAI, Google, and Anthropic. LLM-powered application architectures were relatively simple, with limited data sources and clear model provenance.Manual AI safety reviews were feasible because the number of models and data sources was manageable. Organizations could maintain visibility into their AI components through manual processes and documentation. Phase 2: LLM/RAG Explosion (2023-Present) has brought foundation model APIs that enable massive productivity gains for AI application development.Complex AI supply chains now feature transitive dependencies where models are fine-tuned on other models, RAG systems pull data from multiple sources, and agent frameworks orchestrate multiple AI components.We're currently re-living the same but different visibility crisis where organizations have lost the ability to understand the supply chains that power their production systems. Emerging attacks like data poisoning, and model theft are targeting these complex supply chains with increasing sophistication. Phase 3: Industry Response (Near Future) is just beginning to emerge. SBOM standards like SPDX 3.0 are leading the charge to re-enable supply chain transparency for LLM supply chains constructed from both code and data. AI-native security tools are starting to appear, and we're seeing the first extensions of DevSecOps principles to AI systems. Where do we go from here? We are still in the early stages of new software supply chain evolution, which creates both risk and opportunity for enterprises. Those who act now can establish LLM data supply chain security practices before the major attacks hit, while those who wait will likely face the same painful lessons that organizations experienced during the software supply chain security crisis of the 2010s. Crawl: Embed SBOMs into your current DevSecOps pipeline A vital first step is making sure you have a mature SBOM initiative for your traditional software supply chains. You won't be ready for the future transition to LLM supply chains without this base. This market is mature and relatively lightweight to deploy. It will power software supply chain security or up-level current software supply chain security (SSCS) practices. Organizations that have already invested in SBOM tooling and processes will find it much easier to extend these capabilities to an AI-native world. Walk: Experiment with SPDX 3.0 and system bills of materials Early adopters who want to over-achieve can take several concrete steps: Upgrade to SPDX 3.0 and begin experimenting with the AI and Dataset Profiles. Even if you're not ready for full production deployment, understanding the new metadata fields and how they map to your LLM system components will prepare you for the tooling that's coming. Begin testing AI model metadata collection by documenting the models, datasets, and AI components currently in use across your organization. This inventory process will reveal gaps in visibility and help identify which components pose the highest risk. Insert AI metadata into SBOMs for applications that already integrate AI components. This creates a unified view of both software and LLM dependencies, enabling security teams to assess risk across the entire application stack. Explore trends and patterns to extract insights from your LLM component inventory. Look for patterns in data sources, model licensing, risk levels, and update frequencies that can inform policy development. This process will eventually evolve into a full production LLM data supply chain security capability that will power AI model security at scale. Organizations that begin this journey now will have significant advantages as AI supply chain attacks become more sophisticated and regulatory requirements continue to expand. The window of opportunity is open, but it won't remain that way indefinitely. Just as organizations that ignored software supply chain security in the 2000s paid a heavy price in the 2010s, those who ignore AI supply chain security today will likely face significant challenges as AI attacks mature and regulatory pressure increases. Follow us on LinkedIn or subscribe to our newsletter to stay up-to-date on progress. We will continue to update as this space evolves, sharing practical guidance and real-world experiences as organizations begin implementing LLM data supply chain security at scale. Explore SBOM use-cases for almost any department of the enterprise and learn how to unlock enterprise value to make the most of your software supply chain. Download Now ### Enhancing Security in Cloud-Native Environments with Anchore’s Alex Rybak and Neil Levine ### Anchore Enterprise 5.19: Automated STIG Compliance and Flexible Scanning for Modern DevSecOps The latest release of Anchore Enterprise 5.19 features two major enhancements that address critical needs in government, defense, and enterprise environments: Anchore STIG for Container Images, and  Anchore One-Time Scan.  Anchore STIG for Container Images automates the process of running a STIG evaluation against a container image to shift compliance “left”. By embedding STIG validation directly into the CI/CD pipeline as automated policy-as-code rules, compliance violations are detected early, reducing the time to reach compliance in production. Anchore One-Time Scan is a new API which is optimized for scanning in CI/CD by removing the persistence requirement for storing the SBOM. Now security and software engineers can get stateless scanning, comprehensive vulnerability assessment and policy evaluation through a single CLI command or API call. These new features bring automated compliance validation and flexible scanning options directly into your DevSecOps workflows, enabling organizations to maintain security standards without sacrificing development velocity. Anchore STIG for Container Images: Compliance Automation at Scale Before we jump into the technical details, it's important to understand the compliance challenges that government and defense organizations face daily. Security Technical Implementation Guides (STIGs) represent the gold standard for cybersecurity hardening in federal environments, providing detailed configuration requirements that systems must meet to operate securely. However, traditional STIG compliance has been a largely manual process—time-consuming, error-prone, and difficult to integrate into automated CI/CD pipelines. What is STIG and Why It Matters STIGs are cybersecurity best practices developed by the Defense Information Systems Agency (DISA) that focus on proactive system configuration and hardening. The challenge for modern development teams is that STIG evaluations have traditionally required manual assessment and configuration validation, creating bottlenecks in deployment pipelines and increasing the risk of non-compliant systems reaching production. For organizations pursuing FedRAMP authorization or operating under federal compliance mandates, this manual overhead can significantly slow development cycles while still leaving room for human error. For a real-world example of how STIG compliance challenges are being solved at scale, check out our Cisco Umbrella case study, which details how Cisco uses Anchore Enterprise with STIG for Container Images on their AWS EC2 base images. Learn how to harden your containers and make them "STIG-Ready" with our definitive guide. Download Now Why Adopt Anchore STIG for Container Images? Anchore STIG for Container Images delivers immediate value across multiple organizational levels:  Development teams gain access to “STIG Ready” base images Security teams can access STIG evaluation documents in a single location The automated approach eliminates the manual audit overhead that traditionally slows compliance workflows, while the policy gate integration prevents images which are not evaluated from reaching production. This proactive compliance model significantly reduces the risk of security violations and streamlines the path to regulatory compliance authorizations such as FedRAMP or DoD ATO. How Anchore STIG for Container Images Works Anchore STIG for Container Images automates the entire STIG evaluation process through seamless integration with Cinc (i.e., open source Chef IaC system) and AnchoreCTL orchestration. The solution provides a four-step workflow that transforms manual compliance checking into an automated pipeline component: Install Cinc on your scanning host alongside AnchoreCTL Extract supported STIG profiles $ anchorectl image stig write-profiles [--include-experimental]$ anchorectl image stig write-profiles [--include-experimental] Execute STIG checks using specific profiles through AnchoreCTL commands $ anchorectl image stig run \ --stig-profile .//ubi8/anchore-ubi8-disa-stig-1.0.0.tar.gz$ anchorectl image stig run \ --stig-profile .//ubi8/anchore-ubi8-disa-stig-1.0.0.tar.gz Upload results directly to Anchore Enterprise for centralized management and reporting The add-on supports comprehensive profiles for RHEL 8/9 and Ubuntu 22.04/24.04, with tech preview profiles available for critical applications including:  PostgreSQL Apache Tomcat MongoDB Enterprise Java Runtime Environment New API endpoints provide full programmatic access to STIG evaluations, while the integrated policy gate ensures that only compliant images can progress through your deployment pipeline. The screenshot below shows an example gate that can evaluate whether a STIG evaluation exists for a container and if the age of the evaluation is older than a specified number of days. Anchore Enterprise One-Time Scan: Lightweight Security for Agile Workflows Not every security scanning scenario requires persistent data storage in your Anchore Enterprise deployment. Modern DevSecOps teams often need quick vulnerability assessments for third-party images, temporary validation in CI/CD pipelines, or rapid security triage during incident response. Traditional scanning approaches that persist all data can create unnecessary overhead for these ephemeral use-cases. CI/CD pipeline flexibility is particularly important for organizations operating at scale, where resource optimization and scanning speed directly impact development velocity. Teams need the ability to perform comprehensive security evaluation without the infrastructure overhead of full data persistence, especially when assessing external images or performing one-off security validations. Why and Where to Utilize the One-Time Scan Feature One-Time Scan significantly reduces scanning overhead by eliminating the storage and processing requirements associated with persistent image data. This approach is particularly valuable for organizations scanning large numbers of ephemeral workloads or performing frequent one-off assessments. Primary Use Cases: CI/CD Pipeline Validation: Quick security checks for ephemeral build environments Third-Party Image Assessment: Evaluate external images without adding them to your inventory Incident Response: Rapid vulnerability assessment during security investigations Compliance Verification: Policy evaluation for images that don't require long-term tracking The stateless operation of One Time Scan provides faster scanning results for time-sensitive workflows, while the new stateless_sbom_evaluation metric enables teams to track usage patterns and optimize their scanning strategies. This flexibility supports diverse operational requirements without compromising security analysis quality. How One Time Scan Works Anchore Enterprise's One Time Scan feature introduces a stateless scanning capability that delivers comprehensive vulnerability assessment and policy evaluation without persisting data in your Anchore Enterprise deployment. The feature provides a single API endpoint (POST /v2/scan) that accepts image references and returns complete security analysis results in real-time. The stateless operation includes full policy evaluation against your active policy bundles, specifically leveraging Anchore Secure's gates for vulnerabilities and secret scans. This ensures that even temporary scans benefit from your organization's established security policies and risk thresholds.  For CLI-based workflows, the new AnchoreCTL command anchorectl image one-time-scan provides immediate access to stateless scanning capabilities. $ anchorectl image one-time-scan python:latest --from registry ✔ Completed one time scan python:latest Tag: python:latest Digest: sha256:238379aacf40f83bfec1aa261924a463a91564b85fbbb97c9a96d44dc23bebe7 Policy ID: anchore_secure_default Last Evaluation: 2025-07-08T14:29:47Z Evaluation: pass Final Action: warn Reason: policy_evaluation Policy Evaluation Details: ┌─────────────────┬─────────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┬────────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ GATE │ TRIGGER │ DESCRIPTION │ ACTION │ RECOMMENDATION │ ├─────────────────┼─────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ │ vulnerabilities │ package │ HIGH Vulnerability found in os package type (dpkg) - libdjvulibre-text-3.5.28-2 (fixed in: 3.5.28-2.1~deb12u1)(CVE-2025-53367 - https://security-tracker.debian.org/tracker/CVE-2025-53367) │ warn │ Packages with low, medium, and high vulnerabilities present can be upgraded to resolve these findings. If upgrading is not possible the finding should be added to an allowlist. │ │ vulnerabilities │ package │ HIGH Vulnerability found in os package type (dpkg) - libdjvulibre21-3.5.28-2+b1 (fixed in: 3.5.28-2.1~deb12u1)(CVE-2025-53367 - https://security-tracker.debian.org/tracker/CVE-2025-53367) │ warn │ Packages with low, medium, and high vulnerabilities present can be upgraded to resolve these findings. If upgrading is not possible the finding should be added to an allowlist. │ │ vulnerabilities │ package │ MEDIUM Vulnerability found in non-os package type (binary) - /usr/local/bin/python3.13 (fixed in: 3.14.0b3)(CVE-2025-6069 - https://nvd.nist.gov/vuln/detail/CVE-2025-6069) │ warn │ Packages with low, medium, and high vulnerabilities present can be upgraded to resolve these findings. If upgrading is not possible the finding should be added to an allowlist. │ │ vulnerabilities │ package │ HIGH Vulnerability found in os package type (dpkg) - libdjvulibre-dev-3.5.28-2+b1 (fixed in: 3.5.28-2.1~deb12u1)(CVE-2025-53367 - https://security-tracker.debian.org/tracker/CVE-2025-53367) │ warn │ Packages with low, medium, and high vulnerabilities present can be upgraded to resolve these findings. If upgrading is not possible the finding should be added to an allowlist. │ └─────────────────┴─────────┴───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┴────────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘$ anchorectl image one-time-scan python:latest --from registry ✔ Completed one time scan python:latest Tag: python:latest Digest: sha256:238379aacf40f83bfec1aa261924a463a91564b85fbbb97c9a96d44dc23bebe7 Policy ID: anchore_secure_default Last Evaluation: 2025-07-08T14:29:47Z Evaluation: pass Final Action: warn Reason: policy_evaluation Policy Evaluation Details: ┌─────────────────┬─────────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┬────────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ GATE │ TRIGGER │ DESCRIPTION │ ACTION │ RECOMMENDATION │ ├─────────────────┼─────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ │ vulnerabilities │ package │ HIGH Vulnerability found in os package type (dpkg) - libdjvulibre-text-3.5.28-2 (fixed in: 3.5.28-2.1~deb12u1)(CVE-2025-53367 - https://security-tracker.debian.org/tracker/CVE-2025-53367) │ warn │ Packages with low, medium, and high vulnerabilities present can be upgraded to resolve these findings. If upgrading is not possible the finding should be added to an allowlist. │ │ vulnerabilities │ package │ HIGH Vulnerability found in os package type (dpkg) - libdjvulibre21-3.5.28-2+b1 (fixed in: 3.5.28-2.1~deb12u1)(CVE-2025-53367 - https://security-tracker.debian.org/tracker/CVE-2025-53367) │ warn │ Packages with low, medium, and high vulnerabilities present can be upgraded to resolve these findings. If upgrading is not possible the finding should be added to an allowlist. │ │ vulnerabilities │ package │ MEDIUM Vulnerability found in non-os package type (binary) - /usr/local/bin/python3.13 (fixed in: 3.14.0b3)(CVE-2025-6069 - https://nvd.nist.gov/vuln/detail/CVE-2025-6069) │ warn │ Packages with low, medium, and high vulnerabilities present can be upgraded to resolve these findings. If upgrading is not possible the finding should be added to an allowlist. │ │ vulnerabilities │ package │ HIGH Vulnerability found in os package type (dpkg) - libdjvulibre-dev-3.5.28-2+b1 (fixed in: 3.5.28-2.1~deb12u1)(CVE-2025-53367 - https://security-tracker.debian.org/tracker/CVE-2025-53367) │ warn │ Packages with low, medium, and high vulnerabilities present can be upgraded to resolve these findings. If upgrading is not possible the finding should be added to an allowlist. │ └─────────────────┴─────────┴───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┴────────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ Upgrade to Anchore Enterprise 5.19 Anchore Enterprise 5.19 represents a significant advancement in container security automation, delivering the compliance capabilities and scanning flexibility that modern organizations require. The combination of automated STIG compliance and stateless scanning options enables teams to maintain rigorous security standards without creating a drag on development velocity. Whether you're pursuing FedRAMP authorization, managing compliance requirements in government environments, or simply need more flexible scanning options for your DevSecOps workflows, these new capabilities provide the foundation for scalable, automated container security. Ready to upgrade? Existing customers should reach out to their account manager to access Anchore Enterprise 5.19 and begin leveraging these new capabilities.  For technical implementation guidance and detailed configuration instructions, visit our documentation site. New to Anchore? Start with our 15-day free trial or request a guided demo to see these features in action. Save your developers time with Anchore Enterprise. Get instant access with a 15-day free trial. START FREE TRIAL ### Anchore Achieves AWS Security Competency & Launches Anchore Enterprise AMI We are excited to announce two significant milestones that further strengthen our partnership with Amazon Web Services (AWS): Anchore has achieved AWS Security Competency in Application Security — SBOM Use-case Anchore Enterprise AWS Machine Image (AMI) is now available for streamlined deployment These announcements represent another major step in Anchore and AWS's deepening collaboration to help Fortune 2000 enterprises, federal agencies, and defense contractors secure their software supply chains. AWS Security Competency: SBOM Leadership Validation The AWS Security Competency validates what Anchore customers have known for many years — Anchore is ready to provide SBOM management, container security and automated compliance enforcement to Fortune 2000 enterprises, federal agencies, and defense contractors who require a bullet-proof software supply chain. This competency represents technical validation of Anchore's SBOM-powered security capabilities through a rigorous AWS assessment of our solution architecture and customer success stories. AWS evaluated our platform's ability to deliver comprehensive software supply chain transparency, vulnerability management, and automated compliance enforcement at enterprise scale. Real-world validation comes from customers like: Cisco Umbrella leveraged Anchore's SBOM-powered container security to accelerate meeting all six FedRAMP requirements. They deployed Anchore into a high-security environment that had to meet stringent compliance standards, including STIG compliance for Amazon EC2 nodes backing their Amazon EKS deployment. DoD Iron Bank adopted Anchore for SBOM-powered container security and DoD software factory compliance, validating our platform's ability to meet the most demanding security requirements in government and defense environments. For decision makers, the AWS Security Competency provides confidence in solution reliability and seamless AWS integration. It streamlines procurement through verified partner status and ensures enhanced support through our strengthened AWS partnership. Anchore Enterprise Cloud Image: Simplifying Deployment with an AWS AMI The Anchore Enterprise Cloud Image represents a pre-built, virtual appliance deployment option that serves as an alternative to the popular Kubernetes Helm chart deployments for use-cases that require a lightweight, batteries-included integration. This isn't about reducing features—it's about eliminating complexity where Kubernetes expertise isn't readily available or necessary. Technical advantages include: Dramatically reduced deployment complexity through a ready-to-run Amazon Machine Image (AMI) that eliminates the need for a PhD in Kubernetes. The AMI delivers optimized performance on select AWS instance types, with deterministic performance guidelines for better capacity planning and cost management. Anchore's interactive Cloud Image Manager provides guided setup that intelligently assesses your AWS environment, ensures correct resource provisioning, and automates installation with appropriate configurations. Integrated compliance policy packs for NIST, SSDF and FedRAMP frameworks ensure your container security posture aligns with regulatory requirements from day one. Business benefits that matter to leadership: Faster time-to-value for container security initiatives means your teams can focus on securing containers rather than managing infrastructure. Reduced operational overhead frees up resources for strategic security initiatives rather than deployment troubleshooting. This prescriptive solution is ideal for teams without extensive Kubernetes expertise, proof-of-concept deployments, and smaller-scale implementations that need enterprise-grade security without enterprise-level complexity. Strengthening Our AWS Partnership for Customer Success These milestones build on our growing AWS collaboration, including our AWS Marketplace availability and ISV Accelerate Program membership. This represents our broader commitment to enterprise and public sector customers who rely on AWS infrastructure for their most critical applications. The joint value proposition is clear: seamless AWS infrastructure integration combined with enhanced support through our combined AWS and Anchore expertise. We're addressing the full spectrum of deployment preferences, whether you need the scale-out capabilities of EKS or the simplified deployment of our EC2 AMI option. This partnership strengthening directly benefits our mutual customers through validated integration patterns, streamlined support channels, and deployment flexibility that matches your team's expertise and requirements. Moving Forward Together The combination of AWS Security Competency validation and simplified AMI deployment options demonstrates our commitment to comprehensive support for enterprise and government security requirements. These milestones strengthen our partnership and enable customer success at scale, whether you're securing containers for a commercial enterprise or meeting compliance requirements for federal agencies. Our deepening AWS partnership ensures you have the deployment flexibility, validated security capabilities, and enterprise support needed to secure your software supply chain with confidence. Ready to get started? For AMI deployment: Contact our sales team for Cloud Image deployment consultation tailored to your AWS environment For general inquiries: Connect with our team to discuss how AWS Security Competency benefits and deployment options can accelerate your software supply chain security initiatives Save your developers time with Anchore Enterprise. Get instant access with a 15-day free trial. START FREE TRIAL ### Time to Take Another Look at Grype: A Year of Major Improvements If you last tried Grype a year ago and haven't checked back recently, you're in for some pleasant surprises. The past twelve months have significantly improved the accuracy and performance of our open source vulnerability scanner. Whether you're dealing with false positives, slow database updates, or wanting deeper insights into your vulnerability data, Grype has evolved considerably. Let's dive into the highlights that make now a perfect time to give Grype another look. Dramatically Fewer False Positives One of the most common complaints we've heard over the years was about false positives - vulnerabilities being incorrectly flagged where they didn't actually exist. This problem was particularly acute when scanning Java applications, where a Python package named "redis" might trigger vulnerabilities meant for the Redis database server, or where different ecosystems would cross-contaminate results. The root cause was our reliance on CPE (Common Platform Enumeration) matching from the National Vulnerability Database. While comprehensive, CPE matching often lacked the ecosystem-specific context needed for accurate results. The solution? We've fundamentally shifted our approach to prioritize the GitHub Advisory Database, which provides ecosystem-specific vulnerability data. The results speak for themselves: Up to 80% reduction in false positives across some ecosystems More accurate matching that respects package ecosystem boundaries Cleaner, more actionable scan results # Before: Multiple false positives for "redis"  $ grype redis:latest ... CVE-2022-0543    redis    pkg:gem/redis@4.8.0 # After: Only legitimate vulnerabilities reported $ grype redis:latest # Clean results focused on actual Redis server vulnerabilities Don't worry if you still need CPE matching for specific use cases - it's still available and configurable. But for most users, the new defaults provide dramatically better accuracy. So, while not completely solved, we’re another step closer to nirvana. Database Revolution: Faster, Smaller, Smarter Behind the scenes, we've completely reimagined how Grype stores and accesses vulnerability data with our move from database schema v5 to v6. This isn't just a version bump - it's a fundamental architectural improvement. The numbers tell the story: MetricSchema v5Schema v6ImprovementDownload Size210 MB↓ 65 MB ↓ 69% smallerOn-disk DB Size1.6 GB↓ 900 MB↓ 44% smaller For your day-to-day workflow, this means: Faster CI/CD pipelines with quicker database updates Reduced bandwidth costs especially important for air-gapped environments Better performance on resource-constrained systems But the improvements go beyond just size. The new schema is built around OSV (Open Source Vulnerability) standards and includes powerful new datasets: Enhanced Intelligence with CISA KEV and EPSS Grype now includes CISA's Known Exploited Vulnerabilities (KEV) database and EPSS (Exploit Prediction Scoring System) data. This means you can now prioritize vulnerabilities actively exploited in the wild or have a high probability of exploitation. This contextual information helps security teams focus their remediation efforts on the most important vulnerabilities. The KEV and EPSS data and a vulnerability’s severity are now used to calculate a “Risk” value, presented in the Grype tabular output. The tabular output from Grype is now sorted by the calculated “Risk” column by default. Database Search: Your New Best Friend One of the most powerful additions to Grype is the enhanced database search functionality. Previously, investigating vulnerability data meant manually searching through multiple sources. Now, you can query the Grype database directly to understand what's in there and why certain matches occur.This is best illustrated with a few examples: Find all vulnerabilities affecting log4j Search for specific vulnerability details Search for vulns in a specific package/library and ecosystem This transparency helps with: Debugging unexpected results - understand exactly why a match occurred Security research - explore vulnerability patterns across ecosystems Compliance reporting - validate that your scanning covers relevant vulnerability sources A Cast of Thousands (Well, Five): The Ecosystem Advantage While Grype is the star of this story, its improvements are powered by advances across our entire toolchain. Syft, our SBOM generation tool, has dramatically expanded its package detection capabilities over the past year: New Binary Detection: Chrome/Chromium browsers curl and other common utilities Dart language binaries PHP interpreters and extensions Haskell and OCaml binaries Enhanced Language Support: Improved .NET detection with better dependency relationships NuGet package support Enhanced Java cataloging with better Maven support Python packaging improvements with dependency relationships Support for Rust cargo-auditable binaries Better Container Analysis: Support for scanning Debian archives directly Improved handling of symlinks and complex file systems Better performance with large container images This expanded detection means Grype can now find and assess vulnerabilities in a broader range of software components, giving you more comprehensive security coverage. Configuration Profiles: Simplify Your Setup Managing Grype configuration across different environments previously required maintaining separate config files. Now, Grype supports hierarchical configuration with profiles, making it easy to maintain different scanning policies for various environments as well as per-project exclusion lists. PURL Support: Scan What You Know Sometimes you don't need to scan an entire container image - you just want to check if a specific package version has known vulnerabilities. Grype now supports direct PURL (Package URL) scanning: Check a specific package version Feed Grype one or more PURLs from a file This is particularly useful for dependency checking in CI/CD pipelines or when you want to validate specific component versions. Performance Under the Hood Beyond the user-facing features, significant engineering work has improved Grype's performance and reliability: Faster vulnerability matching with optimized database queries Reduced memory consumption especially when scanning large container images Better error handling with more informative messages when things go wrong The Road Ahead The past year has established a solid foundation for Grype's future. With the new database architecture in place, we can more rapidly integrate new vulnerability sources and provide richer context about security issues. Key areas we're continuing to develop include: Enhanced support for emerging package ecosystems Better integration with vulnerability management workflows More sophisticated vulnerability prioritization Expanded scanning capabilities for different artifact types Try It Today If you're already using Grype, updating to the latest version will automatically give you these improvements. If you're new to Grype or haven't tried it recently, installation is straightforward, from brew or using our installer. Install and run Grype For CI/CD integration, the Grype GitHub Action and Docker images make integration seamless. Grype vs The World Have you tested Grype recently? Maybe you're comparing it to other tools in the market. Let us know how we got on, we would love to know. This post on our community Discourse is a great place to share your experience and give us your feedback. I also put all the above commands in there, for easy copy/paste-ability! Get Involved Grype is open source, and community contributions have been essential to these improvements. Whether you're reporting bugs, suggesting features, or contributing code, there are multiple ways to get involved: GitHub: anchore/grype for issues and contributions Community: Join our Discourse community for discussions and support, and let us know how you get on! Newsletter: Sign up for our community newsletter for updates The past year has shown that security scanning becomes a force multiplier rather than a bottleneck when tooling gets out of the way and provides accurate, actionable results. Grype's evolution continues to focus on this goal: giving you the information you need to secure your software supply chain without the noise. Give it another look - you might be surprised by how much has changed! ### How to Use Anchore & DefectDojo to Stand Up Your DevSecOps Function ### SPDX 3.0: From Software Inventory to System Risk Orchestration The next phase of software supply chain security isn't about better software supply chain inventory management—it's the realization that distributed, micro-services architecture expands an application's "supply chain" beyond the walls of isolated, monolithic containers to a dynamic graph of interconnected services working in concert. Kate Stewart, co-founder of SPDX and one of the most influential voices in software supply chain security, discovered this firsthand while developing SPDX 3.0. Users were importing SBOMs into databases and asking interconnection questions that the legacy format couldn't answer. Her key insight drove the development of SPDX 3.0: "It's more than just software now, it really is a system." The goal became transforming the SBOM format into a graph-native data structure that captures complex interdependencies between constellations of services. In a recent interview with Anchore's Director of Developer Relations on the Future of SBOMs, Stewart shared insights, shaped by decades of collaboration in the trenches with SBOM users and the sculpting of SBOM standards based on ground truth needs. Her perspectives are uniquely tailored to illuminate the challenge of adapting traditional security models designed for fully self-contained applications to the world of distributed micro-services architectures. The architectural evolution from monolithic, containerized application to interconnected constellations of single-purpose services doesn't just change how software is built—it fundamentally changes what we're trying to secure. Learn about how SBOMs have adapted to the world of micro-services architecture with the co-founder of SPDX and SBOMs. Watch Now When Software Became Systems In the containerized monolith era, traditional SBOMs (think: < SPDX 2.2) were perfectly suited for their purpose. They were designed for self-contained applications with clear boundaries where everything needed was packaged together. Risk assessment was straightforward: audit the container, secure the application. Thing to scan 👇 ================ +-------------------------------------------------+ | Container | | +-------------------------------------------+ | | | Monolithic Application | | | | +----------+ +---------+ +----------+ | | | | | Frontend | | Backend | | Database | | | | | +----------+ +---------+ +----------+ | | | +-------------------------------------------+ | +-------------------------------------------------+ Thing to scan 👇 ================ +-------------------------------------------------+ | Container | | +-------------------------------------------+ | | | Monolithic Application | | | | +----------+ +---------+ +----------+ | | | | | Frontend | | Backend | | Database | | | | | +----------+ +---------+ +----------+ | | | +-------------------------------------------+ | +-------------------------------------------------+ [ User ] | v +------------+ | Frontend | (container) 👈 Thing... +------------+ | v +--------------+ | API Server | (container) 👈 [s]... +--------------+ / \ v v +----------+ +--------+ | Auth Svc | | Orders | (container) 👈 to... +----------+ +--------+ \ / v v +------------+ | Database | (container) 👈 scan. +------------+ [ User ] | v +------------+ | Frontend | (container) 👈 Thing... +------------+ | v +--------------+ | API Server | (container) 👈 [s]... +--------------+ / \ v v +----------+ +--------+ | Auth Svc | | Orders | (container) 👈 to... +----------+ +--------+ \ / v v +------------+ | Database | (container) 👈 scan. +------------+ But the distributed architecture movement changed everything. Cloud-native architectures spread components across multiple domains. Microservices created interdependencies that span networks, data stores, and third-party services. AI systems introduced entirely new categories of components including training data, model pipelines, and inference endpoints. Suddenly, the neat boundaries of traditional applications dissolved into complex webs of interconnected services. Even with this evolution in software systems, the fundamental question of software supply chain security hasn't evolved. Security teams still need to know, "what showed up; at what point in time AND do it at scale." The new challenge is that system complexity has exploded exponentially and the legacy SBOM standards weren't prepared for it. Supply chain risk now flows through connections, not just components. Understanding what you're securing requires mapping relationships, not just cataloging parts. But if the structure of risk has changed, so has the nature of vulnerabilities themselves. Where Tomorrow's Vulnerabilities Will Hide The next generation of critical vulnerabilities won't just be in code—they'll emerge from the connections and interactions between complex webs of software services. Traditional security models relied on a castle-and-moat approach: scan containers at build time, stamp them for clearance, and trust them within the perimeter. But distributed architectures expose the fundamental flaw in this thinking. When applications are decomposed into atomic services the holistic application context is lost. A low severity vulnerability in one system component that is white listed for the sake of product delivery speed can still be exploited and alter a payload that is benign to the exploited component but disastrous to a downstream component. The shift to interconnected services demands a zero-trust security paradigm where each interaction between services requires the same level of assurance as initial deployment. Point-in-time container scans can't account for the dynamic nature of service-to-service communication, configuration changes, or the emergence of new attack vectors through legitimate service interactions. In order to achieve this new security paradigm, SPDX needed a facelift. The new idea about an SBOM that can store the entire application context across independent services is sometimes called a SaaSBOM. SPDX 3.0 implements this idea via a new concept called profiles, where application profiles can be built from a collection of individual service profiles and operations or infrastructure profiles can also capture data on the build and runtime environments. Your risk surface isn't just your code anymore—it's your entire operational ecosystem from hardware component supplier to data providers to third-party cloud service. Understanding these expanding risks requires a fundamental shift from periodic snapshots (i.e., castle-and-moat posture) to continuous intelligence (i.e., zero-trust posture). From Periodic Audits to Continuous Risk Intelligence The shift to zero-trust architectures requires more than just changing security policies—it demands a fundamental reimagining of how we monitor and verify the safety of interconnected systems in real-time. Traditional compliance operates on snapshot thinking: quarterly audits, annual assessments, point-in-time inventories. This approach worked when applications were monolithic containers that changed infrequently. But when services communicate continuously across network boundaries, static assessments become obsolete before they're complete. By the time audit results are available, dozens of deployments, configuration changes, and scaling events have already altered the system's risk profile. Kate Stewart's vision of "continuous compliance" addresses this fundamental mismatch between static assessment and dynamic systems. S—System—BOMs capture dependencies and their relationships in real-time as they evolve, enabling automated policy enforcement that can keep pace with DevOps-speed development. This continuous visibility means teams can verify that each service-to-service interaction maintains the same security assurance as initial deployment, fulfilling the zero-trust requirement. The operational transformation is profound. Teams can understand blast radius immediately when incidents occur, tracing impact through the actual dependency graph rather than outdated documentation. Compliance verification happens inline with development pipelines rather than as a separate audit burden. Most importantly, security teams can identify and address misconfigurations or policy violations before they create exploitable vulnerabilities. This evolution transforms security from a periodic checkpoint into continuous strategic intelligence, turning what was once a cost center into a competitive advantage that enables faster, safer innovation. The Strategic Imperative—Why This Matters Now Organizations that adapt to system-level visibility will have decisive advantages in risk management, compliance, and operational resilience as the regulatory and competitive landscape evolves. The visibility problem remains foundational: you can't secure what you can't see. Traditional tools provide (system) component visibility, but emergent system risks only emerge through relationship mapping. Kate emphasizes this idea noting that "safety is a system property". If you want to achieve system-level guarantees of security or risk, being able to see only the trees and not the forest won't cut it. Regulatory evolution is driving urgency around this transition. Emerging regulations (e.g., EO 14028, EU CRA, DORA, FedRAMP, etc.) increasingly focus on system-level accountability, making organizations liable for the security of entire systems, including interactions with trusted third-parties. Evidence requirements are evolving from point-in-time documentation to continuously demonstrable evidence, as seen in initiatives like FedRAMP 20x. Audit expectations are moving toward continuous verification rather than periodic assessment. Competitive differentiation emerges through comprehensive risk visibility that enables faster, safer innovation. Organizations achieve reduced time-to-market through automated compliance verification. Customer trust builds through demonstrable security posture. Operational resilience becomes a competitive moat in markets where system reliability determines business outcomes. Business continuity integration represents perhaps the most significant strategic opportunity. Security risk management aligns naturally with business continuity planning. System understanding enables scenario planning and resilience testing. Risk intelligence feeds directly into business decision-making. Security transforms from a business inhibitor into an enabler of agility. This isn't just about security—it's about business resilience and agility in an increasingly interconnected world. The path forward requires both vision and practical implementation. The Path Forward The transition from S—software—BOMs to S—system—BOMs represents more than technological evolution—it's a fundamental shift in how we think about risk management in distributed systems. Four key insights emerge from this evolution.  Architectural evolution demands corresponding security model evolution—the tools and approaches that worked for monoliths cannot secure distributed systems.  Risk flows through connections, requiring graph-based understanding that captures relationships and dependencies.  Continuous monitoring and compliance must replace periodic audits to match the pace of modern development and deployment.  System-level visibility becomes a competitive advantage for organizations that embrace it early. Organizations that make this transition now will be positioned for success as distributed architectures become even more complex and regulatory requirements continue to evolve. The alternative—continuing to apply monolithic security thinking to distributed systems—becomes increasingly untenable. The future of software supply chain security isn't about better inventory—it's about intelligent orchestration of system-wide risk management. If you're interested in how to make the transition from generating static software SBOMs to dynamic system SBOMs, check out Anchore SBOM or reach out to our team to schedule a demo. Explore SBOM use-cases for almost any department of the enterprise and learn how to unlock enterprise value to make the most of your software supply chain. Download Now ### How to Respond When Your Customers Require an SBOM (and Even Write It Into the Contract!) Your sales team just got off a call with a major prospect. The customer is asking for an SBOM—a software bill of materials—and they want it written directly into the contract. The request is escalated to the executive team and from there directly into your inbox. Maybe it's a government agency responding to new federal mandates, a highly regulated enterprise implementing board-level security requirements, or a large EU-based SaaS buyer preparing for upcoming regulatory changes. Suddenly, a deal that seemed straightforward now hinges on your ability to deliver comprehensive software supply chain transparency. If this scenario sounds familiar, you're definitely not alone. SBOM requirements are increasing across industries, fueled by new regulations like the US Executive Order 14028 and the EU Cyber Resilience Act. For most software vendors, this represents entirely new territory where the stakes—revenue, reputation, and customer trust—are very real. This development isn't entirely negative news, however. Organizations that proactively build robust SBOM capabilities are discovering they're not just avoiding lost deals—they're actually building a significant competitive advantage. Early adopters consistently report faster sales cycles with security-conscious prospects and access to previously unreachable government contracts that require supply chain transparency.  Don't believe me? I've brought the receipts: 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'.—CEO, API Management Vendor >> Read whole customer case study here >> This blog post will walk you through the critical steps needed to meet customer SBOM demands effectively, help you avoid costly implementation mistakes, and even show you how to turn compliance requirements into genuine business advantages. 5-Minute Decision Framework: Are SBOMs Urgent for Your Organization? High urgency signals: Government prospects, enterprise RFPs mentioning SBOMs, existing customers asking software supply chain security questions, competitors promoting SBOM capabilities. Medium urgency signals: Industry peers discussing SBOM strategies, security questionnaires becoming more detailed, procurement teams asking about vulnerability management. Preparation signals: Strong CI/CD pipelines, good dependency management, existing security tooling, cross-functional project execution capability. Red flags: Legacy systems with unknown dependencies, manual build processes, siloed teams, limited engineering bandwidth. Why Customers Are Demanding SBOMs—And What That Means For You SBOMs aren’t a passing trend. In fact, the regulatory pressure from governments around the world are steadily driving SBOM adoption outside of the public sector. These new regulations have forced vendors, especially those selling to the US government and in the EU, to scrutinize what’s in the software. US Government: EO 14028 requires federal agencies to collect SBOMs from vendors EU Enterprises: The EU Cyber Resilience Act (CRA) requires an SBOM for any enterprise that sells "products with software components" in the EU market BUT won't be fully enforced until December 2027—you still have time to get ahead of this one! Highly regulated industries: Meaning defense (continuous ATO), healthcare (FDA approval) and finance (DORA, PCI DSS 4.0) all require SBOMs But what are your customers really after? Most are looking for: A clear, standardized inventory of what’s in your software (open source, third-party, proprietary) Evidence you’re proactively remediating supply chain vulnerabilities A baseline for risk assessment and future incident response Some customers will have strict formats or frequent asks; others are just “checking the box.” It’s important to clarify what’s really required. Decoding the Request for an SBOM: What’s Actually Required? When a customer asks for an SBOM, don’t assume you know what they want. Here’s how to get clarity: Ask these questions Format: Do you require SPDX, CycloneDX, or will any standard SBOM format do? Update Frequency: Is a one-time SBOM sufficient, or do you require continuous updates with every new release? NOTE: If your customer is FedRAMP authorized or a US federal agency (including DoD) continuous monitoring (ConMon) is required Depth: Do you want only direct dependencies, or transitive (all sub-dependencies) as well? Delivery: How do you want to receive the SBOM—portal, API, email, physical media? Minimum requirements Most regulated buyers accept SPDX or CycloneDX formats as long as they meet the NTIA's Minimum Elements. One SBOM per major release is typical, unless otherwise specified. Red Flags Unreasonably frequent update requests (e.g., “every nightly build”) Requests for highly granular or proprietary information you can’t legally or safely disclose Contract language examples “Vendor shall provide an SBOM in SPDX or CycloneDX format at product release.” “Vendor will update the SBOM within 30 days of any significant component change.” Key Risks and Negotiation Tactics The biggest risk? Overcommitting—contractually agreeing to deliver what you can’t.  Contract negotiations around SBOM requirements present unique challenges that combine technical complexity with significant business risk. Understanding common problematic language and developing protective strategies prevents overcommitment and reduces legal exposure. Here’s how to stay safe: Risks Operational: You lack fully instrumented software development pipeline with integrated SBOM generation and can’t meet the update frequency as promised. Legal: You don't have complete supply chain transparency and risk exposing proprietary or third-party code you’re not allowed to disclose. Reputational: Missing deadlines or failing to deliver undermines customer trust. Red flags in contracts Unlimited liability clauses for SBOM accuracy  100% accurate SBOMs create impossible standards—no automated tool achieves this level of accuracy, and manual verification is prohibitively expensive Penalty clauses for incomplete or inaccurate SBOMs You should be able to remediate mistakes in a reasonable timeframe Real-time or continuous SBOM update requirements ignoring practical development and release cycles Requirements for complete proprietary component disclosure  May violate third-party licensing agreements or expose competitive advantages No provision for IP protection If you're increasing their supply chain transparency they need to reciprocate and protect your interests Vague standards (“must provide industry best-practice SBOMs” without specifics) How to negotiate Push back on frequency:  "We can provide an updated SBOM at each major release, but not with every build." Standard delivery timelines should align with existing release cycles—quarterly updates for stable enterprise software, per-release delivery for rapidly evolving products. Don't roll over on accuracy: "We can generate SBOMs automatically as part of our normal software development process, provide reasonable manual validation and correct any identified issues." Reasonable accuracy standards acknowledge tool limitations while demonstrating good faith effort. Protect sensitive info:  "SBOM details do not extend to proprietary components or components protected by confidentiality." Redact or omit sensitive components, and communicate this upfront. Quick-Start: Fast Path to SBOM Compliance (for Resource-Constrained Teams) You don’t need to boil the ocean. Here’s how to get started—fast: First Five Moves Clarify the ask: Use the questions above to pin down what’s really required. Inventory your software: Identify what you build, ship, and what major dependencies you include. Choose your tooling: For modern apps, consider open source tools (e.g., Syft) or commercial platforms (e.g., Anchore SBOM). For legacy systems, some manual curation may be needed. Assign ownership: Clearly define who in engineering, security, or compliance is responsible. Pilot a single SBOM: Run a proof of concept for one release, review, and iterate. Pro tips: Automate where possible (integrate SBOM tools into CI/CD). Don’t over-engineer for the first ask—start with what you can support. Handling legacy/complex systems: Sometimes, a partial or high-level SBOM is enough. Communicate limitations honestly and document your rationale. Efficient Operationalization: Making SBOMs Work in Your Workflow When you're ready to operationalize your SBOM initiative, there are four important topics to consider: Automate SBOM creation: Integrate tools into your build pipeline; trigger SBOM creation with each release. SBOM management:Store SBOMs in a central repository for easy search and analysis. Version and change management:Update SBOMs when major dependencies or components change. Delivery methods: Secure portal Customer-specific API Encrypted email attachment This is also a good time to consider the build vs buy question. There are commercial options to solve this challenge if building a homegrown system would be a distraction to your company's core mission. Turning Compliance into Opportunity SBOMs aren’t just a checkbox—they can help your business: Win deals faster: “Having a ready SBOM helped us close with a major public sector buyer ahead of a competitor.” Shorten security reviews: Automated SBOM delivery means less back-and-forth during customer due diligence. Build trust: Demonstrate proactive risk management and transparency. Consider featuring your SBOM readiness as a differentiator in sales and marketing materials. SBOM Readiness Checklist ::Checklist:: Have we clarified the customer’s actual SBOM requirements? ✅: Continue ❌: Send request back to customer account team with SBOM requirements Do we know which SBOM format(s) are acceptable? ✅: Continue ❌: Send request back to customer account team with SBOM requirements Have we inventoried all shipped software and dependencies? ✅: Continue ❌: Send to engineering to build a software supply chain inventory Have we selected and tested an SBOM generation tool? ✅: Continue ❌: Send to engineering to select and integrate an SBOM generation tool into CI/CD pipeline Do we have clear roles for SBOM creation, review, and delivery? ✅: Continue ❌: Work with legal, compliance, security and engineering to document SBOM workflow Are our contractual obligations documented and achievable? ✅: Continue ❌: Work to legal to clarify and document obligations Do we have a process for handling sensitive or proprietary code? ✅: You're all good ❌: Work with engineering and security to identify sensitive or proprietary information and develop a redaction process Conclusion: From Reactive to Strategic SBOM requirements are here to stay—but meeting them doesn’t have to be painful or risky. The most forward-thinking organizations are transforming SBOM compliance from a burden into a strategic advantage. By proactively developing robust SBOM capabilities, you’re not just checking a box—you’re positioning your company as a market leader in security maturity and transparency. As security expectations rise across all sectors, your investment in SBOM readiness can become a key differentiator, driving higher contract values and protecting your business against less-prepared competitors. Ready to take the first step? Save your developers time with Anchore SBOM. Get instant access with a 15-day free trial. START FREE TRIAL ### The SBOM Paradox: Why 'Useless' Today Means Essential Tomorrow "Most SBOMs are barely valid, few meet minimum government requirements, and almost none are useful." Harsh. But this is still a common sentiment by SBOM users on LinkedIn. Software bills of materials (SBOMs) often feel like glorified packing slips—technically present but practically worthless. Yet Kate Stewart, one of the most respected figures in open source, has dedicated over a decade of her career to SBOMs. As co-founder of SPDX and a Linux Foundation Fellow, she's guided this standard from its inception in 2010 through multiple evolutions. Why would someone of her caliber pour years into something supposedly "useless"? Because Stewart, the Linux Foundation and the legion of SDPX contributors see something the critics don't: today's limitations aren't a failure of vision—they're a foundation for the growing complexity of the software supply chain of the future. Because Stewart, the Linux Foundation and the legion of SDPX contributors see something the critics don't: today's limitations aren't a failure of vision—they're a deliberate strategy. They're following the classic startup playbook: nail a minimal use-case first, achieve critical mass, then expand horizontally. The "uselessness" critics complain about? That's a feature, not a bug. Death by a Thousand Cuts To understand where we're headed, we need to start where it all began: back in 2009 with Kate and a few of her key software architects at Freescale Semiconductor spending their weekends manually scanning software packages for licenses before the launch of a new semiconductor chip. Stewart and her team faced what seemed like a manageable challenge—tracking open source software (OSS) licenses for roughly 500 dependencies. But as she recalls, "It was death by a thousand cuts." Every weekend, they'd pore over packages, hunting for license information, trying to avoid the legal landmines hidden in their newest chip's software supply chain. The real shock came from discovering how naive their assumptions were. "Everyone assumes the top-level license is all there is," Stewart explains, "but surprise!" Buried deep in transitive dependencies—the dependencies of dependencies—were licenses that could torpedo entire projects. GPL code hidden three layers deep could force a proprietary product open source. MIT licenses with unusual clauses could create attribution nightmares. This wasn't just Freescale's problem. Across the industry, companies were hemorrhaging engineering hours on manual license compliance. The Counterintuitive Choice Here's where the story takes an unexpected turn. When the Linux Foundation's FOSSBazaar working group came together to design a solution, they made a choice that still frustrates people today: they went minimal. Radically minimal. The working group—including Stewart and other industry experts—envisioned SBOMs as "software metadata containers"—infinitely expandable vessels for any information about software components. The technology could support hashing, cryptographic attestations, vulnerability data, quality metrics, and more. But instead of trying to predict every potential use-case they chose to pare the original SPDX spec down to only its essentials. Stewart knew that removing these features would make SBOMs "appear" almost useless for any purpose. So why did they proceed? The answer lies in a philosophy that would define SBOM's entire evolution: "[We framed] SBOMs as simply an "ingredients list"…but there's a lot more information and metadata that you can annotate and document to open up significant new use-cases. [The additional use-cases are] really powerful BUT we needed to start with the minimum viable definition." The goal wasn't to solve every problem on day one—it was to get everyone speaking the same language. They chose adoption over the overwhelming complexity of a fully featured standard. Why the 'Useless' Jab Persists By launching SPDX with a minimal definition to encourage broad adoption and make the concept approachable, the industry began evaluating it equally as minimally—seeing SBOMs as simple ingredient lists rather than an extensible framework. The simplicity of the standard made it easier to grasp, but also easier to dismiss. Today's critics have valid points: Most SBOMs barely meet government minimums They're treated as static documents, generated once and forgotten Organizations create them purely for compliance, extracting zero operational value The tools generating them produce inconsistent, often invalid outputs But here's what the critics miss: SBOMs aren't truly static documents—at least, not in practice. They're more like Git version-controlled files: static snapshots that form a dynamic record over time. Each one captures the meta state of an application at a given moment, but their value emerges from their evolution. As Stewart emphasizes, "Every time you apply a security fix you are revving your package. A new revision needs a new SBOM." Just as Git commits accumulate to form a living history of a codebase, SBOMs should accumulate and evolve to reflect the ongoing lifecycle of an application. The perception problem is real, but it's also temporary. The HTTP Playbook To understand why the minimal SBOMs strategy is powerful, consider the evolution of HTTP. In 1991, the original HTTP/0.9 protocol could only request a document using a GET method and receive raw HTML bytes in return. There were no status codes, no headers, and no extensibility. Critics at the time leveled familiar critiques against the fledgling protocol—"barely functional", "useless", etc. But that simplicity was its genius. It was a minimum viable definition that was easy to implement and rapidly adopted.  And because it was adopted, it grew and evolved. Today, HTTP headers handle: Security policies (Content‑Security‑Policy, Strict‑Transport‑Security) Performance optimization (caching, compression) State management (cookies and session handling) Authentication and authorization Client hints and feature detection Nobody in 1991 imagined we'd use HTTP headers to prevent cross‑site scripting attacks or optimize mobile performance. But the extensible design made it possible. SBOMs are following the exact same playbook. The industry expected them to solve license management—the original Package Facts vision. Instead, the killer app turned out to be vulnerability management, driven by the explosion of software supply chain attacks like SolarWinds and Log4j. "SPDX has grown use‑case by use‑case," Stewart notes. And each new use-case doesn't just add features—it enables entirely new categories of applications. SBOMs today are where HTTP was in 1991—functionally limited but primed for explosion. The Expansion Is Already Here The evolution from SPDX 2.x to 3.0 proves this strategy is working. The changes aren't incremental—they're transformational: From Documents to Graphs: SPDX 3.0 abandons the monolithic document model for knowledge graph model. Instead of one big file, you have interconnected metadata that can be queried, analyzed, and visualized as a network. From Software to Systems: The new specification handles… Service profiles for cloud infrastructure AI model and dataset profiles (tracking what data trained your models) Hardware BOMs for IoT and embedded systems Build profiles that cryptographically link source to binary End-of-life metadata for dependency lifecycle management Real-World Implementations: This isn't theoretical. The Yocto project already generates build-native SBOMs. The Zephyr project produces three interlinked SBOMs: Source SBOM for the Zephyr RTOS itself Source SBOM for your application Build SBOM that cryptographically links everything together These implementations show SBOMs evolving from compliance checkboxes to operational necessities. The Endgame: Transparency at Scale Kate Stewart summarizes the vision in seven words: "Transparency is the path to minimizing risk." But transparency alone isn't valuable—it's what transparency enables that matters. When every component in your software supply chain has rich, queryable metadata, you can: Instantly identify affected systems when a zero-day disclosure drops Prove compliance with regulations automatically Track technical debt and maintenance burden in real-time Make informed decisions about component selection Automate security policy enforcement The platform effect is already kicking in. More adoption drives more use-cases. More use-cases drive better tooling. Better tooling drives more adoption. It's the same virtuous cycle that turned HTTP from a simple network protocol into the nervous system of the web. Explore SBOM use-cases for almost any department of the enterprise and learn how to unlock enterprise value to make the most of your software supply chain. Download Now Playing the Long Game The critiques of SBOMs as they are today suffer from a failure of imagination. Yes, they're minimal. Yes, they're often poorly implemented. Yes, they feel like "compliance theater". All true. The founders of SPDX made a calculated bet: it's better to have adoption of a simple but potentially "useless" standard that can evolve than to have a perfect standard that nobody uses. By starting small, they avoided the fate of countless over-engineered standards that died in committee. Now, with the cold start overcome and adoption growing, the real expansion begins. As software supply chains grow more complex—incorporating AI models, IoT devices, and cloud services—the metadata infrastructure to manage them must evolve as well. The teams generating "barely valid" SBOMs today are building the muscle memory and tooling that will power tomorrow's software transparency infrastructure. Every "useless" SBOM is a vote for an open, transparent, secure software ecosystem. The paradox resolves itself: SBOMs are useless today precisely so they can become essential tomorrow. Learn about SBOMs, how they came to be and how they are used to enable valuable use-cases for modern software. Watch Now ### SCA vs. SBOM: How They Differ & Why They Work Best as a Team ### False Positives and False Negatives in Vulnerability Scanning: Lessons from the Trenches When Good Scanners Flag Bad Results Imagine this: Friday afternoon, your deployment pipeline runs smoothly, tests pass, and you're ready to push that new release to production. Then suddenly: BEEP BEEP BEEP - your vulnerability scanner lights up like a Christmas tree: "CRITICAL VULNERABILITY DETECTED!" Your heart sinks. Is it a legitimate security concern requiring immediate action, or just another false positive that will consume your weekend? If you've worked in DevSecOps for over five minutes, you know this scenario all too well. False positives and false negatives are the yin and yang of vulnerability scanning - equally problematic but in opposite ways. False positives cry wolf when there's no real threat, leading to alert fatigue and wasted resources. False negatives are the silent killers, allowing actual vulnerabilities to slip through undetected. Both undermine confidence in your security tooling. At Anchore, we've been battling these issues alongside our community, and the GitHub issues for our open source scanner, Grype, tell quite a story. In this post, we'll dissect real-world examples of false results, explain their root causes, and show how vulnerability scanning has evolved to become more accurate over time. The Curious Case of Cross-Ecosystem Confusion One of the most common causes of false positives is "cross-ecosystem confusion." This happens when a vulnerability scanner mistakenly applies a vulnerability from one ecosystem to a different but similarly named package in another ecosystem. Take the case of Google's Protobuf libraries. In early 2023, Grype flagged Go applications using google.golang.org/protobuf as vulnerable to CVE-2015-5237 and CVE-2021-22570, both of which affect the C++ version of Protobuf. As one frustrated user commented in Issue #1179: "I was just bitten by the CVEs affecting the C++ version of protobuf when I'm using the Go package. Arguably, it shouldn't even be included on those CVEs in Github because it's a completely different code base…" This user wasn't alone. Looking at the data, we found a whopping 44 instances of these cross-ecosystem false positives across various projects, affecting everything from etcd to Prometheus to kubectl. The root cause? CPE-based vulnerability matching. The Common Platform Enumeration (CPE) system, while standardized, often lacks the granularity needed to distinguish between different implementations of similarly named software. When Binary Isn't So Binary: The System Package Conundrum Another fascinating case study comes from Issue #2527, where Grype reported CVE-2022-1271 for the gzip utility on Ubuntu 22.04 despite the package being patched. The problem stemmed from how Linux distributions like Ubuntu handle symbolic links between /bin and /usr/bin. The package manager knew the file was part of the gzip package, but Syft (Grype's companion tool for generating SBOMs) was identifying the binary separately without connecting it to its parent package. As Grype contributor Alex Goodman explained during a live stream: "This issue was related to how Syft handled symlinks, particularly with the 'user merge' in some Linux distributions. Syft wasn't correctly following symlinks in parent directories when associating files with their Debian packages." This case is particularly interesting because it highlights the complex relationship between package managers and the actual files on disk. Even when a vulnerability is properly patched in a package, the scanner might still flag the binary if it doesn't correctly associate it. The .NET Parent-Child Relationship Drama .NET developers will appreciate this next one. In Issue #1693, a user reported that Grype wasn't detecting the GHSA-98g6-xh36-x2p7 vulnerability in System.Data.SqlClient version 4.8.5. The issue was related to how .NET packages are cataloged. Syft was finding the .NET assemblies and reporting their assembly versions (like 4.700.22.51706), but these don't align with the NuGet package versions (4.8.5) used in vulnerability databases. A contributor demonstrated: $ grype -q dir:. ✔ Vulnerability DB [no update available] ✔ Indexed file system /Users/wagoodman/scratch/grype-1693 ✔ Cataloged contents 500f014f33608c18 ├── ✔ Packages [1 packages] └── ✔ Executables [0 executables] ✔ Scanned for vulnerabilities [0 vulnerability matches] NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY System.Data.SqlClient 4.8.5 4.8.6 dotnet GHSA-98g6-xh36-x2p7 High$ grype -q dir:. ✔ Vulnerability DB [no update available] ✔ Indexed file system /Users/wagoodman/scratch/grype-1693 ✔ Cataloged contents 500f014f33608c18 ├── ✔ Packages [1 packages] └── ✔ Executables [0 executables] ✔ Scanned for vulnerabilities [0 vulnerability matches] NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY System.Data.SqlClient 4.8.5 4.8.6 dotnet GHSA-98g6-xh36-x2p7 High This issue highlights the challenges of correctly identifying artifacts across different packaging systems, especially when version information is stored or represented differently. Goodbye CPE, Hello GHSA: The Evolution of Matching If there's a hero in these tales of false results, it's the shift from CPE-based matching to more ecosystem-aware approaches. In 2023, we published a blog post, "Say Goodbye to False Positives, " announcing a significant change in Grype's approach. As Keith Zantow explained: "After experimenting with a number of options for improving vulnerability matching, ultimately one of the simplest solutions proved most effective: stop matching with CPEs." Instead, Grype primarily relies on the GitHub Advisory Database (GHSA) for vulnerability data. This change led to dramatic improvements: "In our set of test data, we have been able to reduce false positive matches by 2,000+, while only seeing 11 false negatives." That's a trade-off most security teams would gladly accept! The shift to GHSA-based matching also brought another significant benefit: community involvement in correcting vulnerability data. Practical Strategies for Managing False Results Based on our experiences and community feedback, here are some practical strategies for dealing with false results in vulnerability scanning: Use a quality gate in your CI/CD pipeline: Similar to Grype's quality gate, which compares results against manually labeled vulnerabilities, you can create a baseline of known issues to avoid regression. Customize matching behavior: Modern vulnerability scanners like Grype allow you to adjust matching behavior through configuration. For instance, you can modify CPE matching for specific ecosystems: match: java: using-cpes: false python: using-cpes: true match: java: using-cpes: false python: using-cpes: true Create ignore rules for known false positives: When all else fails, explicitly ignore known false positives. Grype supports this through configuration: ignore: - vulnerability: CVE-2022-1271 fix-state: unknown package: type: binary version: 18.17.1 ignore: - vulnerability: CVE-2022-1271 fix-state: unknown package: type: binary version: 18.17.1 Contribute upstream: We believe the best solution is often to fix the data at its source. This is not a consistent practice across the industry. However, as one contributor noted in Issue #773: "Since we use GHSA now, it's possible for users to seek to correct the data by raising an issue or PR against https://github.com/github/advisory-database." Conclusion: The Never-Ending Quest for Accuracy The battle against false results in vulnerability scanning is never truly over. Scanners must continuously adapt as software ecosystems evolve and new packaging systems emerge. The good news is that we're making substantial progress. By analyzing the closed issues in the Grype repository over the past 12 months, we can see that the community has successfully addressed dozens of false-positive patterns affecting hundreds of real-world applications. In the immortal words of one relieved user after we fixed a particularly vexing set of false positives: "OMG. This is my favorite GH issue ever now. Great work to the grype team. Holy cow! 🐮 I'm really impressed.” At Anchore, we remain committed to this quest for accuracy. After all, vulnerability scanning is only helpful if you can trust the results. Whether you're using our open-source tools like Grype and Syft or Anchore Enterprise, know that each false positive you report helps improve the system for everyone. So the next time your vulnerability scanner lights up like a Christmas tree on Friday afternoon, remember: you're not alone in this battle, and the tools are improving daily. And who knows? Maybe it's a real vulnerability this time, and you'll be the hero who saved the day! Are you struggling with false positives or false negatives in your vulnerability scanning? Share your experiences on our Discourse, and report any issues on GitHub. And if you're looking for a way to manage your SBOMs and vulnerability findings at scale, check out Anchore Enterprise. ### NIS2 Compliance with SBOMs: a Scalable, Secure Supply Chain Solution This blog post has been archived and replaced by the supporting pillar page that can be found here: https://anchore.com/wp-admin/post.php?post=987475325&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. ### The True Cost of Compliance: Demonstrating the Value of Cybersecurity ### AWS Summit Washington, DC ### Take Control of Your Software Supply Chain: Introducing Anchore SBOM Today, we’re launching Anchore SBOM. Anchore Enterprise now allows you to manage internal and external SBOMs in a single location to track your software supply chain issues and meet your compliance requirements. What is Anchore SBOM? Anchore SBOM is a set of new capabilities in Anchore Enterprise that allow customers to gain comprehensive visibility into the software components present in both their internally developed and third-party supplied software to identify and mitigate security and compliance risks. It provides a centralized platform for viewing, managing, and analyzing Software Bill of Materials (SBOMs), including the capability to “Bring Your Own SBOMs” (BYOS) by importing SBOMs created outside of Anchore Enterprise and organizing them into groups, reflecting a logical organization structures for easier management, control, analysis, and reporting for enhanced collaboration across business and engineering functions. Importing external SBOMs enables users to go beyond standard container analysis by incorporating SBOMs generated outside of Anchore, whether from other SCA tools or vendor sources, which, in turn, ensures comprehensive visibility across all components of their applications. Why are SBOMs Important? In an era of escalating software supply chain attacks—and mounting pressure from regulators, customers, and security teams—visibility into what goes into your applications is no longer optional. Modern software is complex and often built by distributed teams on a foundation of open-source and third-party components. Staying secure and compliant requires continuous, end-to-end insight into your software stack. That means knowing exactly what’s in your applications at every stage of the DevOps lifecycle—from code to cloud. This is where SBOMs come in. SBOMs are machine-readable inventories that capture the full composition of your applications by listing every package and dependency they include. Key Features and Benefits Bring Your Own SBOM (BYOS): Import SBOMs in SPDX (versions 2.1-2.3), CycloneDX (versions 1.0-1.6), and Syft native formats – analyze components and manage prioritized vulnerabilities.  Validate SBOMs: Assess uploaded SBOM quality to ensure they meet schema standards and contain necessary data for vulnerability scanning. Manage SBOMs Centrally: Store and group SBOMs to reflect logical organization structures for easier management, control, analysis, and reporting for enhanced collaboration across business and engineering functions.  Identify Vulnerabilities: Identify and report vulnerabilities within uploaded SBOMs for fast and efficient remediation. Prioritize and Triage with Anchore Score: A prioritized vulnerability rating based on CVSS Score and Severity, EPSS, and CISA KEV data reduces noise and drastically improves triage time. Why Does This Matter? Demand for software supply chain transparency is surging, driven by emerging regulations (such as NIS2, U.S. Cybersecurity Executive Orders, and the EU’s Cyber Resilience Act), industry standards (like PCI DSS), and sector-specific requirements from agencies such as the FDA and SEC. As a result, SBOMs have become essential for enterprises and government agencies seeking critical visibility into their software ecosystems. Anchore SBOM enables you to consolidate SBOMs continuously generated throughout your development lifecycle—scanning every commit in Git, every build artifact in the CI/CD pipeline, and every deployment to Kubernetes—alongside external SBOMs produced by other tools or provided by your software vendors. This unified view offers comprehensive visibility into your software supply chain. It enables you to meet regulatory requirements and satisfy your customers’ asks with a complete, up-to-date inventory of all your assets and their current security issues. Learn more about Anchore SBOM  or contact us directly for a demo. With the newly announced Anchore SBOM feature, teams can start safely consuming OSS while mitigating security and compliance risks. Register for our technical launch webinar. ### What is Software Composition Analysis (SCA)? This blog post has been archived and replaced by the supporting pillar page that can be found here: https://anchore.com/wp-admin/post.php?post=987475061&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. ### Easyjson and foreign influence, should we panic? Wired recently published an article titled Security Researchers Warn a Widely Used Open Source Tool Poses a 'Persistent' Risk to the US which paints a dire picture of a popular open source Go package named easyjson. This sounds like it could be a problem if you read the article, so how much panic is appropriate for this situation? In order to ruin the big conclusion, the answer is “not much”. So what’s the deal? Are the adversaries using open source as a trojan horse into our software? They are, without question. Remember XZ Utils or tj-actions/changed-files? Those are both well resourced attacks against important open source components. It’s clear that open source is a target for attackers. We can name two examples, it’s likely there are more. But what about easyjson? Is that a supply chain attack? So far it doesn’t look like it. There is no evidence that using the easyjson Go library creates a risk for an organization. Could this change someday? Absolutely, but so could any other open source library. The potential risk from a Russian company controlling a popular open source library probably isn’t an important detail. Let’s look at some examples. Pulling all this data is a lot of work, but there are some quick things anyone can observe in a web browser. Let’s use a couple of popular NPM packages. It’s easy to find this list which is why I’m using NPM, but the example will apply to anything in GitHub Lodash Chalk Request commander.js React If we dig into the owners of those widely used repositories, the only one that lists a real location is React, it’s in Menlo Park, California, USA—the headquarters for Meta. Where are those other repositories located? We don’t really know. It’s also worth pointing out that all of those repositories have many contributors from all over the world. Just because a project is controlled by an organization in a country doesn’t mean all contributions are from that country. We know easyjson is from a Russian company because they aren’t trying to hide this fact. The organization that holds the easyjson repository is Mail.ru, a Russian company—and they list their location as Russia. If they want to conduct nefarious activities against open source, this isn’t the best way to do it. There are some lessons in this though. Knowing exactly what software pieces you have is super important for keeping things secure and running smoothly. Imagine you need to find every place you're using "easyjson." Could you do it quickly? Probably not easily, right? Today's software has a lot of hidden parts and pieces. If you don't have a clear inventory of all those pieces, a software bill of materials (SBOM), finding something like easyjson will take forever and you might miss something. If there's a security problem with easyjson, that delay in finding it can cause serious trouble and make you vulnerable. Being able to quickly find and fix these kinds of issues is important when most of our software is open source. The issue of open source sovereignty introduces complex challenges in today's interconnected world. If organizations and governments decide to prioritize understanding the origins of their open source dependencies, they immediately encounter a fundamental question: which countries warrant the most scrutiny? Establishing such a list risks geopolitical bias and may not accurately reflect the actual threat landscape. Furthermore, the practicalities of tracking the geographical origins of open source contributions are significant. Developers and maintainers operate globally, and attributing code contributions to a specific nation-state is fraught with difficulty. IP address geolocation can be easily circumvented, and self-reported location data is unreliable, especially in the context of malicious actors who would intentionally falsify such information. This raises serious doubts about relying on geographical data for assessing open source security risks. It necessitates exploring alternative or supplementary methods for ensuring the integrity and trustworthiness of the open source software supply chain, methods that move beyond simplistic notions of national origin. For a long time, we've kind of just trusted open source stuff without really checking it out. Organizations grab these components and throw them into their systems, and so far that’s mostly worked. Things are changing though. People are getting more worried about vulnerabilities, and there are new rules coming out, like the Cyber Resilience Act, that are going to make us be more careful with software. We're probably going to have to check things out before we use them, keep an eye on them for security issues, and update them regularly. Basically, just assuming everything's fine isn't going to cut it anymore. We need to start being a lot more aware of security. This means organizations are going to have to learn new ways to work and change how they do things to make sure their software is safe and follows the rules. Wrapping up The origin of easyjson being traced back to a Russian company raises a valid point about the perception and utilization of open source software. While the geographical roots of a project don't inherently signify malicious intent, this instance serves as a potent reminder that open source is not simply "free stuff" devoid of obligations for its users. The responsibility for ensuring the security and trustworthiness of the software we integrate into our projects lies squarely with those who build and deploy it. Anchore has two tools, Syft and Grype that can help us take responsibility for the open source software we use. Syft can generate SBOMs, making sure we know what we have. Then we can use Grype to scan those SBOMs for vulnerabilities, making sure our software isn’t an actual threat to our environments. When a backdoor is found in an open source package, like XZ Utils, Grype will light up like a Christmas tree letting you know there’s a problem. The EU Cyber Resilience Act (CRA) shifts this burden of responsibility onto software builders. This approach acknowledges the practical limitations of expecting individual open source developers, who often contribute their time and effort voluntarily, to shoulder the comprehensive security and maintenance demands of widespread software usage. Instead of relying on the goodwill and diligence of unpaid contributors to conduct our due diligence, the CRA framework encourages a more proactive and accountable stance from the entities that commercially benefit from and distribute software, including open source components. This shift in perspective is crucial for the long-term health and security of the software ecosystem. It fosters a culture of proactive risk assessment, thorough vetting of dependencies, and ongoing monitoring for vulnerabilities. By recognizing open source as a valuable resource that still requires careful consideration and due diligence, rather than a perpetually free and inherently secure commodity, we can collectively contribute to a more resilient and trustworthy digital landscape. The focus should be on building secure systems by responsibly integrating open source components, rather than expecting the open source community to single-handedly guarantee the security of every project that utilizes their code. Learn the 5 best practices for container security and how SBOMs play a pivotal role in securing your software supply chain. Download Now ### EU CRA SBOM Requirements: Overview & Compliance Tips This blog post has been archived and replaced by the supporting pillar page that can be found here: https://anchore.com/wp-admin/post.php?post=987475103&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. ### SBOMs as the Crossroad of the Software Supply Chain: Anchore Learning Week  (Day 5) Welcome to the final installment in our 5-part series on Software Bills of Materials (SBOMs). Throughout this series, we've explored  SBOM basics,  technical implementation,  scaling strategies, and expert perspectives.  Now, we'll examine how SBOMs intersect with various disciplines across the software ecosystem. SBOMs don't exist in isolation—they're part of a broader landscape of software development, security, and compliance practices. Understanding these intersections is crucial for organizations looking to maximize the value of their SBOM initiatives. Regulatory Compliance and SBOMs: Global SBOM Mandates As regulations increasingly mandate SBOMs, staying informed about compliance requirements is crucial for software businesses. The US was the first-mover in the "mandatory SBOM for securing software supply chains" movement with the White House's Executive Order (EO) 14028 impacting enterprises that do business with the US federal government The EU Cyber Resilience Act (CRA) was the fast follower of the movement but with a much larger scope. Any company selling software in the EU must maintain SBOMs of their product Our Ask Me Anything: SBOMs and the Executive Order webinar features Anchore SBOM and government compliance experts advising on how to avoid common pitfalls in EO 14028. You'll learn: How to interpret specific EO 14028 requirements for your organization Which artifacts satisfy compliance requirements and which don't Pro tips on how to navigate EO 14028 with the least amount of frustration Open Source Software Security and SBOMs: Risk Management for Invisible Risk Open source components dominate modern applications, yet create an accountability paradox. Your software likely contains 150+ OSS dependencies you didn't write and can't fully audit but you're entirely responsible for any vulnerabilities they introduce. On top of this, OSS adoption is only getting bigger. This means your organization will inherit more vulnerabilities as time goes on. Our guide to resolving the challenges of this accountability paradox, How is Open Source Software Security Managed in the Software Supply Chain?: Examines the unique challenges of securing open source components Offers practical strategies for managing open source risk at scale Provides frameworks for evaluating the security maturity of OSS projects DevSecOps and SBOMS: Types and Uses for Each Stage The integration of SBOMs into DevSecOps workflows represents a powerful opportunity to enhance security while maintaining development velocity. The Evolution of SBOMs in the DevSecOps Lifecycle is a two-part series that breaks down how SBOMs fit into each phase of the DevSecOps lifecycle: Part 1: From Planning to Build Explores how different SBOM types support specific DevSecOps stages Maps SBOM creation points to key development milestones Demonstrates how early SBOM integration prevents costly late-stage issues Part 2: From Release to Production Shows how to automate SBOM generation, validation, and analysis Explores integration with release and deploy pipelines Provides practical examples of SBOM-driven security gates Conclusion: The SBOM Journey Continues Throughout our five-part series on SBOMs, we've provided the knowledge you need to implement effective software supply chain security. From foundational concepts to technical implementation, scaling strategies, and regulatory compliance, you now have comprehensive understanding to put SBOMs to work immediately. Software supply chain attacks continue to escalate, making SBOM implementation essential for proactive security.  Ready to see immediate results? Experience how Anchore Enterprise transforms SBOM management—sign up for a free trial or contact us for a demo today. Don't want to miss a day? Subscribe to our newsletter for updates or follow us on LinkedIn, X or BlueSky to get notifications as each post is published. ### Establish Visibility and Manage Risk in the Supply Chain with Anchore SBOM ### How the US Navy Approaches DevSecOps with Raise 2.0 ### SBOM Insights on LLMs, Compliance Attestations and Security Mental Models: Anchore Learning Week (Day 4) Welcome to the fourth installment in our 5-part series on software bill of materials (SBOMs) In our previous posts, we've covered SBOM fundamentals, SBOM generation and scalable SBOM management. Now, we shift our focus to the bigger picture, exploring strategic perspectives from software supply chain thought leaders. After you've finished day four, dive into day five, "SBOMs as the Crossroad of the Software Supply Chain". Understanding the evolving role of SBOMs in software supply chain security requires more than just technical knowledge—it demands strategic vision. In this post, we share insights from industry experts who are shaping the future of SBOM standards, practices, and use-cases. Insights on SBOMs in the LLM Era LLMs have impacted every aspect of the software industry and software supply chain security is no exception. To understand how industry luminaries like Kate Stewart are thinking about the future of SBOMs through this evolution, watch Understanding SBOMs: Deep Dive with Kate Stewart. This webinar highlights several key points: LLMs pose unique transparency challenges:The emergence of large language models reduces transparency since behavior is stored in datasets and training processes rather than code Software introspection limitations: Already difficult with traditional software, introspection becomes both harder AND more important in the LLM era Dataset lineage tracking: Stewart draws a parallel between SBOMs for supply chain security and the need for dataset provenance for LLMs Behavior traceability: She advocates for "SBOMs of [training] datasets" that allow organizations to trace behavior back to a foundational source "Transparency is the path to minimizing risk." —Kate Stewart This perspective expands the SBOM concept beyond mere software component inventories to encompass the broader information needed for transparency in AI-powered systems. Watch the talk. SBOMs as Compliance Attestation Data Containers—Not Supply Chain Documents Compliance requirements for software supply chain security continue to evolve rapidly. To understand how SBOMs are being reimagined as compliance attestation containers rather than static supply chain documents, watch Trust in the Supply Chain: CycloneDX Attestations & SBOMs with Steve Springett. This webinar highlights several key points: Content over format debates: Springett emphasizes that "content is king"—the actual data within SBOMs and their practical use-cases matter far more than format wars Machine-readable attestations: Historically manual compliance activities can now be automated through structured data that provides verifiable evidence to auditors Business process metadata: CycloneDX can include compliance process metadata like security training completion, going beyond component inventories Compliance flexibility: The ability to attest to any standard, from government requirements to custom internal company policies Quality-focused approach: Springett introduces five dimensions for evaluating SBOM completeness and a maturity model with profiles for different stakeholders (AppSec, SRE, NetSec, Legal/IP) https://vimeo.com/1080989671?share=copy "The end-goal is transparency." — Steve Springett Echoing the belief of Kate Stewart, Springett reinforces the purpose of SBOMs as transparency tools. His perspective transforms our understanding of SBOMs from static component inventories to versatile data containers that attest to broader security and compliance activities. Watch the talk. Security as Unit Tests: A New Mental Model Kelsey Hightower, Google's former distinguished engineer, offers a pragmatic perspective that reframes security in developer-friendly terms. Watch Software Security in the Real World with Kelsey Hightower to learn how his "Security as Unit Tests" mental model helps developers integrate security naturally into their workflow by: Treating security requirements as testable assertions How SBOMs act as source of truth for supply chain data for tests Integrating verification into the CI/CD pipeline Making security outcomes measurable and reproducible Hightower's perspective helps bridge the gap between development practices and security requirements, with SBOMs serving as a foundational element in automated verification. Watch the talk. Looking Ahead As we've seen from these expert perspectives, SBOMs are not just a technical tool but a strategic asset that intersects with many aspects of software development and security. In our final post, we'll explore these intersections in depth, examining how SBOMs relate to DevSecOps, open source security, and regulatory compliance. Stay tuned for the final installment in our series, "SBOMs as the Crossroad of the Software Supply Chain," where we'll complete our comprehensive exploration of software bills of materials. Don't want to miss a day? Subscribe to our newsletter for updates or follow us on LinkedIn, X or BlueSky to get notifications as each post is published. ### DevOps-Scale SBOM Management: Anchore Learning Week (Day 3) Welcome to the third installment in our 5-part series on software bill of materials (SBOMs)—check here for day 1 and day 2. Now, we're leveling up to tackle one of the most significant challenges organizations face: scaling SBOM management to keep pace with the velocity of modern, DevOps-based software development. After you've digested this part, jump into day four, "SBOM Insights on LLMs, Compliance Attestations and Security Mental Models", and day five "SBOMs as the Crossroad of the Software Supply Chain". As your SBOM adoption graduates from proof-of-concept to enterprise implementation, several critical questions emerge: How do you manage thousands—or even millions—of SBOMs? How do you seamlessly integrate SBOM processes into complex CI/CD environments? How do you extract maximum value from your growing SBOM repository? Let's explore three powerful resources that form a roadmap for scaling your SBOM initiative across your organization. SBOM Automation: The Key to Scale After you've generated your first SBOM and discovered the value, the next frontier is scaling across your entire software environment. Without robust automation, manual SBOM processes quickly become bottlenecks in fast-moving DevOps environments. Key benefits: Eliminates time-consuming manual SBOM generation and analysis Ensures consistent SBOM quality across all repositories Enables real-time security and compliance insights https://vimeo.com/1079661839?share=copy#t=0 The webinar Understanding SBOMs: How to Automate, Generate & Manage SBOMs delivers practical strategies for building automation into your SBOM pipeline from day one. This session unpacks how well-designed SBOM management services can handle CI/CD pipelines that process millions of software artifacts daily. Real-world SBOMs: How Google Scaled to 4M+ SBOMs Daily Nothing builds confidence like seeing how industry leaders have conquered the same challenges you're facing. Google's approach to SBOM implementation offers invaluable lessons for organizations of any size. The webinar "How SBOMs Protect Google's Massive Software Supply Chain" reveals how one of tech's largest players scaled their SBOM program to an astonishing 4 million+ SBOMs generated daily. This deep dive shows you: How Google architected their SBOM ecosystem for massive scale Integration patterns that connect SBOMs to their broader security infrastructure Practical lessons learned during their implementation journey This resource transforms theoretical SBOM scaling concepts into tangible strategies you can adapt for your environment. If an organization as large and complex as Google can successfully deploy an SBOM initiative at scale—you can too! Watch the talk now. Build vs Buy?—Anchore Enterprise Building a scalable SBOM data pipeline with advanced features like vulnerability management and automated compliance policy enforcement represents a significant engineering investment. For many organizations, leveraging purpose-built solutions makes strategic sense. Anchore Enterprise offers an alternative path with three integrated components: Anchore SBOM: A turnkey SBOM management platform with enterprise-grade features Anchore Secure: Cloud-native vulnerability management powered by comprehensive SBOM data Anchore Enforce: An SBOM-driven policy enforcement engine that automates compliance checks Start with a free trial for AWS customers or a tailored demo. The Road Ahead As you scale your SBOM initiative, keep one eye on emerging trends and use cases. The SBOM ecosystem continues to evolve rapidly, with new applications emerging regularly. In our next post, we'll explore insights from industry experts on the future of SBOMs and their strategic importance. Stay tuned for part four of our series, "SBOM Insights on LLMs, Compliance Attestations and Security Mental Models". Don't want to miss a day? Subscribe to our newsletter for updates or follow us on LinkedIn, X or BlueSky to get notifications as each post is published. ### SBOM Generation Step-by-Step: Anchore Learning Week (Day 2) Welcome to day 2 of our 5-part series on Software Bills of Materials (SBOMs). In our previous post, we covered the basics of SBOMs and why they're essential for modern software security. Now, we're ready to roll up our sleeves and get technical. After you've digested this part, jump into day three, "DevOps-Scale SBOM Management", day four, "SBOM Insights on LLMs, Compliance Attestations and Security Mental Models", and day five "SBOMs as the Crossroad of the Software Supply Chain". This post is designed for hands-on practitioners—the engineers, developers, and security professionals who want to move from theory to implementation. We'll explore practical tools and techniques for generating, integrating, and leveraging SBOMs in your development workflows. Getting Started: Step-by-Step SBOM Generation Guides Ready to generate your first SBOM? How to Generate an SBOM with Free, Open Source Tools will guide you through everything you need to know. What you'll learn: A list of the 4 most popular SBOM generation tools How to install and configure Syft How to scan source code, a container or a file directory's supply chain composition How to generate an SBOM in CycloneDX or SPDX formats based on the supply chain composition scan A decision framework for evaluating and choosing an SBOM generator Generating accurate SBOMs is the foundation of your software supply chain transparency initiative. Without SBOMs, valuable use-cases like vulnerability management, compliance audit management or license management are low-value, time sinks instead of efficient, value-add activities. Follow the step by step guide on the blog. If you're looking for step-by-step guides for popular ecosystems like Javascript, Python, GitHub or Docker 👈follow the links). Under the Hood: How SBOM Generation Works For those interested in the gory technical details of how a software composition analysis (SCA) tool and SBOM generator scale this function, How Syft Scans Software to Generate SBOMs is the perfect blog post to scratch that intellectual itch. What you'll learn: The scanning algorithms that identify software components How Syft handles package ecosystems (npm, PyPI, Go modules, etc.) Performance optimization techniques for large codebases Ways to contribute to the open source project Understanding the "how" behind the SBOM generation process enables you to troubleshoot edge cases and customize tools when you're ready to squeeze the most value from your SBOM initiative. Read the blog for details. Pro tip: Clone the Syft repository and step through the code with a debugger to really understand what's happening during a scan. It's the developer equivalent of taking apart an engine to see how it works. Advancing with Policy-as-Code Our guide, The Developer’s Guide to SBOMs & Policy-as-Code, bridges the gap between generating SBOMs and automating the SBOM use-cases that align with business objectives. A policy-as-code strategy allows many of the use-cases to scale in cloud native environments and deliver outsized value. What you'll learn: How to automate tedious compliance tasks with PaC and SBOMs How to define security policies (via PaC) that leverage SBOM data Integration patterns for CI/CD pipelines How to achieve continuous compliance with automated policy enforcement Combining SBOMs with policy-as-code creates a force multiplier for your security efforts, allowing you to automate compliance and vulnerability management at scale. Read the blog for details. Pro tip: Start with simple policies that flag known CVEs, then gradually build more sophisticated rules as your team gets comfortable with the approach Taking the Next Step After dipping your feet into the shallow end of SBOM generation and integration, the learning continues with an educational track on scaling SBOMs for enterprise-grade deployments. In our next post, we'll lay out how to take your SBOM initiative from proof-of-concept to production, with insights on automation, management, and real-world case studies.  Stay tuned for part three of our series, "DevOps-Scale SBOM Management," where we'll tackle the challenges of implementing SBOMs across large teams and complex environments. Don't want to miss a day? Subscribe to our newsletter for updates or follow us on LinkedIn, X or BlueSky to get notifications as each post is published. ### SBOM Fundamentals: Anchore Learning Week (Day 1) This blog post is the first in our 5-day series exploring the world of SBOMs and their role in securing the foundational but often overlooked 3rd-party software supply chain. Whether you're just beginning your SBOM journey or looking to refresh your foundational knowledge, these resources will provide a solid understanding of what SBOMs are and why they matter. Day two is a guide to "SBOM Generation Step-by-Step", day three presents "DevOps-Scale SBOM Management", day four, "SBOM Insights on LLMs, Compliance Attestations and Security Mental Models", and day five "SBOMs as the Crossroad of the Software Supply Chain". Learn SBOM Fundamentals in 1 Hour or Less Short on time but need to understand SBOMs yesterday? Start your educational journey with this single-serving webinar on SBOM fundamentals—watch it at 2x for a true ​​speedrun. https://vimeo.com/1077762819?share=copy Understanding SBOMs: An Introduction to Modern Development This webinar features Anchore's team of SBOM experts who guide you through all the SBOM basics - topics covered: Defining SBOM standards and formats Best practices for generating and automating SBOMs Integrating SBOMs into existing infrastructure and workflows Practical tips for protecting against emerging supply chain threats "You really need to know what you're shipping and what's there."—Josh Bressers This straightforward yet overlooked insight demonstrates the foundational nature of SBOMs to software supply chain security. Operating without visibility into your components creates significant security blind spots. SBOMs create the transparency needed to defend against the rising tide of supply chain attacks. Improve SBOM Initiative Success: Crystalize the Core ​​SBOM Mental Models Enjoyed the webinar but want to go deeper? Our eBook, SBOM 101: Understand, Implement & Leverage SBOMs for Stronger Security & Risk Management, covers similar ground but with the depth and nuance to level up your SBOM knowledge: Why SBOMs matter How to choose an SBOM format Explain how SBOMs are the central component of software supply chain A quick reference table of SBOM use-cases This gives you a strong foundation to build your SBOM initiative on. The mental models presented in the eBook help you:  avoid common implementation pitfalls,  align your SBOM strategy with security objectives, and  communicate SBOM value to stakeholders across your organization.  Rather than blindly following compliance requirements, you'll learn the "why" behind SBOMs and make informed decisions about automation tools, integration points, and formats that are best suited for your specific environment. Free Download SBOM Use-Cases: Generate Enterprise Value Across Entire Organization To round out your SBOM fundamentals education, How to Unlock Enterprise Value with SBOMs: Use Cases for Security, Engineering, Compliance, Legal and Sales is our white paper that deep dives into the surprisingly wide range of SBOM use-cases. SBOMs don't just provide value to security teams, they're a cross-functional technology that creates value across your organization. Security teams: Rapidly identify vulnerable components when zero-days hit the news Engineering teams: Make data-driven architecture decisions about third-party dependencies to incorporate Compliance teams: Automate evidence collection for compliance audits Legal teams: Proactively manage software license compliance and IP risks Sales teams: Accelerate sales cycles by using transparency as a tool to build trust fast "Transparency is the path to minimizing risk."—Kate Stewart, VP of Embedded Systems at The Linux Foundation and Founder of SPDX This core SBOM principle applies across all business functions. Our white paper shows how properly implemented SBOMs create a unified source of truth about your software components that empowers teams beyond security to make better decisions. Perfect for technical leaders who need to justify SBOM investments and drive cross-team adoption. Free Download What's Next? After completing the fundamentals, you're ready to get your hands dirty and learn the nitty-gritty of SBOM generation and CI/CD build pipeline integration. In our next post, we'll map out a technical learning path with deep-dives for practitioners looking to get hands-on experience. Stay tuned for part two of our series, "SBOM Generation Step-by-Step". Don't want to miss a day? Subscribe to our newsletter for updates or follow us on LinkedIn, X or BlueSky to get notifications as each post is published. ### Join Anchore Open Source Team: Live Stream ### Anchore’s SBOM Learning Week: From Reactive to Resilient in 5 Days Your software contains 150+ dependencies you didn't write, don't maintain, and can't fully audit—yet you're accountable for every vulnerability they introduce. Organizations implementing comprehensive SBOM strategies detect supply chain compromises in minutes instead of days—or worse after a breach. Anchore has been leading the SBOM charge for almost a decade: providing educational resources, tools and insights, and to help organizations secure their software supply chains. To help organizations navigate this critical aspect of software development, we're excited to announce SBOM Learning Week!  Each day of the week we will be publishing a new blog post that provides an overview of how to progress on your SBOM educational journey. By the end of the week, you will have a full learning path laid out to guide you from SBOM novice to SBOM expert. Why SBOM Learning Week, Why Now? With recent executive orders (e.g., EO 14028) mandating SBOMs for federal software vendors and industry standards increasingly recommending their adoption, organizations across sectors are racing to weave SBOMs into their software development lifecycle. However, many still struggle with fundamental questions: What exactly is an SBOM and why does it matter? How do I generate, manage, and leverage SBOMs effectively? How do I scale SBOM practices across a large organization? What do leading experts predict for the future of SBOM adoption? How do SBOMs integrate with existing security and development practices? SBOM Learning Week answers these questions through a carefully structured learning journey designed for both newcomers and experienced practitioners. What to Expect Each Day Monday: SBOM Fundamentals We'll start with the fundamentals, exploring what SBOMs are, why they matter, and the key standards that define them. This foundational knowledge will prepare you for the more advanced topics to come. Read Day 1: SBOM Fundamentals now Tuesday: Technical Deep-dives Day two focuses on hands-on implementation, with practical guidance for generating SBOMs using open source tools, integrating them into CI/CD pipelines, and examining how SBOM generation actually works under the hood. Read Day 2: SBOM Generation Step-by-Step now Wednesday: DevOps-Scale SBOM Management Moving beyond initial implementation, we'll explore how organizations can scale their SBOM practices across enterprise environments, featuring real-world examples from companies like Google. Read Day 3: DevOps-Scale SBOM Management now Thursday: SBOM Insights on LLMs, Compliance Attestations and Security Mental Models On day four, we'll share insights from industry thought leaders on how software supply chain security and SBOMs are adapting to LLMs, how SBOMs are better thought of as compliance data containers than supply chain documents and how SBOMs and vulnerability scanners fit into existing developer mental models. Read Day 4: SBOM Insights now Friday: SBOMs as the Crossroad of the Software Supply Chain We'll conclude by examining how SBOMs intersect with DevSecOps, open source security, and regulatory compliance, providing a holistic view of how SBOMs fit into the broader security landscape. Read Day 5: SBOM Intersections now Join Us on This Learning Journey Whether you're a security leader looking to strengthen your organization's defenses, a developer seeking to integrate security into your workflows, or an IT professional responsible for compliance, SBOM Learning Week offers valuable insights for your role. Each day's post will build on the previous content, creating a comprehensive resource you can reference as you develop and mature your organization's SBOM initiative. We'll also be monitoring comments and questions on our social channels (LinkedIn, BlueSky, X) throughout the week to help clarify concepts and address specific challenges you might face. Mark your calendars and join us starting Monday as we embark on this exploration of one of today's most important cybersecurity technologies. The journey to a more secure software supply chain begins with understanding what's in your code—and SBOM Week will show you exactly how to get there. Don't want to miss a day? Subscribe to our newsletter for updates or follow us on LinkedIn, X or BlueSky to get notifications as each post is published. ### Navigating the Path to Federal Markets: Your Complete FedRAMP Guide The federal cloud market is projected to reach $78+ billion by 2029, but only a small fraction of cloud providers have successfully achieved FedRAMP authorization. That's why we're excited to announce our new white paper, "Unlocking Federal Markets: The Enterprise Guide to FedRAMP." This comprehensive resource is designed for cloud service providers (CSPs) looking to navigate the complex FedRAMP authorization process, providing actionable insights and step-by-step guidance to help you access the lucrative federal cloud marketplace. From understanding the authorization process to implementing continuous monitoring requirements, this guide offers a clear roadmap through the FedRAMP journey. More than just a compliance checklist, it delivers strategic insights on how to approach FedRAMP as a business opportunity while minimizing the time and resources required. ⏱️ Can't wait till the end?📥 Download the white paper now 👇👇👇 Download Now Why FedRAMP Authorization Matters FedRAMP is the gateway to federal cloud business, but many organizations underestimate its complexity and strategic importance. Our white paper transforms your approach by: Clarifying the Authorization Process: Understand the difference between FedRAMP authorization and certification, and learn the specific roles of key stakeholders. Streamlining Compliance: Learn how to integrate security and compliance directly into your development lifecycle, reducing costs and accelerating time-to-market. Establishing Continuous Monitoring: Build sustainable processes that maintain your authorization status through the required continuous monitoring activities. Creating Business Value: Position your FedRAMP authorization as a competitive advantage that opens doors across multiple agencies. What's Inside the White Paper? Our guide is organized to follow your FedRAMP journey from start to finish. Here's a preview of what you'll find: FedRAMP Overview: Learn about the historical context, goals and benefits of the program. Key Stakeholders: Understand the roles of federal agencies, 3PAOs and the FedRAMP PMO. Authorization Process: Navigate through all phases—Preparation, Authorization and Continuous Monitoring—with detailed guidance for each step. Strategic Considerations: Make informed decisions about impact levels, deployment models and resource requirements. Compliance Automation: Discover how Anchore Enforce can transform FedRAMP from a burdensome audit exercise into a streamlined component of your software delivery pipeline. You'll also find practical insights on staffing your authorization effort, avoiding common pitfalls and estimating the level of effort required to achieve and maintain FedRAMP authorization. Transform Your Approach to Federal Compliance The white paper emphasizes that FedRAMP compliance isn't just a one-time hurdle but an ongoing commitment that requires a strategic approach. By treating compliance as an integral part of your DevSecOps practice—with automation, policy-as-code and continuous monitoring—you can turn FedRAMP from a cost center into a competitive advantage. Whether your organization is just beginning to explore FedRAMP or looking to optimize existing compliance processes, this guide provides the insights needed to build a sustainable approach that opens doors to federal business opportunities. Download the White Paper Today FedRAMP authorization is more than a compliance checkbox—it's a strategic enabler for your federal market strategy. Our comprehensive guide gives you the knowledge and tools to navigate this complex process successfully. 📥 Download the white paper now and unlock your path to federal markets. Learn how to navigate FedRAMP authorization while avoiding all of the most common pitfalls. Download Now ### Anchore Community Spotlight - Bringing Cloud Native Principles to the Developer Desktop ### From War Room to Workflow: How Anchore Transforms CVE Incident Response When CVE-2025-1974 (#IngressNightmare) was disclosed, incident response teams had hours—at most—before exploits appeared in the wild. Imagine two companies responding:  Company A rallies a war room with 13 different teams frantically running kubectl commands across the org’s 30+ clusters while debugging inconsistent permission issues.  Company B's security analyst runs a single query against their centralized SBOM inventory and their policy-as-code engine automatically dispatches alerts and remediation recommendations to affected teams.  Which camp would you rather be in when the next critical CVE drops? Most of us prefer the team that built visibility for their software supply chain security before the crisis hit. CVE-2025-1974 was particularly acute because of ingress-nginx's popularity as a Kubernetes Admission Controller (40%+ of Kubernetes administrators) and the type/severity of the vulnerability (RCE & CVSS 9.8—scary!) We won't go deep on the details; there are plenty of good existing resources already. Instead we'll focus on:  The inconsistency between the naive incident response guidance and real-world challenges The negative impacts common to incident response for enterprise-scale Kubernetes deployments How Anchore Enterprise alleviates these consequences The benefits of an integrated incident response strategy How to utilize Anchore Enterprise to respond in real-time to a security incident Learn how SBOMs enable organizations to react to zero-day disclosures in minutes rather than days or weeks. Save a Seat An Oversimplified Response to a Complex Threat When the Ingress Nightmare vulnerability was published, security blogs and advisories quickly filled with remediation advice. The standard recommendation was clear and seemed straightforward: run a simple kubectl command to determine if your organization was impacted: kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginxkubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx If vulnerable versions were found, upgrade immediately to the patched versions. This advice isn't technically wrong. The command will indeed identify instances of the vulnerable ingress-nginx controller. But it makes a set of assumptions that bear little resemblance to Kubernetes deployments in modern enterprise organizations: That you run a single Kubernetes cluster That you have a single Kubernetes administrator That this admin has global privileges across the entire cluster For the vast majority of enterprises today, none of these assumptions are true. The Reality of Enterprise-Scale Kubernetes: Complex & Manual The reality of Kubernetes deployments at large organizations is far more complex than most security advisories acknowledge: 1. Inherited Complexity Kubernetes administration structures almost always mirror organizational complexity. A typical enterprise doesn't have a single cluster managed by a single team—they have dozens of clusters spread across multiple business units, each with their own platform teams, their own access controls, and often their own security policies. This organizational structure, while necessary for business operations, creates significant friction for vital incident response activities; vulnerability detection and remediation. When a critical CVE like Ingress Nightmare drops, there's no single person who can run that kubectl command across all environments. 2. Vulnerability Management Remains Manual While organizations have embraced Kubernetes to automate their software delivery pipelines and increase velocity, the DevOps-ification of vulnerability and patch management have lagged. Instead they retain their manual, human-driven processes. During the Log4j incident in 2021, we observed engineers across industries frantically connecting to servers via SSH and manually dissecting container images, trying to determine if they were vulnerable. Three years later, for many organizations, the process hasn't meaningfully improved—they've just moved the complexity to Kubernetes. The idea that teams can manually track and patch vulnerabilities across a sprawling Kubernetes estate is not just optimistic—it's impossible at enterprise-scale. The Cascading Negative Impacts: Panic, Manual Coordination & Crisis Response When critical vulnerabilities emerge, organizations without supply chain visibility face: Organizational Panic: The CISO demands answers within the hour while security teams scramble through endless logs, completely blind to which systems contain the vulnerable components. Complex Manual Coordination: Security leads discover they need to scan hundreds of clusters but have access to barely a fifth of them, as Slack channels erupt with conflicting information and desperate access requests. Resource-Draining Incident Response: By day three of the unplanned war room, engineers with bloodshot eyes and unchanged clothes stare at monitors, missing family weekends while piecing together an ever-growing list of affected systems. Delayed Remediation: Six weeks after discovering the vulnerability in a critical payment processor, the patch remains undeployed as IT bureaucracy delays the maintenance window while exposed customer data hangs in the balance. The Solution: Centralized SBOM Inventory + Automated Policy Enforcement Organizations with mature software supply chain security leverage Anchore Enterprise to address these challenges through an integrated SBOM inventory and policy-as-code approach: 1. Anchore SBOM: Comprehensive Component Visibility Anchore Enterprise transforms vulnerability response through its industry-leading SBOM repository. When a critical vulnerability like Ingress Nightmare emerges, security teams use Anchore's intuitive dashboard to instantly answer the existential question: "Are we impacted?" This approach works because: Role-based access to a centralized inventory is provided by Anchore SBOM for security incident response teams, cataloging every component across all Kubernetes clusters regardless of administrative boundaries Components missed by standard package manager checks (including binaries, language-specific packages, and container base images) are identified by AnchoreCTL, a modern software composition analysis (SCA) scanner Vulnerability correlation in seconds is enabled through Anchore SBOM's repository with its purpose-built query engine, turning days of manual work into a simple search operation 2. Anchore Enforce: Automated Policy Enforcement Beyond just identifying vulnerable components, Anchore Enforce's policy engine integrates directly into an existing CI/CD pipeline (i.e., policy-as-code security gates). This automatically answers the follow-up questions: "Where and how do we remediate?" Anchore Enforce empowers teams to: Alert code owners to the specific location of vulnerable components Provide remediation recommendations directly in developer workflows (Jira, Slack, GitLab, GitHub, etc.) Eliminate manual coordination between security and development teams with the policy engine and DevTools-native integrations Quantifiable Benefits: No Panic, Reduced Effort & Reduced Risk Organizations that implement this approach see dramatic improvements across multiple dimensions: Eliminated Panic: The fear and uncertainty that typically accompany vulnerability disclosures disappear when you can answer "Does this impact us?" in minutes rather than days. Immediate clarity on the impact of the disclosure is at your finger tips with the Anchore SBOM inventory and Kubernetes Runtime Dashboard Reduced Detection Effort: The labor-intensive coordination between security, platform, and application teams becomes unnecessary. Security incident response teams already have access to all the data they need through the centralized Anchore SBOM inventory generated as part of normal CI/CD pipeline use. Minimized Exploitation Risk: The window of vulnerability shrinks dramatically as developers are able to address vulnerabilities before they can be exploited. Developers receive automated alerts and remediation recommendations from Anchore Enforce's policy engine that integrate natively with existing development workflows. How to Mitigate CVE-2025-1974 with Anchore Enterprise Let's walk through how to detect and mitigate CVE-2025-1974 with Anchore Enterprise across a Kubernetes cluster. The Kubernetes Runtime Dashboard serves as the user interface for your SBOM database. We'll demonstrate how to: Identify container images with ingress-nginx integrated Locate images where CVE-2025-1974 has been detected Generate reports of all vulnerable container images Generate reports of all vulnerable running container instances in your Kubernetes cluster Step 1: Identify location(s) of impacted assets The Anchore Enterprise Dashboard can be filtered to show all clusters with the ingress-nginx controller deployed. Thanks to the existing SBOM inventory of cluster assets, this becomes a straightforward task, allowing you to quickly pinpoint where vulnerable components might exist. Step 2: Drill into container image analysis for additional details By examining vulnerability and policy compliance analysis at the container image level, you gain increased visibility into the potential cluster impact. This detailed view helps prioritize remediation efforts based on risk levels. Step 3: Drill down into container image vulnerability report When you drill down into the CVE-2025-1974 vulnerability, you can view additional details that help understand its nature and impact. Note the vulnerability's unique identifier, which will be needed for subsequent steps. From here, you can click the 'Report' button to generate a comprehensive vulnerability report for CVE-2025-1974. Step 4: Configure a vulnerability report for CVE-2025-1974 To generate a report on all container images tagged with the CVE-2025-1974 unique vulnerability ID: Select the Vulnerability Id filter Paste the CVE-2025-1974 vulnerability ID into the filter field Click 'Preview Results' to see affected images Step 5: Generate container image vulnerability report The vulnerability report identifies all container images tagged with the unique vulnerability ID. To remediate the vulnerability effectively, base images that running instances are built from need to be updated to ensure the fix propagates across all cluster services. Step 6: Generate Kubernetes namespace vulnerability report While there may be only two base images containing the vulnerability, these images might be reused across multiple products and services in the Kubernetes cluster. A report based solely on base images can obscure the true scale of vulnerable assets in a cluster. A namespace-based report provides a more accurate picture of your exposure. Wrap-Up: Building Resilience Before the Crisis The next Ingress Nightmare-level vulnerability isn't a question of if, but when. Organizations that invest in software supply chain security before a crisis occurs will respond with targeted remediation rather than scrambling in war rooms. Anchore's SBOM-powered SCA provides the comprehensive visibility and automated policy enforcement needed to transform vulnerability response from a chaotic emergency into a routine, manageable process. By building software supply chain security into your DevSecOps pipeline today, you ensure you'll have the visibility you need when it matters most. Ready to see how Anchore Enterprise can strengthen your Kubernetes security posture? Request a demo today to learn how our solutions can help protect your critical infrastructure from vulnerabilities like CVE-2025-1974. Learn how Spectro Cloud secured their Kubernetes-based software supply chain and the pivotal role SBOMs played. Watch Now ### Accelerating Container Security on AWS: Introducing the Anchore Enterprise Cloud Image Today, we're launching the Anchore Enterprise Cloud Image, a pre-built image designed to dramatically reduce the complexity and time associated with deploying Anchore Enterprise in your AWS environment.  Anchore Enterprise Cloud Image is designed for practitioners working on small teams or projects that are focused on integrating robust container scanning and compliance checks into build pipelines, but perhaps without the immediate need for the full scale-out capabilities of a Kubernetes-based deployment. No working knowledge of Kubernetes is required in order to fully utilize SBOM powered Software Composition Analysis provided by Anchore Enterprise.  Addressing the Deployment Overhead: Anchore Enterprise has long been recognized for its powerful analysis engine and comprehensive policy enforcement, typically deployed on Kubernetes using Helm. While this architecture provides immense scalability, scheduling and flexibility for large organizations handling 10,000s of daily scans, we understand that for smaller teams or individual projects, the operational overhead of managing a Kubernetes cluster can be atime and resource burden. The Anchore Enterprise Cloud Image directly addresses this challenge. We've packaged a fully functional Anchore Enterprise instance into a ready-to-run Amazon Machine Image (AMI). This prescriptive deployment eliminates the need for intricate Kubernetes knowledge, allowing you to focus on securing your containers from day one. https://vimeo.com/1077945265?share=copy Key Features and Benefits for AWS Practitioners: Radically Simplified Deployment: Forget complex Helm charts and manual configuration. Simply launch the AMI from the AWS Marketplace in your preferred region (including GovCloud), and you're on your way. This significantly reduces the time and effort required for initial setup. Interactive Cloud Image Manager: We've introduced a user-friendly, console-based Cloud Image Manager that guides you through the initial configuration and manages upgrades. Upon booting the AMI, this tool intelligently assesses your AWS environment, ensures the correct resources are provisioned, and then prompts you for basic setup parameters. It then automates the installation and all of the services necessary to run it with their appropriate configurations. Guided First Scan Experience: Once the installation is complete, accessing the Anchore Enterprise UI is seamless. A new in-product wizard will walk you through the process of performing your first container image scan, allowing you to quickly experience the power of Anchore's deep analysis capabilities. Optimized Performance on Select Instance Types: We've rigorously tested Anchore Enterprise on a specific set of AWS instance types to identify the optimal balance of cost and performance for the application. This means we can provide you with deterministic performance guidelines regarding the volume of data the deployment can effectively process, allowing for better capacity planning and cost management. Integrated Compliance Policy Packs: For organizations with stringent compliance requirements, the Cloud Image simplifies the adoption of industry-standard policies. Based on your subscription entitlement, the Cloud Image will automatically install relevant policy packs, such as those aligned with NIST or FedRAMP frameworks. This ensures that your container security posture aligns with your regulatory needs from the outset. Who is this for? The Anchore Enterprise Cloud Image on AWS is ideal for: Small to medium-sized teams looking for a streamlined deployment experience. Projects that require immediate container scanning and compliance capabilities without the overhead of managing Kubernetes. Organizations seeking a prescriptive and easily manageable container security solution on AWS. Teams wanting to quickly evaluate the capabilities of Anchore Enterprise in their AWS environment. Getting Started We believe the Anchore Enterprise Cloud Image represents a significant step in making our powerful container security platform more accessible to a wider range of AWS customers. By abstracting away the complexities of infrastructure management, we empower you to focus on what matters most: securing your software supply chain. If you are interested in trying Anchore Enterprise as a Cloud Image, please contact sales.  ### The NVD Enrichment Crisis: One Year Later—How Anchore is Filling the Vulnerability Data Gap About one year ago, Anchore’s own Josh Bressers broke the story that NVD (National Vulnerability Database) was not keeping up with its vulnerability enrichment. This week, we sat down with Josh to see how things are going. > Josh, can you tell our readers what you mean when you say NVD stopped enriching data? Sure! When people or organizations disclose a new security vulnerability, it’s often just a CVE (Common Vulnerabilities and Exposures) number (like CVE-2024-1234) and a description.  Historically, NVD would take this data, and NVD analysts would add two key pieces of information: the CPEs (Common Platform Enumerations), which are meant to identify the affected software, and the CVSS (Common Vulnerability Scoring System) score, which is meant to give users of the data a sense of how serious the vulnerability is and how it can be exploited.  For many years, NVD kept up pretty well. Then, in March 2024, they stopped. > That sounds bad. Were they able to catch up? Not really.  One of the problems they face is that the number of CVEs in existence is growing exponentially. They were having trouble keeping up in 2024, but 2025 is making CVEs even faster than 2024 did, plus they have the backlog of CVEs that weren’t enriched during 2024.  It seems unlikely that they can catch up at this point. Graph showing how few CVE IDs are being enriched with matching data since April 2024 Graph showing the number of total CVEs (green) and the number of enriched CVEs (red). "The line slopes say it all"—NVD is behind and the number of unreviewed CVEs is growing. > So what’s the upshot here? Why should we care that NVD isn’t able to enrich vulnerabilities? Well, there are basically two problems with NVD not enriching vulnerabilities.  First, if they don’t have CPEs on them, there’s no machine-readable way to know what software they affect. In other words, part of the work NVD was doing is writing down what software (or hardware) is affected in a machine-readable way, enabling vulnerability scanners and other software to tell which components are affected.  The loss of this is obviously bad. It means that there is a big pile of security flaws that are public—meaning that threat actors know about them—but security teams will have a harder time detecting them. Un-enriched CVEs are not labeled with CPEs, so programmatic analysis is off the table and teams will have to fall back to manual review. Second, enrichment of CVEs is supposed to add a CVSS score—essentially a severity level—to CVEs. CVSS isn’t perfect, but it does allow organizations to say things like, “this vulnerability is very easy to exploit, so we need to get it fixed before this other CVE which is very hard to exploit.” Without CVSS or something like it, these tradeoffs are much harder for organizations to make. > And this has been going on for more than a year? That sounds bad. What is Anchore doing to keep their customers safe? The first thing we needed to do was make a place where we can take up some of the slack that NVD can’t. To do this, we created a public database of our own CVE enrichment. This means that, when major CVEs are disclosed, we can enrich them ahead of NVD, so that our scanning tools (both Grype and Anchore Secure) are able to detect vulnerable packages—even if NVD never has the resources to look into that particular CVE. Additionally, because NVD severity scores are becoming less reliable and less available, we’ve built a prioritization algorithm into Anchore Secure that allows customers to keep doing the kind of triaging they used to rely on NVD CVSS for. > Is the vulnerability enhancement data publicly available? Yes, the data is publicly available.  Also, the process for changing it is out in the open. One of the more frustrating things about working with NVD enrichment was that sometimes they would publish an enrichment with really bad data and then all you could do was email them—sometimes they would fix it right away and sometimes they would never get to it. With Anchore’s open vulnerability data, anyone in the community can review and comment on these enrichments. > So what are your big takeaways from the past year? I think the biggest takeaway is that we can still do vulnerability matching.  We’re pulling together our own public vulnerability database, plus data feeds from various Linux distributions and of course GitHub Security Advisories to give our customers the most accurate vulnerability scan we can. In many ways, reducing our reliance on NVD CPEs has improved our matching (see this post, for example). The other big takeaway is that, because so much of our data and tooling are open source, the community can benefit from and help with our efforts to provide the most accurate security tools in the world. > What can community members do to help? Well, first off, if you’re really interested in vulnerability data or have expertise with the security aspects of specific open source projects/operating systems, head on over to our vulnerability enhancement repo or start contributing to the tools that go into our matching like Syft, Grype, and Vunnel. But the other thing to do, and I think more people can do this, is just use our open source tools! File issues when you find things that aren’t perfect. Ask questions on our forum. And of course, when you get to the point that you have dozens of folders full of Syft SBOMs and tons of little scripts running Grype everywhere—call us—and we can let Anchore Enterprise take care of that for you. Learn the 5 best practices for container security and how SBOMs play a pivotal role in securing your software supply chain. Download Now ### Shift Right Security for EKS ### Automate Your Compliance: How Anchore Enforce Secures the Software Supply Chain In an era where a single line of compromised code can bring entire enterprise systems to their knees, software supply chain security has transformed from an afterthought to a mission-critical priority. The urgency is undeniable: while software supply chain attacks grew by a staggering 540% year-over-year from 2019 to 2022, organizations have rapidly responded.  Organizations have taken notice—the priority given to software supply chain security saw a remarkable 200% increase in 2024 alone, signaling a collective awakening to the existential threat of supply chain attacks. Cybercriminals are no longer just targeting individual applications—they're weaponizing the complex, interconnected software supply chains that power global businesses. To combat this rising threat, organizations are deploying platforms to automate BOTH detecting vulnerabilities AND enforcing supply chain security policies. This one-two combo is reducing the risk of a breach from a 3rd-party supplier from cascading into their software environment. Anchore Enforce, a module of Anchore Enterprise, enables organizations to automate both security and compliance policy checks throughout the development lifecycle. It allows teams to shift compliance left and easily generate reporting evidence for auditors by defining detailed security standards and internal best practices 'as-code'. In this blog post, we'll demonstrate how to get started with using Anchore Enforce's policy engine to automate both discovering non-compliant software and preventing it from reaching production. Learn about software supply chain security in the real-world with former Google Distinguish Engineer, Kelsey Hightower. Watch Now A Brief Primer on Policy-as-Code & Policy Packs Policy-as-code (PaC) translates organizational policies—whether security requirements, licensing restrictions, or compliance mandates—from human-readable documentation into machine-executable code that integrates with your existing DevSecOps platform and tooling. This typically comes in the form of a policy pack. A policy pack is a set of pre-defined security and compliance rules the policy engine executes to evaluate source code, container images or binaries. To make policy integration as easy as possible, Anchore Enforce comes with out-of-the-box policy packs for a number of popular compliance frameworks (e.g., FedRAMP or STIG compliance). A policy consists of three key components:  Triggers:  The code that checks whether a specific compliance control is present and configured correctly Gates:  A group of triggers that act as a checklist of security controls to check for Actions: A stop, warn or go directive explaining the policy-compliant action to take To better understand PaC and policy packs, we use airport security as an analogy. When you travel, you pass through multiple checkpoints, each designed to identify and catch different risks. At security screening, officers check for weapons, liquids, and explosives. At immigration control, officials verify visas and passports. If something is wrong, like an expired visa or a prohibited item, you might be stopped, warned, or denied entry. Anchore Enforce works in a similar way for container security. Policy gates act as checkpoints, ensuring only safe and compliant images are deployed. One aspect of a policy might check for vulnerabilities (like a security screening for dangerous items), while another ensures software licenses are valid (like immigration checking travel documents). If a container has a critical flaw such as a vulnerable version of Log4j it gets blocked, just like a flagged passenger would be stopped from boarding a flight. By enforcing these policies, Anchore Enforce helps secure an organization's software supply chain; just as airport security ensures dangerous passengers/items from making it through. If you're looking for a deeper dive on PaC, read Anchore's Developer's Guide to SBOMs & Policy-as-Code. Getting Started: the Developer Perspective Getting started with Anchore Enforce is easy but determining where to insert it into your workflow is critical. A perfect home for Anchore Enforce is distributed within the CI/CD process, specifically during the localised build process.  This approach enables rapid feedback for developers, providing a gate which can determine whether a build should progress or halt depending on your policies. Container images are great for software developers—they encapsulate an application and all of its dependencies into a portable package, providing consistency and simplified management. As a developer, you might be building a container image on a local machine or in a pipeline, using Docker and a dockerfile. For this example, we’ll assume you are using a GitLab Runner to run a job which builds an image for your application. We'll also be using AnchoreCTL, Anchore Enterprise's CLI tool to automate calling Anchore Enforce's policy engine to evaluate your container against the CIS security standard—a set of industry standard container security best practices. First, you’ll want to set a number of environment variables in your GitLab repository: ANCHORECTL_USERNAME (protected) ANCHORECTL_PASSWORD (protected and masked) ANCHORECTL_URL (protected) ANCHORECTL_ACCOUNT These variables will be used to authenticate against your Anchore Enterprise deployment. Anchore Enterprise also supports API keys.   Next, you’ll want to set up your GitLab Runner job definition whereby AnchoreCTL is run after you’ve built a container image. The job definition below shows how you might build an image, then run AnchoreCTL to perform a policy evaluation: ### Anchore Distributed Scan # You will need three variables defined: # ANCHORECTL_USERNAME # ANCHORECTL_PASSWORD # ANCHORECTL_URL # ANCHORECTL_ACCOUNT .login_gitlab_registry: - echo "$CI_REGISTRY_PASSWORD" | docker login $CI_REGISTRY -u $CI_REGISTRY_USER --password-stdin .install_anchorectl_alpine: - apk update && apk add curl - 'echo "Downloading anchorectl from: ${ANCHORECTL_URL}"' - 'curl $ANCHORECTL_URL/v2/system/anchorectl?operating_system=linux&architecture=amd64" -H "accept: */*" | tar -zx anchorectl && mv -v anchorectl /usr/bin && chmod +x /usr/bin/anchorectl && /usr/bin/anchorectl version' image: docker:latest services: - docker:dind stages: - build - anchore variables: ANCHORECTL_FAIL_BASED_ON_RESULTS: "true" ANCHORE_IMAGE: ${CI_REGISTRY_IMAGE}:${CI_COMMIT_REF_SLUG} Build: stage: build before_script: - !reference [.login_gitlab_registry] script: - docker build -t ${ANCHORE_IMAGE} . - docker push ${ANCHORE_IMAGE} Anchore: stage: anchore before_script: - !reference [.install_anchorectl_alpine] - !reference [.login_gitlab_registry] script: - 'export PATH="${HOME}/.local/bin/:${PATH}"' ### scan image and push to anchore enterprise - anchorectl image add --no-auto-subscribe --wait --dockerfile ./Dockerfile --from registry ${ANCHORE_IMAGE} ### then get the results: - anchorectl image check --detail ${ANCHORE_IMAGE} The following environment variable (which can also be passed as the -f flag to AnchoreCTL) ensures that the return code is set to 1 if the policy evaluation result shows as 'fail'. You can use this to break your build:   ANCHORECTL_FAIL_BASED_ON_RESULTS: "true" Then the AnchoreCTL image check command can be used to either validate against the default policy or specifically against a given policy (using the -p flag). This could be useful since your account in Anchore Enterprise can only have one default policy permanently active: anchorectl image check --detail ${ANCHORE_IMAGE} -p When executed, this pipeline will scan your container image against your selected policy requirements and immediately provide feedback. Developers see exactly which policy gates failed and receive specific remediation steps, often as simple as updating a package or adjusting a configuration parameter. And that’s it! With a few extra lines in your job definition, you’re now validating your newly built image against Anchore Enterprise for policy violations. On failure, the job will stop and if the build fails in this manner, the --detail option will give you an explanation of failures with remediation recommendations! This is a great way to get fast feedback and stop/warn/go directives directly within the development flow.  Operationalizing Compliance Checks:  the Security Engineer Perspective While developers benefit from shift-left security checks during builds, security teams need a broader view across the entire container landscape. They’ll likely be working to scan containers after they are built by the development teams, having already been pushed or staged testing or even deployed and already running. The critical requirement for the security team is the need to evaluate a large number of images regularly for the latest critical vulnerabilities. This can also be done with policy evaluation; feeding everything in the registry through policy gates.  Below you can see how the team might manage this via the Anchore Enforce user interface (UI). The security team has access to a range of policies, including: CIS (included by default in all Anchore Enterprise deployments) NIST 800-53 NIST 800-190 US DoD (Iron Bank) DISA FedRAMP For this UI walkthrough, we will demonstrate the use-case using the CIS policy pack. Navigate to the policy section in your Anchore UI and activate your desired policy. If you are an Anchore customer and do not have a desired policy pack, contact our Customer Success team for further information on entitlements. Once this is activated, we will see how this is set in action by scanning an image.  Navigate to Images, and select the image you want to check for compliance by clicking on the image digest.  Once the policy check is complete, you will see a screen containing the results of the policy check. This screen displays the actions applied to various artifacts based on Anchore Enforce's policy engine findings, aligned with the rules defined in the policy packs. It also highlights the specific rule an artifact is failing. Based on these results, you can determine the appropriate remediation approach.  The security team can generate reports in JSON or CSV format, simplifying the sharing of compliance check results. Wrap-Up As software supply chain attacks continue to evolve and grow in sophistication, organizations need robust, automated solutions to protect their environments. Anchore Enforce delivers exactly that by providing: Automated compliance enforcement that catches issues early in the development process, when they're easiest and least expensive to fix Comprehensive policy coverage with pre-built packs for major standards like CIS, NIST, and FedRAMP that eliminate the need to translate complex requirements into executable controls Flexible implementation options for both developers seeking immediate feedback and security teams managing enterprise-wide compliance Actionable remediation guidance that helps teams quickly address policy violations without extensive research or security expertise By integrating Anchore Enforce into your DevSecOps workflow, you're not just checking a compliance box—you're establishing a powerful defense against the rising tide of supply chain attacks. You're also saving developer time, reducing friction between security and development teams, and building confidence with customers and regulators who demand proof of your security posture. The software supply chain security challenge isn't going away. With Anchore Enforce, you can meet it head-on with automation that scales with your organization. Reach out to our team to learn more or start a free trial to kick the tires yourself. Automate FedRAMP and STIG compliance with Anchore Enterprise. Get instant access with a 15-day free trial. START FREE TRIAL ### How to Identify and Tackle SBOM Sprawl ### The Critical Role of SBOMs in PCI DSS 4.0 Compliance Is your organization's PCI compliance coming up for renewal in 2025? Or are you looking to achieve PCI compliance for the first time? Version 4.0 of the Payment Card Industry Data Security Standard (PCI DSS) became mandatory on March 31, 2025. For enterprise's utilizing a 3rd-party software software supply chain—essentially all companies, according to The Linux Foundation's report on open source penetration—PCI DSS v4.0 requires companies to maintain comprehensive inventories of supply chain components. The SBOM standard has become the cybersecurity industry's consensus best practice for securing software supply chains and meeting the requirements mandated by regulatory compliance frameworks. This document serves as a comprehensive guide to understanding the pivotal role of SBOMs in navigating the complexities of PCI DSS v4.0 compliance. Learn about the role that SBOMs for the security of your organization in this white paper. Download Now Understanding the Fundamentals: PCI DSS 4.0 and SBOMs What is PCI DSS 4.0? Developed to strengthen payment account data (e.g., credit cards) security and standardize security controls globally, PCI DSS v4.0 represents the next evolution of this standard; ultimately benefiting consumers worldwide.  This version supersedes PCI DSS 3.2.1, which was retired on March 31, 2023. The explicit goals of PCI DSS v4.0 include promoting security as a continuous process, enhancing flexibility in implementation, and introducing enhancements in validation methods. PCI DSS v4.0 achieved this by introducing a total of 64 new security controls. NOTE: PCI DSS had a minor version bump to 4.0.1 in mid-2024. The update is limited and doesn't add or remove any controls or change any deadlines, meaning the software supply chain requirements apply to both versions. Demystifying SBOMs A software bill of materials (SBOM) is fundamentally an inventory of all software dependencies utilized by a given application. Analogous to a "Bill of Materials" in manufacturing, which lists all raw materials and components used to produce a product, an SBOM provides a detailed list of software components, including libraries, 3rd-party software, and services, that constitute an application.  The benefits of maintaining SBOMs are manifold, including enhanced transparency into the software supply chain, improved vulnerability management by identifying at-risk components, facilitating license compliance management, and providing a foundation for comprehensive supply chain risk assessment. How SBOMs Address PCI DSS 4.0 Requirements—The Critical Link PCI DSS Requirement 6: Develop and Maintain Secure Systems and Software PCI DSS Principal Requirement 6, titled “Develop and Maintain Secure Systems and Software,” aims to ensure the creation and upkeep of secure systems and applications through robust security measures and regular vulnerability assessments and updates. This requirement encompasses five primary areas: Processes and mechanisms for developing and maintaining secure systems and software are defined and understood Bespoke and custom software are developed securely Security vulnerabilities are identified and addressed Public-facing web applications are protected against attacks Changes to all system components are managed securely Deep Dive into Requirement 6.3.2: Component Inventory for Vulnerability Management Within the “Security vulnerabilities are identified and addressed” category of Requirement 6, Requirement 6.3.2 mandates:  An inventory of bespoke and custom software, and 3rd-party software components incorporated into bespoke and custom software is maintained to facilitate vulnerability and patch management The purpose of this evolving requirement is to enable organizations to effectively manage vulnerabilities and patches within all software components, including 3rd-party components such as libraries and APIs embedded in their bespoke and custom software.  While PCI DSS v4.0 does not explicitly prescribe the use of SBOMs, they represent the cybersecurity industry's consensus method for achieving compliance with this requirement by providing a detailed and readily accessible inventory of software components. How SBOMs Enable Compliance with 6.3.2 By requiring an inventory of all software components, Requirement 6.3.2 necessitates a mechanism for comprehensive tracking. SBOMs automatically generate an inventory of all components in use, whether developed internally or sourced from third parties. This detailed inventory forms the bedrock for identifying known vulnerabilities associated with these components. Platforms leveraging SBOMs can map component inventories to databases of known vulnerabilities, providing continuous insights into potential risks.  Consequently, SBOMs are instrumental in facilitating effective vulnerability and patch management by enabling organizations to understand their software supply chain and prioritize remediation efforts. Connecting SBOMs to other relevant PCI DSS 4.0 Requirements Beyond Requirement 6.3.2, SBOMs offer synergistic benefits in achieving compliance with other aspects of PCI DSS v4.0. Requirement 11.3.1.1  This requirement necessitates the resolution of high-risk or critical vulnerabilities. SBOMs enable ongoing vulnerability monitoring, providing alerts for newly disclosed vulnerabilities affecting the identified software components, thereby complementing the requirement for tri-annual vulnerability scans.  Platforms like Anchore Secure can track newly disclosed vulnerabilities against SBOM inventories, facilitating proactive risk mitigation. Implementing SBOMs for PCI DSS 4.0: Practical Guidance Generating Your First SBOM The generation of SBOMs can be achieved through various methods. A Software Composition Analysis (SCA) tool, like the open source SCA Syft or the commercial AnchoreCTL, offer automated software composition scanning and SBOM generation for source code, containers or software binaries. Looking for a step-by-step "how to" guide for generating your first SBOM? Read our technical guide. These tools integrate with build pipelines and can output SBOMs in standard formats like SPDX and CycloneDX. For legacy systems or situations where automated tools have limitations, manual inventory processes may be necessary, although this approach is generally less scalable and prone to inaccuracies.  Regardless of the method, it is crucial to ensure the accuracy and completeness of the SBOM, including both direct and transitive software dependencies. Essential Elements of an SBOM for PCI DSS While PCI DSS v4.0 does not mandate specific data fields for SBOMs, it is prudent to include essential information that facilitates vulnerability management and component tracking. Drawing from recommendations by the National Telecommunications and Information Administration (NTIA), a robust SBOM should, at a minimum, contain: Component Name Version String Supplier Name Unique Identifier (e.g., PURL or CPE) Component Hash Author Name Operationalizing SBOMs: Beyond Inventory The true value of an SBOM lies in its active utilization for software supply chain use-cases beyond component inventory management. Vulnerability Management SBOMs serve as the foundation for continuous vulnerability monitoring. By integrating SBOM data with vulnerability databases, organizations can proactively identify components with known vulnerabilities. Platforms like Anchore Secure enable the mapping of SBOMs to known vulnerabilities, tracking exploitability and patching cadence. Patch Management A comprehensive SBOM facilitates informed patch management by highlighting the specific components that require updating to address identified vulnerabilities. This allows security teams to prioritize patching efforts based on the severity and exploitability of the vulnerabilities within their software ecosystem. Maintaining Vulnerability Remediation Documentation It is essential to maintain thorough documentation of vulnerability remediation efforts in order to achieve the emerging continuous compliance trend from global regulatory bodies. Utilizing formats like CVE (Common vulnerabilities and Exposures) or VEX (Vulnerability Exploitability eXchange) alongside SBOMs can provide a standardized way to communicate the status of vulnerabilities, whether a product is affected, and the steps taken for mitigation. Acquiring SBOMs from Third-Party Suppliers PCI DSS Requirement 6.3.2 explicitly includes 3rd-party software components. Therefore, organizations must not only generate SBOMs for their own bespoke and custom software but also obtain SBOMs from their technology vendors for any libraries, applications, or APIs that are part of the card processing environment. Engaging with suppliers to request SBOMs, potentially incorporating this requirement into contractual agreements, is a critical step. It is advisable to communicate preferred SBOM formats (e.g., CycloneDX, SPDX) and desired data fields to ensure the received SBOMs are compatible with internal vulnerability management processes. Challenges may arise if suppliers lack the capability to produce accurate SBOMs; in such instances, alternative risk mitigation strategies and ongoing communication are necessary. NOTE: Remember the OSS maintainers that authored the open source components integrated into your application code are NOT 3rd-party suppliers in the traditional sense—you are! Almost all OSS licenses contain an "as is" clause that absolves them of liability for any code quality issues like vulnerabilities. This means that by using their code, you are now responsible for any security vulnerabilities in the code (both known and unknown). Navigating the Challenges and Ensuring Success Addressing Common Challenges in SBOM Adoption Implementing SBOMs across an organization can present several challenges: Generating SBOMs for closed-source or legacy systems where build tool integration is difficult may require specialized tools or manual effort The volume and frequency of software updates necessitate automated processes for SBOM generation and continuous monitoring Ensuring the accuracy and completeness of SBOM data, including all levels of dependencies, is crucial for effective risk management Integrating SBOM management into existing software development lifecycle (SDLC) and security workflows requires collaboration and process adjustments Effective SBOM adoption necessitates cross-functional collaboration between development, security, and procurement teams to establish policies and manage vendor relationships Best Practices for SBOM Management To ensure the sustained effectiveness of SBOMs for PCI DSS v4.0 compliance and beyond, organizations should adopt the following best practices: Automate SBOM generation and updates wherever possible to maintain accuracy and reduce manual effort Establish clear internal SBOM policies regarding format, data fields, update frequency, and retention Select and implement appropriate SBOM management tooling that integrates with existing security and development infrastructure Clearly define roles and responsibilities for SBOM creation, maintenance, and utilization across relevant teams Provide education and training to development, security, and procurement teams on the importance and practical application of SBOMs The Broader Landscape: SBOMs Beyond PCI DSS 4.0 As predicted, the global regulatory push toward software supply chain security and risk management with SBOMs as the foundation continues to gain momentum in 2025. PCI DSS v4.0 is the next major regulatory framework embracing SBOMs. This follows the pattern set by the US Executive Order 14028 and the EU Cyber Resilience Act, further cementing SBOMs as a cornerstone of modern cybersecurity best practice.  Wrap-Up: Embracing SBOMs for a Secure Payment Ecosystem The integration of SBOMs into PCI DSS v4.0 signifies a fundamental shift towards a more secure and transparent payment ecosystem. SBOMs are no longer merely a recommended practice but a critical component for achieving and maintaining compliance with the evolving requirements of PCI DSS v4.0, particularly Requirement 6.3.2.  By providing a comprehensive inventory of software components and their dependencies, SBOMs empower organizations to enhance their security posture, reduce the risk of costly data breaches, improve their vulnerability management capabilities, and effectively navigate the complexities of regulatory compliance. Embracing SBOM implementation is not just about meeting a requirement; it is about building a more resilient and trustworthy software foundation for handling sensitive payment card data. If you're interested to learn more about how Anchore Enterprise can help your organization harden their software supply chain and achieve PCI DSS v4.0 compliance, get in touch with our team! Interested to learn about all of the software supply chain use-cases that SBOMs enable? Read our new white paper and start unlocking enterprise value. Download Now ### Generating SBOMs for JavaScript Projects: A Developer's Guide Let's be honest: modern JavaScript projects can feel like a tangled web of packages. Knowing exactly what's in your final build is crucial, especially with rising security concerns. That's where a Software Bill of Materials (SBOM) comes in handy – it lists out all the components. We'll walk you through creating SBOMs for your JavaScript projects using Anchore's open-source tool called Syft, which makes the process surprisingly easy (and free!). Why You Need SBOMs for Your JavaScript Projects JavaScript developers face unique supply chain security challenges. The NPM ecosystem has seen numerous security incidents, from protestware to dependency confusion attacks. With most JavaScript applications containing hundreds or even thousands of dependencies, manually tracking each one becomes impossible. SBOMs solve this problem by providing: Vulnerability management: Quickly identify affected packages when new vulnerabilities emerge License compliance: Track open source license obligations across all dependencies Dependency visibility: Map your complete software supply chain Regulatory compliance: Meet evolving government and industry requirements Let's explore how to generate SBOMs across different JavaScript project scenarios. Getting Started with Syft Syft is an open source SBOM generation tool that supports multiple formats including SPDX and CycloneDX. It's written in Go, and ships as a single binary. Let's install it: For Linux & macOS: # Install the latest release of Syft using our installer script curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin Alternatively, use Homebrew on macOS: brew install syft For Microsoft Windows: winget install Anchore.Syft Verify the installation: syft version Application: syft Version: 1.20.0 BuildDate: 2025-02-21T20:44:47Z GitCommit: 46522bcc5dff8b65b61a7cda1393abe515802306 GitDescription: v1.20.0 Platform: darwin/arm64 GoVersion: go1.24.0 Compiler: gc Scenario 1: Scanning a JavaScript Container Image Let's start by scanning a container image of EverShop, an open source NodeJS e-commerce platform. Container scanning is perfect for projects already containerized or when you want to analyze production-equivalent environments. # Pull and scan the specified container syft evershop/evershop:latest Here's the first few lines, which summarise the work Syft has done. ✔ Loaded image evershop/evershop:latest ✔ Parsed image sha256:d29e670d6b2ada863… ✔ Cataloged contents 9f402cbc7ddf769ce068a101… ├── ✔ Packages [1,188 packages] ├── ✔ File digests [1,255 files] ├── ✔ File metadata [1,255 locations] └── ✔ Executables [26 executables] Next is a human-readable table consisting of the name of the software package, the version found and the type which could be npm, deb, rpm and so-on. The output is very long (over a thousand lines), because, as we know, javascript applications often contain many packages. We're only showing the first and last few lines here: NAME VERSION TYPE @alloc/quick-lru 5.2.0 npm @ampproject/remapping 2.3.0 npm @babel/cli 7.26.4 npm @babel/code-frame 7.26.2 npm @babel/compat-data 7.26.3 npm ⋮ yargs 16.2.0 npm yargs-parser 20.2.9 npm yarn 1.22.22 npm zero-decimal-currencies 1.2.0 npm zlib 1.3.1-r2 apk The output shows a comprehensive inventory of packages found in the container, including: System packages (like Ubuntu/Debian packages) Node.js dependencies from package.json Other language dependencies if present For a more structured output that can be consumed by other tools, use format options: # Scan the container and output a CycloneDX SBOM syft evershop/evershop:latest -o cyclonedx-json > ./evershop-sbom.json This command generates a CycloneDX JSON SBOM, which is widely supported by security tools and can be shared with customers or partners. Scenario 2: Scanning Source Code Directories When working with source code only, Syft can extract dependency information directly from package manifest files. Let's clone the EverShop repository and scan it: # Clone the repo git clone https://github.com/evershopcommerce/evershop.git cd ./evershop # Check out the latest release git checkout v1.2.2 # Create a human readble list of contents syft dir:. ✔ Indexed file system . ✔ Cataloged contents cdb4ee2aea69cc6a83331bbe96dc2c… ├── ✔ Packages [1,045 packages] ├── ✔ File digests [3 files] ├── ✔ File metadata [3 locations] └── ✔ Executables [0 executables] [0000] WARN no explicit name and version provided for directory source, deriving artifact ID from the given path (which is not ideal) NAME VERSION TYPE @alloc/quick-lru. 5.2.0 npm @ampproject/remapping 2.3.0 npm @aws-crypto/crc32 5.2.0 npm @aws-crypto/crc32c 5.2.0 npm @aws-crypto/sha1-browser 5.2.0 npm ⋮ yaml 1.10.2 npm yaml 2.6.0 npm yargs 16.2.0 npm yargs-parser 20.2.9 npm zero-decimal-currencies 1.2.0 npm The source-only scan focuses on dependencies declared in package.json files but won't include installed packages in node_modules or system libraries that might be present in a container. For tracking changes between versions, we can check out a specific tag: # Check out an earlier tag from over a year ago git checkout v1.0.0 # Create a machine readable SBOM document in SPDX format syft dir:. -o spdx-json > ./evershop-v1.0.0-sbom.json Scenario 3: Scanning a Built Project on Your Workstation For the most complete view of your JavaScript project, scan the entire built project with installed dependencies: # Assuming you're in your project directory and have run npm install syft dir:. -o spdx-json > ./evershop-v1.2.2-sbom.json # Grab five random examples from the SBOM with version and license info jq '.packages[] | "\(.name) \(.versionInfo) \(.licenseDeclared)"' \ < ./evershop-v1.2.2-sbom.json | shuf | head -n 5 "pretty-time 1.1.0 MIT" "postcss-js 4.0.1 MIT" "minimist 1.2.8 MIT" "@evershop/postgres-query-builder 1.2.0 MIT" "path-type 4.0.0 MIT" This approach captures: Declared dependencies from package.json Actual installed packages in node_modules Development dependencies if they're installed Any other files that might contain package information Going Beyond SBOM Generation: Finding Vulnerabilities with Grype An SBOM is most valuable when you use it to identify security issues. Grype, another open source tool from Anchore, can scan directly or use Syft SBOMs to find vulnerabilities. For Linux & macOS: # Install the latest release of Grype using our installer script curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin Alternatively, use Homebrew on macOS: brew install grype For Microsoft Windows: winget install Anchore.Grype Verify the installation: grype version Application: grype Version: 0.89.1 BuildDate: 2025-03-13T20:22:27Z GitCommit: 718ea3060267edcae7b10a9bf16c0acdad10820a GitDescription: v0.89.1 Platform: darwin/arm64 GoVersion: go1.24.1 Compiler: gc Syft Version: v1.20.0 Supported DB Schema: 6 Let's check an older version of EverShop for known vulnerabilities. Note that the first time you run grype, it will download a ~66MB daily vulnerability database and unpack it. # Clone the example repo, if we haven't already git clone https://github.com/evershopcommerce/evershop.git cd ./evershop # Check out an older release of the application from > 1 year ago git checkout v1.0.0 # Create an SPDX formatted SBOM and keep it syft dir:. -o spdx-json > ./evershop-v1.0.0-sbom.json # Scan the SBOM for known vulnerabilities grype ./evershop-v1.0.0-sbom.json We can also scan the directory directly with Grype, which leverages Syft internally. However, it's usually preferable to use Syft to generate the SBOM initially, because that's a time consuming part of the process. grype dir:. Either way we run it, Grype identifies vulnerabilities in the dependencies, showing severity levels, the vulnerability ID, and version that the issue was fixed in. ✔ Scanned for vulnerabilities [43 vulnerability matches] ├── by severity: 2 critical, 19 high, 14 medium, 8 low, 0 negligible └── by status: 40 fixed, 3 not-fixed, 0 ignored NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY @babel/helpers 7.20.7 7.26.10 npm GHSA-968p-4wvh-cqc8 Medium @babel/runtime 7.22.5 7.26.10 npm GHSA-968p-4wvh-cqc8 Medium @babel/traverse 7.20.12 7.23.2 npm GHSA-67hx-6x53-jw92 Critical @evershop/evershop 1.0.0-rc.8 1.0.0-rc.9 npm GHSA-32r3-57hp-cgfw Critical @evershop/evershop 1.0.0-rc.8 1.0.0-rc.9 npm GHSA-ggpm-9qfx-mhwg High axios 0.21.4 1.8.2 npm GHSA-jr5f-v2jv-69x6 High ⋮ We can even ask Grype to explain the vulnerabilities in more detail. Let's take one of the critical vulnerabilities and get Grype to elaborate on the details. Note that we are scanning the existing SBOM, which is faster than running Grype against the container or directory, as it skips the need to build the SBOM internally. grype ./evershop-v1.0.0-sbom.json -o json | grype explain --id GHSA-67hx-6x53-jw92 The output is a human readable description with clickable links to find out more from the upstream sources. GHSA-67hx-6x53-jw92 from github:language:javascript (Critical) Babel vulnerable to arbitrary code execution when compiling specifically crafted malicious code Related vulnerabilities: - nvd:cpe CVE-2023-45133 (High) Matched packages: - Package: @babel/traverse, version: 7.20.12 PURL: pkg:npm/%40babel/traverse@7.20.12 Match explanation(s): - github:language:javascript:GHSA-67hx-6x53-jw92 Direct match (package name, version, and ecosystem) against @babel/traverse (version 7.20.12). Locations: URLs: - https://github.com/advisories/GHSA-67hx-6x53-jw92 - https://nvd.nist.gov/vuln/detail/CVE-2023-45133 Auditing Licenses with Grant Security isn't the only compliance concern for JavaScript developers. Grant helps audit license compliance based on the SBOM data. For Linux & macOS: curl -sSfL https://raw.githubusercontent.com/anchore/grant/main/install.sh | sh -s -- -b /usr/local/bin Alternatively, use Homebrew on macOS: brew install anchore/grant/grant Grant is not currently published for Microsoft Windows, but can be built from source. Verify the installation: grant version Application: grant Version: 0.2.6 BuildDate: 2025-01-22T21:09:16Z GitCommit: d24cecfd62c471577bef8139ad28a8078604589e GitDescription: v0.2.6 Platform: darwin/arm64 GoVersion: go1.23.4 Compiler: gc # Analyze licenses used by packages listed in the SBOM grant analyze -s evershop-sbom.json Grant identifies licenses for each component and flags any potential license compliance issues in your dependencies. By default the Grant configuration has a deny-all for all licenses. * ./evershop-v1.0.0-sbom.json * license matches for rule: default-deny-all; matched with pattern * * Apache-2.0 * Artistic-2.0 * BSD-2-Clause * BSD-3-Clause * CC-BY-3.0 * CC0-1.0 * ISC * MIT * Unlicense * WTFPL Finding out which packages are under what license is straightforward with the --show-packages option: grant check ./evershop-v1.0.0-sbom.json --show-packages * ./evershop-v1.0.0-sbom.json * license matches for rule: default-deny-all; matched with pattern * * Apache-2.0 * @ampproject/remapping * @webassemblyjs/leb128 * @xtuc/long * acorn-node * ansi-html-community ⋮ Integrating SBOMs into Your Development Workflow For maximum benefit, integrate SBOM generation and vulnerability scanning into your CI/CD pipeline: Generate during builds: Add SBOM generation to your build process Scan for vulnerabilities: Automatically check for security issues Store SBOMs as artifacts: Keep them alongside each release Track changes: Compare SBOMs between versions to identify supply chain changes For example, in GitHub workflows use our sbom-action and scan-action, built on Syft and Grype: jobs: build: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v4 - name: Create SBOM uses: anchore/sbom-action@v0 id: sbom with: format: spdx-json output-file: "${{ github.event.repository.name }}-sbom.spdx.json" - name: Scan SBOM uses: anchore/scan-action@v6 id: scan with: sbom: "${{ github.event.repository.name }}-sbom.spdx.json" fail-build: false severity-cutoff: medium output-format: json - name: Upload SBOM as artifact uses: actions/upload-artifact@v2 with: name: sbom.json path: sarif_file: ${{ steps.sbom.outputs.sbom }} Best Practices for JavaScript SBOM Generation Generate SBOMs for both development and production dependencies: Each has different security implications Use package lockfiles: These provide deterministic builds and more accurate SBOM generation Include SBOMs in your release process: Make them available to users of your libraries or applications Automate the scanning process: Don't rely on manual checks Keep tools updated: Vulnerability databases are constantly evolving Wrapping Up The JavaScript ecosystem moves incredibly fast, and keeping track of what's in your apps can feel like a never-ending battle. That's where tools like Syft, Grype, and Grant come in. They give you X-ray vision into your dependencies without the hassle of sign-ups, API keys, or usage limits. Once developers start generating SBOMs and actually see what's lurking in their node_modules folders, they can't imagine going back to flying blind. Whether you're trying to patch the next Log4j-style vulnerability in record time or just making sure you're not accidentally violating license terms, having that dependency data at your fingertips is a game-changer. Give these tools a spin in your next project. Your future self will thank you when that critical security advisory hits your inbox, and you can immediately tell if you're affected and exactly where. Want to learn more about software supply chain security? Check out our resources on SBOM management and container vulnerability scanning. ### Truth in IT: Keeping Your Code Shipshape with SBOMs! ### What is DevSecOps? Here at Anchore, we consistently work with our users and customers to improve the security of their container images. During these conversations, there is typically an initiative to embed container image scanning into CI/CD pipelines to meet DevSecOps goals. But what do we mean when we say DevSecOps? We can think of DevSecOps as empowering engineering teams to take ownership of how their products will perform in production by integrating security practices into their existing automation and DevOps workflow. A core principle of DevSecOps is creating a 'Security as Code' culture. Now that's there is increased transparency and collaboration, security is now everyone's responsibility. By building on the cultural changes of the DevOps framework, security teams are added to DevOps initiatives early to help plan for security automation. Additionally, security engineers should constantly be providing feedback and educating both Ops and development teams on best practices. What are the Benefits of DevSecOps? There are quite a few benefits to including security practices to the software development and delivery lifecycle. I've listed some of the core benefits below: Costs are reduced by uncovering and fixing security issues further left in the development lifecycle versus in production environments. Speed of product delivery is increased by incorporating automated security tests versus adding security testing at the end of lifecycle. Increased transparency and team collaboration leads to faster detection and recovery of threats. Implementing immutable infrastructure improves overall security by reducing vulnerabilities, increasing automation, and encourages organizations to move to the cloud. When thinking about what tooling and tests to put in place, organizations should look at their entire development lifecycle and environment. This can often include source control, third-party libraries, container registries, CI/CD pipelines, and orchestration and release tools. Anchore and DevSecOps As a container security company, we strongly believe containers help with a successful journey to DevSecOps. Containers are lightweight, faster than VMs, and allow developers to create predictable, scalable environments isolated from other applications or services. This leads to increased productivity across all teams, faster development, and less time fixing bugs and other environment issues. Containers are also immutable, meaning unchanged once created. To fix a vulnerable container, it is simply replaced by a patched, newer version. When planning security steps in a continuous integration pipeline, I often recommend adding a mandatory image analysis step to uncover vulnerable packages, secrets, credentials, or misconfigurations prior to the image being pushed to a production registry. As part of this image scanning step, I also recommend enforcing policies on the contents of the container images that have just been analyzed. Anchore policies are made up of a set of user-defined rules such as: Security vulnerabilities Image manifest changes Configuration file contents Presence of credentials in an image Unused exposed ports Package whitelists and blacklists Based on the rules created and the final result of the policy evaluation, users can choose to fail the image scanning step of a CI build, and not promote the image to a production container registry. The integration of a flexible policy engine helps organizations stay on top of compliance requirements constantly and can react faster if audited. Security teams responsible for creating policy rules should be educating developers on why these rules are being created and what steps they can take to avoid breaking them. Conclusion DevSecOps means integrating security practices into application development from start to finish. Not only does this require new tooling, automation, and integration, but it also involves a significant culture change and investment from every developer, release engineer, and security engineer. Everyone is responsible for openness, feedback, and education. Once the culture is intact and in place, DevSecOps practices and processes can be implemented to achieve a more secure development process as a whole. ### The Developer's Guide to SBOMs & Policy-as-Code If you're a developer, this vignette may strike a chord: You're deep in the flow, making great progress on your latest feature, when someone from the security team sends you an urgent message. A vulnerability has been discovered in one of your dependencies and has failed a compliance review. Suddenly, your day is derailed as you shift from coding to a gauntlet of bureaucratic meetings. This is an unfortunate reality for developers at organizations where security and compliance are bolt-on processes rather than integrated parts of the whole. Your valuable development time is consumed with digging through arcane compliance documentation, attending security reviews and being relegated to compliance training sessions. Every context switch becomes another drag on your productivity, and every delayed deployment impacts your ability to ship code. Two niche DevSecOps/software supply chain technologies have come together to transform the dynamic between developers and organizational policy—software bills of materials (SBOMs) and policy-as-code (PaC). Together, they dramatically reduce the friction between development velocity and risk management requirements by making policy evaluation and enforcement: Automated and consistent Integrated into your existing workflows Visible early in the development process In this guide, we'll explore how SBOMs and policy-as-code work, the specific benefits they bring to your daily development work, and how to implement them in your environment. By the end, you'll understand how these tools can help you spend less time manually doing someone else's job and more time doing what you do best—writing great code. Interested to learn about all of the software supply chain use-cases that SBOMs enable? Read our new white paper and start unlocking enterprise value. Download Now A Brief Introduction to Policy-as-Code You're probably familiar with Infrastructure-as-Code (IaC) tools like Terraform, AWS CloudFormation, or Pulumi. These tools allow you to define your cloud infrastructure in code rather than clicking through web consoles or manually running commands. Policy-as-Code (PaC) applies this same principle to policies from other departments of an organization. What is policy-as-code? At its core, policy-as-code translates organizational policies—whether they're security requirements, licensing restrictions, or compliance mandates—from human-readable documents into machine-readable representations that integrate seamlessly with your existing DevOps platform and tooling. Think of it this way: IaC gives you a DSL for provisioning and managing cloud resources, while PaC extends this concept to other critical organizational policies that traditionally lived outside engineering teams. This creates a bridge between development workflows and business requirements that previously existed in separate silos. Why do I care? Let's play a game of would you rather. Choose the activity from the table below that you'd rather do: Before Policy-as-CodeAfter Policy-as-CodeRead lengthy security/legal/compliance  documentation to understand requirementsReference policy translated into code with clear comments and explanationsManually review your code policy compliance and hope you interpreted policy correctlyReceive automated, deterministic policy evaluation directly in CI/CD build pipelineAttend compliance training sessions because you didn't read the documentationLearn policies by example as concrete connections to actual development tasksSetup meetings with security, legal or compliance teams to get code approvalGet automated approvals through automated policy evaluation without review meetingsWait till end of sprint and hope VP of Eng can get exception to ship with policy violationsIdentify and fix policy violations early when changes are simple to implement While the game is a bit staged, it isn't divorced from reality. PaC is meant to relieve much of the development friction associated with the external requirements that are typically hoisted onto the shoulders of developers. From oral tradition to codified knowledge Perhaps one of the most under appreciated benefits of policy-as-code is how it transforms organizational knowledge. Instead of policies living in outdated Word documents or in the heads of long-tenured employees, they exist as living code that evolves with your organization. When a developer asks "Why do we have this restriction?" or "What's the logic behind this policy?", the answer isn't "That's just how we've always done it" or "Ask Alice in Compliance." Instead, they can look at the policy code, read the annotations, and understand the reasoning directly. In the next section, we'll explore how software bills of materials (SBOMs) provide the perfect data structure to pair with policy-as-code for managing software supply chain security. A Brief Introduction to SBOMs (in the Context of PaC) If policy-as-code provides the rules engine for your application's dependency supply chain, then Software Bills of Materials (SBOMs) provide the structured, supply chain data that the policy engine evaluates. What is an SBOM? An SBOM is a formal, machine-readable inventory of all components and dependencies used in building a software artifact. If you're familiar with Terraform, you can think of an SBOM as analogous to a dev.tfstate file but it stores the state of your application code's 3rd-party dependency supply chain which is then reconciled against a main.tf file (i.e., policy) to determine if the software supply chain is compliant or in violation of the defined policy. SBOMs vs package manager dependency files You may be thinking, "Don't I already have this information in my package.json, requirements.txt, or pom.xml file?" While these files declare your direct dependencies, they don't capture the complete picture: They don't typically include transitive dependencies (dependencies of your dependencies) They don't include information about the components within container images you're using They don't provide standardized metadata about vulnerabilities, licenses, or provenance They aren't easily consumable by automated policy engines across different programming languages and environments SBOMs solve these problems by providing a standardized format that comprehensively documents your entire software supply chain in a way that policy engines can consistently evaluate. A universal policy interface: How SBOMs enable policy-as-code Think of SBOMs as creating a standardized "policy interface" for your software's supply chain metadata. Just as APIs create a consistent way to interact with services, SBOMs create a consistent way for policy engines to interact with your software's composable structure. This standardization is crucial because it allows policy engines to operate on a known data structure rather than having to understand the intricacies of each language's package management system, build tool, or container format. For example, a security policy that says "No components with critical vulnerabilities may be deployed to production" can be applied consistently across your entire software portfolio—regardless of the technologies used—because the SBOM provides a normalized view of the components and their vulnerabilities. In the next section, we'll explore the concrete benefits that come from combining SBOMs with policy-as-code in your development workflow. How do I get Started with SBOMs and Policy-as-Code Now that you understand what SBOMs and policy-as-code are and why they're valuable, let's walk through a practical implementation. We'll use Anchore Enterprise as an example of a policy engine that has a DSL to express a security policy which is then directly integrated into a CI/CD runbook. The example will focus on a common software supply chain security best practice: preventing the deployment of applications with critical vulnerabilities. Tools we'll use For this example implementation, we'll use the following components from Anchore: AnchoreCTL: A software composition analysis (SCA) tool and SBOM generator that scans source code, container images or application binaries to populate an SBOM with supply chain metadata Anchore Enforce: The policy engine that evaluates SBOMs against defined policies Anchore Enforce JSON: The Domain-Specific Language (DSL) used to define policies in a machine-readable format While we're using Anchore in this example, the concepts apply to other SBOM generators and policy engines as well. Step 1: Translate human-readable policies to machine-readable code The first step is to take your organization's existing policies and translate them into a format that a policy engine can understand. Let's start with a simple but effective policy. Human-Readable Policy: Applications with critical vulnerabilities must not be deployed to production environments. This policy needs to be translated into the Anchore Enforce JSON policy format: { "id": "critical_vulnerability_policy", "version": "1.0", "name": "Block Critical Vulnerabilities", "comment": "Prevents deployment of applications with critical vulnerabilities", "rules": [ { "id": "block_critical_vulns", "gate": "vulnerabilities", "trigger": "package", "comment": "Rule evaluates each dependency in an SBOM against vulnerability database. If the dependency is found in the database, all known vulnerability severity scores are evaluated for a critical value. If match if found policy engine returns STOP action to CI/CD build task", "parameters": [ { "name": "package_type", "value": "all" }, { "name": "severity_comparison", "value": "=" }, { "name": "severity", "value": "critical" }, ], "action": "stop" } ] } This policy code instructs the policy engine to: Examine all application dependencies (i.e., packages) in the SBOM Check if any dependency/package has vulnerabilities with a severity of "critical" If found, return a "stop" action that will fail the build If you're looking for more information on the capabilities of the Anchore Enforce DSL, our documentation provides the full capabilities of the Anchore Enforce policy engine. Step 2: Deploy Anchore Enterprise with the policy engine With the example policy defined, the next step is to deploy Anchore Enterprise (AE) and configure the Anchore Enforce policy engine. The high-level steps are: Deploy Anchore Enterprise platform in your test environment via Helm Chart (or other); includes policy engine Load your policy into the policy engine Configure access controls/permissions between AE deployment and CI/CD build pipeline If you're interested to get hands-on with this, we have developed a self-paced workshop that walks you through a full deployment and how to set up a policy. You can get a trial license by signing up for our free trial. Step 3: Integrate SBOM generation into your CI/CD pipeline Now you need to generate SBOMs as part of your build process and have them evaluated against your policies. Here's an example of how this might look in a GitHub Actions workflow: name: Build App and Evaluate Supply Chain for Vulnerabilities on: push: branches: [ main ] pull_request: branches: [ main ] jobs: build-and-evaluate: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Build Application run: | # Build application as container image docker build -t myapp:latest . - name: Generate SBOM run: | # Install AnchoreCTL curl -sSfL https://anchorectl-releases.anchore.io/v1.0.0/anchorectl_1.0.0_linux_amd64.tar.gz | tar xzf - -C /usr/local/bin # Execute supply chain composition scan of container image, generate SBOM and send to policy engine for evaluation anchorectl image add --wait myapp:latest - name: Evaluate Policy run: | # Get policy evaluation results RESULT=$(anchorectl image check myapp:latest --policy critical_vulnerability_policy) # Handle the evaluation result if [[ $RESULT == *"Status: pass"* ]]; then echo "Policy evaluation passed! Proceeding with deployment." else echo "Policy evaluation failed! Deployment blocked." exit 1 fi - name: Deploy if Passed if: success() run: | # Your deployment steps here This workflow: Builds your application as a container image using Docker Installs AnchoreCTL Scans container image with SCA tool to map software supply chain Generates an SBOM based on the SCA results Submits the SBOM to the policy engine for evaluation Gets evaluation results from policy engine response Continues or halts the pipeline based on the policy response Step 4: Test the integration With the integration in place, it's time to test that everything works as expected: Create a test build that intentionally includes a component with a known critical vulnerability Push the build through your CI/CD pipeline Confirm that: The SBOM is correctly generated The policy engine identifies the vulnerability The pipeline fails as expected If all goes well, you've successfully implemented your first policy-as-code workflow using SBOMs! Step 5: Expand your policy coverage Once you have the basic integration working, you can begin expanding your policy coverage to include: Security policies Compliance policies Software license policies Custom organizational policies Environment-specific requirements (e.g., stricter policies for production vs. development) Work with your security and compliance teams to translate their requirements into policy code, and gradually expand your automated policy coverage. This process is a large upfront investment but creates recurring benefits that pay dividends over the long-term. Step 6: Profit! With SBOMs and policy-as-code implemented, you'll start seeing the benefits almost immediately: Fast feedback on security and compliance issues Reduced manual compliance tasks Better documentation of what's in your software and why Consistent evaluation and enforcement of policies Certainty about policy approvals The key to success is getting your security and compliance teams to embrace the policy-as-code approach. Help them understand that by translating their policies into code, they gain more consistent enforcement while reducing manual effort. Wrap-Up As we've explored throughout this guide, SBOMs and policy-as-code represent a fundamental shift in how developers interact with security and compliance requirements. Rather than treating these as external constraints that slow down development, they become integrated features of your DevOps pipeline. Key takeaways Policy-as-Code transforms organizational policies from static documents into dynamic, version-controlled code that can be automated, tested, and integrated into CI/CD pipelines. SBOMs provide a standardized format for documenting your software's components, creating a consistent interface that policy engines can evaluate. Together, they enable "shift-left" security and compliance, providing immediate feedback on policy violations without meetings or context switching. Integration is straightforward with pre-built plugins for popular DevOps platforms, allowing you to automate policy evaluation as part of your existing build process. The benefits extend beyond security to include faster development cycles, reduced compliance burden, and better visibility into your software supply chain. Get started today Ready to bring SBOMs and policy-as-code to your development environment? Anchore Enterprise provides a comprehensive platform for generating SBOMs, defining policies, and automating policy evaluation across your software supply chain. Learn the 5 best practices for container security and how SBOMs play a pivotal role in securing your software supply chain. Download Now ### Contributing to Vulnerability Data: Making Security Better for Everyone Software security depends on accurate vulnerability data. While organizations like NIST maintain the National Vulnerability Database (NVD), the sheer volume of vulnerabilities discovered daily means that sometimes data needs improvement. At Anchore, we're working to enhance this ecosystem through open-source contributions, and we need your help. Why Vulnerability Data Matters When you run a security scanner like Grype, it relies on vulnerability data to determine if your software components have known security issues. This data includes crucial details like: Which versions of software are affected How the vulnerability can be exploited What versions contain the fix However, this data isn't always perfect. Sometimes, version ranges are incorrect, package names don't match reality, or the metadata needs enrichment. These inaccuracies can lead to false positives (flagging secure components as vulnerable) and false negatives (missing actual vulnerabilities). Our Approach to Better Data We maintain a set of open-source repositories that help improve vulnerability data quality: A data enrichment repository where contributors can submit corrections Tools for processing and validating these corrections Generated outputs that integrate with existing vulnerability databases This approach allows us to fix inaccuracies quickly and share these improvements with the broader security community. For example, we've helped correct version ranges for Java packages where the official data was incomplete and added missing metadata for WordPress plugins. How You Can Help We've published a comprehensive technical guide for contributors, but here's the quick version: Find an Issue: Maybe you've noticed incorrect version information in a CVE, or you're aware of missing package metadata Make the Fix: Clone our repository and use our tools to create or update the relevant records Submit a Pull Request: Share your improvements with the community The most valuable contributions often come from security researchers and developers encountering data issues daily. Your real-world experience helps identify where the data needs improvement. Impact of Contributions Every contribution helps make security tooling more accurate for everyone. When you fix a false positive, you help thousands of developers avoid unnecessary security alerts. When you add missing metadata, you help security tools better understand the software ecosystem. These improvements benefit individual developers using our open-source tools like Grype and major organizations, including Microsoft, Cisco, and various government agencies. By contributing, you'll help make the entire software supply chain more secure. Getting Started Ready to contribute? Here's what to do next: Check out our technical guide for detailed setup instructions Join our community forum to connect with other contributors Start with small improvements - even fixing one incorrect version range makes a difference The security community strengthens when we work together. Your contributions, whether big or small, help make vulnerability data more accurate for everyone. Let's improve software security one pull request at a time. ### Software Supply Chain Transparency: Why SBOMs Are the Missing Piece in Your ConMon Strategy This blog post has been archived and replaced by the supporting pillar page that can be found here: https://anchore.com/wp-admin/post.php?post=987475395&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. ### Securing Open Source Software Supply Chains – The Next Frontier of Innovation ### Rapid Incident Response to Zero-Day Vulnerabilities with SBOMs ### How to Automate Container Vulnerability Scanning for Harbor Registry with Anchore Enterprise Security engineers at modern enterprises face an unprecedented challenge: managing software supply chain risk without impeding development velocity, all while threat actors exploit the rapidly expanding attack surface. With over 25,000 new vulnerabilities in 2023 alone and supply chain attacks surging 540% year-over-year from 2019 to 2022, the exploding adoption of open source software has created an untenable security environment. To overcome these challenges security teams are in need of tools to scale their impact and invert the they are a speed bump for high velocity software delivery. If your DevSecOps pipeline utilizes the open source Harbor registry then we have the perfect answer to your needs. Integrating Anchore Enterprise—the SBOM-powered container vulnerability management platform—with Harbor offers the force-multiplier security teams need. This one-two combo delivers: Proactive vulnerability management: Automatically scan container images before they reach production Actionable security insights: Generate SBOMs, identify vulnerabilities and alert on actionable insights to streamline remediation efforts Lightweight implementation: Native Harbor integration requiring minimal configuration while delivering maximum value Improved cultural dynamics: Reduce security incident risk and, at the same time, burden on development teams while building cross-functional trust This technical guide walks through the implementation steps for integrating Anchore Enterprise into Harbor, equipping security engineers with the knowledge to secure their software supply chain without sacrificing velocity. Learn the essential container security best practices to reduce the risk of software supply chain attacks in this white paper. Download Now Integration Overview Anchore Enterprise can integrate with Harbor in two different ways—each has pros and cons: Pull Integration Model In this model, Anchore uses registry credentials to pull and analyze images from Harbor: Anchore accesses Harbor using standard Docker V2 registry integration Images are analyzed directly within Anchore Enterprise Results are available in Anchore's interface and API Ideal for organizations where direct access to Harbor is restricted but API access is permitted Push Integration Model In this model, Harbor uses its native scanner adapter feature to push images to Anchore for analysis: Harbor initiates scans on-demand through its scanner adapter as images are added Images are scanned within the Anchore deployment Vulnerability scan results are stored in Anchore and sent to Harbor's UI Better for environments with direct access to Harbor that want immediate scans Both methods provide strong security benefits but differ in workflow and where results are accessed. Setting Up the Pull Integration Let's walk through how to configure Anchore Enterprise to pull and analyze images from your Harbor registry. Prerequisites Anchore Enterprise installed and running Harbor registry deployed and accessible Harbor user account with appropriate permissions Step 1: Configure Registry Credentials in Anchore In Anchore Enterprise, navigate to the "Registries" section Select "Add Registry" Fill in the following details: Registry Hostname or IP Address: [your Harbor API URL or IP address, e.g., http://harbor.yourdomain.com] Name: [Human readable name] Type: docker_v2 Username: [your Harbor username, e.g., admin] Password: [your Harbor password] Configure any additional options like SSL validation if necessary Test the connection Save the configuration Step 2: Analyze an Image from Harbor Once the registry is configured, you can analyze images stored in Harbor: Navigate to the "Images" section in Anchore Enterprise Select "Add Image" Choose your Harbor registry from the dropdown Specify the repository and tag for the image you want to analyze Click "Analyze" Anchore will pull the image from Harbor, decompose it, generate an SBOM, and scan for vulnerabilities. This process typically takes a few minutes depending on image size. Step 3: Review Analysis Results After analysis completes: View the vulnerability report in the Anchore UI Check the generated SBOM for all dependencies Review compliance status against configured policies Export reports or take remediation actions as needed Setting Up the Push Integration Now let's configure Harbor to push images to Anchore for scanning using the Harbor Scanner Adapter. Prerequisites Harbor v2.0 or later installed Anchore Enterprise deployed and accessible Harbor Scanner Adapter for Anchore installed Step 1: Deploy the Harbor Scanner Adapter If not already deployed, install the Harbor Scanner Adapter for Anchore: Download or copy the harbor-adapter-anchore.yaml template from our GitHub repository Customize the template for your Harbor deployment. The required fields are: ANCHORE_ENDPOINT  ANCHORE_USERNAME  ANCHORE_PASSWORD Apply the Kubernetes manifest: kubectl apply -f harbor-adapter-anchore.yaml Step 2: Configure the Scanner in Harbor Log in to Harbor as an administrator Navigate to "Administration" → "Interrogation Services" In the "Scanners" tab, click "New Scanner" Enter the following details: Name: Anchore Description: Anchore Enterprise Scanner Endpoint: http://harbor-scanner-anchore:8080 Auth: None (or as required by your configuration) Save and set as default if desired Step 3: Configure Project Scanning Settings For each project that should use Anchore scanning: Navigate to the project in Harbor Go to "Configuration" Enable "Automatically scan images on push" AND Enable "Automatically generate SBOM on push" Save the configuration Step 4: Test the Integration Tag an image for your Harbor project: docker tag my-test-application:latest harbor.yourdomain.com/project-name/my-test-application:latest Push the image to Harbor: docker push harbor.yourdomain.com/project-name/my-test-application:latest Verify the automatic scan starts in Harbor Review the results in your Harbor UI once scanning completes Advanced Configuration Features Now that you have the base configuration working for the Harbor Scanner Adapter, you are ready to consider some additional features to increase your security posture. Scheduled Scanning Beyond on-push scanning, you can configure scheduled scanning to catch newly discovered vulnerabilities in existing images: In Harbor, navigate to "Administration" → "Interrogation Services" → "Vulnerability" Set the scan schedule (hourly, daily, weekly, etc.) Save the configuration This ensures all images are regularly re-scanned as vulnerability databases are updated with newly discovered and documented vulnerabilities. Security Policy Enforcement To enforce security at the pipeline level: In your Harbor project, navigate to "Configuration" Enable "Prevent vulnerable images from running" Select the vulnerability severity level threshold (Low, Medium, High, Critical) Images with vulnerabilities above this threshold will be blocked from being pulled* *Be careful with this setting for a production environment. If an image is flagged as having a vulnerability and your container orchestrator attempts to pull the image to auto-scale a service it may cause instability for users. Proxy Image Cache Harbor's proxy cache capability provides an additional security layer: Navigate to "Registries" in Harbor and select "New Endpoint" Configure a proxy cache to a public registry like Docker Hub All images pulled from Docker Hub will be cached locally and automatically scanned for vulnerabilities based on your project settings Security Tips and Best Practices from the Anchore Team Use Anchore Enterprise for highest fidelity vulnerability data The Anchore Enterprise dashboard surfaces complete vulnerability details Full vulnerability data can be configured with downstream integrations like Slack, Jira, ServiceNow, etc.  "Good data empowers good people to make good decisions."—Dan Perry, Principal Customer Success Engineer, Anchore Configuration Best Practices For optimal security posture: Configure per Harbor project: Use different vulnerability scanning settings for different risk profiles Mind your environment topology: Adjust network timeouts and SSL settings based on network topology; make sure Harbor and Anchore Enterprise deployments are able to communicate securely Secure Access Controls Adopt least privilege principle: Use different credentials per repository Utilize API keys: For service accounts and integrations, use API keys rather than user credentials Conclusion Integrating Anchore Enterprise with Harbor registry creates a powerful security checkpoint in your DevSecOps pipeline. By implementing either the pull or push model based on your specific needs, you can automate vulnerability scanning, enforce security policies, and maintain compliance requirements. This integration enables security teams to: Detect vulnerabilities before images reach production Generate and maintain accurate SBOMs Enforce security policies through prevention controls Maintain continuous security through scheduled scans With these tools properly integrated, you can significantly reduce the risk of deploying vulnerable containers to production environments, helping to secure your software supply chain. Save your developers time with Anchore Enterprise. Get instant access with a 15-day free trial. START FREE TRIAL If you're a visual learner, this content is also available in webinar format. Watch it on-demand below: ### Grype DB Schema Evolution: From v5 to v6 - Smaller, Faster, Better In our latest Grype release, we've updated the DB schema to v6. This update isn't just a cosmetic change; it's a thoughtful redesign that optimizes data storage and matching performance. For you, this means faster database updates (65MB vs 210MB downloads), quicker scans, and more comprehensive vulnerability detection, all while maintaining the familiar output format and user experience you rely on. The Past: Schema v5 Originally, grype’s vulnerability data was managed using two main tables: VulnerabilityModel: This table stores package-specific vulnerability details. Each affected package version required a separate row, which led to significant metadata duplication. VulnerabilityMetadataModel: To avoid duplicating large strings (like detailed vulnerability descriptions), metadata was separated into its own table. This v1 design was born out of necessity. Early CGO-free SQLite drivers didn’t offer SQLite's plethora of features. In later releases we were able to swap out the SQLite driver to the newly available modernc.org/sqlite driver and use GORM for general access. However, v2 - v5 had the same basic design approach. This led to space inefficiencies: the on-disk footprint grew to roughly 1.6 GB, and the cost was notable even after compression (210 MB as a tar.gz). When it came to searching the database, we organized rows into “namespaces” which was a string that indicated the intended ecosystem this affected (e.g. a specific distro name + version, a language name, etc, for instance redhat:distro:redhat:7 or cpe:nvd).When searching for matches in Grype, we would cast a wide net on an initial search within the database by namespace + package name and refine the results by additionally parsed attributes, effectively casting a smaller net as we progressed. As the database grew we came across more examples where the idea of a “namespace” just didn’t make sense (for instance, what if you weren’t certain what namespace your software artifact landed in, do you simply search all namespaces?). We clearly needed to remove the notion of namespaces as a core input into searching the database. Another thing that happened after the initial release of the early Grype DB schemas: the Open Source Vulnerability schema (OSV) was released. This format enabled a rich, machine-readable format that could be leveraged by vulnerability data providers when publishing vulnerability advisories, and meant that tools could more easily consume data from a broad set of vulnerability sources, providing more accurate results for end users. We knew that we wanted to more natively be able to ingest this format and maybe even express records internally in a similar manner. The Present: Schema v6 To address these challenges, we've entirely reimagined how Grype stores and accesses vulnerability data: At a high level, the new DB is primarily a JSON blob store for the bulk of the data, with specialized indexes for efficient searching. The stored JSON blobs are heavily inspired by the OSV schema, but tailored to meet Grype's specific needs. Each entity we want to search by gets its own table with optimized indexes, and these rows point to the OSV-like JSON blob snippets. Today, we have three primary search tables: AffectedPackages: These are packages that exist in a known language, packaging ecosystem, or specific Linux distribution version. AffectedCPEs: These are entries from NVD which do not have a known packaging ecosystem. Vulnerabilities: These contain core vulnerability information without any packaging information. One of the most significant improvements is removing "namespaces" entirely from within the DB. Previously, client-based changes were needed to craft the correct namespace for database searches. This meant shipping software updates for what were essentially data corrections. In v6, we've shifted these cases to simple lookup tables in the DB, normalizing search input. We can fix or add search queries through database updates alone, no client update required. Moreover, the v6 schema's modular design simplifies extending functionality. Integrating additional vulnerability feeds or other external data sources is now far more straightforward, ensuring that Grype remains flexible and future-proof. The Benefits: What's New in the Database In terms of content, v6 includes everything from v5 plus important additions: Withdrawn vulnerabilities: We now persist "withdrawn" vulnerabilities. While this doesn't affect matching, it improves reference capabilities for related vulnerability data Enhanced datasets: We've added the CISA Known Exploited Vulnerabilities and EPSS (Exploit Prediction Scoring System) datasets to the database The best way to explore this data is with the grype db search and grype db search vuln commands.  search allows you to discover affected packages by a wide array of parameters (package name, CPE, purl, vulnerability ID, provider, ecosystem, linux distribution, added or modified since a particular date, etc): $ grype db search --pkg log4j VULNERABILITY PACKAGE ECOSYSTEM NAMESPACE VERSION CONSTRAINT ALAS-2021-003 log4j rpm amazon:distro:amazonlinux:2022 < 2.15.0-1.amzn2022.0.1 ALAS-2021-004 log4j rpm amazon:distro:amazonlinux:2022 < 2.16.0-1.amzn2022 ALAS-2021-008 log4j rpm amazon:distro:amazonlinux:2022 < 2.17.0-1.amzn2022.0.1 ALAS-2022-011 log4j rpm amazon:distro:amazonlinux:2022 < 2.17.1-1.amzn2022.0.1 ALAS-2022-1739 log4j rpm amazon:distro:amazonlinux:2 < 1.2.17-17.amzn2 ALAS-2022-1750 log4j rpm amazon:distro:amazonlinux:2 < 1.2.17-18.amzn2 ALAS-2022-225 log4j rpm amazon:distro:amazonlinux:2022 < 2.17.2-1.amzn2022.0.3 CVE-2017-5645 log4j rpm redhat:distro:redhat:5 CVE-2017-5645 cpe:2.3:a:apache:log4j:*:*:*:*:*:* nvd:cpe >= 2.0, < 2.8.2 ... search vuln enables being able to search just for vulnerability records: $ grype db search vuln CVE-2021-44228 ID PROVIDER PUBLISHED SEVERITY REFERENCE CVE-2021-44228 debian (10, 11, 12, 13, unstable) negligible https://security-tracker.debian.org/tracker/CVE-2021-44228 CVE-2021-44228 debian (9) critical https://security-tracker.debian.org/tracker/CVE-2021-44228 CVE-2021-44228 nvd 2021-12-10 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H https://nvd.nist.gov/vuln/detail/CVE-2021-44228 CVE-2021-44228 sles (15.4, 15.5, 15.6) critical https://www.suse.com/security/cve/CVE-2021-44228 CVE-2021-44228 ubuntu (14.4, 16.4, 18.4, 20.4, 21.10, 21.4) high https://ubuntu.com/security/CVE-2021-44228 As with all of our tools, there is -o json available with these commands to be able to explore the raw affected package, affected CPE, and vulnerability records: $ grype db search vuln CVE-2021-44228 -o json --provider nvd [ { "id": "CVE-2021-44228", "assigner": [ "security@apache.org" ], "description": "Apache Log4j2 2.0-beta9 through 2.15.0 (excluding security releases 2.12.2, 2.12.3, and 2.3.1) JNDI features...", "refs": [...], "severities": [...], "provider": "nvd", "status": "active", "published_date": "2021-12-10T10:15:09.143Z", "modified_date": "2025-02-04T15:15:13.773Z", "known_exploited": [ { "cve": "CVE-2021-44228", "vendor_project": "Apache", "product": "Log4j2", "date_added": "2021-12-10", "required_action": "For all affected software assets for which updates exist, the only acceptable remediation actions are: 1) Apply updates; OR 2) remove affected assets from agency networks. Temporary mitigations using one of the measures provided at https://www.cisa.gov/uscert/ed-22-02-apache-log4j-recommended-mitigation-measures are only acceptable until updates are available.", "due_date": "2021-12-24", "known_ransomware_campaign_use": "known", "urls": [ "https://nvd.nist.gov/vuln/detail/CVE-2021-44228" ], "cwes": [ "CWE-20", "CWE-400", "CWE-502" ] } ], "epss": [ { "cve": "CVE-2021-44228", "epss": 0.97112, "percentile": 0.9989, "date": "2025-03-03" } ] } ] Dramatic Size Reduction: The Technical Journey One of the standout improvements of v6 is the dramatic size reduction: MetricSchema v5Schema v6ImprovementRaw DB Size1.6 GB900 MB44% smallerCompressed Archive210 MB65 MB69% smaller This means you'll experience significantly faster database updates and reduced storage requirements. We build and distribute Grype database archives daily to provide users with the most up-to-date vulnerability information. Over the past five years, we've added more vulnerability sources, and the database has more than doubled in size, significantly impacting users who update their databases daily. Our optimization strategy included: Switching to zstandard compression: This yields better compression ratios compared to gzip, providing immediate space savings. Database layout optimization: We prototyped various database layouts, experimenting with different normalization levels (database design patterns that eliminate data redundancy). While higher normalization saved space in the raw database, it sometimes yielded worse compression results. We found the optimal balance between normalization and leaving enough unnormalized data for compression algorithms to work effectively. Real-World Impact These improvements directly benefit several common scenarios: CI/CD Pipelines: With a 69% smaller download size, your CI/CD pipelines will update vulnerability databases faster, reducing build times and costs. Air-gapped Environments: If you're working in air-gapped environments and need to transport the database, its significantly smaller size makes this process much more manageable. Resource-constrained Systems: The smaller memory footprint means Grype can now run more efficiently on systems with limited resources. Conclusion The evolution of the Grype database schema from v5 to v6 marks a significant milestone. By rethinking our database structure and using the OSV schema as inspiration, we've created a more efficient, scalable, and feature-rich database that directly benefits your vulnerability management workflows. We'd like to encourage you to update to the latest version of Grype to take advantage of these improvements. If you have feedback on the new schema or ideas for further enhancements, please share them with us on Discourse, and if you spot a bug, let us know on GitHub. If you’d like to get updates about the Anchore Open Source Community, sign up for our low-traffic community newsletter. Stay tuned for more updates as we refine Grype and empower your security practices! ### The future of SBOMs with Kate Stewart Beyond Compliance: Exploring the Evolution & Future of Software Bill of Materials ### Making Virtual Machine Security Analysis Easier with sbom-vm Security professionals often need to analyze the contents of virtual machines (VMs) to generate Software Bills of Materials (SBOMs). This seemingly straightforward task can become surprisingly complex. I'd like to introduce sbom-vm, a prototype tool I created to simplify this process. The Current Challenge Security teams typically use tools such as Syft to generate SBOMs by running it directly inside virtual machines. While this approach works, it comes with significant limitations. VMs with constrained resources can experience out-of-memory errors during scanning. Large filesystems containing millions of files can lead to scans that take hours or even days. In some environments, running analysis tools inside production VMs isn't permitted at all. These limitations surfaced through various user reports and feature requests in the Syft project. While Syft and other libraries, such as stereoscope could be extended to handle VM disk images directly, users needed a solution today. A New Approach with sbom-vm I developed sbom-vm over a weekend to tackle this challenge from a different angle. Instead of operating inside the virtual machine, sbom-vm works directly with VM disk images from the host system. The tool mounts these images in read-only mode using qemu-nbd, automatically detects and mounts common filesystem types, and runs Syft against the mounted filesystem from the host system. This approach fundamentally changes how we analyze VM contents. Running outside the virtual machine, sbom-vm sidesteps resource constraints and performance limitations. The read-only nature of all operations ensures the safety of the source material, while support for multiple disk formats and filesystem types provides broad compatibility. Technical Implementation At its core, sbom-vm leverages standard Linux utilities to handle disk images safely. Here's an example of how it manages filesystem mounting: def mount_filesystem(self): self.mounted_partition = self.find_filesystem_partition() self.mount_point.mkdir(parents=True, exist_ok=True) # Get filesystem type result = self._run_command(["blkid", "-o", "value", "-s", "TYPE", self.mounted_partition]) fs_type = result.stdout.strip().lower() logger.info(f"Mounting {fs_type} filesystem") if fs_type == "zfs_member": self._handle_zfs(self.mounted_partition) elif fs_type == "btrfs": mount_opts = ["mount", "-t", "btrfs", "-o", "ro"] self._run_command(mount_opts + [self.mounted_partition, str(self.mount_point)]) The tool currently supports multiple disk formats, including qcow2 and vmdk, along with common filesystems such as ext4, ZFS, BTRFS, NTFS, HFS+, and APFS. This broad compatibility ensures it works with most virtual machine images you'll likely encounter. But it’s early days—I don’t know what crazy filesystems and disk image systems others may have. Getting Started To try sbom-vm, you'll need a Linux system with some common utilities installed: # Install Syft, so we can generate an SBOM from the VM # See also: https://github.com/anchore/syft $ snap install syft # Install Linux utilities to manage disk images $ sudo apt install qemu-utils gdisk fdisk parted util-linux # Grab sbom-vm from GitHub $ git clone https://github.com/popey/sbom-vm $ cd sbom-vm There's a script provided to generate test images: # Generate/download some test images to play with $ sudo ./generate-test-images.py Generating the test images doesn't take long: Now you can scan the images with sbom-vm! # Run sbom-vm against one of the test images. $ sudo ./sbom-vm.py ./test_images/ubuntu_22.04_zfs.qcow2 Here's what that looks like, slightly speeded up: Future Development So, while sbom-vm provides a practical solution today, there's room for enhancement. Future development could add support for additional disk image formats, enhance filesystem type detection, and integrate with cloud provider VM snapshots. Performance optimizations for large filesystems and potential integration with Syft's native capabilities are also on the roadmap. Join the Project sbom-vm is open source under the MIT license, and I welcome contributions. Whether you're interested in adding support for new filesystem types, improving documentation, or reporting issues, you can find the project on GitHub at https://github.com/popey/sbom-vm. While sbom-vm began as a weekend project, it potentially provides immediate value for security professionals who need to analyze VM disk images. It demonstrates how targeted solutions can bridge gaps in the security toolchain while considering more extensive architectural changes.If you’d like to get updates about the Anchore Open Source Community, sign up for our low-traffic community newsletter and drop by our community discourse. ### NIST SP 800-190: Overview & Compliance Checklist This blog post has been archived and replaced by the supporting pillar page that can be found here: https://anchore.com/wp-admin/post.php?post=987474946&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. ### Unlocking the Power of SBOMs: A Complete Guide Software Bill of Materials (SBOMs) are no longer optional—they’re mission-critical. That’s why we’re excited to announce the release of our new white paper, “Unlock Enterprise Value with SBOMs: Use-Cases for the Entire Organization.” This comprehensive guide is designed for security and engineering leadership at both commercial enterprises and federal agencies, providing actionable insights into how SBOMs are transforming the way organizations manage software complexity, mitigate risk, and drive business outcomes. From software supply chain security to DevOps acceleration and regulatory compliance, SBOMs have emerged as a cornerstone of modern software development. They do more than provide a simple inventory of application components; they enable rapid security incident response, automated compliance, reduced legal risk, and accelerated software delivery. ⏱️ Can't wait till the end?📥 Download the white paper now 👇👇👇 Download Now Why SBOMs Are a Game Changer SBOMs are no longer just a checklist item—they’re a strategic asset. They provide an in-depth inventory of every component within your software ecosystem, complete with critical metadata about suppliers, licensing rights, and security postures. This newfound transparency is revolutionizing cross-functional operations across enterprises by: Accelerating Incident Response: Quickly identify vulnerable components and neutralize threats before they escalate. Enhancing Vulnerability Management: Prioritize remediation efforts based on risk, ensuring that developer resources are optimally deployed. Strengthening Compliance: Automate and streamline adherence to complex regulatory requirements such as FedRAMP, SSDF Attestation, and DoD’s continuous ATO. Reducing Legal Risk: Manage open source license obligations proactively, ensuring that every component meets your organization’s legal and security standards. What’s Inside the White Paper? Our white paper is organized by organizational function; each section highlighting the relevant SBOM use-cases. Here’s a glimpse of what you can expect: Security: Rapidly identify and mitigate zero-day vulnerabilities, scale vulnerability management, and detect software drift to prevent breaches. Engineering & DevOps: Eliminate wasted developer time with real-time feedback, automate dependency management, and accelerate software delivery. Regulatory Compliance: Automate policy checks, streamline compliance audits, and meet requirements like FedRAMP and SSDF Attestation with ease. Legal: Reduce legal exposure by automating open source license risk management. Sales: Instill confidence in customers and accelerate sales cycles by proactively providing SBOMs to quickly build trust. Also, you’ll find real-world case studies from organizations that have successfully implemented SBOMs to reduce risk, boost efficiency, and gain a competitive edge. Learn how companies like Google and Cisco are leveraging SBOMs to drive business outcomes. Empower Your Enterprise with SBOM-Centric Strategies The white paper underscores that SBOMs are not a one-trick pony. They are the cornerstone of modern software supply chain management, driving benefits across security, engineering, compliance, legal, and customer trust. Whether your organization is embarking on its SBOM journey or refining an established process, this guide will help you unlock cross-functional value and future-proof your technology operations. Download the White Paper Today SBOMs are more than just compliance checkboxes—they are a strategic enabler for your organization’s security, development, and business operations. Whether your enterprise is just beginning its SBOM journey or operating a mature SBOM initiative, this white paper will help you uncover new ways to maximize value. Explore SBOM use-cases for almost any department of the enterprise and learn how to unlock enterprise value to make the most of your software supply chain. Download Now ### Generating Python SBOMs: Using pipdeptree and Syft SBOM (software bill of materials) generation is becoming increasingly important for software supply chain security and compliance. Several approaches exist for generating SBOMs for Python projects, each with its own strengths. In this post, we'll explore two popular methods: using pipdeptree with cyclonedx-py and Syft. We'll examine their differences and see why Syft is better for many use-cases. Learn the 5 best practices for container security and how SBOMs play a pivotal role in securing your software supply chain. Download Now Why Generate Python Package SBOMs? Before diving into the tools, let's understand why generating an SBOM for your Python packages is increasingly critical in modern software development. Security analysis is a primary driver—SBOMs provide a detailed inventory of your dependencies that security teams can use to identify vulnerabilities in your software supply chain and respond quickly to newly discovered threats. The cybersecurity compliance landscape is also evolving rapidly, with many organizations and regulations (e.g., EO 14028) now requiring SBOMs as part of software delivery to ensure transparency and traceability in an organization's software supply chain. From a maintenance perspective, understanding your complete dependency tree is essential for effective project management. SBOMs help development teams track dependencies, plan updates, and understand the potential impact of changes across their applications. They're particularly valuable when dealing with complex Python applications that may have hundreds of transitive dependencies. License compliance is another crucial aspect where SBOMs prove invaluable. By tracking software licenses across your entire dependency tree, you can ensure your project complies with various open source licenses and identify potential conflicts before they become legal issues. This is especially important in Python projects, where dependencies might introduce a mix of licenses that need careful consideration. Generating a Python SBOM with pipdeptree and cyclonedx-py The first approach we'll look at combines two specialized Python tools: pipdeptree for dependency analysis and cyclonedx-py for SBOM generation. Here's how to use them: # Install the required tools $ pip install pipdeptree cyclonedx-bom # Generate requirements with dependencies $ pipdeptree --freeze > requirements.txt # Generate SBOM in CycloneDX format $ cyclonedx-py requirements requirements.txt > cyclonedx-sbom.json This Python-specific approach leverages pipdeptree's deep understanding of Python package relationships. pipdeptree excels at: Detecting circular dependencies Identifying conflicting dependencies Providing a clear, hierarchical view of package relationships Generating a Python SBOM with Syft: A Universal SBOM Generator Syft takes a different approach. As a universal SBOM generator, it can analyze Python packages and multiple software artifacts. Here's how to use Syft with Python projects: # Install Syft (varies by platform) # See: https://github.com/anchore/syft#installation $ curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin # Generate SBOM from requirements.txt $ syft requirements.txt -o cyclonedx-json # Or analyze an entire Python project $ syft path/to/project -o cyclonedx-json Key Advantages of Syft Syft's flexibility in output formats sets it apart from other tools. In addition to the widely used CycloneDX format, it supports SPDX for standardized software definitions and offers its own native JSON format that includes additional metadata. This format flexibility allows teams to generate SBOMs that meet various compliance requirements and tooling needs without switching between multiple generators. Syft truly shines in its comprehensive analysis capabilities. Rather than limiting itself to a single source of truth, Syft examines your entire Python environment, detecting packages from multiple sources, including requirements.txt files, setup.py configurations, and installed packages. It seamlessly handles virtual environments and can even identify system-level dependencies that might impact your application. The depth of metadata Syft provides is particularly valuable for security and compliance teams. For each package, Syft captures not just basic version information but also precise package locations within your environment, file hashes for integrity verification, detailed license information, and Common Platform Enumeration (CPE) identifiers. This rich metadata enables more thorough security analysis and helps teams maintain compliance with security policies. Comparing the Outputs We see significant differences in detail and scope when examining the outputs from both approaches. The pipdeptree with cyclonedx-py combination produces a focused output that concentrates specifically on Python package relationships. This approach yields a simpler, more streamlined SBOM that's easy to read but contains limited metadata about each package. Syft, on the other hand, generates a more comprehensive output that includes extensive metadata for each package. Its SBOM provides rich details about package origins, includes comprehensive CPE identification for better vulnerability matching, and offers built-in license detection. Syft also tracks the specific locations of files within your project and includes additional properties that can be valuable for security analysis and compliance tracking. Here's a snippet comparing the metadata for the rich package in both outputs: // pipdeptree + cyclonedx-py { "bom-ref":"pkg:pypi/rich@13.9.4", "type":"library", "name":"rich", "version":"13.9.4" } // Syft { "bom-ref":"pkg:pypi/rich@13.9.4", "type":"library", "author":"Will McGugan ", "name":"rich", "version":"13.9.4", "licenses":[{"license":{"id": "MIT"}}], "cpe":"cpe:2.3:a:will_mcgugan_project:python-rich:13.9.4:*:*:*:*:*:*:*", "purl":"pkg:pypi/rich@13.9.4", "properties":[ { "name":"syft:package:language", "value":"python" }, { "name":"syft:location:0:path", "value":"/.venv/lib/python3.10/site-packages/rich-13.9.4.dist-info/METADATA" } ] } Why Choose Syft? While both approaches are valid, Syft offers several compelling advantages. As a universal tool that works across multiple software ecosystems, Syft eliminates the need to maintain different tools for different parts of your software stack. Its rich metadata gives you deeper insights into your dependencies, including detailed license information and precise package locations. Syft's support for multiple output formats, including CycloneDX, SPDX, and its native format, ensures compatibility with your existing toolchain and compliance requirements. The project's active development means you benefit from regular updates and security fixes, keeping pace with the evolving software supply chain security landscape. Finally, Syft's robust CLI and API options make integrating into your existing automation pipelines and CI/CD workflows easy. How to Generate a Python SBOM with Syft Ready to generate SBOMs for your Python projects? Here's how to get started with Syft: Install Syft following the official installation guide For a quick SBOM of your Python project: $ syft path/to/your/project -o cyclonedx-json Explore different output formats: $ syft path/to/your/project -o spdx-json $ syft path/to/your/project -o syft-json Conclusion While pipdeptree combined with cyclonedx-py provides a solid Python-specific solution, Syft offers a more comprehensive and versatile approach to SBOM generation. Its ability to handle multiple ecosystems, provide rich metadata, and support various output formats makes it an excellent choice for modern software supply chain security needs. Whether starting with SBOMs or looking to improve your existing process, Syft provides a robust, future-proof solution that grows with your needs. Try it and see how it can enhance your software supply chain security today. Learn about the role that SBOMs for the security of your organization in this white paper. Download Now ### Community Spotlight: Laurent Goderre (Docker) ### Effortless SBOM Analysis: How Anchore Enterprise Simplifies Integration As software supply chain security becomes a top priority, organizations are turning to Software Bill of Materials (SBOM) generation and analysis to gain visibility into the composition of their software and supply chain dependencies in order to reduce risk. However, integrating SBOM analysis tools into existing workflows can be complex, requiring extensive configuration and technical expertise. Anchore Enterprise, a leading SBOM management and container security platform, simplifies this process with seamless integration capabilities that cater to modern DevSecOps pipelines. This article explores how Anchore makes SBOM analysis effortless by offering automation, compatibility with industry standards, and integration with popular CI/CD tools. Learn about the role that SBOMs for the security of your organization in this white paper. Download Now The Challenge of SBOM Analysis Integration SBOMs play a crucial role in software security, compliance, and vulnerability management. However, organizations often face challenges when adopting SBOM analysis tools: Complex Tooling: Many SBOM solutions require significant setup and customization. Scalability Issues: Enterprises managing thousands of dependencies need scalable and automated solutions. Compatibility Concerns: Ensuring SBOM analysis tools work seamlessly across different DevOps environments can be difficult. Compliance Requirements: Organizations must align with frameworks like Executive Order 14028, EU Cybersecurity Resilience Act (CRA), ISO 27001, and the Secure Software Development Framework (SSDF)  Anchore addresses these challenges by providing a sleek approach to SBOM analysis with easy-to-use integrations. How Anchore Simplifies SBOM Analysis Integration 1. Automated SBOM Generation and Analysis Anchore automates SBOM generation from various sources, including container images, software packages, and application dependencies. This eliminates the need for manual intervention, ensuring continuous security and compliance monitoring. Supports multiple SBOM formats: CycloneDX, SPDX, and Anchore’s native json format. Automatically scans and analyzes SBOMs for vulnerabilities, licensing issues, and  security and compliance policy violations. Provides real-time insights to security teams. 2. Seamless CI/CD Integration DevSecOps teams require tools that integrate effortlessly into their existing workflows. Anchore achieves this by offering: Popular CI/CD platform plugins: Jenkins, GitHub Actions, GitLab CI/CD, Azure DevOps and more. API-driven architecture: Embed SBOM generation and analysis in any DevOps pipeline. Policy-as-code support: Enforce security and compliance policies within CI/CD workflows. AnchoreCTL: A command-line (CLI) tool for developers to generate and analyze SBOMs locally before pushing to production. 3. Cloud Native and On-Premises Deployment Organizations have diverse infrastructure requirements, and Anchore provides flexibility through: Cloud native support: Works seamlessly with Kubernetes, OpenShift, AWS, and GCP. On-premises deployment: For organizations requiring strict control over data security. Hybrid model: Allows businesses to use cloud-based Anchore Enterprise while maintaining on-premises security scanning. Bonus: Anchore also offers an air-gapped deployment option for organizations working with customers that provide critical national infrastructure like energy, financial services or defense.See how Anchore Enterprise enabled Dreamfactory to support the defense industry. 4. Comprehensive Policy and Compliance Management Anchore helps organizations meet regulatory requirements with built-in policy enforcement: Out-of-the-box policies: CIS benchmarks, FedRAMP, and DISA STIG compliance. Integrated vulnerability databases: Automated vulnerability assessment using industry-standard databases like OSS Index, NVD, VEX, and Snyk. User-defined policy-as-code: Custom policies to detect software misconfigurations and enforce security best practices. Custom user policies is a helpful feature to define security policies based on geography; security and compliance can vary widely depending on national borders. 5. Developer-Friendly Approach A major challenge in SBOM adoption is developer resistance due to complexity. Anchore makes security analysis developer-friendly by: Providing CLI and API tools for easy interaction. Delivering clear, actionable vulnerability reports instead of overwhelming developers with false positives. Integrating directly with development environments, such as VS Code and JetBrains IDEs. Providing an industry standard 24/7 customer support through Anchore’s customer success team. Conclusion Anchore has positioned itself as a leader in SBOM analysis by making integration effortless, automating security checks, and supporting industry standards. Whether an organization is adopting SBOMs for the first time or looking to enhance its software supply chain security, Anchore provides a scalable and developer-friendly solution. By integrating automated SBOM generation, CI/CD compatibility, cloud native deployment, and compliance management, Anchore enables businesses (no matter the size) and government institutions to adopt SBOM analysis without disrupting their workflows. As software security becomes increasingly critical, tools like Anchore will play a pivotal role in ensuring a secure and transparent software supply chain.For organizations seeking a simple to deploy SBOM analysis solution, Anchore Enterprise is here to deliver results to your organization. Request a demo with our team today! Learn the 5 best practices for container security and how SBOMs play a pivotal role in securing your software supply chain. Download Now ### Syft 1.20: Faster Scans, Smarter License Detection, and Enhanced Bitnami Support We're excited to announce Syft v1.20.0! If you're new to the community, Syft is Anchore's open source software composition analysis (SCA) and SBOM generation tool that provides foundational support for software supply chain security for modern DevSecOps workflows. The latest version is packed with performance improvements, enhanced SBOM accuracy, and several community-driven features that make software composition scanning more comprehensive and efficient than ever. Understand, Implement & Leverage SBOMs for Stronger Security & Risk Management Download Now 50x Faster Windows Scans Scanning projects with numerous DLLs was reported to take peculiarly long when running on Windows, sometimes up to 50 minutes. A sharp-eyed community member (@rogueai) discovered that certificate validation was being performed unnecessarily during DLL scanning. A fix was merged into this release and those lengthy scans have been dramatically reduced from to just a few minutes—a massive performance improvement for Windows users! Bitnami Embedded SBOM Support: Maximum Accuracy Container images from Bitnami include valuable embedded SBOMs located at /opt/bitnami/. These SBOMs, packaged by the image creators themselves, represent the most authoritative source for package metadata. Thanks to community member @juan131 and maintainer @willmurphyscode, Syft now includes a dedicated cataloger for these embedded SBOMs. This feature wasn't simple to implement. It required careful handling of package relationships and sophisticated deduplication logic to merge authoritative vendor data with Syft's existing scanning capabilities. The result? Scanning Bitnami images gives you the most accurate SBOM possible, combining authoritative vendor data with Syft's comprehensive analysis. Smarter License Detection Handling licenses for non-open source projects can be a bit tricky. We discovered that when license files can’t be matched to a valid SPDX expression, they sometimes get erroneously marked as “unlicensed”—even when valid license text is present. For example, our dpkg cataloger occasionally encountered a license like: NVIDIA Software License Agreement and CUDA Supplement to Software License Agreement And categorized the package as unlicensed. Ideally, the cataloger would capture this non-standards compliant license whether the maintainer follows SDPX or not. Community member @HeyeOpenSource and maintainer @spiffcs tackled this challenge with an elegant solution: a new configuration option that preserves the original license text when SPDX matching fails. While disabled by default for compatibility, you can enable this feature with license.include-unknown-license-content: true in your configuration. This ensures you never lose essential license information, even for non-standard licenses. Go 1.24: Better Performance and Versioning The upgrade to Go 1.24 brings two significant improvements: Faster Scanning: Thanks to Go 1.24's optimized map implementations, discussed in this Bytesize Go post—and other performance improvements—we're seeing scan times reduced by as much as 20% in our testing. Enhanced Version Detection: Go 1.24's new version embedding means Syft can now accurately report its version and will increasingly provide more accurate version information for Go applications it scans: syft:   go1.24.0 $ go version -m ./syft path    github.com/anchore/syft/cmd/syft mod     github.com/anchore/syft v1.20.0 This also means that as more applications are built with Go 1.24—the versions reported by Syft will become increasingly accurate over time. Everyone’s a winner! Join the Conversation We’re proud of these enhancements and grateful to the community for their contributions. If you’re interested in contributing or have ideas for future improvements, head to our GitHub repo and join the conversation. Your feedback and pull requests help shape the future of Syft and our other projects. Happy scanning! Stay updated on future community spotlights and events by subscribing to our community newsletter. Learn how MegaLinter leverages Syft and Grype to generate SBOMs and create vulnerability reports Watch Now ### Anchore Community Spotlight: Nicolas Vuillamy from MegaLinter Want to learn how a powerful open-source linting tool that supports over 50 programming languages came to be? Join us for an engaging conversation with Nicolas Vuillamy, the creator of MegaLinter, as he shares the journey from its Bash origins to becoming a comprehensive static code analysis solution developers use worldwide. In this discussion, Nicolas explores: - The evolution and core features of MegaLinter- Why static code analysis matters for development teams- How MegaLinter helps maintain code quality and security- Tips for getting started with the tool- How MegaLinter leverages Syft and Grype to generate SBOMs and create vulnerability reports Watch the whole discussion on YouTube to dive deeper into Nicolas's insights and learn how MegaLinter can enhance your development workflow. Stay updated on future community spotlights and events by subscribing to our community newsletter. ### FedRAMP Continuous Monitoring: Overview & Checklist This blog post has been archived and replaced by the supporting pillar page that can be found here: https://anchore.com/wp-admin/post.php?post=987474886&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. ### Trust in the Supply Chain: CycloneDX Attestations & SBOMs ### How Syft Scans Software to Generate SBOMs Syft is an open source CLI tool and Go library that generates a Software Bill of Materials (SBOM) from source code, container images and packaged binaries. It is a foundational building block for various use-cases: from vulnerability scanning with tools like Grype, to OSS license compliance with tools like Grant. SBOMs track software components—and their associated supplier, security, licensing, compliance, etc. metadata—through the software development lifecycle. At a high level, Syft takes the following approach to generating an SBOM: Determine the type of input source (container image, directory, archive, etc.) Orchestrate a pluggable set of catalogers to scan the source or artifact Each package cataloger looks for package types it knows about (RPMs, Debian packages, NPM modules, Python packages, etc.) In addition, the file catalogers gather other metadata and generate file hashes Aggregate all discovered components into an SBOM document Output the SBOM in the desired format (Syft, SPDX, CycloneDX, etc.) Let's dive into each of these steps in more detail. Learn the 5 best practices for container security and how SBOMs play a pivotal role in securing your software supply chain. Download Now Flexible Input Sources Syft can generate an SBOM from several different source types: Container images (both from registries and local Docker/Podman engines) Local filesystems and directories Archives (TAR, ZIP, etc.) Single files This flexibility is important as SBOMs are used in a variety of environments, from a developer's workstation to a CI/CD pipeline. When you run Syft, it first tries to autodetect the source type from the provided input. For example: # Scan a container image  syft ubuntu:latest # Scan a local filesystem syft ./my-app/ Pluggable Package Catalogers The heart of Syft is its decoupled architecture for software composition analysis (SCA). Rather than one monolithic scanner, Syft delegates scanning to a collection of catalogers, each focused on a specific software ecosystem. Some key catalogers include: apk-db-cataloger for Alpine packages dpkg-db-cataloger for Debian packages rpm-db-cataloger for RPM packages (sourced from various databases) python-package-cataloger for Python packages java-archive-cataloger for Java archives (JAR, WAR, EAR) npm-package-cataloger for Node/NPM packages Syft automatically selects which catalogers to run based on the source type. For a container image, it will run catalogers for the package types installed in containers (RPM, Debian, APK, NPM, etc). For a filesystem, Syft runs a different set of catalogers looking for installed software that is more typical for filesystems and source code. This pluggable architecture gives Syft broad coverage while keeping the core streamlined. Each cataloger can focus on accurately detecting its specific package type. If we look at a snippet of the trace output from scanning an Ubuntu image, we can see some catalogers in action: [0001] DEBUG discovered 91 packages cataloger=dpkg-db-cataloger...   [0001] DEBUG discovered 0 packages cataloger=rpm-db-cataloger [0001] DEBUG discovered 0 packages cataloger=npm-package-cataloger Here, the dpkg-db-cataloger found 91 Debian packages, while the rpm-db-cataloger and npm-package-cataloger didn't find any packages of their types—which makes sense for an Ubuntu image. Aggregating and Outputting Results Once all catalogers have finished, Syft aggregates the results into a single SBOM document. This normalized representation abstracts away the implementation details of the different package types. The SBOM includes key data for each package like: Name Version Type (Debian, RPM, NPM, etc) Files belonging to the package Source information (repository, download URL, etc.) File digests and metadata It also contains essential metadata, including a copy of the configuration used when generating the SBOM (for reproducibility). The SBOM will contain detailed information about package evidence, which packages were parsed from (within package.Metadata). Finally, Syft serializes this document into one or more output formats. Supported formats include: Syft's native JSON format SPDX's tag-value and JSON CycloneDX's JSON and XML Having multiple formats allows integrating Syft into a variety of toolchains and passing data between systems that expect certain standards. Revisiting the earlier Ubuntu example, we can see a snippet of the final output: NAME VERSION        TYPE apt     2.7.14build2  deb base-files   13ubuntu10.1  deb bash         5.2.21-2ubuntu4    deb Container Image Parsing with Stereoscope To generate high-quality SBOMs from container images, Syft leverages a stereoscope library for parsing container image formats. Stereoscope does the heavy lifting of unpacking an image into its constituent layers, understanding the image metadata, and providing a unified filesystem view for Syft to scan. This encapsulation is quite powerful, as it abstracts the details of different container image specs (Docker, OCI, etc.), allowing Syft to focus on SBOM generation while still supporting a wide range of images. Cataloging Challenges and Future Work While Syft can generate quality SBOMs for many source types, there are still challenges and room for improvement. One challenge is supporting the vast variety of package types and versioning schemes. Each ecosystem has its own conventions, making it challenging to extract metadata consistently. Syft has added support for more ecosystems and evolved its catalogers to handle edge-cases to provide support for an expanding array of software tooling. Another challenge is dynamically generated packages, like those created at runtime or built from source. Capturing these requires more sophisticated analysis that Syft does not yet do. To illustrate, let's look at two common cases: Runtime Generated Packages Imagine a Python application that uses a web framework like Flask or Django. These frameworks allow defining routes and views dynamically at runtime based on configuration or plugin systems. For example, an application might scan a /plugins directory on startup, importing any Python modules found and registering their routes and models with the framework. These plugins could pull in their own dependencies dynamically using importlib. From Syft's perspective, none of this dynamic plugin and dependency discovery happens until the application actually runs. The Python files Syft scans statically won't reveal those runtime behaviors. Furthermore, plugins could be loaded from external sources not even present in the codebase Syft analyzes. They might be fetched over HTTP from a plugin registry as the application starts. To truly capture the full set of packages in use, Syft would need to do complex static analysis to trace these dynamic flows, or instrument the running application to capture what it actually loads. Both are much harder than scanning static files. Source Built Packages Another typical case is building packages from source rather than installing them from a registry like PyPI or RubyGems. Consider a C++ application that bundles several libraries in a /3rdparty directory and builds them from source as part of its build process. When Syft scans the source code directory or docker image, it won't find any already built C++ libraries to detect as packages. All it will see are raw source files, which are much harder to map to packages and versions. One approach is to infer packages from standard build tool configuration files, like CMakeLists.txt or Makefile. However, resolving the declared dependencies to determine the full package versions requires either running the build or profoundly understanding the specific semantics of each build tool. Both are fragile compared to scanning already built artifacts. Some Language Ecosystems are Harder Than Others It's worth noting that dynamism and source builds are more or less prevalent in different language ecosystems. Interpreted languages like Python, Ruby, and JavaScript tend to have more runtime dynamism in their package loading compared to compiled languages like Java or Go. That said, even compiled languages have ways of loading code dynamically, it just tends to be less common. Likewise, some ecosystems emphasize always building from source, while others have a strong culture of using pre-built packages from central registries. These differences mean the level of difficulty for Syft in generating a complete SBOM varies across ecosystems. Some will be more amenable to static analysis than others out of the box. What Could Help? To be clear, Syft has already done impressive work in generating quality SBOMs across many ecosystems despite these challenges. But to reach the next level of coverage, some additional analysis techniques could help: Static analysis to trace dynamic code flows and infer possible loaded packages (with soundness tradeoffs to consider) Dynamic instrumentation/tracing of applications to capture actual package loads (sampling and performance overhead to consider) Standardized metadata formats for build systems to declare dependencies (adoption curve and migration path to consider) Heuristic mapping of source files to known packages (ambiguity and false positives to consider) None are silver bullets, but they illustrate the approaches that could help push SBOM coverage further in complex cases. Ultimately, there will likely always be a gap between what static tools like Syft can discover versus the actual dynamic reality of applications. But that doesn't mean we shouldn't keep pushing the boundary! Even incremental improvements in these areas help make the software ecosystem more transparent and secure. Syft also has room to grow in terms of programming language support. While it covers major ecosystems like Java and Python well, more work is needed to cover languages like Go, Rust, and Swift completely. As the SBOM landscape evolves, Syft will continue to adapt to handle more package types, sources, and formats. Its extensible architecture is designed to make this growth possible. Get Involved Syft is fully open source and welcomes community contributions. If you're interested in adding support for a new ecosystem, fixing bugs, or improving SBOM generation, the repo is the place to get started. There are issues labeled "Good First Issue" for those new to the codebase. For more experienced developers, the code is structured to make adding new catalogers reasonably straightforward. No matter your experience level, there are ways to get involved and help push the state of the art in SBOM generation. We hope you'll join us! Learn about the role that SBOMs for the security of your organization in this white paper. Download Now ### STIG in Action: Continuous Compliance with MITRE & Anchore ### Community Spotlight: MegaLinter ### DORA + SBOM Primer: Achieving Software Supply Chain Security in Regulated Industries This blog post has been archived and replaced by the supporting pillar page that can be found here: https://anchore.com/wp-admin/post.php?post=987475393&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. ### SBOMs 101: A Free, Open Source eBook for the DevSecOps Community Today, we're excited to announce the launch of "Software Bill of Materials 101: A Guide for Developers, Security Engineers, and the DevSecOps Community". This eBook is free and open source resource that provides a comprehensive introduction to all things SBOMs. Why We Created This Guide While SBOMs have become increasingly critical for software supply chain security, many developers and security professionals still struggle to understand and implement them effectively. We created this guide to help bridge that knowledge gap, drawing on our experience building popular SBOM tools like Syft. What's Inside The ebook covers essential SBOM topics, including: Core concepts and evolution of SBOMs Different SBOM formats (SPDX, CycloneDX) and their use cases Best practices for generating and managing SBOMs Real-world examples of SBOM deployments at scale Practical guidance for integrating SBOMs into DevSecOps pipelines We've structured the content to be accessible to newcomers while providing enough depth for experienced practitioners looking to expand their knowledge. Community-Driven Development This guide is published under an open source license and hosted on GitHub at https://github.com/anchore/sbom-ebook. The collective wisdom of the DevSecOps community will strengthen this resource over time. We welcome contributions whether fixes, new content, or translations. Getting Started You can read the guide online, download PDF/ePub versions, or clone the repository to build it locally. The source is in Markdown format, making it easy to contribute improvements. Join Us We invite you to: Read the guide at https://github.com/anchore/sbom-ebook Star the repository to show your support Share feedback through GitHub issues Contribute improvements via pull requests Help spread the word about SBOM best practices The software supply chain security challenges we face require community collaboration. We hope this guide advances our collective understanding of SBOMs and their role in securing the software ecosystem. Learn about the role that SBOMs play for the security of your organization in this white paper. Download Now ### Increase Supply Chain Transparency & Security with Harbor and Anchore ### How to Tackle SBOM Sprawl and Secure Your Supply Chain This blog post has been archived and replaced by the supporting pillar page that can be found here: https://anchore.com/wp-admin/post.php?post=987475397&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. ### 2025 Cybersecurity Executive Order Requires Up Leveled Software Supply Chain Security A few weeks ago, the Biden administration published a new Executive Order (EO) titled “Executive Order on Strengthening and Promoting Innovation in the Nation’s Cybersecurity”. This is a follow-up to the original cybersecurity executive order—EO 14028—from May 2021. This latest EO specifically targets improvements to software supply chain security that addresses gaps and challenges that have surfaced since the release of EO 14028.  While many issues were identified, the executive order named and shamed software vendors for signing and submitting secure software development compliance documents without fully adhering to the framework. The full quote: In some instances, providers of software to the Federal Government commit[ed] to following cybersecurity practices, yet do not fix well-known exploitable vulnerabilities in their software, which put the Government at risk of compromise. The Federal Government needs to adopt more rigorous 3rd-party risk management practices and greater assurance that software providers... are following the practices to which they attest. In response to this behavior, the 2025 Cybersecurity EO has taken a number of additional steps to both encourage cybersecurity compliance and deter non-compliance—the carrot and the stick. This comes in the form of 4 primary changes: Compliance verification by CISA Legal repercussions for non-compliance Contract modifications for Federal agency software acquisition Mandatory adoption of software supply chain risk management practices by Federal agencies In this post, we’ll explore the new cybersecurity EO in detail, what has changed in software supply chain security compliance and what both federal agencies and software providers can do right now to prepare. What Led to the New Cybersecurity Executive Order? In the wake of massive growth of supply chain attacks—especially those from nation-state threat actors like China—EO 14028 made software bill of materials (SBOMs) and software supply chain security spotlight agenda items for the Federal government. As directed by the EO, the National Institute of Standards and Technology (NIST) authored the Secure Software Development Framework (SSDF) to codify the specific secure software development practices needed to protect the US and its citizens.  Following this, the Office of Management and Budget (OMB) published a memo that established a deadline for agencies to require vendor compliance with the SSDF. Importantly, the memo allowed vendors to “self-attest” to SSDF compliance. In practice, many software providers chose to go the easy route and submitted SSDF attestations while only partially complying with the framework. Although the government initially hoped that vendors would not exploit this somewhat obvious loophole, reality intervened, leading to the issuance of the 2025 cybersecurity EO to close off these opportunities for non-compliance. What’s Changing in the 2025 EO? 1. Rigorous verification of secure software development compliance No longer can vendors simply self-attest to SSDF compliance. The Cybersecurity and Infrastructure Security Agency (CISA) is now tasked with validating these attestations and via the additional compliance artifacts the new EO requires. Providers that fail validation risk increased scrutiny and potential consequences such as… 2. CISA authority to refer non-compliant vendors to DOJ A major shift comes from the EO’s provision allowing CISA to forward fraudulent attestations to the Department of Justice (DOJ). In the EO’s words, officials may “refer attestations that fail validation to the Attorney General for action as appropriate.” This raises the stakes for software vendors, as submitting false information on SSDF compliance could lead to legal consequences.  3. Explicit SSDF compliance in software acquisition contracts The Federal Acquisition Regulatory Council (FAR Council) will issue contract modifications that explicitly require SSDF compliance and additional items to enable CISA to programmatically verify compliance. Federal agencies will incorporate updated language in their software acquisition contracts, making vendors contractually accountable for any misrepresentations in SSDF attestations. See the "FAR council contract updates" section below for the full details. 4. Mandatory adoption of supply chain risk management Agencies must now embed supply chain risk management (SCRM) practices agency-wide, aligning with NIST SP 800-161, which details best practices for assessing and mitigating risks in the supply chain. This elevates SCRM to a "must-have" strategy for every Federal agency. Other Notable Changes Updated software supply chain security compliance controls NIST will update both NIST SP 800-53, the "Control Catalog", and the SSDF (NIST SP 800-218) to align with the new policy. The updates will incorporate additional controls and greater detail on existing controls. Although no controls have yet been formally added or modified, NIST is tasked with modernizing these documents to align with changes in secure software development practices. Once those updates are complete, agencies and vendors will be expected to meet the revised requirements. Policy-as-code pilot Section 7 of the EO describes a pilot program focused on translating security controls from compliance frameworks into “rules-as-code” templates. Essentially, this adopts a policy-as-code approach, often seen in DevSecOps, to automate compliance. By publishing machine-readable security controls that can be integrated directly into DevOps, security, and compliance tooling, organizations can reduce manual overhead and friction, making it easier for both agencies and vendors to consistently meet regulatory expectations. FedRAMP incentives and new key management controls The Federal Risk and Authorization Management Program (FedRAMP), responsible for authorizing cloud service providers (CSPs) for federal use, will also see important updates. FedRAMP will develop policies that incentivize or require CSPs to share recommended security configurations, thereby promoting a standard baseline for cloud security. The EO also proposes updates to FedRAMP security controls to address cryptographic key management best practices, ensuring that CSPs properly safeguard cryptographic keys throughout their lifecycle. How to Prepare for the New Requirements FAR council contract updates Within 30 days of the EO release, the FAR Council will publish recommended contract language. This updated language will mandate: Machine-readable SSDF Attestations: Vendors must provide an SSDF attestation in a structured, machine-readable format. Compliance Reporting Artifacts: High-level artifacts that demonstrate evidence of SSDF compliance, potentially including automated scan results, security test reports, or vulnerability assessments. Customer List: A list of all civilian agencies using the vendor’s software, enabling CISA and federal agencies to understand the scope of potential supply chain risk. Important Note: The 30-day window applies to the FAR Council to propose new contract language—not for software vendors to become fully compliant. However, once the new contract clauses are in effect, vendors who want to sell to federal agencies will need to meet these updated requirements. Action Steps for Federal Agencies Federal agencies will bear new responsibilities to ensure compliance and mitigate supply chain risk. Here’s what you should do now: Inventory 3rd-Party Software Component Suppliers Why It Matters: You can’t protect what you don’t know. An SBOM-powered software composition analysis (SCA) tool can integrate into your DevSecOps pipeline and generate a real-time inventory. Assess Visibility into Supplier Risk Perform a vulnerability scan on all 3rd-party components. If you already have SBOMs, scanning them for vulnerabilities is a quick way to find identity risk. Identify Critical Suppliers Determine which software vendors are mission-critical. This helps you understand where to focus your risk management efforts. Assess Data Sensitivity If a vendor handles sensitive data (e.g., PII), extra scrutiny is needed. A breach here has broader implications for the entire agency. Map Potential Lateral Movement Risk Understand if a vendor’s software could provide attackers with lateral movement opportunities within your infrastructure. Action Steps for Software Providers For software vendors, especially those who sell to the federal government, proactivity is key to maintaining and expanding federal contracts. Inventory Your Software Supply Chain Implement an SBOM-powered SCA solution within your DevSecOps pipeline to gain real-time visibility into all 3rd-party components. Assess Supplier Risk Perform vulnerability scanning on 3rd-party supplier components to identify any that could jeopardize your compliance or your customers’ security. Identify Sensitive Data Handling If your software processes personally identifiable information (PII) or other sensitive data, expect increased scrutiny. On the flip side, this may make your offering “mission-critical” and less prone to replacement—but it also means compliance standards will be higher. Map Your Own Attack Surface Assess whether a 3rd-party supplier breach could cascade into your infrastructure and, by extension, your customers. Prepare Compliance Evidence Start collecting artifacts—such as vulnerability scan reports, secure coding guidelines, and internal SSDF compliance checklists—so you can quickly meet new attestation requirements when they come into effect. Wrap-Up The 2025 Cybersecurity EO is a direct response to the flaws uncovered in EO 14028’s self-attestation approach. By requiring 3rd-party validation of SSDF compliance, the government aims to create tangible improvements in its cybersecurity posture—and expects the same from all who supply its agencies. Given the rapid timeline, preparation is crucial. Both federal agencies and software providers should begin assessing their supply chain risks, implementing SBOM-driven visibility, and proactively planning for new attestation and reporting obligations. By taking steps now, you’ll be better positioned to meet the new requirements. Learn about SSDF Attestation with this guide. The eBook will take you through everything you need to know to get started. Download Now ### A Complete Guide to Container Security This blog post has been archived and replaced by the supporting pillar page that can be found here: https://anchore.com/wp-admin/post.php?post=987474704&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. ### Rocky Mountain Cyber Symposium 2025 ### WEST 2025 ### Software Supply Chain Security in 2025: SBOMs Take Center Stage In recent years, we’ve witnessed software supply chain security transition from a quiet corner of cybersecurity into a primary battlefield. This is due to the increasing complexity of modern software that obscures the full truth—applications are a tower of components of unknown origin. Cybercriminals have fully embraced this hidden complexity as a ripe vector to exploit. Software Bills of Materials (SBOMs) have emerged as the focal point to achieve visibility and accountability in a software ecosystem that will only grow more complex. SBOMs are an inventory of the complex dependencies that make up modern applications. SBOMs help organizations scale vulnerability management and automate compliance enforcement. The end goal is to increase transparency in an organization's supply chain where 70-90% of modern applications are open source software (OSS) dependencies. This significant source of risk demands a proactive, data-driven solution. Looking ahead to 2025, we at Anchore, see two trends for SBOMs that foreshadow their growing importance in software supply chain security: Global regulatory bodies continue to steadily drive SBOM adoption Foundational software ecosystems begin to implement build-native SBOM support In this blog, we'll walk you through the contextual landscape that leads us to these conclusions; keep reading if you want more background. Global Regulatory Bodies Continue Growing Adoption of SBOMs As supply chain attacks surged, policymakers and standards bodies recognized this new threat vector as a critical threat with national security implications. To stem the rising tide supply chain threats, global regulatory bodies have recognized that SBOMs are one of the solutions. Over the past decade, we’ve witnessed a global legislative and regulatory awakening to the utility of SBOMs. Early attempts like the US Cyber Supply Chain Management and Transparency Act of 2014 may have failed to pass, but they paved the way for more significant milestones to come. Things began to change in 2021, when the US Executive Order (EO) 14028 explicitly named SBOMs as the foundation for a secure software supply chain. The following year the European Union’s Cyber Resilience Act (CRA) pushed SBOMs from “suggested best practice” to “expected norm.” The one-two punch of the US’s EO 14028 and the EU’s CRA has already prompted action among regulators worldwide. In the years following these mandates, numerous global bodies issued or updated their guidance on software supply chain security practices—specifically highlighting SBOMs. Cybersecurity offices in Germany, India, Britain, Australia, and Canada, along with the broader European Union Agency for Cybersecurity (ENISA), have each underscored the importance of transparent software component inventories. At the same time, industry consortiums in the US automotive (Auto-ISAC) and medical device (IMDRF) sectors recognized that SBOMs can help safeguard their own complex supply chains, as have federal agencies such as the FDA, NSA, and the Department of Commerce. By the close of 2024, the pressure mounted further. In the US, the Office of Management and Budget (OMB) set a due date requiring all federal agencies to comply with the Secure Development Framework (SSDF), effectively reinforcing SBOM usage as part of secure software development. Meanwhile, across the Atlantic, the EU CRA officially became law, cementing SBOMs as a cornerstone of modern software security. This constant pressure ensures that SBOM adoption will only continue to grow. It won't be long until SBOMs become table stakes for anyone operating an online business. We expect the steady march forward of SBOMs to continue in 2025.  In fact, this regulatory push has been noticed by the foundational ecosystems of the software industry and they are reacting accordingly. Software Ecosystems Trial Build-Native SBOM Support Until now, SBOM generation has been relegated to afterthought in software ecosystems. Businesses scan their internal supply chains with software composition analysis (SCA) tools; trying to piece together a picture of their dependencies. But as SBOM adoption continues its upward momentum, this model is evolving. In 2025, we expect that leading software ecosystems will promote SBOMs to a first-class citizen and integrate them natively into their build tools. Industry experts have recently begun advocating for this change. Brandon Lum, the SBOM Lead at Google, notes, “The software industry needs to improve build tools propagating software metadata.” Rather than forcing downstream consumers to infer the software’s composition after the fact, producers will generate SBOMs as part of standard build pipelines. This approach reduces friction, makes application composition discoverable, and ensures that software supply chain security is not left behind. We are already seeing early examples: Linux Ecosystem (Yocto): The Yocto Project’s OpenEmbedded build system now includes native SBOM generation. This demonstrates the feasibility of integrating SBOM creation directly into the developer toolchain, establishing a blueprint for other ecosystems to follow. Python Ecosystem: In 2024, Python maintainers explored proposals for build-native SBOM support, motivated by the regulations such as, the Secure Software Development Framework (SSDF) and the EU's CRA. They’ve envisioned a future where projects, package maintainers, and contributors can easily annotate their code with software dependency metadata that will automatically propagate at build time. Perl Ecosystem: The Perl Security Working Group has also begun exploring internal proposals for SBOM generation, again driven by the CRA’s regulatory changes. Their goal: ensure that Perl packages have SBOM data baked into their ecosystems so that compliance and security requirements can be met more effortlessly. Java Ecosystem: The Eclipse Foundation and VMware’s Spring Boot team have introduced plug-ins for Java build tools like Maven or Gradle that streamline SBOM generation. While not fully native to the compiler or interpreter, these integrations lower the barrier to SBOM adoption within mainstream Java development workflows. In 2025 we won’t just be talking about build-native SBOMs in abstract terms—we’ll have experimental support for them from the most forward thinking ecosystems. This shift is still in its infancy but it foreshadows the central role that SBOMs will play in the future of cybersecurity and software development as a whole. Closing Remarks The writing on the wall is clear: supply chain attacks aren’t slowing down—they are accelerating. In a world of complex, interconnected dependencies, every organization must know what’s inside its software to quickly spot and respond to risk. As SBOMs move from a nice-to-have to a fundamental part of building secure software, teams can finally gain the transparency they need over every component they use, whether open source or proprietary. This clarity is what will help them respond to the next Log4j or XZ Utils issue before it spreads, putting security team's back in the driver’s seat and ensuring that software innovation doesn’t come at the cost of increased vulnerability. Learn about the role that SBOMs for the security of your organization in this white paper. Download Now ### The Complete Guide to Software Supply Chain Security The mega-trends of the containerization of applications and the rise of open-source software components have sped up the velocity of software delivery. This evolution, while offering significant benefits, has also introduced complexity and challenges to traditional software supply chain security.  Anchore was founded on the belief that the legacy security solutions of the monolith-era could be re-built to deliver on the promises of speed without sacrificing security. Anchore is trusted by Fortune 100 companies and the most exacting federal agencies across the globe because it has delivered on this promise.   If you’d like to learn more about how the Anchore Enterprise platform is able to accomplish this, feel free to book a time to speak with one of our specialists. If you’re looking to get a better understanding of how software supply chains operate, where the risks lie and best practices on how to manage the risks, then keep reading. An Overview of Software Supply Chains  Before you can understand how to secure the software supply chain, it’s important to understand what the software supply chain is in the first place. A software supply chain is all of the individual software components that make up a software application.  Software supply chains are similar to physical supply chains. When you purchase an iPhone all you see is the finished product. Behind the final product is a complex web of component suppliers that are then assembled together to produce an iPhone. Displays and camera lenses from a Japanese company, CPUs from Arizona, modems from San Diego, lithium ion batteries from a Canadian mine; all of these pieces come together in a Shenzhen assembly plant to create a final product that is then shipped straight to your door. In the same way that an iPhone is made up of a screen, a camera, a CPU, a modem, and a battery, modern applications are composed of individual software components (i.e. dependencies) that are bundled together to create the finished product.  With the rise of open source software, most of these components are open source frameworks, libraries and operating systems. Specifically, 70-90% of modern applications are built utilizing open source software components. Before the ascent of open source software, applications were typically developed with proprietary, in-house code without a large and diverse set of software “suppliers”. In this environment the entire “supply chain” were employees of the company which reduced the complex nature of managing all of these teams. The move to Cloud Native and DevSecOps design patterns dramatically sped up the delivery of software with the complication that the complexity of coordinating all of the open source software suppliers increased significantly. This shift in the way that software is developed impacts essentially all modern software that is written. This means that all businesses and government agencies are waking up to the realization that they are building a software supply chain whether they want it or not. One of the ways this new supply chain complexity is being tamed is with the software bill of materials (SBOM). A software bill of materials (SBOM) is a structured list of software components, modules, and libraries that are included in a given piece of software. Similar to the nutrition labels on the back of the foods that you buy, SBOMs are a list of ingredients that go into the software that your applications consume. We normally think of SBOMs as an artifact of the development process. As a developer is “manufacturing” their application using different dependencies they are also building a “recipe” based on the ingredients. What is software supply chain security?  Software supply chain security is the process of finding and preventing any vulnerabilities that exist from impacting the software applications that utilize the vulnerable components. Going back to the iPhone analogy from the previous section, in the same way that an attacker could target one of the iPhone suppliers to modify a component before the iPhone is assembled, a software supply chain threat actor could do the same but target an open source package that is then built into a commercial application.  Given the size and prevalence of open source software components in modern applications, the supply chain is only as secure as its weakest link. The image below of the iceberg has become a somewhat overused meme of software supply chain security but it has become overused precisely because it explains the situation so well. A different analogy would be to view the open source software components that your application is built using as a pyramid. Your application’s supply chain is all of the open source components that your proprietary business logic is built on top of. The rub is that each of these components that you utilize have their own pyramid of dependencies that they are built with. The foundation of your app might look solid but there is always the potential that if you follow the dependencies chain far enough down that you will find a vulnerability that could topple the entire structure. This gives adversaries their opening. A single compromised package allows attackers to manipulate all of the packages “downstream” of their entrypoint. This reality was viscerally felt by the software industry (and all industries that rely on the software industry, meaning all industries) during the Log4j incident.  Common Software Supply Chain Risks Software development is a multifaceted process, encompassing various components and stages. From the initial lines of code to the final deployment in a production environment, each step presents potential risks for vulnerabilities to creep in. As organizations increasingly integrate third-party components and open-source libraries into their applications, understanding the risks associated with the software supply chain becomes paramount. This section delves into the common risks that permeate the software supply chain, offering insights into their origins and implications. Source Code Supply chain risks start with the code itself. Below are the most common risks associated with a software supply chain when generating custom first-party code: Insecure first-party code Custom code is the first place to be aware of risk in the supply chain. If the code written by your developers isn’t secure then your application will be vulnerable at its foundation. Insecure code is any application logic that can be manipulated to perform a function that wasn’t originally intended by the developer. For example, if a developer writes a function that allows a user to login to their account by checking the user database that a username and password match the ones provided by the user but an attacker crafts a payload that instead causes the function to delete the entire user database this is insecure code. Source code management (SCM) compromise Source code is typically stored in a centralized repository so that all of your developers can collaborate on the same codebase. An SCM is software that can potentially be vulnerable the same as your first-party code. If an adversary gains access to your SCM through a vulnerability in the software or through social engineering then they will be able to manipulate your source code at the foundation. Developer environments Developer environments are powerful productivity tools for your engineers but they are another potential fount of risk for an organization. Most integrated developer environments come with a plug-in system so that developers can customize their workflows for maximum efficiency. These plug-in systems typically also have a marketplace associated with them. In the same way that a malicious Chrome browser plug-in and compromise a user's laptop, a malicious developer plug-in can gain access to a “trusted” engineers development system and piggyback on this trusted access to manipulate the source code of an application. 3rd-Party Dependencies (Open source or otherwise) Third-party software is really just first-party software written by someone else. The same way that the cloud is just servers run by someone else. Third-party software dependencies are potentially vulnerable to all of the same risks associated with your own first-party code in the above section. Since it isn’t your code you have to deal with the risks in a different way. Below we layout the two risks associated with this software supply chain risk: Known vulnerabilities (CVEs, etc) Known vulnerabilities are insecure or malicious code that has been identified in a third-party dependency. Typically the maintainer of a third-party dependency will fix their insecure code when they are notified and publish an update. Sometimes if the vulnerability isn’t a priority they won’t address it for a long time (if ever). If your developers rely on this dependency for your application then you have to assume the risk. Unknown vulnerabilities (zero-days) Unknown vulnerabilities are insecure or malicious code that hasn’t been discovered. These vulnerabilities can lay dormant in a codebase for months, years or even decades. When they are finally uncovered and announced there is typically a scramble across the world by any business that uses software (i.e. almost all businesses) to figure out whether they utilize this dependency and how to protect themselves from having it be exploited. Attackers are in a scramble themselves to determine who is using the vulnerable software and crafting exploits to take advantage of businesses that are slow to react. Build Pipeline & Artifact Repository Build pipeline compromise A software build pipeline is a software system that pulls the original source code from an SCM then pulls all of the third-party dependencies from their source repositories and goes through the process of creating and optimizing the code into a binary that can then be stored in an artifact repository. It is similar to an SCM in that it is software, it is composed of both first- and third-party code which means there will be all of the same associated risks to its source code and software dependencies. Organizations deal with these risks differently than the developers of the build systems because they do not control this code. Instead the risks are around managing who has access to the build system and what they can do with their access. Risks range from modifying where the build system is pulling source code from to modifying the build instructions to inject malicious or vulnerable code into previously secure source. Artifact registry compromise An artifact registry is a centralized repository of the fully built applications (typically in the format of a container or image) that a deployment orchestrator would use to pull the software from in order to run it in a production environment. It is also software similar to a build pipeline or SCM and has the same associated risks as mentioned before. Typically, the risks of registries are managed through how trust is managed between the registry and the build system or any other system/person that has access to it. Risks range from an attacker poisoning the registry with an untrusted container or an attacker gaining privileged access to the repository and modifying a container in place. Production Deployment orchestrator compromise A deployment orchestrator is a system that pulls pre-built software binaries and runs the applications on servers. It is another type of software system similar to a build pipeline or SCM and has the same associated risks as mentioned before. Typically, the risks of orchestrators are managed through trust relationships between the orchestrator and the artifact registry or any other system/person that has access to it. Risks range from an attacker manipulating the orchestrator into deploying an untrusted container or an attacker gaining privileged access to the orchestrator and modifying a running container or manifest. Production environment compromise The production environment is the application running on a server that was deployed by an orchestrator. It is the software system built from the original source code that fulfills user’s requests. It is the final product that is created from the software supply chain. The risks associated with this system are different from most other systems because it typically serves users outside of the organization and has different risks associated with it because not as much is known about external users as internal users.  Examples of software supply chain attacks As reliance on third-party components and open-source libraries grows, so does the potential for vulnerabilities in the software supply chain. Several notable incidents have exposed these risks, emphasizing the need for proactive security and a deep understanding of software dependencies. In this section, we explore significant software supply chain attacks and the lessons they impart. SolarWinds (2020) In one of the most sophisticated supply chain attacks, malicious actors compromised the update mechanism of SolarWinds' Orion software. This breach allowed the attackers to distribute malware to approximately 18,000 customers. The attack had far-reaching consequences, affecting numerous government agencies, private companies, and critical infrastructure. Lessons Learned: The SolarWinds attack underscored the importance of securing software update mechanisms and highlighted the need for continuous monitoring and validation of software components. Log4j (2021) In late 2021, a critical vulnerability was discovered in the Log4j logging library, a widely used Java-based logging utility. Dubbed "Log4Shell," this vulnerability allowed attackers to execute arbitrary code remotely, potentially gaining full control over vulnerable systems. Given the ubiquity of Log4j in various software applications, the potential impact was massive, prompting organizations worldwide to scramble for patches and mitigation strategies. Lessons Learned: The Log4j incident underscored the risks associated with ubiquitous open-source components. It highlighted the importance of proactive vulnerability management, rapid response to emerging threats, and the need for organizations to maintain an updated inventory of third-party components in their software stack. NotPetya (2017) Originating from a compromised software update mechanism of an Ukrainian accounting software, NotPetya spread rapidly across the globe. Masquerading as ransomware, its primary intent was data destruction. Major corporations, including Maersk, FedEx, and Merck, faced disruptions, leading to financial losses amounting to billions. Lessons Learned: NotPetya highlighted the dangers of nation-state cyber warfare and the need for robust cybersecurity measures, even in seemingly unrelated software components. Node.js Packages coa and rc In July 2021, two widely-used npm packages, coa and rc, were compromised. Malicious versions of these packages were published to the npm registry, attempting to run a script to access sensitive information from users' .npmrc files. The compromised versions were downloaded thousands of times before being identified and removed. Lessons Learned: This incident emphasized the vulnerabilities in open-source repositories and the importance of continuous monitoring of dependencies. It also highlighted the need for developers and organizations to verify the integrity of packages before installation and to be wary of unexpected package updates. JuiceStealer Malware JuiceStealer is a malware spread through a technique known as typosquatting on the PyPI (Python Package Index). Malicious packages were seeded on PyPI, intending to infect users with the JuiceStealer malware, designed to steal sensitive browser data. The attack involved a complex chain, including phishing emails to PyPI developers. Lessons Learned: JuiceStealer showcased the risks of typosquatting in package repositories and the importance of verifying package names and sources. It also underscored the need for repository maintainers to have robust security measures in place to detect and remove malicious packages promptly. Node.js Packages colors and faker In January 2022, the developer behind popular npm libraries colors and faker intentionally sabotaged both packages in an act of "protestware." This move affected thousands of applications, leading to broken builds and potential security risks. The compromised versions were swiftly removed from the npm registry. Lessons Learned: This incident highlighted the potential risks associated with relying heavily on open-source libraries and the actions of individual developers. It underscored the importance of diversifying dependencies, having backup plans, and the need for the open-source community to address developer grievances constructively. Standards and Best Practices for Preventing Attacks There are a number of different initiatives to define best practices for software supply chain security. Organizations ranging from the National Institute of Standards and Technology (NIST) to the Cloud Native Computing Foundation (CNCF) to Open Source Security Foundation (OpenSSF) have created fantastically detailed documentation on their recommendations to achieve an optimally secure supply chain. Choosing any of the standards defined is better than choosing none or even cherry-picking from each of the standards to create a program that is best tailored to the risk profile of your organization. If you’d prefer to stick to one for simplicity sake and need some help deciding, Anchore has detailed our thoughts on the pros and cons of each software supply chain standard here. Below is a concise summary of each of the major standards to help get you started: National Institute of Standards and Technology (NIST) NIST has a few different standards that are worth noting. We’ve ordered them from the broadest to the most specific and, coincidently, chronically as well. NIST SP 800-53, “Security and Privacy Controls for Information Systems and Organizations” NIST 800-53, aka the Control Catalog, is the grandaddy of NIST security standards. It has had a long life and evolved alongside the security landscape. Typically paired with NIST 800-37, the Risk Management Framework or RMF, this pair of standards create a one-two punch that not only produce a highly secure environment for protecting classified and confidential information but set up organizations to more easily be compliant with federal compliance standards like FedRAMP. Software supply chain security (SSCS) topics first began filtering into NIST 800-53 in 2013 but it wasn’t until 2020 that the Control Catalog was updated to break out SSCS into its own section. If your concern is to get up and running with SCSS as quickly as possible then this standard will be overkill. If your goal is to build toward FedRAMP and NIST 800-53 compliance as well as build a secure software development process then this standard is for you. If you’re looking for something more specific, one of the two next standards might be for you. If you need a comprehensive guide to NIST 800-53 or its spiritual sibling, NIST 800-37, we have put together both. You can find a detailed but comprehensible guide to the Control Catalog here and the same plain english, deep-dive into NIST 800-37 here. NIST SP 800-161, “Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations” NIST 800-161 is an interesting application of both the RMF and the Control Catalog for supply chain security specifically. The controls in NIST 800-161 take the base controls from NIST 800-53 and provide guidance on how to achieve more specific outcomes for the controls. For the framework, NIST 800-161 takes the generic RMF and creates a version that is tailored to SSCS.  NIST 800-161 is a comprehensive standard that will guide your organization to create a development process with its primary output being highly secure software and systems.  NIST SP 800-218, “Secure Software Development Framework (SSDF)” NIST 800-218, the SSDF, is an even more refined standard than NIST 800-161. The SSDF targets the software developer as the audience and gives even more tailored recommendations on how to create secure software systems. If you’re a developer attempting to build secure software that complies with all of these standards, we have an ongoing blog series that breaks down the individual controls that are part of the SSDF. NIST SP 800-204D, “Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines” Focused specifically on Cloud-native architectures and Continuous Integration/Continuous Delivery (CI/CD) pipelines, NIST 800-204D is a significantly more specific standard than any of the previous standards. That being said, if the primary insertion point for software supply chain security in your organization is via the DevOps team then this standard will have the greatest impact on your overall software supply chain security. Also, it is important to note that this standard is still a draft and will likely change as it is finalized. Open Source Security Foundation (OpenSSF) A project of the Linux Foundation, the Open Source Security Foundation is a cross-industry organization that focuses on the security of the open source ecosystem. Since most 3rd-party dependencies are open source they carry a lot of weight in the software supply chain security domain.  Supply-chain Levels for Software Artifacts (SLSA) If an SBOM is an ingredients label for a product then the SLSA (pronounced ‘salsa’) is the food safety handling guidelines of the factory where they are produced. It focuses primarily on updating traditional DevOps workflows with signed attestations around the quality of the software that is produced. Google originally donated the framework and has been using an internal version of SLSA since 2013 which it requires for all of their production workloads.  You can view the entire framework on its dedicated website here Secure Supply Chain Consumption Framework (S2C2F)  The S2C2F is similar to SLSA but much broader in its scope. It gives recommendations around the security of the entire software supply chain using both traditional security practices such as scanning for vulnerabilities. It touches on signed attestations but not at the same level of depth at the SLSA. The S2C2F was built and donated by Microsoft, where it has been used and refined internally since 2019. You can view the entire list of recommendations on its GitHub repository. Cloud Native Computing Foundation (CNCF) The CNCF is also a project of the Linux Foundation but is focused on the entire ecosystem of open-source, cloud-native software. The Security Technical Advisory Group at the CNCF has a vested interest in supply chain security because the majority of the software that is incubated and matured at the CNCF is part of the software development lifecycle. Software Supply Chain Best Practices White Paper The Security Technical Advisory Group at CNCF, created a best practices white paper that was heralded as a huge step forward for the security of software supply chains. The document creation was led by the CTO of Docker and the Chief Open Source Officer at Isovalent. It captures over 50 recommended practices to secure the software supply chain. You can view the full document here. Types of Supply Chain Compromise This document isn’t a standard or best practices, instead it is support for the best practices white paper that defines a full list of supply chain compromises. Catalog of Supply Chain Compromises This isn’t a standard or best practices document, as well. It is instead a detailed history of the significant supply chain breaches that have occurred over the years. Helpful for understanding this history that informed the best practices detailed in the accompanying white paper. How Anchore Can Help  Anchore is a leading software supply chain security company that has built a modern, SBOM-powered software composition analysis (SCA) platform that helps organizations incorporate many of the software supply chain best practices that are defined in the above guides. As we have learned working with Fortune 100 enterprises and federal agencies, including the Department of Defense, an organization's supply chain security can only be as good as the depth of their data on their supply chain and the automation of processing the raw data into actionable insights. Anchore Enterprise provides an end-to-end software supply chain security system with total visibility, deep inspection, automated enforcement, expedited remediation and trusted reporting to deliver the actionable insights to make a supply chain as secure as possible. If you’d like to learn more about the Anchore Enterprise platform or speak with a member of our team, feel free to book a time to speak with one of our specialists. ### All Things SBOM in 2025: a Weekly Webinar Series Software Bills of Materials (SBOMs) have quickly become a critical component in modern software supply chain security. By offering a transparent view of all the components that make up your applications, SBOMs enable you to pinpoint vulnerabilities before they escalate into costly incidents. As we enter 2025, software supply chain security and risk management for 3rd-party software dependencies are top of mind for organizations. The 2024 Anchore Software Supply Chain Security Survey notes that 76% of organizations consider these challenges top priorities. Given this, it is easy to see why understanding what SBOMs are—and how to implement them—is key to a secure software supply chain. To help organizations achieve these top priorities Anchore is hosting a weekly webinar series dedicated entirely to SBOMs. Beginning January 14 and running throughout Q1, our webinar line-up will explore a wide range of topics (see below). Industry luminaries like Kate Stewart (co-founder of the SPDX project) and Steve Springett (Chair of the OWASP CycloneDX Core Working Group) will be dropping in to provide unique insights and their special blend of expertise on all things SBOMs. The series will cover: SBOM basics and best practices SDPX and SBOMs in-depth with Kate Stewart Getting started: How to generate an SBOM Software supply chain security and CycloneDX with Steve Springett Scaling SBOMs for the enterprise Real-world insights on applying SBOMs in high-stakes or regulated sectors A look ahead at the future of SBOMs and software supply chain security with Kate Stewart And more! We invite you to learn from experts, gain practical skills, and stay ahead of the rapidly evolving world of software supply chain security. Visit our events page to register for the webinars now or keep reading to get a sneak peek at the content. #1 Understanding SBOMs: An Intro to Modern Development Date/Time: Tuesday, January 14, 2025 – 10am PST / 1pm ESTFeaturing:  Lead Developer of Syft Anchore VP of Security Anchore Director of Developer Relations Register Now We are kicking off the series with an introduction to the essentials of SBOMs. This session will cover the basics of SBOMs—what they are, why they matter, and how to get started generating and managing them. Our experts will walk you through real-world examples (including Log4j) to show just how vital it is to know what’s in your software. Key Topics: Defining SBOM standards and formats Best practices for generating and automating SBOMs Integrating SBOMs into existing infrastructure and workflows Practical tips for protecting against emerging supply chain threats This webinar is perfect for both technical practitioners and business leaders looking to establish a strong SBOM foundation. #2 Understanding SBOMs: Deep Dive with Kate Stewart Date/Time: Wednesday, January 22, 2025 – 10am PST / 1pm ESTFeatured Guest: Kate Stewart (co-founder of SPDX) Register Now Our second session brings you a front-row seat to an in-depth conversation with Kate Stewart, co-founder of the SPDX project. Kate is a leading voice in software supply chain security and the SBOM standard. From the origins of the SPDX standard to the latest challenges in license compliance, Kate will provide an extensive behind-the-scenes look into the world of SBOMs. Key Topics: The history and evolution of SBOMs, including the creation of SPDX Balancing license compliance with security requirements How SBOMs support critical infrastructure with national security concerns The impact of emerging technology—like open source LLMs—on SBOM generation and analysis If you’re ready for a more advanced look at SBOMs and their strategic impact, you won’t want to miss this conversation. #3 How to Automate, Generate, and Manage SBOMs Date/Time: Wednesday, January 29, 2025 – 12pm EST / 9am PSTFeaturing:  Anchore Director of Developer Relations Anchore Principal Solutions Engineer Register Now For those seeking a hands-on approach, this webinar dives into the specifics of automating SBOM generation and management within your CI/CD pipeline. Anchore's very own Alan Pope (Developer Relations) and Sean Fazenbaker (Solutions) will walk you through proven techniques for integrating SBOMs to reveal early vulnerabilities, minimize manual interventions, and improve overall security posture. Key Topics: Automating SBOM generation during build and deployment stages Seamless integration into existing CI/CD workflows Managing SBOM data at scale Balancing cost and effort between manual processes and automation This is the perfect session for teams focused on shifting security left and preserving developer velocity. What’s Next? Beyond our January line-up, we have more exciting sessions planned throughout Q1. Each webinar will feature industry experts and dive deeper into specialized use-cases and future technologies: CycloneDX & OWASP with Steve Springett – A closer look at this popular SBOM format, its technical architecture, and VEX integration. SBOM at Scale: Enterprise SBOM Management – Learn from large organizations that have successfully rolled out SBOM practices across hundreds of applications. SBOMs in High-Stakes Environments – Explore how regulated industries like healthcare, finance, and government handle unique compliance challenges and risk management. The Future of Software Supply Chain Security – Join us in March as we look ahead at emerging standards, tools, and best practices with Kate Stewart returning as the featured guest. Stay tuned for dates and registration details for each upcoming session. Follow us on your favorite social network (Twitter, Linkedin, Bluesky) or visit our events page to stay up-to-date. Learn about the role that SBOMs for the security of your organization in this white paper. Download Now ### The Top Ten List: The 2024 Anchore Blog To close out 2024, we're going to count down the top 10 hottest hits from the Anchore blog in 2024! The Anchore content team continued our tradition of delivering expert guidance, practical insights, and forward-looking strategies on DevSecOps, cybersecurity compliance, and software supply chain management. This top ten list spotlights our most impactful blog posts from the year, each tackling a different angle of modern software development and security. Hot topics this year include:  All things SBOM (software bill of materials) DevSecOps compliance for the Department of Defense (DoD) Regulatory compliance for federal government vendors (e.g., FedRAMP & SSDF Attestation) Vulnerability scanning and management—a perennial favorite! Our selection runs the gamut of knowledge needed to help your team stay ahead of the compliance curve, boost DevSecOps efficiency, and fully embrace SBOMs. So, grab your popcorn and settle in—it’s time to count down the blog posts that made the biggest splash this year! The Top Ten List 10 | A Guide to Air Gapping Kicking us off at number 10 is a blog that’s all about staying off the grid—literally. Ever wonder what it really means to keep your network totally offline?  A Guide to Air Gapping: Balancing Security and Efficiency in Classified Environments breaks down the concept of “air gapping”—literally disconnecting a computer from the internet by leaving a "gap of air" between your computer and an ethernet cable. It is generally considered a security practice to protect classified, military-grade data or similar. Our blog covers the perks, like knocking out a huge range of cyber threats, and the downsides, like having to manually update and transfer data. It also details how Anchore Enforce Federal Edition can slip right into these ultra-secure setups, blending top-notch protection with the convenience of automated, cloud-native software checks. 9 | SBOMs + Vulnerability Management == Open Source Security++ Coming in at number nine on our countdown is a blog that breaks down two of our favorite topics; SBOMs and vulnerability scanners—And how using SBOMs as your foundation for vulnerability management can level up your open source security game. SBOMs and Vulnerability Management: OSS Security in the DevSecOps Era is all about getting a handle on:  every dependency in your code,  scanning for issues early and often, and  speeding up the DevSecOps process so you don’t feel the drag of legacy security tools.  By switching to this modern, SBOM-driven approach, you’ll see benefits like faster fixes, smoother compliance checks, and fewer late-stage security surprises—just ask companies like NVIDIA, Infoblox, DreamFactory and ModuleQ, who’ve saved tons of time and hassle by adopting these practices. 8 | Improving Syft’s Binary Detection Landing at number eight, we’ve got a blog post that’s basically a backstage pass to Syft’s binary detection magic. Improving Syft’s Binary Detection goes deep on how Syft—Anchore's open source SBOM generation tool—uncovers out the details of executable files and how you can lend a hand in making it even better.  We walk you through the process of adding new binary detection rules, from finding the right binaries and testing them out, to fine-tuning the patterns that match their version strings.  The end goal? Helping all open source contributors quickly get started making their first pull request and broadening support for new ecosystems. A thriving, community-driven approach to better securing the global open source ecosystem. 7 | A Guide to FedRAMP in 2024: FAQs & Key Takeaways Sliding in at lucky number seven, we’ve got the ultimate cheat sheet for FedRAMP in 2024 (and 2025😉)! Ever wonder how Uncle Sam greenlights those fancy cloud services? A Guide to FedRAMP in 2024: FAQs & Key Takeaways spills the beans on all the FedRAMP basics you’ve been struggling to find—fast answers without all the fluff.  It covers what FedRAMP is, how it works, who needs it, and why it matters; detailing the key players and how it connects with other federal security standards like FISMA. The idea is to help you quickly get a handle on why cloud service providers often need FedRAMP certification, what benefits it offers, and what’s involved in earning that gold star of trust from federal agencies. By the end, you’ll know exactly where to start and what to expect if you’re eyeing a spot in the federal cloud marketplace. 6 | Introducing Grant: OSS Licence Management At number six on tonight’s countdown, we’re rolling out the red carpet for Grant—Anchore’s snazzy new software license-wrangling sidekick! Introducing Grant: An OSS project for inspecting and checking license compliance using SBOMs covers how Grant helps you keep track of software licenses in your projects.  By using SBOMs, Grant can quickly show you which licenses are in play—and whether any have changed from something friendly to something more restrictive. With handy list and check commands, Grant makes it easier to spot and manage license risk, ensuring you keep shipping software without getting hit with last-minute legal surprises. 5 | An Overview of SSDF Attestation: Compliance Need-to-Knows Landing at number five on tonight’s compliance countdown is a big wake-up call for all you software suppliers eyeing Uncle Sam’s checkbook: the SSDF Attestation Form. That’s right—starting now, if you wanna do business with the feds, you gotta show off those DevSecOps chops, no exceptions! In Using the Common Form for SSDF Attestation: What Software Producers Need to Know we break down the new Secure Software Development Attestation Form—released in March 2024—that’s got everyone talking in the federal software space.  In short, if you’re a software vendor wanting to sell to the US government, you now have to “show your work” when it comes to secure software development. The form builds on the SSDF framework, turning it from a nice-to-have into a must-do. It covers which software is included, the timelines you need to know, and what happens if you don’t shape up. There are real financial risks if you can’t meet the deadlines or if you fudge the details (hello, criminal penalties!). With this new rule, it’s time to get serious about locking down your dev practices or risk losing out on government contracts. 4 | Prep your Containers for STIG At number four, we’re diving headfirst into the STIG compliance world—the DoD’s ultimate ‘tough crowd’ when it comes to security! If you’re feeling stressed about locking down those container environments—we’ve got you covered. 4 Ways to Prepare your Containers for the STIG Process is all about tackling the often complicated STIG process for containers in DoD projects.  You’ll learn how to level up your team by cross-training cybersecurity pros in container basics and introducing your devs and architects to STIG fundamentals. It also suggests going straight to the official DISA source for current STIG info, making the STIG Viewer a must-have tool on everyone’s workstation, and looking into automation to speed up compliance checks.  Bottom line: stay informed, build internal expertise, and lean on the right tools to keep the STIG process from slowing you down. 3 | Syft Graduates to v1.0! Give it up for number three on our countdown—Syft’s big graduation announcement! In Syft Reaches v1.0! Syft celebrates hitting the big 1.0 milestone!  Syft is Anchore's OSS tool for generating SBOMs, helping you figure out exactly what’s inside your software, from container images to source code. Over the years, it’s grown to support over 40 package types, outputting SBOMs in various formats like SPDX and CycloneDX. With v1.0, Syft’s CLI and API are now stable, so you can rely on it for consistent results and long-term compatibility.  But don’t worry—development doesn’t stop here. The team plans to keep adding support for more ecosystems and formats, and they invite the community to join in, share ideas, and contribute to the future of Syft. 2 | RAISE 2.0 Overview: RMF and ATO for the US Navy Next up at number two is the lowdown on RAISE 2.0—your backstage pass to lightning-fast software approvals with the US Navy! In RMF and ATO with RAISE 2.0 — Navy’s DevSecOps solution for Rapid Delivery we break down what RAISE 2.0 means for teams working with the Department of the Navy’s containerized software.  The key takeaway? By using an approved DevSecOps platform—known as an RPOC—you can skip getting separate ATOs for every new app.  The guidelines encourage a “shift left” approach, focusing on early and continuous security checks throughout development. Tools like Anchore Enforce Federal Edition can help automate the required security gates, vulnerability scans, and policy checks, making it easier to keep everything compliant.  In short, RAISE 2.0 is all about streamlining security, speeding up approvals, and helping you deliver secure code faster. 1 | Introduction to the DoD Software Factory Taking our top spot at number one, we’ve got the DoD software factory—the true VIP of the DevSecOps world! We’re talking about a full-blown, high-security software pipeline that cranks out code for the defense sector faster than a fighter jet screaming across the sky. In Introduction to the DoD Software Factory we break down what a DoD software factory really is—think of it as a template to build a DoD-approved DevSecOps pipeline.  The blog post details how concepts like shifting security left, using microservices, and leveraging automation all come together to meet the DoD’s sky-high security standards. Whether you choose an existing DoD software factory (like Platform One) or build your own, the goal is to streamline development without sacrificing security.  Tools like Anchore Enforce Federal Edition can help with everything from SBOM generation to continuous vulnerability scanning, so you can meet compliance requirements and keep your mission-critical apps protected at every stage. Wrap-Up That wraps up the top ten Anchore blog posts of 2024! We covered it all: next-level software supply chain best practices, military-grade compliance tactics, and all the open-source goodies that keep your DevSecOps pipeline firing on all cylinders.  The common thread throughout them all is the recognition that security and speed can work hand-in-hand. With SBOM-driven approaches, modern vulnerability management, and automated compliance checks, organizations can achieve the rapid, secure, and compliant software delivery required in the DevSecOps era. We hope these posts will serve as a guide and inspiration as you continue to refine your DevSecOps practice, embrace new technologies, and steer your organization toward a more secure and efficient future. If you enjoyed our greatest hits album of 2024 but need more immediacy in your life, follow along in 2025 by subscribing to the Anchore Newsletter or following Anchore on your favorite social platform: LinkedIn Bluesky Twitter/X Mastodon Learn about the role that SBOMs for the security of your organization in this white paper. Download Now ### Going All In: Anchore at SBOM Plugfest 2024 When we were invited to participate in Carnegie Mellon University's Software Engineering Institute (SEI) SBOM Harmonization Plugfest 2024, we saw an opportunity to contribute to SBOM generation standardization efforts and thoroughly exercise our open-source SBOM generator, Syft.  While the Plugfest only required two SBOM submissions, we decided to go all in - and learned some valuable lessons along the way. The Plugfest Challenge The SBOM Harmonization Plugfest aims to understand why different tools generate different SBOMs for the same software. It's not a competition but a collaborative study to improve SBOM implementation harmonization. The organizers selected eight diverse software projects, ranging from Node.js applications to C++ libraries, and asked participants to generate SBOMs in standard formats like SPDX and CycloneDX. Going Beyond the Minimum Instead of just submitting two SBOMs, we decided to: SBOM generation for all eight target projects Create both source and binary analysis SBOMs where possible Output in every format Syft supports Test both enriched and non-enriched versions Validate everything thoroughly This comprehensive approach would give us (and the broader community) much more data to work with. Automation: The Key to Scale To handle this expanded scope, we created a suite of scripts to automate the entire process: Target acquisition Source SBOM generation Binary building Binary SBOM generation SBOM validation The entire pipeline runs in about 38 minutes on a well-connected server, generating nearly three hundred SBOMs across different formats and configurations. The Power of Enrichment One of Syft's interesting features is its --enrich option, which can enhance SBOMs with additional metadata from online sources. Here's a real example showing the difference in a CycloneDX SBOM for Dependency-Track: $ wc -l dependency-track/cyclonedx-json.json dependency-track/cyclonedx-json_enriched.json   5494 dependency-track/cyclonedx-json.json   6117 dependency-track/cyclonedx-json_enriched.json The enriched version contains additional information like license URLs and CPE identifiers: {   "license": {     "name": "Apache 2",     "url": "http://www.apache.org/licenses/LICENSE-2.0"   },   "cpe": "cpe:2.3:a:org.sonatype.oss:JUnitParams:1.1.1:*:*:*:*:*:*:*" } These additional identifiers are crucial for security and compliance teams - license URLs help automate legal compliance checks, while CPE identifiers enable consistent vulnerability matching across security tools. SBOM Generation of Binaries While source code analysis is valuable, many Syft users analyze built artifacts and containers. This reflects real-world usage where organizations must understand what's being deployed, not just what's in the source code. We built and analyzed binaries for most target projects: PackageBuild MethodKey FindingsDependency TrackDockerThe container SBOMs included ~1000 more items than source analysis, including base image components like Debian packagesHTTPiepip installBinary analysis caught runtime Python dependencies not visible in sourcejqDockerPython dependencies contributed significant additional packagesMinecoloniesGradleJava runtime java archives appeared in binary analysis, but not in the sourceOpenCVCMakeBinary and source SBOMs were largely the samehexylCargo buildRust static linking meant minimal difference from sourcenodejs-goofDockerNode.js runtime and base image packages significantly increased the component count Some projects, like gin-gonic (a library) and PHPMailer, weren't built as they're not typically used as standalone binaries. The differences between source and binary SBOMs were striking. For example, the Dependency-Track container SBOM revealed: Base image operating system packages Runtime dependencies not visible in source analysis Additional layers of dependencies from the build process System libraries and tools included in the container This perfectly illustrates why both source and binary analysis are important: Source SBOMs show some direct development dependencies Binary/container SBOMs show the complete runtime environment Together, they provide a full picture of the software supply chain Organizations can leverage these differences in their CI/CD pipelines - using source SBOMs for early development security checks and binary/container SBOMs for final deployment validation and runtime security monitoring. Unexpected Discovery: SBOM Generation Bug One of the most valuable outcomes wasn't planned at all. During our comprehensive testing, we discovered a bug in Syft's SPDX document generation. The SPDX validators were flagging our documents as invalid due to absolute file paths: file name must not be an absolute path starting with "/", but is: /.github/actions/bootstrap/action.yaml file name must not be an absolute path starting with "/", but is: /.github/workflows/benchmark-testing.yaml file name must not be an absolute path starting with "/", but is: /.github/workflows/dependabot-automation.yaml file name must not be an absolute path starting with "/", but is: /.github/workflows/oss-project-board-add.yaml The SPDX specification requires relative file paths in the SBOM, but Syft used absolute paths. Our team quickly developed a fix, which involved converting absolute paths to relative ones in the format model logic: // spdx requires that the file name field is a relative filename // with the root of the package archive or directory func convertAbsoluteToRelative(absPath string) (string, error) {     // Ensure the absolute path is absolute (although it should already be)     if !path.IsAbs(absPath) {         // already relative         log.Debugf("%s is already relative", absPath)         return absPath, nil     }     // we use "/" here given that we're converting absolute paths from root to relative     relPath, found := strings.CutPrefix(absPath, "/")     if !found {         return "", fmt.Errorf("error calculating relative path: %s", absPath)     }     return relPath, nil } The fix was simple but effective - stripping the leading "/" from absolute paths while maintaining proper error handling and logging. This change was incorporated into Syft v1.18.0, which we used for our final Plugfest submissions. This discovery highlights the value of comprehensive testing and community engagement. What started as a participation in the Plugfest ended up improving Syft for all users, ensuring more standard-compliant SPDX documents. It's a perfect example of how collaborative efforts like the Plugfest can benefit the entire SBOM ecosystem. SBOM Validation We used multiple validation tools to verify our SBOMs: CycloneDX's sbom-utility SPDX's pyspdxtools NTIA's online validator Interestingly, we found some disparities between validators. For example, some enriched SBOMs that passed sbom-utility validation failed with pyspdxtools. Further, the NTA online validator gave us another different result in many cases. This highlights the ongoing challenges in SBOM standardization - even the tools that check SBOM validity don't always agree! Key Takeaways Automation is crucial: Our scripted approach allowed us to efficiently generate and validate hundreds of SBOMs. Real-world testing matters: Building and analyzing binaries revealed insights (and bugs!) that source-only analysis might have missed. Enrichment adds value: Additional metadata can significantly enhance SBOM utility, though support varies by ecosystem. Validation is complex: Different validators can give different results, showing the need for further standardization. Looking Forward The SBOM Harmonization Plugfest results will be analyzed in early 2025, and we're eager to see how different tools handled the same targets. Our comprehensive submission will help identify areas where SBOM generation can be improved and standardized. More importantly, this exercise has already improved Syft for our users through the bug fix and given us valuable insights for future development. We're committed to continuing this thorough testing and community participation to make SBOM generation more reliable and consistent for everyone. The final SBOMs are published in the plugfest-sboms repo, with the scripts in the plugfest-scripts repository. Consider using Syft for SBOM generation against your code and containers, and let us know how you get on in our community discourse. ### Understanding SBOMs: Deep Dive with Kate Stewart ### Understanding SBOMs: How to Automate, Generate and Manage SBOMs ### Automating SBOMs: From Creation to Scanning & Analysis This blog post has been archived and replaced by the supporting pillar page that can be found here: https://anchore.com/wp-admin/post.php?post=987474667&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. ### ModuleQ reduces vulnerability management time by 80% with Anchore Secure ModuleQ, an AI-driven enterprise knowledge platform, knows only too well the stakes for a company providing software solutions in the highly regulated financial services sector. In this world where data breaches are cause for termination of a vendor relationship and evolving cyberthreats loom large, proactive vulnerability management is not just a best practice—it’s a necessity.  ModuleQ required a vulnerability management platform that could automatically identify and remediate vulnerabilities, maintain airtight security, and meet stringent compliance requirements—all without slowing down their development velocity. Learn the essential container security best practices to reduce the risk of software supply chain attacks in this white paper. Download Now The Challenge: Scaling Security in a High-Stakes Environment ModuleQ found itself drowning in a flood of newly released vulnerabilities—over 25,000 in 2023 alone. Operating in a heavily regulated industry meant any oversight could have severe repercussions. High-profile incidents like the Log4j exploit underscored the importance of supply chain security, yet the manual, resource-intensive nature of ModuleQ’s vulnerability management process made it hard to keep pace. The mandate that no critical vulnerabilities reached production was a particularly high bar to meet with the existing manual review process. Each time engineers stepped away from their coding environment to check a separate security dashboard, they lost context, productivity, and confidence. The fear of accidentally letting something slip through the cracks was ever present. The Solution: Anchore Secure for Automated, Integrated Vulnerability Management ModuleQ chose Anchore Secure to simplify, automate, and fully integrate vulnerability management into their existing DevSecOps workflows. Instead of relying on manual security reviews, Anchore Secure injected security measures seamlessly into ModuleQ’s Azure DevOps pipelines, .NET, and C# environment. Every software build—staged nightly through a multi-step pipeline—was automatically scanned for vulnerabilities. Any critical issues triggered immediate notifications and halted promotions to production, ensuring that potential risks were addressed before they could ever reach customers. Equally important, Anchore’s platform was built to operate in on-prem or air-gapped environments. This guaranteed that ModuleQ’s clients could maintain the highest security standards without the need for external connectivity. For an organization whose customers demand this level of diligence, Anchore’s design provided peace of mind and strengthened client relationships. Results: Faster, More Secure Deployments By adopting Anchore Secure, ModuleQ dramatically accelerated and enhanced its vulnerability management approach: 80% Reduction in Vulnerability Management Time: Automated scanning, triage, and reporting freed the team from manual checks, letting them focus on building new features rather than chasing down low-priority issues. 50% Less Time on Security Tasks During Deployments: Proactive detection of high-severity vulnerabilities streamlined deployment workflows, enabling ModuleQ to deliver software faster—without compromising security. Unwavering Confidence in Compliance: With every new release automatically vetted for critical vulnerabilities, ModuleQ’s customers in the financial sector gained renewed trust. Anchore’s support for fully on-prem deployments allowed ModuleQ to meet stringent security demands consistently. Looking Ahead In an era defined by unrelenting cybersecurity threats, ModuleQ proved that speed and security need not be at odds. Anchore Secure provided a turnkey solution that integrated seamlessly into their workflow, saving time, strengthening compliance, and maintaining the agility to adapt to future challenges. By adopting an automated security backbone, ModuleQ has positioned itself as a trusted and reliable partner in the financial services landscape. Looking for more details? Read the ModuleQ case study in full. If you're ready to move forward see all of the features on Anchore Secure's product page or reach out to our team to schedule a demo. Save your developers time with Anchore Enterprise. Get instant access with a 15-day free trial. START FREE TRIAL ### Understanding SBOMs: An Introduction to Modern Development ### Enhancing Container Security with NVIDIA’s AI Blueprint and Anchore's Syft Container security is critical - one breach can lead to devastating data losses and business disruption. NVIDIA's new AI Blueprint for Vulnerability Analysis transforms how organizations handle these risks by automating vulnerability detection and analysis. For enhanced container security, this AI-powered solution is a potential game-changer. At its core, the Blueprint combines AI-driven scanning with NVIDIA's Morpheus Cybersecurity SDK to identify vulnerabilities in seconds rather than hours or days for enhanced container security. The system works through a straightforward process: First, it generates a Software Bill of Materials (SBOM) using Syft, Anchore's open-source tool. This tool creates a detailed inventory of all software components in a container. This SBOM feeds into an AI pipeline that leverages large language models (LLMs) and retrieval-augmented generation (RAG) to analyze potential vulnerabilities for enhanced container security. The AI examines multiple data sources - from code repositories to vulnerability databases - and produces a detailed analysis of each potential threat. Most importantly, it distinguishes between genuine security risks and false positives by considering environmental factors and dependency requirements. The system then provides clear recommendations through a standardized Vulnerability Exploitability eXchange (VEX) status, as illustrated below. Container security is further enhanced by these clear recommendations. This Blueprint is particularly valuable because it automates traditional manual security analysis. Security teams can stop spending days investigating potential vulnerabilities and focus on addressing confirmed threats. This efficiency is invaluable for organizations managing container security at scale with enhanced container security solutions. Want to try it yourself? Check out the Blueprint, read more in the NVIDIA blog post, and explore the vulnerability-analysis git repo. Let us know if you've tried this out with Syft, over on the Anchore Community Discourse. ### Survey Data Shows 200% Increase in Software Supply Chain Focus Data found in the recent Anchore 2024 Software Supply Chain Security Report shows that there has been a 200% increase in the priority of software supply chain security. As attacks continue to increase, organizations are doubling their focus in this area. There is much to understand across the industry with the nuances and intensity of software supply chain attacks across the past twelve months. Below we've compiled a graphical representation of the insights gathered in the Anchore 2024 Software Supply Chain Security Report, to provide a visual approach to the unique insights, experiences, and practices of over 100 organizations that are the targets of software supply chain attacks. Download Full Report ### Your Guide to Cybersecurity Compliance, from Federal Policy to Industry Standards This blog post has been archived and replaced by the supporting pillar page that can be found here: https://anchore.com/wp-admin/post.php?post=987472563&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. ### The Evolution of SBOMs in the DevSecOps Lifecycle: Part 2 Welcome back to the second installment of our two-part series on "The Evolution of SBOMs in the DevSecOps Lifecycle". In our first post, we explored how Software Bills of Materials (SBOMs) evolve over the first 4 stages of the DevSecOps pipeline—Plan, Source, Build & Test—and how each type of SBOM serves different purposes. Some of those use-cases include: shift left vulnerability detection, regulatory compliance automation, OSS license risk management and incident root cause analysis. In this part, we'll continue our exploration with the final 4 stages of the DevSecOps lifecycle, examining: Analyzed SBOMs at the Release (Registry) stage Deployed SBOMs during the Deployment phase Runtime SBOMs in Production (Operate & Monitor stages) As applications migrate down the pipeline, design decisions made at the beginning begin to ossify becoming more difficult to change; this influences the challenges that are experienced and the role that SBOMs play in overcoming these novel problems. Some of the new challenges that come up include: pipeline leaks, vulnerabilities in third-party packages, and runtime injection. All of which introduce significant risk. Understanding how SBOMs evolve across these stages helps organizations mitigate these risks effectively. Whether you're aiming to enhance your security posture, streamline compliance reporting, or improve incident response times, this comprehensive guide will equip you with the knowledge to leverage SBOMs effectively from Release to Production. Additionally, we'll offer pro tips to help you maximize the benefits of SBOMs in your DevSecOps practices. So, let's continue our journey through the DevSecOps pipeline and discover how SBOMs can transform the latter stages of your software development lifecycle. Learn the 5 best practices for container security and how SBOMs play a pivotal role in securing your software supply chain. Download Now Release (or Registry) => Analyzed SBOM After development is completed and the new release of the software is declared a "golden" image the build system will push the release artifact to a registry for storage until it is deployed. At this stage, an SBOM that is generated based on these container images, binaries, etc. is named an "Analyzed SBOM" by CISA. The name is a little confusing since all SBOMs should be analyzed regardless of the stage they are generated. A more appropriate name might be a Release SBOM but we'll stick with CISA's name for now. At first glance, it would seem that Analyzed SBOMs and the final Build SBOMs should be identical since it is the same software but that doesn't hold up in practice. DevSecOps pipelines aren't hermetically sealed systems, they can be "leaky". You might be surprised what finds its way into this storage repository and eventually gets deployed bypassing your carefully constructed build and test setup. On top of that, the registry holds more than just first-party applications that are built in-house. It also stores 3rd-party container images like operating systems and any other self-contained applications used by the organization. The additional metadata that is collected for an Analyzed SBOM includes: Release images that bypass the happy path build and test pipeline 3rd-party container images, binaries and applications Pros and Cons Pros: Comprehensive Artifact Inventory: A more holistic view of all software—both 1st- and 3rd-party—that is utilized in production. Enhanced Security and Compliance Posture: Catches vulnerabilities and non-compliant images for all software that will be deployed to production. This reduces the risk of security incidents and compliance violations. Third-Party Supply Chain Risk Management: Provides insights into the vulnerabilities and compliance status of third-party components. Ease of implementation: This stage is typically the lowest lift for implementation given that most SBOM generators can be deployed standalone and pointed at the registry to scan all images. Cons: High Risk for Release Delays: Scanning images at this stage are akin to traditional waterfall-style development patterns. Most design decisions are baked-in and changes typically incur a steep penalty. Difficult to Push Feedback into Exist Workflow: The registry sits outside of typical developer workflows and creating a feedback loop that seamlessly reports issues without changing the developer's process is a non-trivial amount of work. Complexity in Management: Managing SBOMs for both internally developed and third-party components adds complexity to the software supply chain. Use-Cases Software Supply Chain Security: Organizations can detect vulnerabilities in both their internal developed software and external software to prevent supply chain injections from leading to a security incident. Compliance Reporting: Reporting on both 1st- and 3rd-party software is necessary for industries with strict regulatory requirements. Detection of Leaky Pipelines: Identifies release images that have bypassed the standard build and test pipeline, allowing teams to take corrective action. Third-Party Risk Analysis: Assesses the security and compliance of third-party container images, binaries, and applications before they are deployed. Example: An organization subject to strict compliance standards like FedRAMP or cATO uses Analyzed SBOMs to verify that all artifacts in their registry, including third-party applications, comply with security policies and licensing requirements. This practice not only enhances their security posture but also streamlines the audit process. Pro Tip A registry is an easy and non-invasive way to test and evaluate potential SBOM generators. It won't give you a full picture of what can be found in your DevSecOps pipeline but it will at least give you an initial idea of its efficacy and help you make the decision on whether to go through the effort of integrating it into your build pipeline where it will produce deeper insights. Deploy => Deployed SBOM As your container orchestrator is deploying an image from your registry into production it will also orchestrate any production dependencies such as sidecar containers or production dependencies. At this stage, an SBOM that is generated is named an "Deployed SBOM" by CISA. The ideal scenario is that your operations team is storing all of these images in the same central registry as your engineering team but—as we've noted before—reality diverges from the ideal. The additional metadata that is collected for a Deployed SBOM includes: Any additional sidecar containers or production dependencies that are injected or modified through a release controller. Pros and Cons Pros: Enhanced Security Posture: The final gate to prevent vulnerabilities from being deployed into production. This reduces the risk of security incidents and compliance violations. Leaky Pipeline Detection: Another location to increase visibility into the happy path of the DevSecOps pipeline being circumvented. Compliance Enforcement: Some compliance standards require a deployment breaking enforcement gate before any software is deployed to production. A container orchestrator release controller is the ideal location to implement this. Cons: Essentially the same issues that come up during the release phase. High Risk for Release Delays: Scanning images at this stage are even later than traditional waterfall-style development patterns and will incur a steep penalty if an issue is uncovered. Difficult to Push Feedback into Exist Workflow: A deployment release controller sits outside of typical developer workflows and creating a feedback loop that seamlessly reports issues without changing the developer's process is a non-trivial amount of work. Use-Cases Strict Software Supply Chain Security: Implementing a pipeline breaking gating mechanism is typically reserved for only the most critical security vulnerabilities (think: an actively exploitable known vulnerability). High-Stakes Compliance Enforcement: Industries like defense, financial services and critical infrastructure will require vendors to implement a deployment gate for specific risk scenarios beyond actively exploitable vulnerabilities. Compliance Audit Automation: Most regulatory compliance frameworks mandate audit artifacts at deploy time, these documents can be automatically generated and stored for future audits. Example: A Deployed SBOM can be used as the source of truth for generating a report that demonstrates that no HIGH or CRITICAL vulnerabilities were deployed to production during an audit period. Pro Tip Combine a Deployed SBOM with a container vulnerability scanner that cross-checks all vulnerabilities against CISA's Known Exploitable Vulnerability (KEV) database. In the scenario where a matching KEV is found for a software component you can configure your vulnerability scanner to return a FAIL response to your release controller to abort the deployment. This strategy creates an ideal balance between not adding delays to software delivery and an extremely high probability for a security incident.  Operate & Monitor (or Production) => Runtime SBOM After your container orchestrator has deployed an application into your production environment it is live and serving customer traffic. An SBOM that is generated at this stage don't have a name as specified by CISA. They are sometimes referred to as "Runtime SBOMs". SBOMs are still a new-ish standard and will continue to evolve.  The additional metadata that is collected for a Runtime SBOM includes: Modifications (i.e., intentional hotfixes or malicious malware injection) made to running applications in your production environment.  Pros and Cons Pros: Continuous Security Monitoring: Identifies new vulnerabilities that emerge after deployment. Active Runtime Inventory: Provides a canonical view into an organization's active software landscape. Low Lift Implementation: Deploying SBOM generation into a production environment typically only requires deploying the scanner as another container and giving it permission to access the rest of the production environment. Cons: No Shift Left Security: By definition is excluded as a part of a shift left security posture. Potential for Release Rollbacks: Scanning images at this stage is the worst possible place for proactive remediation. Discovering a vulnerability could potentially cause a security incident and force a release rollback. Use-Cases Rapid Incident Management: When new critical vulnerabilities are discovered and announced by the community the first priority for an organization is to determine exposure. An accurate production inventory, down to the component-level, is needed to answer this critical question. Threat Detection: Continuously monitoring for anomalous activity linked to specific components. Sealing your system off completely from advanced persistent threats (APTs) is an unfeasible goal. Instead, quick detection and rapid intervention is the scalable solution to limit the impact of these adversaries. Patch Management: As new releases of 3rd-party components and applications are released an inventory of impacted production assets provides helpful insights that can direct the prioritization of engineering efforts. Example: When the XZ Utils vulnerability was announced in the spring of 2024, organizations that already automatically generated a Runtime SBOM inventory ran a simple search query against their SBOM database and knew within minutes—or even seconds—whether they were impacted. Pro Tip If you want to learn about how Google was able to go from an all-hands on deck security incident when the XZ Utils vulnerability was announced to an all clear under 10 minutes, watch our webinar with the lead of Google's SBOM initiative. Watch Now Wrap-Up As the SBOM standard has evolved the subject has grown considerably. What started as a structured way to store information about open source licenses has expanded to include numerous use-cases. A clear understanding of the evolution of SBOMs throughout the DevSecOps lifecycle is essential for organizations aiming to solve problems ranging from software supply chain security to regulatory compliance to legal risk management. SBOMs are a powerful tool in the arsenal of modern software development. By recognizing their importance and integrating them thoughtfully across the DevSecOps lifecycle, you position your organization at the forefront of secure, efficient, and compliant software delivery. Ready to secure your software supply chain and automate compliance tasks with SBOMs? Anchore is here to help. We offer SBOM management, vulnerability scanning and compliance automation enforcement solutions. If you still need some more information before looking at solutions, check out our webinar below on scaling a secure software supply chain with Kubernetes. 👇👇👇 Learn how Spectro Cloud secured their Kubernetes-based software supply chain and the pivotal role SBOMs played. Watch Now ### The Evolution of SBOMs in the DevSecOps Lifecycle: From Planning to Production The software industry has wholeheartedly adopted the practice of building new software on the shoulders of the giants that came before them. To accomplish this developers construct a foundation of pre-built, 3rd-party components together then wrap custom 1st-party code around this structure to create novel applications. It is an extraordinarily innovative and productive practice but it also introduces challenges ranging from security vulnerabilities to compliance headaches to legal risk nightmares. Software bills of materials (SBOMs) have emerged to provide solutions for these wide ranging problems. An SBOM provides a detailed inventory of all the components that make up an application at a point in time. However, it's important to recognize that not all SBOMs are the same—even for the same piece of software! SBOMs evolve throughout the DevSecOps lifecycle; just as an application evolves from source code to a container image to a running application. The Cybersecurity and Infrastructure Security Agency's (CISA) has codified this idea by differentiating between all of the different types of SBOMs. Each type serves different purposes and captures information about an application through its evolutionary process. In this 2-part blog series, we'll deep dive into each stage of the DevSecOps process and the associated SBOM. Highlighting the differences, the benefits and disadvantages and the use-cases that each type of SBOM supports. Whether you're just beginning your SBOM journey or looking to deepen your understanding of how SBOMs can be integrated into your DevSecOps practices, this comprehensive guide will provide valuable insights and advice from industry experts. Learn about the role that SBOMs for the security of your organization in this white paper. Download Now Types of SBOMs and the DevSecOps Pipeline Over the past decade the US government got serious about software supply chain security and began advocating for SBOMs as the standardized approach to the problem. As part of this initiative CISA created the Types of Software Bill of Material (SBOM) Documents white paper that codified the definitions of the different types of SBOMs and mapped them to each stage of the DevSecOps lifecycle. We will discuss each in turn but before we do, let's anchor on some terminology to prevent confusion or misunderstanding. Below is a diagram that lays out each stage of the DevSecOps lifecycle as well as the naming convention we will use going forward. With that out of the way, let's get started! Plan => Design SBOM As the DevSecOps paradigm has spread across the software industry, a notable best practice known as the security architecture review has become integral to the development process. This practice embodies the DevSecOps goal of integrating security into every phase of the software lifecycle, aligning perfectly with the concept of Shift-Left Security—addressing security considerations as early as possible. At this stage, the SBOM documents the planned components of the application. The CISA refers to SBOMs generated during this phase as Design SBOMs. These SBOMs are preliminary and outline the intended components and dependencies before any code is written. The metadata that is collected for a Design SBOM includes: Component Inventory: Identifying potential OSS libraries and frameworks to be used as well as the dependency relationship between the components. Licensing Information: Understanding the licenses associated with selected components to ensure compliance. Risk Assessment Data: Evaluating known vulnerabilities and security risks associated with each component. This might sound like a lot of extra work but luckily if you're already performing DevSecOps-style planning that incorporates a security and legal review—as is best practice—you're already surfacing all of this information. The only thing that is different is that this preliminary data is formatted and stored in a standardized data structure, namely an SBOM. Pros and Cons Pros: Maximal Shift-Left Security: Vulnerabilities cannot be found any earlier in the software development process. Design time security decisions are the peak of a proactive security posture and preempt bad design decisions before they become ingrained into the codebase. Cost Efficiency: Resolving security issues at this stage is generally less expensive and less disruptive than during later stages of development or—worst of all—after deployment. Legal and Compliance Risk Mitigation: Ensures that all selected components meet necessary compliance standards, avoiding legal complications down the line. Cons: Upfront Investment: Gathering detailed information on potential components and maintaining an SBOM at this stage requires a non-trivial commitment of time and effort. Incomplete Information: Projects are not static, they will adapt as unplanned challenges surface. A design SBOM likely won't stay relevant for long. Use-Cases There are a number of use-cases that are enabled by  Security Policy Enforcement: Automatically checking proposed components against organizational security policies to prevent the inclusion of disallowed libraries or frameworks. License Compliance Verification: Ensuring that all components comply with the project's licensing requirements, avoiding potential legal issues. Vendor and Third-Party Risk Management: Assessing the security posture of third-party components before they are integrated into the application. Enhance Transparency and Collaboration: A well-documented SBOM provides a clear record of the software's components but more importantly that the project aligns with the goals of all of the stakeholders (engineering, security, legal, etc). This builds trust and creates a collaborative environment that increases the chances of each individual stakeholder outcome will be achieved. Example: A financial services company operating within a strict regulatory environment uses SBOMs during planning to ensure that all components comply with compliance standards like PCI DSS. By doing so, they prevent the incorporation of insecure components that won't meet PCI compliance. This reduces the risk of the financial penalties associated with security breaches and regulatory non-compliance. Pro Tip If your organization is still early in the maturity of its SBOM initiative then we generally recommend moving the integration of design time SBOMs to the back of the queue. As we mention at the beginning of this the information stored in a design SBOMs is naturally surfaced during the DevSecOps process, as long as the information is being recorded and stored much of the value of a design SBOM will be captured in the artifact. This level of SBOM integration is best saved for later maturity stages when your organization is ready to begin exploring deeper levels of insights that have a higher risk-to-reward ratio.  Alternatively, if your organization is having difficulty getting your teams to adopt a collaborative DevSecOps planning process mandating a SBOM as a requirement can act as a forcing function to catalyze a cultural shift. Source => Source SBOM During the development stage, engineers implement the selected 3rd-party components into the codebase. CISA refers to SBOMs generated during this phase as Source SBOMs. The SBOMs generated here capture the actual implemented components and additional information that is specific to the developer who is doing the work. The additional metadata that is collected for a Source SBOM includes: Dependency Mapping: Documenting direct and transitive dependencies. Identity Metadata: Adding contributor and commit information. Developer Environment: Captures information about the development environment. Unlike Design SBOMs which are typically done manually, these SBOMs can be generated programmatically with a software composition analysis (SCA) tool—like Syft. They are usually packaged as command line interfaces (CLIs) since this is the preferred interface for developers.  If you're looking for an SBOM generation tool (SCA embedded), we have a comprehensive list of options to make this decision easier. Pros and Cons Pros: Accurate and Timely Component Inventory: Reflects the actual components used in the codebase and tracks changes as codebase is actively being developed. Shift-Left Vulnerability Detection: Identifies vulnerabilities as components are integrated but requires commit level automation and feedback mechanisms to be effective. Facilitates Collaboration and Visibility: Keeps all stakeholders members informed about divergence from the original plan and provokes conversations as needed. This is also dependent on automation to record changes during development and the notification systems to broadcast the updates. Example: A developer adds a new logging library to the project like an outdated version of Log4j. The SBOM, paired with a vulnerability scanner, immediately flags the Log4Shell vulnerability, prompting the engineer to update to a patched version. Cons: Noise from Developer Toolchains: A lot of times developer environments are bespoke. This creates noise for security teams by recording development dependencies. Potential Overhead: Continuous updates to the SBOM can be resource-intensive when done manually; the only resource efficient method is by using an SBOM generation tool that automates the process. Possibility of Missing Early Risks: Issues not identified during planning may surface here, requiring code changes. Use-Cases Faster Root Cause Analysis: During service incident retrospectives questions about where, when and by whom a specific component was introduced into an application. Source SBOMs are the programmatic record that can provide answers and decrease manual root cause analysis. Real-Time Security Alerts: Immediate notification of vulnerabilities upon adding new components, decreasing time to remediation and keeping security teams informed. Automated Compliance Checks: Ensuring added components comply with security or license policies to manage compliance risk. Effortless Collaboration: Stakeholders can subscribe to a live feed of changes and immediately know when implementation diverges from the plan. Pro Tip Some SBOM generators allow developers to specify development dependencies that should be ignored, similar to .gitignore file. This can help cut down on the noise created by unique developer setups. Build & Test => Build SBOM When a developer pushes a commit to the CI/CD build system an automated process initiates that converts the application source code into an artifact that can then be deployed. CISA refers to SBOMs generated during this phase as Build SBOMs. These SBOMs capture both source code dependencies and build tooling dependencies. The additional metadata that is collected includes: Build Dependencies: Build tooling such as the language compilers, testing frameworks, package managers, etc. Binary Analysis Data: Metadata for compiled binaries that don't utilize traditional container formats. Configuration Parameters: Details on build configuration files that might impact security or compliance. Pros and Cons Pros: Build Infrastructure Analysis: Captures build-specific components which may have their own vulnerability or compliance issues. Reuses Existing Automation Tooling: Enables programmatic security and compliance scanning as well as policy enforcement without introducing any additional build tooling. Reuses Existing Automation Tooling: Directly integrates with developer workflow. Engineers receive security, compliance, etc. feedback without the need to reference a new tool. Reproducibility: Facilitates reproducing builds for debugging and auditing. Cons: SBOM Sprawl: Build processes run frequently, if it is generating an SBOM with each run you will find yourself with a glut of files that you will have to manage. Delayed Detection: Vulnerabilities or non-compliance issues found at this stage may require rework. Use-Cases SBOM Drift Detection: By comparing SBOMs from two or more stages, unexpected dependency injection can be detected. This might take the form of a benign, leaky build pipeline that requires manual workarounds or a malicious actor attempting to covertly introduce malware. Either way this provides actionable and valuable information. Policy Enforcement: Enables the creation of build breaking gates to enforce security or compliance. For high-stakes operating environments like defense, financial services or critical infrastructure, automating security and compliance at the expense of some developer friction is a net-positive strategy. Automated Compliance Artifacts: Compliance requires proof in the form of reports and artifacts. Re-utilizing existing build tooling automation to automate this task significantly reduces the manual work required by security teams to meet compliance requirements. Example: A security scan during testing uses the Build SBOM to identify a critical vulnerability and alerts the responsible engineer. The remediation process is initiated and a patch is applied before deployment. Pro Tip If your organization is just beginning their SBOM journey, this is the recommended phase of the DevSecOps lifecycle to implement SBOMs first. The two primary cons of this phase can be mitigated the easiest. For SBOM sprawl, you can procure a turnkey SBOM management solution like Anchore SBOM.  As for the delay in feedback created by waiting till the build phase, if your team is utilizing DevOps best practices and breaking features up into smaller components that fit into 2-week sprints then this tight scoping will limit the impact of any significant vulnerabilities or non-compliance discovered. Intermission So far we've covered the first half of the DevSecOps lifecycle. Next week we will publish the second part of this blog series where we'll cover the remainder of the pipeline. Watch our socials to be sure you get notified when part 2 is published. If you're looking for some additional reading in the meantime, check out our container security white paper below. Learn the 5 best practices for container security and how SBOMs play a pivotal role in securing your software supply chain. Download Now ### Anchore on AWS Marketplace and joins ISV Accelerate We are excited to announce two significant milestones in our partnership with Amazon Web Services (AWS) today:   Anchore Enterprise can now be purchased through the AWS marketplace and  Anchore has joined the APN's (Amazon Partner Network) ISV Accelerate Program Organizations like Nvidia, Cisco Umbrella and Infoblox validate our commitment to delivering trusted solutions for SBOM management, secure software supply chains, and automated compliance enforcement  and can now benefit from a stronger partnership between AWS and Anchore. Anchore’s best-in-breed container security solution was chosen by Cisco Umbrella as it seamlessly integrated in their AWS infrastructure and accelerated meeting all six FedRAMP requirements. They deployed Anchore into an environment that had to meet a number of high-security and compliance standards. Chief among those was STIG compliance for Amazon EC2 nodes that backed the Amazon EKS deployment.  In addition, Anchore Enterprise supports high-security requirements such as IL4/IL6, FIPS, SSDF attestation and EO 14208 compliance.  Contact Anchore's sales team today for a pricing quote or demo that suits your unique needs. Anchore Enterprise is now available on AWS Marketplace The AWS Marketplace offers a convenient and efficient way for AWS customers to procure Anchore. It simplifies the procurement process, provides greater control and governance, and fosters innovation by offering a rich selection of tools and services that seamlessly integrate with their existing AWS infrastructure.  Anchore Enterprise on AWS Marketplace benefits DevSecOps teams by enabling: Self-procurement via the AWS console Faster procurement with applicable legal terms provided and standardized security review Easier budget management with a single consolidated AWS bill for all infrastructure spend Spend on Anchore Enterprise partially counts towards EDP (Enterprise Discount Program) committed spend By strengthening our collaboration with AWS, customers can now feel at ease that Anchore Enterprise integrates and operates seamlessly on AWS infrastructure. Joining the ISV Accelerate Program allows us to work closely with AWS account teams to ensure seamless support and exceptional service for our joint clients.  Purchase Anchore Enterprise on the AWS Marketplace or contact our sales team for a pricing quote that meets your organization's needs. ### 2024 Trends in Software Supply Chain Security ### Anchore Survey 2024: Only 1 in 5 organizations have full visibility of open source The Anchore 2024 Software Supply Chain Security Report is now available. This report provides a unique set of insights into the experiences and practices of over 100 organizations that are the targets of software supply chain attacks. Survey Highlights The survey shows that amid growing software supply chain risks: The intensity of software supply chain attacks is increasing. 200% increase in the priority of software supply chain security. Only 1 in 5 have full visibility of open source. Third-party software joins open source as a top security challenge. Organizations must comply with an average of 4.9 standards.  78% plan to increase SBOM usage. Respondents worry about AI's impact on software supply chain security. Download Full Report The intensity of software supply chain attacks is increasing. The survey shows that the intensity of software supply chain attacks is increasing, with 21% of successful supply chain attacks having a significant impact, more than doubling from 10% in 2022.  200% increase in the priority of software supply chain security. As a result of increased attacks, organizations are increasing their focus on software supply chain security, with a 200% increase in organizations making it a top priority.  Only 1 in 5 have full visibility of open source. Amid growing software supply chain risks, only 21% of respondents are very confident that they have complete visibility into all the dependencies of the applications their organization builds. Without this critical foundation, organizations are unaware of vulnerabilities that leave them open to supply chain attacks. Third-party software joins open source as a top security challenge. Organizations are looking to secure all elements of their software supply chain, including open source software and 3rd party libraries. While the security of open source software continues to be identified as a significant challenge, in this year’s report, 46% of respondents chose the security of 3rd party software as a significant challenge. Organizations must comply with an average of 4.9 different standards. Compliance is a significant driver in supply chain security. As software supply chain risks grow, governments and industry groups are responding with new guidelines and regulations. Respondents reported the need to comply with an average of almost five separate standards per organization.  Many must comply with new regulatory requirements including the CISA Directive of Known Exploited Vulnerabilities, the Secure Software Development Framework (SSDF), and the EU Cyber Resilience Act. 78% plan to increase SBOM usage. The software bill-of-materials (SBOM) is now a critical component of software supply chain security. An SBOM provides visibility into software ingredients and is a foundation for understanding software vulnerabilities and risks. While just under half of respondents currently leverage SBOMs, a large majority plan to increase SBOM use over the next 18 months. Respondents worry about AI's impact on software supply chain security. A large majority of respondents are concerned about AI's impact on software supply chain security, and as many as a third are very concerned. The highest concerns are with code tested with AI and code generated with AI or with Copilot tools.  Let’s design an action plan Join on December 10, 2024 for a live discussion with VP of Security Josh Bressers on the latest trends. Hear practical steps for building a more resilient software supply chain. Register Now. To minimize risk, avoid reputational damage, and protect downstream users and customers, software supply chain security must become a new practice for every organization that uses or builds software. SBOMs are a critical foundation of this new practice, providing visibility into the dependencies and risks of the software you use.   Here are seven steps to take your software supply chain security to the next level: Assess your software supply chain maturity against best practices.  Identify key challenges and create a plan to make tangible improvements over the coming months. Develop a methodology to document and assess the impact of supply chain attacks on your organization, along with improvements to be made. Create a plan to generate, manage, and share SBOMs as a key pillar of your supply chain security initiative. Learn more with the Expert Guide on SBOMs in Cybersecurity and 6 Ways to Prevent SBOM sprawl.  Delve into existing and emerging compliance requirements and create a plan to automate compliance checks. Learn how to meet compliance standards like NIST, SSDF, and FedRAMP. Identify gaps in tooling and create plans to address the gaps.  See how Anchore can help.  Try open source tools like Syft for SBOM generation and Grype for vulnerability scanning as a good way to get started. Create an organizational structure and define responsibilities to address software supply chain security and risk. Download Full Report ### Tonight’s Movie: The Terminal (of your laptop) A picture paints a thousand words, but a GIF shows every typo in motion. But it doesn't have to! GIFs have long been the go-to in technical docs, capturing real-time terminal output and letting readers watch workflows unfold as if sitting beside you. I recently needed to make some terminal GIFs, so I tried three of the best available tools, and here are my findings. Requirements We recently attended All Things Open, where a TV on our stand needed a rolling demo video. I wanted to add a few terminal usage examples for Syft, Grype, and Grant - our Open-Source, best-in-class container security tools. I tried a few tools to generate the GIFs, which I embedded in a set of Google Slides (for ease) and then captured and rendered as a video that played in a loop on a laptop running VLC. To summarise, this was the intended flow: Typing in a terminal → ↳ Recording ↳ GIF ↳ Google Slides ↳ Video Capture ↳ VLC playlist ↳ Success 🎉 We decided to render it as a video to mitigate conference WiFi issues. Nobody wants to walk past your exhibitor stand and see a 404 or "Network Connectivity Problems" on the Jumbotron®️! The goal was for attendees passing our stand to see the command-line utilities in action. It also allowed us to discuss the demos with interested conferencegoers without busting out a laptop and crouching around it. We just pointed to the screen as a terminal appeared and talked through it. Below is an early iteration of what I was aiming for, taken as a frame grab from a video - hence the slight blur. My requirements were for a utility which: Records a terminal running commands Runs on Linux and macOS because I use both Reliably captures output from the commands being run Renders out a high-quality GIF Is preferably open source Is actively maintained The reason for requiring a GIF rather than a traditional video, such as MP4, is to embed the GIF easily in a Google Slides presentation. While I could create an MP4 and then use a video editor to cut together the videos, I wanted something simple and easily reproducible. I may use MP4s in other situations - such as posting to social media - so if a tool can export to that format easily, I consider that a bonus. It is worth noting that Google Slides supports GIFs up to 1000 frames in length. So, if you have a long-running command captured at a high frame rate, this limit is easy to hit. If that is the case, perhaps render an MP4 and use the right tool for the job, a video editor. "High quality" GIF is a subjective term, but I'm after something that looks pleasing (to me), doesn't distract from the tool being demonstrated, and doesn't visibly stutter. Feature Summary I've put the full summary up here near the top of the article to save wear & tear on your mouse wheel or while your magic mouse is upside down, on charge. The details are underneath the conclusion for those interested and equipped with a fully-charged mouse. † asciinema requires an additional tool such as agg to convert the recorded output to a GIF.◊ t-rec supports X11 on Linux, but currently does not support Wayland sessions.* t-rec development appears to have stalled. Conclusion All three tools are widely used and work fine in many cases. Asciinema is often recommended because it's straightforward to install, and almost no configuration is required. The resulting recordings can be published online and rendered on a web page. While t-rec is interesting, as it records the actual terminal window, not just the session text (as asciinema does), it is a touch heavyweight. As such, with a 4fps frame rate, videos made with t-rec look jerky. I selected vhs for a few reasons. It runs easily on macOS and Linux, so I can create GIFs on my work or personal computer with the same tool. vhs is very configurable, supports higher frame rates than other tools, and is scriptable, making it ideal for creating GIFs for documentation in CI pipelines. vhs being scriptable is, I think, the real superpower here. For example, vhs can be part of a documentation site build system. One configuration file can specify a particular font family, size and color scheme to generate a GIF suitable for embedding in documentation. Another almost identical configuration file might use a different font size or color, which is more suitable for a social media post. The same commands will be run, but the color, font family, font size, and even GIF resolution can be different, making for a very flexible and reliable way to create a terminal GIF for any occasion! vhs ships with a broad default theme set that matches typical desktop color schemes, such as the familiar purple-hue terminal on Ubuntu, as seen below. This GIF uses the "BlexMono Nerd Font Mono" font (a modified version of IBM Plex font), part of the nerd-fonts project. If this GIF seems slow, that's intentional. The vhs configuration can "type" at a configurable speed and slow the resulting captured output down (or speed it up). There are also popular Catppuccin themes that are pretty appealing. The following GIF uses the "catppuccin-macchiato" theme with "Iosevka Term" font, which is part of the Iosevka project. I also added a PS1 environment variable to the configuration to simulate a typical console prompt. vhs can also take a still screenshot during the recording, which can be helpful as a thumbnail image, or to capture a particular frame from the middle of the recording. Below is the final frame from the previous GIF. Here is one of the final (non-animated) slides from the video. I tried to put as little as possible on screen simultaneously, just the title, video, and a QR code for more information. It worked well, with someone even asking how the terminal videos were made. This blog is for them. I am very happy with the results from vhs, and will likely continue using it in documentation, and perhaps social posts - if I can get the font to a readable size on mobile devices. Alternatives I'm aware of OBS Studio and other screen (and window) recording tools that could be used to create an initial video, which could be converted into a GIF. Are there other, better ways to do this? Let me know on our community discourse, or leave a comment wherever you read this blog post. Below are the details about each of the three tools I tested. t-rec t-rec is a "Blazingly fast terminal recorder that generates animated gif images for the web written in rust." This was my first choice, as I had played with it before my current task came up. I initially quite liked that t-rec recorded the entire terminal window, so when running on Linux, I could use a familiar desktop theme indicating to the viewer that the command is running on a Linux host. On a macOS host, I could use a native terminal (such as iTerm2) to hint that the command is run on an Apple computer. However, I eventually decided this wasn't that important at all. Especially given that vhs can be used to theme the terminal so it looks close to a particular host OS. Plus, most of the commands I'm recording are platform agnostic, producing the same output no matter what they're running on. t-rec Usage Configure the terminal to be the size you require with the desired font and any other settings before you start t-rec. Run t-rec. $ t-rec --quiet --output grant The terminal will clear, and recording will begin. Type each command as you normally would. Press CTRL+D to end recording. t-rec will then generate the GIF using the specified name. 🎆 Applying effects to 118 frames (might take a bit) 💡 Tip: To add a pause at the end of the gif loop, use e.g. option `-e 3s` 🎉 🚀 Generating grant.gif Time: ~9s alan@Alans-MacBook-Pro  ~  The output GIF will be written in the current directory by stitching together all the bitmap images taken during the recording. Note the recording below contains the entire terminal user interface and the content. t-rec Benefits t-rec records the video by taking actual bitmap screenshots of the entire terminal on every frame. So, if you're keen on having a GIF that includes the terminal UI, including the top bar and other window chrome, then this may be for you. t-rec Limitations t-rec records at 4 frames per second, which may be sufficient but can look jerky with long commands. There is an unmerged draft PR to allow user-configurable recording frame rates, but it hasn't been touched for a couple of years. I found t-rec would frequently just stop adding frames to a GIF. So the resulting GIF would start okay, then randomly miss out most of the frames, abruptly end, and loop back to the start. I didn't have time to debug why this happened, which got me looking for a different tool. asciinema "Did you try asciinema?" was a common question asked of me, when I mentioned to fellow nerds what I was trying to achieve. Yes. asciinema is the venerable Grand-daddy of terminal recording. It's straightforward to install and setup, has a very simple recording and publishing pipeline. Perhaps too simple. When I wandered around the various exhibitor stands at All Things Open last week, it was obvious who spent far too long fiddling with these tools (me), and which vendors recorded a window, or published an asciinema, with some content blurred out. One even had an ugly demo of our favorite child, grype (don't tell syft I said that), in such a video! Horror of horrors! asciinema doesn't create GIFs directly but instead creates "cast" files, JSON formatted text representations of the session, containing both the user-entered text and the program output. A separate utility, agg (asciinema gif generator), converts the "cast" to a GIF. In addition, another tool, asciinema-edit, can be used to edit the cast file post-recording. asciinema Usage Start asciinema rec, and optionally specify a target file to save as. asciinema rec ./grype.cast Run commands. Type exit when finished. Play back the cast file asciinema play ./grype.cast Convert asciinema recording to GIF. agg --font-family "BlexMono Nerd Font Mono" grype.cast grype.gif Here's the resulting GIF, using the above options. Overall, it looks fine, very much like my terminal appears. Some of the characters are missing or incorrectly displayed, however. For example, the animated braille characters are used while grype is parsing the container image. asciinema - or rather agg (the cast-to-GIF converter) has a few options for customizing the resulting video. There are a small number of themes, the ability to configure the window size (in rows/columns), font family, and size, and set various speed and delay-related options. Overall, asciinema is very capable, fast, and easy to use. The upstream developers are currently porting it from Python to Rust, so I'd consider this an active project. But it wasn't entirely giving me all the options I wanted. It's still a useful utility to keep in your toolbelt. vhs vhs has a novel approach using 'tape' files which describe the recording as a sequence of Type, Enter and Sleep statements. The initial tape file can be created with vhs record and then edited in any standard text editor to modify commands, choice of shell, sleep durations, and other configuration settings. The vhs cassette.tape command will configure the session, then run the commands in a virtual (hidden) terminal. Once the end of the 'tape' is reached, vhs generates the GIF, and optionally, an MP4 video. The tape file can be iterated on to change the theme, font family, size, and other settings, then re-running vhs cassette.tape creates a whole new GIF. vhs Usage Create a .tape file with vis record --shell bash > cassette.tape. Run commands. Type exit when finished. vhs will write the commands and timings to the cassette.tape file, for example: $ cat cassette.tape Sleep 1.5s Type "./grype ubuntu:latest" Enter Sleep 3s Optionally edit the tape file Generate the GIF $ vhs cassette.tape File: ./cassette.tape Sleep 1.5s Type ./grype ubuntu:latest Enter 1 Sleep 3s Creating ... Host your GIF on vhs.charm.sh: vhs publish .gif Below is the resulting default GIF, which looks fantastic out of the box, even before playing with themes, fonts and prompts. vhs Benefits vhs is very configurable, with some useful supported commands in the .tape file. The support for themes, fonts, resolution and 'special' key presses, makes it very flexible for scripting a terminal based application recording. vhs Limitations vhs requires the tape author to specify how long to Sleep after each command - or assume the initial values created with vhs record are correct. vhs does not (yet) auto-advance when a command finishes. This may not be a problem if the command you're recording has a reliable runtime. Still, it might be a problem if the duration of a command is dependent on prevailing conditions such as the network or disk performance. What do you think? Do you like animated terminal output, or would you prefer a video, interactive tool, or just a plain README.md. Let me know on our community discourse, or leave a comment wherever you read this blog post. ### Automate STIG Compliance with MITRE SAF: the Fastest Path to ATO Trying to get your head around STIG (Security Technical Implementation Guides) compliance? Anchore is here to help. With the help of MITRE Security Automation Framework (SAF) we'll walk you through the quickset path to STIG Compliance and ultimately the converted Authority to Operate (ATO). The goal for any company that aims to provide software services to the Department of Defense (DoD) is an ATO. Without this stamp of approval your software will never get into the hands of the warfighters that need it most. STIG compliance is a necessary needle that must be thread on the path to ATO. Luckily, MITRE has developed and open-sourced SAF to smooth the often complex and time-consuming STIG compliance process. We'll get you up to speed on MITRE SAF and how it helps you achieve STIG compliance in this blog post but before we jump straight into the content be sure to bookmark our webinar with the Chief Architect of MITRE Security Automation Framework (SAF), Aaron Lippold. Josh Bressers, VP of Security at Anchore and Lippold provide a behind the scenes look at SAF and how it dramatically reduces the friction of the STIG compliance process. Save a Seat What is the MITRE Security Automation Framework (SAF)? The MITRE SAF is both a high-level cybersecurity framework and an umbrella that encompasses a set of security/compliance tools. It is designed to simplify STIG compliance by translating DISA (Defense Information Systems Agency) SRG (Security Requirements Guide) guidance into actionable steps.  By following the Security Automation Framework, organizations can streamline and automate the hardened configuration of their DevSecOps pipeline to achieve an ATO (Authority to Operate). The SAF offers four primary benefits: Accelerate Path to ATO: By streamlining STIG compliance, SAF enables organizations to get their applications into the hands of DoD operators faster. This acceleration is crucial for meeting operational demands without compromising on security standards. Establish Security Requirements: SAF translates SRGs and STIGs into actionable steps tailored to an organization's specific DevSecOps pipeline. This eliminates ambiguity and ensures security controls are implemented correctly. Build Security In: The framework provides tooling that can be directly embedded into the software development pipeline. By automating STIG configurations and policy checks, it ensures that security measures are consistently applied, leaving no room for false steps. Assess and Monitor Vulnerabilities: SAF offers visualization and analysis tools that assist organizations in making informed decisions about their current vulnerability inventory. It helps chart a path toward achieving STIG compliance and ultimately an ATO. The overarching vision of the MITRE SAF is to "implement evolving security requirements while deploying apps at speed." In essence, it allows organizations to have their cake and eat it too—gaining the benefits of accelerated software delivery without letting cybersecurity risks grow unchecked. How does MITRE SAF work? MITRE SAF is segmented into 5 capabilities that map to specific stages of the DevSecOps pipeline or STIG compliance process: Plan Harden Validate Normalize Visualize Let's break down each of these capabilities. Plan There are hundreds of existing STIGs for products ranging from Microsoft Windows to Cisco Routers to MySQL databases. On the off chance that a product your team wants to use doesn't have a pre-existing STIG, SAF's Vulcan tool is helps translate the application SRG into a tailored STIG that can then be used to achieve compliance. Vulcan helps streamline the process of creating STIG-ready security guidance and the accompanying InSpec automated policy that confirms a specific instance of software is configured in a compliant manner. Vulcan does this by modeling the STIG intent form and tailoring the applicable SRG controls into a finished STIG for an application. The finished STIG is then sent to DISA for peer review and formal publishing as a STIG. Vulcan allows the author to develop both human-readable instructions and machine-readable InSpec automated validation code at the same time. Harden The hardening capability focuses on automating STIG compliance through the use of pre-built infrastructure configuration scripts. SAF hardening content allows organizations to: Use their preferred configuration management tools: Chef Cookbooks, Ansible Playbooks, Terraform Modules, etc. are available as open source templates on MITRE's GitHub page. Share and collaborate: All hardening content is open source, encouraging community involvement and shared learning. Coverage for the full development stack: Ensuring that every layer, from cloud infrastructure to applications, adheres to security standards. Validate The validation capability focuses on verifying the hardening meets the applicable STIG compliance standard. These validation checks are automated via the SAF CLI tool that incorporates the InSpec policies for a STIG. With SAF CLI, organizations can: Automatically validate STIG compliance: By integrating SAF CLI directly into your CI/CD pipeline and invoking InSpec policy checks at every build; shifting security left by surfacing policy violations early. Promote community collaboration: Like the hardening content, validation scripts are open source and accessible by the community for collaborative efforts. Span the entire development stack: Validation—similar to hardening—isn't limited to a single layer; it encompasses cloud infrastructure, platforms, operating systems, databases, web servers, and applications. Incorporate manual attestation: To achieve comprehensive coverage of policy requirements that automated tools might not fully address. Normalize Normalization addresses the challenge of interoperability between different security tools and data formats. SAF CLI performs double-duty by taking on the normalization function as well as validation. It is able to: Translate data into OHDF: OASIS Heimdall Data Format (OHDF), is an open standard that structures countless proprietary security metadata formats into a single universal format. Leverage open source OHDF libraries: Organizations can use OHDF converters as libraries within their custom applications. Automate data conversion: By incorporating SAF CLI into the DevSecOps pipeline, data is automatically standardized with each run. Increased compliance efficiency: A single data format for all security data allows interoperability and facilitates efficient and automated STIG compliance. Example: Below is an example of Burp Suite's proprietary data format normalized to the OHDF JSON format: Visualize Visualization is critical for understanding security posture and making informed decisions. SAF provides an open source, self-hosted visualization tool named Heimdall. It ingests OHDF normalized security data and provides the data analysis tools to enable organizations to: Aggregate security and compliance results: Compiling data into comprehensive rollups, charts, and timelines for a holistic view of security and compliance status. Perform deep dives: Allowing teams to explore detailed vulnerability information to facilitate investigation and remediation, ultimately speeding up time to STIG compliance. Guide risk reduction efforts: Visualization of insights help with prioritization of security and compliance tasks reducing risk in the most efficient manner. How is SAF related to a DoD Software Factory? A DoD Software Factory is the common term for a DevSecOps pipeline that meets the definition laid out in DoD Enterprise DevSecOps Reference Design. All software that ultimately achieves an ATO has to be built on a fully implemented DoD Software Factory. You can either build your own or use a pre-existing DoD Software Factory like the US Air Force's Platform One or the US Navy's Black Pearl. As we saw earlier, MITRE SAF is a framework meant to help you achieve STIG compliance and is a portion of your journey towards an ATO. STIG compliance applies to both the software that you write as well as the DevSecOps platform that your software is built on. Building your own DoD Software Factory means committing to going through the ATO process and STIG compliance for the DevSecOps platform first then a second time for the end-user application. Wrap-Up The MITRE SAF is a huge leg up for modern, cloud-native DevSecOps software vendors that are currently navigating the labyrinth towards ATO. By providing actionable guidance, automation tooling, and a community-driven approach, SAF dramatically reduces the time to ATO. It bridges the gap between the speed of DevOps software delivery and secure, compliant applications ready for critical DoD missions with national security implications.  Embracing SAF means more than just meeting regulatory requirements; it's about building a resilient, efficient, and secure development pipeline that can adapt to evolving security demands. In an era where cybersecurity threats are evolving just as rapidly as software, leveraging frameworks like MITRE SAF is not an efficient path to compliance—it's essential for sustained success. Download Now ### Grype Support for Azure Linux 3 released On September 26, 2024 the OSS team at Anchore released general support for Azure Linux 3, Microsoft’s new cloud-focused Linux distribution. This blog post will share some of the technical details of what goes into supporting a new Linux distribution in Grype. Step 1: Make sure Syft identifies the distro correctly In this case, this step happened automatically. Syft is pretty smart about parsing /etc/os-release in an image, and Microsoft has labeled Azure Linux in a standard way. Even before this release, if you’d run the following command, you would see Azure Linux 3 correctly identified. syft -q -o json mcr.microsoft.com/azurelinux/base/core:3.0 | jq .distro { "prettyName": "Microsoft Azure Linux 3.0", "name": "Microsoft Azure Linux", "id": "azurelinux", "version": "3.0.20241005", "versionID": "3.0", "homeURL": "https://aka.ms/azurelinux", "supportURL": "https://aka.ms/azurelinux", "bugReportURL": "https://aka.ms/azurelinux" } Step 2: Build a vulnerable image You can’t test a vulnerability scanner without an image that has known vulnerabilities in it. So just about the first thing to do is make a test image that is known to have some problems. In this case, we started with Azure’s base image and intentionally installed an old version of the golang RPM: FROM mcr.microsoft.com/azurelinux/base/core:3.0@sha256:9c1df3923b29a197dc5e6947e9c283ac71f33ef051110e3980c12e87a2de91f1 RUN tdnf install -y golang-1.22.5-1.azl3 This has a couple of CVEs against it, so we can use it to test whether Grype is working end to end. $ docker build -t azuretest:latest . $ docker image save azuretest:latest > azuretest.tar $ grype ./azuretest.tar ✔ Parsed image sha256:49edd6d1eff19d2b34c27a6ad11a4a8185d2764ae1182c17c563a597d173b8 ✔ Cataloged contents e649de5ff4361e49e52ecdb8fe8acb854cf064247e377ba92669e7a33a228a00 ├── ✔ Packages [122 packages] ├── ✔ File digests [11,141 files] ├── ✔ File metadata [11,141 locations] └── ✔ Executables [426 executables] ✔ Scanned for vulnerabilities [84 vulnerability matches] ├── by severity: 3 critical, 57 high, 3 medium, 0 low, 0 negligible (21 unknown) └── by status: 84 fixed, 0 not-fixed, 0 ignored NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY coreutils 9.4-3.azl3 0:9.4-5.azl3 rpm CVE-2024-0684 Medium curl 8.8.0-1.azl3 0:8.8.0-2.azl3 rpm CVE-2024-6197 High curl-libs 8.8.0-1.azl3 0:8.8.0-2.azl3 rpm CVE-2024-6197 High expat 2.6.2-1.azl3 0:2.6.3-1.azl3 rpm CVE-2024-45492 High expat 2.6.2-1.azl3 0:2.6.3-1.azl3 rpm CVE-2024-45491 High expat 2.6.2-1.azl3 0:2.6.3-1.azl3 rpm CVE-2024-45490 High expat-libs 2.6.2-1.azl3 0:2.6.3-1.azl3 rpm CVE-2024-45492 High expat-libs 2.6.2-1.azl3 0:2.6.3-1.azl3 rpm CVE-2024-45491 High expat-libs 2.6.2-1.azl3 0:2.6.3-1.azl3 rpm CVE-2024-45490 High golang 1.22.5-1.azl3 0:1.22.7-2.azl3 rpm CVE-2023-29404 Critical golang 1.22.5-1.azl3 0:1.22.7-2.azl3 rpm CVE-2023-29402 Critical golang 1.22.5-1.azl3 0:1.22.7-2.azl3 rpm CVE-2022-41722 High krb5 1.21.2-1.azl3 0:1.21.3-1.azl3 rpm CVE-2024-37371 Critical ⋮ Normally, we like to build test images with CVEs from 2021 or earlier against them because this set of vulnerabilities changes slowly. But hats off to the team at Microsoft. We could not find an easy way to get a three-year-old vulnerability into their distro. So, in this case, the team did some behind-the-scenes work to make it easier to add test images that only have newer vulnerabilities as part of this release. Step 3: Write the vunnel provider Vunnel is Anchore’s “vulnerability funnel,” the open-source project that downloads vulnerability data from many different sources and collects and normalizes them so that grype can match them. This step was pretty straightforward because Microsoft publishes complete and up-to-date OVAL XML, so the Vunnel provider can just download it, parse it into our own format, and pass it along. Step 4: Wire it up in Grype, and profit scan away Now Syft identifies the distro, we have test images to use in our CI/CD pipelines so that we’re sure we don’t regress, and Vunnel is downloading the Azure Linux 3 vulnerability data from Microsoft, we’re ready to release the Grype change. In this case, it was a simple change telling Grype where to look in its database for vulnerabilities about the new distro. Conclusion There are two big upshots of this post: First, anyone running Grype v0.81.0 or later can scan images built from Azure Linux 3 and get accurate vulnerability information today, for free. Second, Anchore’s tools make it possible to add a new Linux distro to Syft and Grype in just a few pull requests. All the work we did for this support was open source - you can go read the pull requests on GitHub if you’d like (vunnel, grype-db, grype, test-images). And that means that if your favorite Linux distribution isn’t covered yet, you can let us know or send us a PR. If you'd like to discuss any topics this post raises, join us on discourse. ### Introducing Anchore Data Service and Anchore Enterprise 5.10 We are thrilled to announce the release of Anchore Enterprise 5.10, our tenth release of 2024. This update brings two major enhancements that will elevate your experience and bolster your security posture: the new Anchore Data Service (ADS) and expanded AnchoreCTL ecosystem coverage.  With ADS, we've built a fast and reliable solution that reduces time spent by DevSecOps teams debugging intermittent network issues from flaky services that are vital to software supply chain security. On top of that, we have buffed our software composition analysis (SCA) scanner's ecosystem coverage (e.g., C++, Swift, Elixir, R, etc.) for all Anchore customers. To do this we embedded Syft—our popular, open source SCA/SBOM (software bill of materials) generator—directly into Anchore Enterprise. It's been a fall of big releases at Anchore and we're excited to continue delivering value to our loyal customers. Read on to get all of the gory details >> Announcing the Anchore Data Service Before, customers ran the Anchore Feed Service within their environment to pull data feeds into their Anchore Enterprise deployment. To get an idea of what this looked like, see the architecture diagram of Anchore Enterprise prior to version 5.10: Originally we did this to give customers more control over their environment. Unfortunately this wasn't without its issues. The data feeds are provided by the community which means the services were designed to be accessible but cost-efficient. This meant they were unreliable; frequently having accessibility issues. We only have to stretch our memory back to the spring to recall an example that made national headlines. The National Vulnerability Database (NVD) ran into funding issues. This impacted both the creation of new vulnerabilities AND the availability of their API. This created significant friction for Anchore customers—not to mention the entirety of the software industry. Now, Anchore is running its own enterprise-grade service, named Anchore Data Service (ADS). It is a replacement for the former feed service. ADS aggregates all of the community data feeds, enriches the data (with proprietary threat data) and packages it for customers; all of this with a service availability guarantee expected of an enterprise service. The new architecture with ADS as the intermediary is illustrated below: As a bonus for our customers running air-gapped deployments of Anchore Enterprise, there is no more need to run a second deployment of Anchore Enterprise in a DMZ to pull down the data feeds. Instead a single file is pulled from ADS then transferred to a USB thumb drive. From there a single CLI command is run to update your air-gapped deployment of Anchore Enterprise. Increased AnchoreCTL Ecosystem Coverage We have increased the number of supported ecosystems (e.g., C++, Swift, Elixir, R, etc.) in Anchore Enterprise. This improves coverage and increases the likelihood that all of your organization's applications can be scanned and protected by Anchore Enterprise. More importantly, we have completely re-architected the process for how Anchore Enterprise supports new ecosystems. By integrating Syft—Anchore's open source SBOM generation tool—directly into AnchoreCTL, Anchore's customers will now get access to new ecosystem support as they are merged into Syft's codebase. Before Syft and AnchoreCTL were somewhat separate which caused AnchoreCTL's support for new ecosystems to lag Syft's. Now, they are fully integrated. This enables all of Anchore's enterprise and public sector customers to take full advantage of the open source community's development velocity. Full list of support ecosystems Below is a complete list of all supported ecosystems by both Syft and AnchoreCTL (as of Anchore Enterprise 5.10; see our docs for most current info): Alpine (apk) C (conan) C++ (conan) Dart (pubs) Debian (dpkg) Dotnet (deps.json) Objective-C (cocoapods) Elixir (mix) Erlang (rebar3) Go (go.mod, Go binaries) Haskell (cabal, stack) Java (jar, ear, war, par, sar, nar, native-image) JavaScript (npm, yarn) Jenkins Plugins (jpi, hpi) Linux kernel archives (vmlinuz) Linux kernel a (ko) Nix (outputs in /nix/store) PHP (composer) Python (wheel, egg, poetry, requirements.txt) Red Hat (rpm) Ruby (gem) Rust (cargo.lock) Swift (cocoapods, swift-package-manager) Wordpress plugins After you update to Anchore Enterprise 5.10, the SBOM inventory will now display all of the new ecosystems. Any SBOMs that have been generated for a particular ecosystem will show up top. The screenshot below gives you an idea of what this will look like: Wrap-Up Anchore Enterprise 5.10 marks a new chapter in providing reliable, enterprise-ready security tooling for modern software development. The introduction of the Anchore Data Service ensures that you have consistent and dependable access to critical vulnerability and exploit data, while the expanded ecosystem support means that no part of your tech stack is left unscrutinized for latent risk. Upgrade to the latest version and experience these new features for yourself. To update and leverage these new features check out our docs, reach out to your Customer Success Engineer or contact our support team. Your feedback is invaluable to us, and we look forward to continuing to support your organization's security needs.We are offering all of our product updates as a new quarterly product update webinar series. Watch the fall webinar update in the player below to get all of the juicy tidbits from our product team. Save your developers time with Anchore Enterprise. Get instant access with a 15-day free trial. START FREE TRIAL ### Who watches the watchmen? Introducing yardstick validate Grype scans images for vulnerabilities, but who tests Grype? If Grype does or doesn’t find a given vulnerability in a given artifact, is it right? In this blog post, we’ll dive into yardstick, an open-source tool by Anchore for comparing the results of different vulnerability scans, both against each other and against data hand-labeled by security researchers. Quality Gates In Anchore’s CI pipelines, we have a concept we call a “quality gate.” A quality gate’s job is to ensure each change to each of our tools results in matching at least as good as the version before the change. To talk about quality gates, we need a couple of terms: Reference tool configuration, or just “reference tool” for short - this is an invocation of the tool (Grype, in this case) as it works today, without the change we are considering making Candidate tool configuration, or just “candidate tool” for short - this is an invocation the tool with the change we’re trying to verify. Maybe we changed Vunnel, or the grype source code itself, for example. Test images are images that Anchore has built that are known to have vulnerabilities Label data is data our researchers have labeled, essentially writing down, “for image A, for package B at version C, vulnerability X is really present (or is not really present)” The important thing about the quality gate is that it’s an experiment - it changes only one thing to test the hypothesis. The hypothesis is always, “the candidate tool is as good or better than the reference tool,” and the one thing that’s different is the difference between the candidate tool and the reference tool. For example, if we’re testing a code change in Grype itself, the only difference between reference tool and candidate tool is the code change; the database of vulnerabilities will be the same for both runs. On the other hand, if we’re testing a change to how we build the database, the code for both Grypes will be the same, but the database used by the candidate tool will be built by the new code. Now let's talk through the logic of a quality gate: Run the reference tool and the candidate tool to get reference matches If both tools found nothing, the test is invalid. (Remember we’re scanning images that intentionally have vulnerabilities to test a scanner.) If both tools find exactly the same vulnerabilities, the test passes, because the candidate tool can’t be worse than the reference tool if they find the same things Finally, if both the reference tool and the candidate tool find at least one vulnerability, but not the same set of vulnerabilities, then we need to Do Match Matching Math: Precision, Recall, and F1 The first math problem we do is easy: Did we add too many False Negatives? (Usually one is too many.) For example, if the reference tool found a vulnerability, and the candidate tool didn’t, and the label data says it’s really there, then the gate should fail - we can’t have a vulnerability matcher that misses things we know about! The second math problem is also pretty easy: did we leave too many matches unlabeled? If we left too many matches unlabeled, we can’t do a comparison, because, if the reference tool and the candidate tool both found a lot of vulnerabilities, but we don’t know whether they’re really present or not, we can’t say which set of results is better. So the gate should fail and the engineer making the change will go and label more vulnerabilities.  Now, we get to the harder math. Let’s say the reference tool and the candidate tool both find vulnerabilities, but not exactly the same ones, and the candidate tool doesn’t introduce any false negatives. But let’s say the candidate tool does introduce a false positive or two, but it also fixes false positives and false negatives that the reference tool was wrong about. Is it better? Now we have to borrow some math from science class: Precision is the fraction of matches that are true positives. So if one of the tools found 10 vulnerabilities, and 8 of them are true positives, the precision is 0.8. Recall is the fraction of vulnerabilities that the tool found. So if there were 10 vulnerabilities present in the image and Grype found 9 of them, the recall is 0.9. F1 score is a calculation based on precision and recall that tries to reward high precision and high recall, while penalizing low precision and penalizing low recall. I won’t type out the calculation but you can read about it on Wikipedia or see it calculated in yardstick’s source code. So what’s new in yardstick Recently, the Anchore OSS team released the yardstick validate subcommand. This subcommand encapsulates the above work in a single command, which centralized a bunch of test Python spread out over the different OSS repositories. Now, to add a quality gate with a set of images, we just need to add some yaml like: pr_vs_latest_via_sbom_2022:     description: "same as 'pr_vs_latest_via_sbom', but includes vulnerabilities from 2022 and before, instead of 2021 and before"     max_year: 2022     validations:       - max-f1-regression: 0.1 # allowed to regress 0.1 on f1 score         max-new-false-negatives: 10         max-unlabeled-percent: 0         max_year: 2022         fail_on_empty_match_set: false     matrix:       images:         - docker.io/anchore/test_images:azurelinux3-63671fe@sha256:2d761ba36575ddd4e07d446f4f2a05448298c20e5bdcd3dedfbbc00f9865240d       tools:         - name: syft           # note: we want to use a fixed version of syft for capturing all results (NOT "latest")           version: v0.98.0           produces: SBOM           refresh: false         - name: grype           version: path:../../+import-db=db.tar.gz           takes: SBOM           label: candidate # is candidate better than the current baseline?         - name: grype           version: latest+import-db=db.tar.gz           takes: SBOM           label: reference # this run is the current baseline We think this change will make it easier to contribute to Grype and Vunnel. We know it helped out in the recent work to release Azure Linux 3 support. If you'd like to discuss any topics this post raises, join us on discourse. ### Preparing for a critical vulnerability One morning, you wake up and see a tweet like the one above. The immediate response is often panic. This sounds bad; it probably affects everyone, and nobody knows for certain what to do next. Eventually, the panic subsides, but we still have a problem that needs to be dealt with. So the question to ask is: What can we do? Don't panic Having a vague statement about a situation that apparently will probably affect everyone sounds like a problem we can’t possibly prepare for. Waiting is generally the worst option in situations like this, but there are some things we can do to help us out. One of the biggest challenges in modern infrastructure is just understanding what you have. This sounds silly, but it’s a tough problem because of how most software is built now. You depend on a few open-source projects, and those projects depend on a few other open-source projects, which rely on even more open-source projects. And before you know it, you have 300 open-source projects instead of the 6 you think you installed. Our goal is to create an inventory of all our software. If we have an accurate and updated inventory, you don’t have to wonder if you’re running some random application, like CUPS. You will know beyond a reasonable doubt. Knowing what software you do (or don’t) have deployed can bring an amazing amount of peace of mind. This is not new This was the same story during log4J and xz emergencies. What induced panic in everyone wasn’t the vulnerabilities themselves but the scramble to find where those libraries were deployed. In many instances, we observed engineers manually connecting to servers with SSH and dissecting container images. These security emergencies will never end, but they all play out similarly. There is a time between when something is announced and good actionable guidance appearing. The security community will come to a better understanding of the issue, then we can figure out the best way to deal with whatever the problem is. This could be updating packages, it could mean adjusting firewall rules, or maybe changing a configuration option. While we wait for the best guidance, what if we were going through our software inventory? When Log4Shell happened almost everyone spent the first few days or weeks (or months) just figuring out if they had Log4j anywhere. If you have an inventory, those first few days can be spent putting together a plan for applying the guidance you know is coming. It’s a much nicer way to spend time than frantically searching! The inventory Creating an inventory sounds like it shouldn’t be that hard. How much software do you REALLY have? It’s hard, and software poses a unique challenge because there are nearly infinite ways to build and assemble any given application. Do you have OpenSSL as an operating system package? Or is it a library in a random directory? Maybe it’s statically compiled into the binary. Maybe we download a copy off the internet when the application starts. Maybe it’s all of these … at the same time. This complexity is taken to a new level when you consider how many computers, servers, containers, and apps are deployed. The scale means automation is the only way we can do this. Humans cannot handcraft an inventory. They are too slow and make too many mistakes for this work, but robots are great at it! But the automation we have today isn’t perfect. It’s early days for many of these scanners and inventory formats (such as a Software Bill of Materials or SBOM). We must grasp what possible blind spots our inventories may have. For example, some scanners do a great job finding operating system packages but aren’t as good at finding Java archives (jar files). This is part of what makes the current inventory process difficult. The tooling is improving at an impressive rate; don’t write anything off as too incomplete. It will change and get better in the future. Enter the SBOM Now that we have mentioned SBOMs, we should briefly explain how they fit into this inventory universe. An SBOM does nothing by itself; it’s just a file format for capturing information, such as a software inventory. Anchore developers have written plenty over the years about what an is SBOM, but here is the tl;dr: An SBOM is a detailed list of all software project components, libraries, and dependencies. It serves as a comprehensive inventory that helps understand the software's structure and the origins of its components. An SBOM in your project enhances security by quickly identifying and mitigating vulnerabilities in third-party components. Additionally, it ensures compliance with regulatory standards and provides transparency, which is essential for maintaining trust with stakeholders and users. An example To explain what all this looks like and some of the difficulties, let’s go over an example using the eclipse-temurin Java runtime container image. It would be very common for a developer to build on top of this image. It also shows many of the challenges in trying to pin down a software inventory. The Dockerfile we’re going to reference can be found on GitHub, and the container image can be found on Docker Hub. The first observation is that this container uses Ubuntu as the underlying container image. This is great, Ubuntu has a very nice packaging system and it’s no trouble to see what’s installed. We can easily do this with Syft. bress@anchore → ~ syft ubuntu:24.04 ✔ Parsed image sha256:61b2756d6fa9d6242fafd5b29f674404779be561db2d0bd932aa3640ae67b9e1 ✔ Cataloged contents 74f92a6b3589aa5cac6028719aaac83de4037bad4371ae79ba362834389035aa ├── ✔ Packages [91 packages] ├── ✔ File digests [2,259 files] ├── ✔ File metadata [2,259 locations] └── ✔ Executables [722 executables] NAME VERSION TYPE apt 2.7.14build2 deb base-files 13ubuntu10.1 deb base-passwd 3.6.3build1 deb bash 5.2.21-2ubuntu4 deb bsdutils 1:2.39.3-9ubuntu6.1 deb coreutils 9.4-3ubuntu6 deb dash 0.5.12-6ubuntu5 deb debconf 1.5.86ubuntu1 deb debianutils 5.17build1 deb diffutils 1:3.10-1build1 deb dpkg 1.22.6ubuntu6.1 deb e2fsprogs 1.47.0-2.4~exp1ubuntu4.1 deb findutils 4.9.0-5build1 deb gcc-14-base 14-20240412-0ubuntu1 deb gpgv 2.4.4-2ubuntu17 deb grep 3.11-4build1 deb gzip 1.12-1ubuntu3 deb hostname 3.23+nmu2ubuntu2 deb init-system-helpers 1.66ubuntu1 deb ⋮ There has been nothing exciting so far. But if we look a little deeper at the eclipse temurin Dockerfile, we see it’s installing the Java JDK using wget. That’s not something we’ll find just by looking at Ubuntu packages. bress@anchore ~ syft ubuntu:24.04 ✔ Parsed image sha256:61b2756d6fa9d6242fafd5b29f674404779be561db2d0bd932aa3640ae67b9e1 ✔ Cataloged contents 74f92a6b3589aa5cac6028719aaac83de4037bad4371ae79ba362834389035aa ├── ✔ Packages [91 packages] ├── ✔ File digests [2,259 files] ├── ✔ File metadata [2,259 locations] └── ✔ Executables [722 executables] NAME VERSION TYPE apt 2.7.14build2 deb base-files 13ubuntu10.1 deb base-passwd 3.6.3build1 deb bash 5.2.21-2ubuntu4 deb bsdutils 1:2.39.3-9ubuntu6.1 deb coreutils 9.4-3ubuntu6 deb dash 0.5.12-6ubuntu5 deb debconf 1.5.86ubuntu1 deb debianutils 5.17build1 deb diffutils 1:3.10-1build1 deb dpkg 1.22.6ubuntu6.1 deb e2fsprogs 1.47.0-2.4~exp1ubuntu4.1 deb findutils 4.9.0-5build1 deb gcc-14-base 14-20240412-0ubuntu1 deb gpgv 2.4.4-2ubuntu17 deb grep 3.11-4build1 deb gzip 1.12-1ubuntu3 deb hostname 3.23+nmu2ubuntu2 deb init-system-helpers 1.66ubuntu1 deb If we scan this image with Syft, we can see a few different types of packages installed. bress@anchore ~ syft eclipse-temurin:8u422-b05-jre-noble ✔ Parsed image sha256:d2c2442dea2a2b1164bd6dd39af673db2215ff680910aff7417432b00a3c8e4d ✔ Cataloged contents 805b45dee2c503f1cca36e1ecc6e8625538592e2db32cc04e317a246fb86d0fc ├── ✔ Packages [142 packages] ├── ✔ File digests [3,856 files] ├── ✔ File metadata [3,856 locations] └── ✔ Executables [809 executables] NAME VERSION TYPE ⋮ hostname 3.23+nmu2ubuntu2 deb init-system-helpers 1.66ubuntu1 deb jaccess UNKNOWN java-archive jce 1.8.0_422 java-archive jfr 1.8.0_422 java-archive jsse 1.8.0_422 java-archive libacl1 2.3.2-1build1 deb libapt-pkg6.0t64 2.7.14build2 deb libassuan0 2.5.6-1build1 deb libattr1 1:2.5.2-1build1 deb libaudit-common 1:3.1.2-2.1build1 deb ⋮ The jdk and jre are binaries in the image, as are some Java archives. This is a gotcha to watch for when you’re building an inventory. Many inventories and scanners may only look for known-good packages, not binaries and other files installed on the system. In a perfect world, our SBOM tells us details about everything in the image, not just one package type. At this point, you can imagine a developer adding more things to the container: code they wrote, Java Archives, data files, and maybe even a few more binary files, probably installed with wget or curl. What next This sounds pretty daunting, but it’s not that hard to start building an inventory. You don’t need a fancy system. The easiest way is to find an open source SBOM generator, like Syft, and put the SBOMs in a directory. It’s not perfect, but even searching through those files is faster than manually finding every version of CUPS in your infrastructure. Once you understand an initial inventory, you can investigate more complete solutions. There are countless open-source projects, products (such as Anchore Enterprise), and services that can help here. For example, when starting to build the inventory, don’t expect to go from zero to complete overnight. Big projects need immense patience. It’s like the old proverb that the best time to plant a tree was twenty years ago; the second best time is now. The best time to start an inventory system was a decade ago; the second best time is now. If you'd like to discuss any topics raised in this post, join us on this discourse thread. ### STIG 101: Insights for Compliance and Cyber Readiness ### Compliance Requirements for DISA’s Security Technical Implementation Guides (STIGs) Fast Facts To help organizations meet the DoD's security controls, DISA develops Security Technical Implementation Guides (STIGs) to provide guidance on how to secure operating systems, network devices, software, and other IT systems. STIG compliance is mandatory for any organization that operates within the DoD network or handles DoD information, including DoD contractors and vendors, government agencies, and DoD IT teams. With more than 500 total STIGs, your organization can streamline the STIG compliance process by identifying applicable STIGs upfront, prioritizing fixes, establishing a maintenance schedule, and assigning clear responsibilities to team members. Tools like DISA STIG Viewer, Anchore Enterprise, and SCARP Compliance Checker can help track and automate STIG compliance. In the rapidly modernizing landscape of cybersecurity compliance, evolving to a continuous compliance posture is more critical than ever, particularly for organizations involved with the Department of Defense (DoD) and other government agencies. In February 2025, Microsoft reported that governments are in the top 3 most targeted sectors worldwide. At the heart of the DoD's modern approach to software development is the DoD Enterprise DevSecOps Reference Design, commonly implemented as a DoD Software Factory. A key component of this framework is adhering to the Security Technical Implementation Guides (STIGs) developed by the Defense Information Systems Agency (DISA). STIG compliance within the DevSecOps pipeline not only accelerates the delivery of secure software but also embeds robust security practices directly into the development process, safeguarding sensitive data and reinforcing national security. This comprehensive guide will walk you through what STIGs are, who should care about them, the levels and key categories of STIG compliance, how to prepare for the compliance process, and tools available to automate STIG implementation and maintenance. Read on for the full overview or skip ahead to find the information you need: What are STIGs? Who needs to comply? Levels of STIG compliance Key categories of requirements Preparing for the STIG compliance process STIG compliance tools Save a Seat What are STIGs and who should care? Understanding DISA and STIGs The Defense Information Systems Agency (DISA) is the DoD agency responsible for delivering information technology (IT) support to ensure the security of U.S. national defense systems. To help organizations meet the DoD's rigorous security controls, DISA develops Security Technical Implementation Guides (STIGs). STIGs are configuration standards that provide prescriptive guidance on how to secure operating systems, network devices, software, and other IT systems. They serve as a secure configuration standard to harden systems against cyber threats. For example, a STIG for the open source Apache web server would specify that encryption is enabled for all traffic (incoming or outgoing). This would require the generation of SSL/TLS certificates on the server in the correct location, updating the server's configuration file to reference this certificate and re-configuration of the server to serve traffic from a secure port rather than the default insecure port. Who should care about STIG compliance? In its annual Software Supply Chain Security report, Anchore found that the average organization complies with 4.9 cybersecurity compliance standards. STIG compliance, in particular, is mandatory for any organization that operates within the DoD network or handles DoD information. This includes: DoD Contractors and Vendors: Companies providing products or services to the DoD, a.k.a. the defense industrial base (DIB) Government Agencies: Federal agencies interfacing with the DoD DoD Information Technology Teams: IT professionals within the DoD responsible for system security Connection to the RMF and NIST SP 800-53 The Risk Management Framework (RMF)—known formally as NIST 800-37—is a framework that integrates security and risk management into IT systems as they are being developed. The STIG compliance process outlined below is directly integrated into the higher-level RMF process. As you follow the RMF, the individual steps of STIG compliance will be completed in turn. STIGs are also closely connected to the NIST 800-53, colloquially known as the "Control Catalog". NIST 800-53 outlines security and privacy controls for all federal information systems; the controls are not prescriptive about the implementation, only the best practices and outcomes that need to be achieved.  As DISA developed the STIG compliance standard, they started with the NIST 800-53 controls as a baseline, then "tailored" them to meet the needs of the DoD; these customized security best practices are known as Security Requirements Guides (SRGs). In order to remove all ambiguity around how to meet these higher-level best practices STIGs were created with implementation specific instructions. For example, an SRG will mandate that all systems utilize a cybersecurity best practice, such as, role-based access control (RBAC) to prevent users without the correct privileges from accessing certain systems. A STIG, on the other hand, will detail exactly how to configure an RBAC system to meet the highest security standards. Levels of STIG Compliance The DISA STIG compliance standard uses Severity Category Codes to classify vulnerabilities based on their potential impact on system security. These codes help organizations prioritize remediation efforts. The three Severity Category Codes are: Category I (Cat I): These are the highest severity or highest risk vulnerabilities, allowing an attacker immediate access to a system or network or allowing superuser access. Due to their high risk nature, these vulnerabilities be addressed immediately. Category II (Cat II): These vulnerabilities provide information with a high potential of giving access to intruders. These findings are considered a medium risk and should be remediated promptly. Category III (Cat III): These vulnerabilities constitute the lowest risk, providing information that could potentially lead to compromise. Although not as pressing as Cat II & III issues, it is still important to address these vulnerabilities to minimize risk and enhance overall security. Understanding these categories is crucial in the STIG process, as they guide organizations in prioritizing remediation of vulnerabilities. Key categories of STIG requirements Given the extensive range of technologies used in DoD environments, there are nearly 500 STIGs (as of May 2025) applicable to different systems, devices, applications, and more. While we won't list all STIG requirements and benchmarks here, it's important to understand the key categories and who they apply to. 1. Operating System STIGs Applies to: System Administrators and IT Teams managing servers and workstations Examples: Microsoft Windows STIGs: Provides guidelines for securing Windows operating systems. Linux STIGs: Offers secure configuration requirements for various Linux distributions. 2. Network Device STIGs Applies to: Network Engineers and Administrators Examples: Network Router STIGs: Outlines security configurations for routers to protect network traffic. Network Firewall STIGs: Details how to secure firewall settings to control access to networks. 3. Application STIGs Applies to: Software Developers and Application Managers Examples: Generic Application Security STIG: Outlines the necessary security best practices needed to be STIG compliant Web Server STIG: Provides security requirements for web servers. Database STIG: Specifies how to secure database management systems (DBMS). 4. Mobile Device STIGs Applies to: Mobile Device Administrators and Security Teams Examples: Apple iOS STIG: Guides securing of Apple mobile devices used within the DoD. Android OS STIG: Details security configurations for Android devices. 5. Cloud Computing STIGs Applies to: Cloud Service Providers and Cloud Infrastructure Teams Examples: Microsoft Azure SQL Database STIG: Offers security requirements for Azure SQL Database cloud service. Cloud Computing OS STIG: Details secure configurations for any operating system offered by a cloud provider that doesn't have a specific STIG. Each category addresses specific technologies and includes a STIG checklist to ensure all necessary configurations are applied.  See an example of a STIG checklist for "Application Security and Development" here. How to Prepare for the STIG Compliance Process Achieving DISA STIG compliance involves a structured approach. Here are the stages of the STIG process and tips to prepare: Stage 1: Identifying Applicable STIGs With hundreds of STIGs relevant to different organizations and technology stacks, this step should not be underestimated. First, conduct an inventory of all systems, devices, applications, and technologies in use. Then, review the complete list of STIGs to match each to your inventory to ensure that all critical areas requiring secure configuration are addressed. This step is essential to avoiding gaps in compliance. Tip: Use automated tools to scan your environment then match assets to relevant STIGs. Stage 2: Implementation After you've mapped your technology to the corresponding STIGs, the process of implementing the security configurations outlined in the guides begins. This step may require collaboration between IT, security, and development teams to ensure that the configurations are compatible with the organization's infrastructure while enforcing strict security standards. Be sure to keep detailed records of changes made. Tip: Prioritize implementing fixes for Cat I vulnerabilities first, followed by Cat II and Cat III. Depending on the urgency and needs of the mission, ATO can still be achieved with partial STIG compliance. Prioritizing efforts increases the chances that partial compliance is permitted. Stage 3: Auditing & Maintenance After the STIGs have been implemented, regular auditing and maintenance are critical to ensure ongoing compliance, verifying that no deviations have occurred over time due to system updates, patches, or other changes. This stage includes periodic scans, manual reviews, and remediation of any identified gaps. Additionally, organizations should develop a plan to stay informed about new STIG releases and updates from DISA. Tip: Establish a maintenance schedule and assign responsibilities to team members. Alternatively, adopting a policy-as-code approach to continuous compliance by embedding STIG compliance requirements "-as-code" directly into your DevSecOps pipeline, you can automate this process. General Implementation Tips Training: Ensure your team is familiar with STIG requirements and the compliance process. Collaboration: Work cross-functionally with all relevant departments, including IT, security, and compliance teams. Resource Allocation: Dedicate sufficient resources, including time and personnel, to the compliance effort. Continuous Improvement: Treat STIG compliance as an ongoing process rather than a one-time project. Test for Impact on Functionality: The downside of STIG controls' high level of security is a potential to negatively impact functionality. Be sure to conduct extensive testing to identify broken features, compatibility issues, interoperability challenges, and more. Tools to automate STIG implementation and maintenance The 2024 Report on Software Supply Chain Security found "automating compliance checks" is a top priority, with 52% of respondents ranking it in their top 3 supply chain security challenges. For STIGs, automation can significantly streamline the compliance process. Here are a few tools that can help: 1. Anchore STIG (Static and Runtime) Purpose: Automates the process of checking container images against STIG requirements. Benefits: Simplifies compliance for containerized applications. Integrates into CI/CD pipelines for continuous compliance. Use Case: Ideal for DevSecOps teams utilizing containers in their deployments. 2. SCAP Compliance Checker Purpose: Provides automated compliance scanning using the Security Content Automation Protocol (SCAP). Benefits: Validates system configurations against STIGs. Generates detailed compliance reports. Use Case: Useful for system administrators needing to audit various operating systems. 3. DISA STIG Viewer Purpose: Helps in viewing and managing STIG checklists. Benefits: Allows for easy navigation of STIG requirements. Facilitates documentation and reporting. Use Case: Assists compliance officers in tracking compliance status. 4. DevOps Automation Tools Infrastructure Automation Examples: Red Hat Ansible, Perforce Puppet, Hashicorp Terraform Software Build Automation Examples: CloudBees CI, GitLab Purpose: Automate the deployment of secure configurations that meet STIG compliance across multiple systems. Benefits: Ensures consistent application of secure configuration standards. Reduces manual effort and the potential for errors. Use Case: Suitable for large-scale environments where manual configuration is impractical. 5. Vulnerability Management Tools Examples: Anchore Secure Purpose: Identify vulnerabilities and compliance issues within your network. Benefits: Provides actionable insights to remediate security gaps. Offers continuous monitoring capabilities. Use Case: Critical for security teams focused on proactive risk management. Wrap-Up Achieving DISA STIG compliance is mandatory for organizations working with the DoD. By understanding what STIGs are, who they apply to, and how to navigate the compliance process, your organization can meet the stringent compliance requirements set forth by DISA. As a bonus, you will enhance its security posture and reduce the potential for a security breach. Remember, compliance is not a one-time event but an ongoing effort that requires regular updates, audits, and maintenance. Leveraging automation tools like Anchore STIG and Anchore Secure can significantly ease this burden, allowing your team to focus on strategic initiatives rather than manual compliance tasks. Stay proactive, keep your team informed, and make use of the resources available to ensure that your IT systems remain secure and compliant. Download Now ### Navigating Open Source Software Compliance in Regulated Industries Open source software (OSS) brings a wealth of benefits; speed, innovation, cost savings. But when serving customers in highly regulated industries like defense, energy, or finance, a new complication enters the picture—compliance. Imagine your DevOps-fluent engineering team has been leveraging OSS to accelerate product delivery, and suddenly, a major customer hits you with a security compliance questionnaire. What now?  Regulatory compliance isn't just about managing the risks of OSS for your business anymore; it's about providing concrete evidence that you meet standards like FedRAMP and the Secure Software Development Framework (SSDF). The tricky part is that the OSS "suppliers" making up 70-90% of your software supply chain aren't traditional vendors—they don't have the same obligations or accountability, and they're not necessarily aligned with your compliance needs.  So, who bears the responsibility? You do. The OSS your engineering team consumes is your resource and your responsibility. This means you're not only tasked with managing the security risks of using OSS but also with proving that both your applications and your OSS supply chain meet compliance standards.  In this post, we'll explore why you're ultimately responsible for the OSS you consume and outline practical steps to help you use OSS while staying compliant. Learn about CISA's SSDF attestation form and how to meet compliance. Download Now What does it mean to use open source software in a regulated environment? Highly regulated environments add a new wrinkle to the OSS security narrative. The OSS developers that author the software dependencies that make up the vast majority of modern software supply chains aren't vendors in the traditional sense. They are more of a volunteer workforce that allow you to re-use their work but it is a take it or leave it agreement. You have no recourse if it doesn't work as expected, or worse, has vulnerabilities in it. So, how do you meet compliance standards when your software supply chain is built on top of a foundation of OSS? Who is the vendor? You are! Whether you have internalized this or not the open source software that your developers consume is your resource and thus your responsibility. This means that you are shouldered with the burden of not only managing the security risk of consuming OSS but also having to shoulder the burden of proving that both your applications and the your OSS supply chain meets compliance. Open source software is a natural resource Before we jump into how to accomplish the task set forth in the previous section, let's take some time to understand why you are the vendor when it comes to open source software. The common idea is that OSS is produced by a 3rd-party that isn't part of your organization, so they are the software supplier. Shouldn't they be the ones required to secure their code? They control and maintain what goes in, right? How are they not responsible? To answer that question, let's think about OSS as a natural resource that is shared by the public at large, for instance the public water supply. This shouldn't be too much of a stretch. We already use terms like upstream and downstream to think about the relationship between software dependencies and the global software supply chain. Using this mental model, it becomes easier to understand that a public good isn't a supplier. You can't ask a river or a lake for an audit report that it is contaminant free and safe to drink.  Instead the organization that processes and provides the water to the community is responsible for testing the water and guaranteeing its safety. In this metaphor, your company is the one processing the water and selling it as pristine bottled water.  How do you pass the buck to your "supplier"? You can't. That's the point. This probably has you asking yourself, if I am responsible for my own OSS supply chain then how to meet a compliance standard for something that I don't have control over? Keep reading and you'll find out. How do I use OSS and stay compliant? While compliance standards are often thought of as rigid, the reality is much more nuanced. Just because your organization doesn't own/control the open source projects that you consume doesn't mean that you can't use OSS and meet compliance requirements. There are a few different steps that you need to take in order to build a "reasonably secure" OSS supply chain that will pass a compliance audit. We'll walk you through the steps below: Step 1 — Know what you have (i.e., an SBOM inventory) The foundation of the global software supply chain is the SBOM (software bill of materials) standard. Each of the security and compliance functions outlined in the steps below use or manipulate an SBOM. SBOMs are the foundational component of the global software supply chain because they record the ingredients that were used to produce the application an end-user will consume. If you don't have a good grasp of the ingredients of your applications there isn't much hope for producing any upstream security or compliance guarantees. The best way to create observability into your software supply chain is to generate an SBOM for every single application in your DevSecOps build pipeline—at each stage of the pipeline! Step 2 — Maintain a historical record of application source code To meet compliance standards like FedRAMP and SSDF, you need to be able to maintain a historical record of the source code of your applications, including:  Where it comes from,  Who created it, and  Any modifications made to it over time. SBOMs were designed to meet these requirements. They act as a record of how applications were built and when/where OSS dependencies were introduced. They also double as compliance artifacts that prove you are compliant with regulatory standards. Governments aren't content with self-attestation (at least not for long); they need hard evidence to verify that you are trustworthy. Even though SSDF is currently self-attestation only, the federal government is known for rolling out compliance frameworks in stages. First advising on best-practices, then requiring self-attestation, finally external validation via a certification process.  The Cybersecurity Maturity Model Certification (CMMC) is a good example of this dynamic process. It recently transitioned from self-attestation to external validation with the introduction of the 2.0 release of the framework. Step 3 — Manage your OSS vulnerabilities Not only do you need to keep a record of applications as they evolve over time, you have to track the known vulnerabilities of your OSS dependencies to achieve compliance. Just as SBOMs prove provenance, vulnerability scans are proof that your application and its dependencies aren't vulnerable. These scans are a crucial piece of the evidence that you will need to provide to your compliance officer as you go through the certification process.  Remember the buck stops with you! If the OSS that your application consumes doesn't supply an SBOM and vulnerability scan (which is essentially all OSS projects) then you are responsible to create them. There is no vendor to pass the blame to for proving that your supply chain is reasonably secure and thus compliant. Step 4 — Continuous compliance of open source software supply chain It is important to recognize that modern compliance standards are no longer sprints but marathons. Not only do you have to prove that your application(s) are compliant at the time of audit but you have to be able to demonstrate that it remains secure continuously in order to maintain your certification. This can be challenging to scale but it is made easier by integrating SBOM generation, vulnerability scanning and policy checks directly into the DevSecOps pipeline. This is the approach that modern, SBOM-powered SCAs advocate for. By embedding the compliance policy-as-code into your DevSecOps pipeline as policy gates, compliance can be maintained over time. Developers are alerted when their code doesn't meet a compliance standard and are directed to take the corrective action. Also, these compliance checks can be used to automatically generate the compliance artifacts needed.  You already have an automated DevSecOps pipeline that is producing and delivering applications with minimal human intervention, why not take advantage of this existing tooling to automate open source software compliance in the same way that security was integrated directly into DevOps. Real-world Examples To help bring these concepts to life, we've outlined some real-world examples of how open source software and compliance intersect: Open source project has unfixed vulnerabilities This is far and wide the most common issue that comes up during compliance audits. One of your application's OSS dependencies has a known vulnerability that has been sitting in the backlog for months or even years! There are several reasons why an open source software developer might leave a known vulnerability unresolved: They prioritize a feature over fixing a vulnerability The vulnerability is from a third-party dependency they don't control and can't fix They don't like fixing vulnerabilities and choose to ignore it They reviewed the vulnerability and decided it's not likely to be exploited, so it's not worth their time They're planning a codebase refactor that will address the vulnerability in the future These are all rational reasons for vulnerabilities to persist in a codebase. Remember, OSS projects are owned and maintained by 3rd-party developers who control the repository; they make no guarantees about its quality. They are not vendors. You, on the other hand, are a vendor and must meet compliance requirements. The responsibility falls on you. An OSS vulnerability management program is how you meet your compliance requirements while enjoying the benefits of OSS. Need to fill out a supplier questionnaire Imagine you're a cloud service provider or software vendor. Your sales team is trying to close a deal with a significant customer. As the contract nears signing, the customer's legal team requests a security questionnaire. They're in the business of protecting their organization from financial risk stemming from their supply chain, and your company is about to become part of that supply chain. These forms are usually from lawyers, very formal, and not focused on technical attacks. They just want to know what you're using. The quick answer? "Here's our SBOM."  Compliance comes in the form of public standards like FedRAMP, SSDF, NIST, etc., and these less formal security questionnaires. Either way, being unable to provide a full accounting of the risks in your software supply chain can be a speed bump to your organization's revenue growth and success. Integrating SBOM scanning, generation, and management deeply into your DevSecOps pipeline is key to accelerating the sales process and your organization's overall success. Prove provenance CISA's SSDF Attestation form requires that enterprises selling software to the federal government can produce a historical record of their applications. Quoting directly: "The software producer [must] maintain provenance for internal code and third-party components incorporated into the software to the greatest extent feasible." If you want access to the revenue opportunities the U.S. federal government offers, SSDF attestation is the needle you have to thread. Meeting this requirement without hiring an army of compliance engineers to manually review your entire DevSecOps pipeline demands an automated OSS component observability and management system. Often, we jump to cryptographic signatures, encryption keys, trust roots—this quickly becomes a mess. Really, just a hash of the files in a database (read: SBOM inventory) satisfies the requirement. Sometimes, simpler is better.  Discover the "easy button" to SSDF Attestation and OSS supply chain compliance in our previous blog post. Takeaways OSS Is Not a Vendor—But You Are! The best way to have your OSS cake and eat it too (without the indigestion) is to: Know Your Ingredients: Maintain an SBOM inventory of your OSS supply chain. Maintain a Complete Historical Record: Keep track of your application's source code and build process. Scan for Known Vulnerabilities: Regularly check your OSS dependencies. Continuous Compliance thru Automation: Generate compliance records automatically to scale your compliance process. There are numerous reasons to aim for open source software compliance, especially for your software supply chain: Balance Gains Against Risks: Leverage OSS benefits while managing associated risks. Reduce Financial Risk: Protect your organization's existing revenue. Increase Revenue Opportunities: Access new markets that mandate specific compliance standards. Avoid Becoming a Cautionary Tale: Stay ahead of potential security incidents. Regardless of your motivation for wanting to use OSS and use it responsibly (i.e., securely and compliantly), Anchore is here to help. Reach out to our team to learn more about how to build and manage a secure and compliant OSS supply chain. Learn the container security best practices to reduce the risk of software supply chain attacks. Download Now ### US Navy achieves ATO in days with continuous compliance and OSS risk management Implementing secure and compliant software solutions within the Department of Defense's (DoD) software factory framework is no small feat.  For Black Pearl, the premier DevSecOps platform for the U.S. Navy, and Sigma Defense, a leading DoD technology contractor, the challenge was not just about meeting stringent security requirements but to empower the warfighter.  We'll cover how they streamlined compliance, managed open source software (OSS) risk, and reduced vulnerability overload—all while accelerating their Authority to Operate (ATO) process. Challenge: Navigating Complex Security and Compliance Requirements Black Pearl and Sigma Defense faced several critical hurdles in meeting the stringent security and compliance standards of the DoD Enterprise DevSecOps Reference Design: Achieving RMF Security and Compliance: Black Pearl needed to secure its own platform and help its customers achieve ATO under the Risk Management Framework (RMF). This involved meeting stringent security controls like RA-5 (Vulnerability Management), SI-3 (Malware Protection), and IA-5 (Credential Management) for both the platform and the applications built on it. Maintaining Continuous Compliance: With the RAISE 2.0 memo emphasizing continuous ATO compliance, manual processes were no longer sufficient. The teams needed to automate compliance tasks to avoid the time-consuming procedures traditionally associated with maintaining ATO status. Managing Open-Source Software (OSS) Risks: Open-source components are integral to modern software development but come with inherent risks. Black Pearl had to manage OSS risks for both its platform and its customers' applications, ensuring vulnerabilities didn't compromise security or compliance. Vulnerability Overload for Developers: Developers often face an overwhelming number of vulnerabilities, many of which may not pose significant risks. Prioritizing actionable items without draining resources or slowing down development was a significant challenge. "By using Anchore and the Black Pearl platform, applications inherit 80% of the RMF's 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, Product Lead/Solutions Architect Solution: Automating Compliance and Security with Anchore To address these challenges, Black Pearl and Sigma Defense implemented Anchore, which provided: Policy Packs to Meet RMF Security Controls: Black Pearl used Anchore Enterprise's DoD policy pack to identify, evaluate, prioritize, enforce, and report on security controls necessary for RMF compliance. This ensured that both the platform and customer applications met all required standards. Automated and Continuous ATO Compliance: Anchore's automation capabilities managed security findings and tracked Plan of Action and Milestones (POA&Ms), reducing manual intervention and ensuring continuous compliance without the usual resource drain. "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 Managing OSS Risks with Continuous Monitoring: Anchore's integrated vulnerability scanner, policy enforcer, and reporting system provided continuous monitoring of open-source software components. This proactive approach ensured vulnerabilities were detected and addressed promptly, effectively mitigating security risks. Automated Prioritization of Vulnerabilities: By integrating the Anchore Developer Bundle, Black Pearl enabled automatic prioritization of actionable vulnerabilities. Developers received immediate alerts on critical issues, reducing noise and allowing them to focus on what truly matters. Results: Accelerated ATO and Enhanced Security The implementation of Anchore transformed Black Pearl's compliance process and security posture: Platform ATO in 3-5 days: With Anchore's integration, Black Pearl users accessed a fully operational DevSecOps platform within days, a significant reduction from the typical six months for DIY builds. "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 Significantly reduced time spent on compliance reporting: Anchore automated compliance checks and artifact generation, cutting down hours spent on manual reviews and ensuring consistency in reports submitted to authorizing officials. Proactive OSS risk management: By shifting security and compliance to the left, developers identified and remediated open-source vulnerabilities early in the development lifecycle, mitigating risks and streamlining the compliance process. Reduced vulnerability overload with prioritized vulnerability reporting: Anchore's prioritization of vulnerabilities prevented developer overwhelm, allowing teams to focus on critical issues without hindering development speed. Conclusion: Empowering the Warfighter Through Efficient Compliance and Security Black Pearl and Sigma Defense's partnership with Anchore demonstrates how automating security and compliance processes leads to significant efficiencies. This empowers Navy divisions to focus on developing software that supports the warfighter.  Achieving ATO in days rather than months is a game-changer in an environment where every second counts, setting a new standard for efficiency through the combination of Black Pearl's robust DevSecOps platform and Anchore's comprehensive security solutions. If you're facing similar challenges in securing your software supply chain and accelerating compliance, it's time to explore how Anchore can help your organization achieve its mission-critical objectives. Download the full case study below👇 Download Now ### Introducing the Anchore Data Service ### Mark Your Calendars: Anchore's Must-Attend Events and Webinars in October Are you ready for cooler temperatures and the changing of the leaves? Anchore is! We are excited to announce a series of events and webinars next month. From in-person conferences to insightful webinars, we have a lineup designed to keep you informed about the latest developments in software supply chain security, DevSecOps, and compliance. Join us to learn, connect, and explore how Anchore can help your organization navigate the evolving landscape of software security. EVENT: TD Synnex Inspire Date: October 9-12, 2024 Location: Booth T84 | Greenville Convention Center in Greenville, SC Register Here Anchore is thrilled to be exhibiting at the 2024 TD SYNNEX Inspire. Visit us at Booth T84 in the Pavilion to discover how Anchore secures containers for AI, machine learning applications—with a special emphasis on high-performance computing (HPC). Anchore has helped many Fortune 50 enterprises scale their container security and vulnerability management programs for their entire software supply chain including luminaries like NVIDIA. If you'd like to book dedicated time to speak with our team, drop by our booth or email us at sales@anchore.com. WEBINAR: Introducing the Anchore Data Service Date: October 15, 2024 at 10am PT Save a Seat We will showcase the exciting new features introduced in Anchore Enterprise 5.8, 5.9, and 5.10. All designed to effortlessly secure your software supply chain and reduce risk for your organization. Highlights include: Version 5.10: New Anchore Data Service which automatically updates your vulnerability feeds—even in air-gapped environments! Version 5.9: Improved SBOM generation with native integration of Syft, etc. Version 5.8: CISA Known Exploited Vulnerabilities (KEV) feed, etc. We will be demo-ing all of the new features, sharing pro tips and providing takeaways on how to best utilize the new releases. Don't miss out! EVENT: All Things Open Conference Date: October 27-29, 2024 Location: Booth #95 | Raleigh Convention Center in Raleigh, NC Register Here Anchore is excited to participate in the 2024 All Things Open Conference—one of the largest open source software events in the U.S. Drop by and visit us at Booth #95 to learn how our open source tools, Syft and Grype, can help you start your journey to a more secure DevSecOps pipeline.  Anchore employees will be on hand to help you understand: Learn how to generate Software Bill of Materials (SBOMs) with Syft Learn how to perform vulnerability scanning for container images and filesystems with Grype How to automated compliance in a DevSecOps pipeline WEBINAR: Accelerate FedRAMP Compliance on Amazon EKS with Anchore Date: October 29, 2024 at 10am PT Save a Seat Navigating FedRAMP compliance can be challenging, but Anchore and AWS are here to simplify the process. Join Luis Morales, Solutions Architect at AWS, and Brian Thomason, Manager of Partner and Solutions Engineering at Anchore, as they explain how Cisco achieved FedRAMP compliance in weeks rather than months. In this live session, we'll share actionable guidance and insights that address: How to meet six FedRAMP vulnerability scanning requirements Automating STIG and FIPS compliance for Amazon EC2 virtual machines Securing containers end-to-end across CI/CD, Amazon EKS, and ECS *We'll also discuss the architecture of Anchore running in an AWS customer environment, demonstrating how to leverage AWS tools and services to enhance your cloud security posture. WEBINAR: Expert Series: Solving Real-World Challenges in FedRAMP Compliance Date: October 30, 2024 at 10am PT Save a Seat Navigating the path to FedRAMP authorization can be daunting, especially with the evolving landscape of federal security requirements. In this Expert Series webinar, Neil Levine, SVP of Product at Anchore, and Mike Strohecker, Director of Cloud Operations at InfusionPoints, will share real-world stories of how we've helped our FedRAMP customers overcome key challenges—from achieving compliance faster to meeting the latest FedRAMP Rev 5 requirements. We'll dive into practical solutions, including: Overcoming common FedRAMP compliance hurdles Meeting Rev 5 security hardening standards like STIG and CIS (CM-6) Effectively shifting security left in the CI/CD pipeline Automating policy enforcement and continuous monitoring *We'll also explore the future impact of the July 2024 FedRAMP modernization memo, highlighting how increased automation with OSCAL is transforming the compliance process. Wrap-Up With a brimming schedule of events, October promises to be a jam packed month for Anchore and our community. Whether you're interested in our latest product updates, exploring strategies for FedRAMP compliance, or connecting at industry-leading events, there's something for everyone. Mark your calendars and join us to stay ahead in the evolving world of software supply chain security. Stay informed about upcoming events and developments at Anchore by bookmarking our Events Page and checking back regularly! ### We migrated from S3 to R2. Thankfully nobody noticed Sometimes, the best changes are the ones that you don’t notice. Well, some of you reading this may not have noticed, but there’s a good chance that many of you did notice a hiccup or two in Grype database availability that suddenly became a lot more stable. One of the greatest things about Anchore, is that we are empowered to make changes quickly when needed. This is the story about doing just that: identifying issues in our database distribution mechanism and making a change to improve the experience for all our users. A Heisenbug is born It all started some time ago, in a galaxy far away. As early as 2022, when we received reports that some users had issues downloading the Grype database. These issues included general slowness and timeouts, with users receiving the dreaded: context deadline exceeded; and manually downloading the database from a browser could show similar behavior: Debugging these transient single issues among thousands of legitimate, successful downloads was problematic for the team, as no one could reproduce these reliably, so it remained unclear what the cause was. A few more reports trickled in here and there, but everything seemed to work well whenever we tested this ourselves. Without further information, we had to chalk this up to something like unreliable network transfers in specific regions or under certain conditions, exacerbated by the moderately large size of the database: about 200 MB, compressed. To determine any patterns or provide feedback to our CDN provider that users are having issues downloading the files, we set up a job to download the database periodically, adding DataDog monitoring across many regions to do the same thing. We noticed a few things: periodic and regular issues downloading the database, and the failures seemed to correlate to high-volume periods – just after a new database was built, for example. We continued monitoring these, but the intermittent failures didn’t seem frequent enough to cause great concern. Small things matter At some point leading up to August, we also began to get reports of users experiencing issues downloading the Grype database listing file. When Grype downloads the database, it first downloads a listing file to determine if a newer database exists. At the time, this file contained a historical record of 450 databases worth of metadata (90 days × each of the 5 Grype database versions), so the listing file clocked in around 200 KB.  Grype only really needs the latest database, so the first thing we did was trim this file down to only the last few days; once we shrunk this file to under 5k, the issues downloading the listing file itself went away. This was our first clue about the problem: smaller files worked fine. Fast forward to August 16, 2024: we awoke to multiple reports from people worldwide indicating they had the same issues downloading the database. We finally started to see the same thing ourselves after many months of being unable to reproduce the failures meaningfully. What happened? We had reached an inflection point of traffic that was causing issues with the CDN being able to deliver these files reliably to end users. Interestingly, the traffic was not from Grype but rather from Syft invocations checking for application updates: 1 million times per hour – approximately double what we saw previously, and this amount of traffic was beginning to affect users of Grype adversely - since they were served from the same endpoint, possibly due to the volume causing some throttling by the CDN provider. The right tool for the job As a team, we had individually investigated these database failures, but we decided it was time for all of us to strap on our boots and solve this. The clue we had from decreasing the size of the listing file was crucial to understanding what was going on. We were using a standard CDN offering backed by AWS S3 storage.  Finding documentation about the CDN usage resulted in vague information that didn't help us understand if we were decidedly doing something wrong or not. However, much of the documentation was evident in that it talked about web traffic, and we could assume this is how the service is optimized based on our experience with a more web-friendly sized listing file. After much reading, it started to sound like larger files should be served using the Cloudflare R2 Object Storage offering instead… So that's what we did: the team collaborated via a long, caffeine-fuelled Zoom call over an entire day. We updated our database publishing jobs to additionally publish databases and updated listing files to a second location backed by the Cloudflare R2 Object Storage service, served from grype.anchore.io instead of toolbox-data.anchore.io/grype.  We verified this was working as expected with Grype and finally updated the main listing file to point to this new location. The traffic load moved to the new service precisely as expected. This was completely transparent for Grype end-users, and our monitoring jobs have been green since! While this wasn’t fun to scramble to fix, it’s great to know that our tools are popular enough to cause problems with a really good CDN service. Because of all the automated testing we have in place, our autonomy to operate independently, and robust publishing jobs, we were able to move quickly to address these issues. After letting this change operate over the weekend, we composed a short announcement for our community discourse to keep everyone informed.  Many projects experience growing pains as they see increased usage; our tools are no exception. Still, we were able almost seamlessly to provide everyone with a more reliable experience quickly and have had reports that the change has solved issues for them. Hopefully, we won’t have to make any more changes even when usage grows another 100x… If you have any feedback for the Syft & Grype developers, head over to our community discourse. ### Expert Series: Solving Real-World Challenges in FedRAMP Compliance ### How to build an OSS risk management program In previous blog posts we have covered the risks of open source software (OSS) and security best practices to manage that risk. From there we zoomed in on the benefits of tightly coupling two of those best practices (SBOMs and vulnerability scanning).  Now, we'll dig deeper into the practical considerations of integrating this paired solution into a DevSecOps pipeline. By examining the design and implementation of SBOMs and vulnerability scanning, we'll illuminate the path to creating a holistic open source software (OSS) risk management program. Learn about the role that SBOMs for the security of your organization in this white paper. Download Now How do I integrate SBOM management and vulnerability scanning into my development process? Ideally, you want to generate an SBOM at each stage of the software development process (see image below). By generating an SBOM and scanning for vulnerabilities at each stage, you unlock a number of novel use-cases and benefits that we covered previously. Let's break down how to integrate SBOM generation and vulnerability scanning into each stage of the development pipeline: Source (PLAN & CODE) The easiest way to integrate SBOM generation and vulnerability scanning into the design and coding phases is to provide CLI (command-line interface) tools to your developers. Engineers are already used to these tools—and have a preference for them! If you're going the open source route, we recommend both Syft (SBOM generation) and Grype (vulnerability scanner) as easy options to get started. If you're interested in an integrated enterprise tool then you'll want to look at AnchoreCTL. Developers can generate SBOMs and run vulnerability scans right from the workstation. By doing this at design or commit time developers can shift security left and know immediately about security implications of their design decisions. If existing vulnerabilities are found, developers can immediately pivot to OSS dependencies that are clean or start a conversation with their security team to understand if their preferred framework will be a deal breaker. Either way, security risk is addressed early before any design decisions are made that will be difficult to roll back. Build (BUILD + TEST) The ideal location to integrate SBOM generation and vulnerability scanning during the build and test phases are directly into the organization's continuous integration (CI) pipeline. The same self-contained CLI tools used during the source stage are integrated as additional steps into CI scripts/runbooks. When a developer pushes a commit that triggers the build process, the new steps are executed and both an SBOM and vulnerability scan are created as outputs.  Check out our docs site to see how AnchoreCTL (running in distributed mode) makes this integration a breeze. If you're having trouble convincing your developers to jump on the SBOM train, we recommend that developers think about all security scans as just another unit test that is part of their testing suite. Running these steps in the CI pipeline delays feedback a little versus performing the check as incremental code commits are made as an application is being coded but it is still light years better than waiting till a release is code complete.  If you are unable to enforce vulnerability scanning of OSS dependencies by your engineering team, a CI-based strategy can be a good happy medium. It is much easier to ensure every build runs exactly the same each time than it is to do the same for developers. Release (aka Registry) Another integration option is the container registry. This option will require you to either roll your own service that will regularly call the registry and scan new containers or use a service that does this for you. See how Anchore Enterprise can automate this entire process by reviewing our integration docs. Regardless of the path you choose, you will end up creating an IAM service account within your CI application which will give your SBOM and vulnerability scanning solution the access to your registries. The release stage tends to be fairly far along in the development process and is not an ideal location for these functions to run. Most of the benefits of a shift left security posture won't be available anymore. If this is an additional vulnerability scanning stage—rather than the sole stage—then this is a fantastic environment to integrate into. Software supply chain attacks that target registries are popular and can be prevented with a continuous scanning strategy. Deploy This is the traditional stage of the SDLC (software development lifecycle) to run vulnerability scans. SBOM generation can be added on as another step in an organization's continuous deployment (CD) runbook. Similar to the build stage, the best integration method is by calling CLI tools directly in the deploy script to generate the SBOM and then scan it for vulnerabilities. Alternatively, if you utilize a container orchestrator like Kubernetes you can also configure an admission controller to act as a deployment gate. The admissions controller should be configured to make a call out to a standalone SBOM generator and vulnerability scanner.  If you'd like to understand how this is implemented with Anchore Enterprise, see our docs. While this is the traditional location for running vulnerability scans, it is not recommended that this is the only stage to scan for vulnerabilities. Feedback about security issues would be arriving very late in the development process and prior design decisions may prevent vulnerabilities from being easily remediated. Don't do this unless you have no other option. Production (OPERATE + MONITOR) This is not a traditional stage to run vulnerability scans since the goal is to prevent vulnerabilities from getting to production. Regardless, this is still an important environment to scan. Production containers have a tendency to drift from their pristine build states (DevSecOps pipelines are leaky!). Also, new vulnerabilities are discovered all of the time and being able to prioritize remediation efforts to the most vulnerable applications (i.e., runtime containers) considerably reduces the risk of exploitation. The recommended way to run SBOM generation and vulnerability scans in production is to run an independent container with the SBOM generator and vulnerability scanner installed. Most container orchestrators have SDKs that will allow you to integrate an SBOM generator and vulnerability scanner to the preferred administration CLI (e.g., kubectl for k8s clusters).  Read how Anchore Enterprise integrates these components together into a single container for both Kubernetes and Amazon ECS. How do I manage all of the SBOMs and vulnerability scans? Tightly coupling SBOM generation and vulnerability scanning creates a number of benefits but it also creates one problem; a firehose of data. This unintended side effect is named SBOM sprawl and it inevitably becomes a headache in and of itself. The concise solution to this problem is to create a centralized SBOM repository. The brevity of this answer downplays the challenges that go along with building and managing a new data pipeline. We'll walk you through the high-level steps below but if you're looking to understand the challenges and solutions of SBOM sprawl in more detail, we have a separate article that covers that. Integrating SBOMs and vulnerability scanning for better OSS risk management Assuming you've deployed an SBOM generator and vulnerability scanner into at least one of your development stages (as detailed above in "How do I integrate SBOM management and vulnerability scanning into my development process?") and have an SBOM repository for storing your SBOMs and/or vulnerability scans, we can now walkthrough how to tie these systems together. Create a system to pull vulnerability feeds from reputable sources. If you’re looking for a way to get started here, read our post on how to get started. Regularly scan your catalog of SBOMs for vulnerabilities, storing the results alongside the SBOMs. Implement a query system to extract insights from your inventory of SBOMs. Create a dashboard to visualize your software supply chain’s health. Build alerting automation to ping your team as newly discovered vulnerabilities are announced. Maintain all of these DIY security applications and tools.  Continue to incrementally improve on these tools as new threats emerge, technologies evolve and development processes change. If this feels like more work than you're willing to take on, this is why security vendors exist. See the benefits of a managed SBOM-powered SCA below. Prefer not to DIY? Evaluate Anchore Enterprise Anchore Enterprise was designed from the ground up to provide a reliable software supply chain security platform that requires the least amount of work to integrate and maintain. Included in the product is: Out-of-the-box integrations for popular CI/CD software (e.g., GitHub, Jenkins, GitLab, etc.) End-to-end SBOM management Enterprise-grade vulnerability scanning with best-in-class false positives Built-in SBOM drift detection Remediation recommendations Continuous visibility and monitoring of software supply chain health Enterprises like NVIDIA, Cisco, Infoblox, etc. have chosen Anchore Enterprise as their "easy button" to achieve open source software security with the least amount of lift. If you're interested to learn more about how to roll out a complete OSS security solution without the blood, sweat and tears that come with the DIY route—reach out to our team to get a demo or try Anchore Enterprise yourself with a 15-day free trial. Learn the container security best practices to reduce the risk of software supply chain attacks. Download Now ### Accelerate FedRAMP Compliance on Amazon EKS with Anchore ### TD Synnex Inspire ### All Things Open Conference ### SBOMs and Vulnerability Management: OSS Security in the DevSecOps Era The rise of open-source software (OSS) development and DevOps practices has unleashed a paradigm shift in OSS security. As traditional approaches to OSS security have proven inadequate in the face of rapid development cycles, the Software Bill of Materials (SBOM) has re-made OSS vulnerability management in the era of DevSecOps. This blog post zooms in on two best practices from our introductory article on OSS security and the software supply chain: Maintain a Software Dependency Inventory Implement Vulnerability Scanning These two best practices are set apart from the rest because they are a natural pair. We'll cover how this novel approach, Scaled OSS vulnerability management under the pressure of rapid software delivery Is set apart from legacy SCAs Unlocks new use-cases in software supply chain security, OSS risk management, etc. Benefits software engineering orgs Benefits an organization's overall security posture Has measurably impacted modern enterprises, such as, NVIDIA, Infoblox, etc. Whether you're a seasoned DevSecOps professional or just beginning to tackle the challenges of securing your software supply chain, this blog post offers insights into how SBOMs and vulnerability management can transform your approach to OSS security. Learn about the role that SBOMs for the security of your organization in this white paper. Download Now Why do I need SBOMs for OSS vulnerability management? The TL;DR is SBOMs enabled DevSecOps teams to scale OSS vulnerability management programs in a modern, cloud native environment. Legacy security tools (i.e., SCA platforms) weren't built to handle the pace of software delivery after a DevOps face lift. Answering this question in full requires some historical context. Below is a speed-run of how we got to a place where SBOMs became the clear solution for vulnerability management after the rise of DevOps and OSS; the original longform is found on our blog. If you're not interested in a history lesson, skip to the next section, "What new use-cases are unlocked with a software dependency inventory?" to get straight to the impact of this evolution on software supply chain security (SSCS). A short history on software composition analysis (SCA) SCAs were originally designed to solve the problem of OSS licensing risk Remember that Microsoft made a big fuss about the dangers of OSS at the turn of the millennium Vulnerability scanning and management was tacked-on later These legacy SCAs worked well enough until DevOps and OSS popularity hit critical mass How the rise of OSS and DevOps principles broke legacy SCAs DevOps and OSS movements hit traction in the 2010s Software development and delivery transitioned from major updates with long development times to incremental updates with frequent releases Modern engineering organizations are measured and optimized for delivery speed Legacy SCAs were designed to scan a golden image once and take as much as needed to do it; upwards of weeks in some cases This wasn't compatible with the DevOps promise and created friction between engineering and security This meant not all software could be scanned and much was scanned after release increasing the risk of a security breach SBOMs as the solution SBOMs were introduced as a standardized data structure that comprised a complete list of all software dependencies (OSS or otherwise) These lightweight files created a reliable way to scan software for vulnerabilities without the slow performance of scanning the entire application—soup to nuts Modern SCAs utilize SBOMs as the foundational layer to power vulnerability scanning in DevSecOps pipelines SBOMs + SCAs deliver on the performance of DevOps without compromising security What is the difference between SBOMs and legacy SCA scanning? SBOMs offer two functional innovations over the legacy model:  Deeper visibility into an organization's application inventory and;  A record of changes to applications over-time. The deeper visibility comes from the fact that modern SCA scanners identify software dependencies recursively and build a complete software dependency tree (both direct and transitive). The record of changes comes from the fact that the OSS ecosystem has begun to standardize the contents of SBOMs to allow interoperability between OSS consumers and producers. Legacy SCAs typically only scan for direct software dependencies and don't recursively scan for dependencies of dependencies. Also, legacy SCAs don't generate standardized scans that can then be used to track changes over time. What new use-cases are unlocked with an SBOM inventory? The innovations brought by SBOMs (see above) have unlocked new use-cases that benefit both the software supply chain security niche and the greater DevSecOps world. See the list below: OSS Dependency Drift Detection Ideally software dependencies are only injected in source code but the reality is that CI/CD pipelines are leaky and both automated and one-off modifications are made at all stages of development. Plugging 100% of the leaks is a strategy with diminishing returns. Application drift detection is a scalable solution to this challenge. SBOMs unlocks drift detection by creating a point-in-time record on the composition of an application at each stage of the development process. This creates an auditable record of when software builds are modified; how they are changed and who changed it.  Software Supply Chain Attack Detection Not all dependency injections are performed by benevolent 1st-party developers. Malicious threat actors who gain access to your organization's DevSecOps pipeline or the pipeline of one of your OSS suppliers can inject malicious code into your applications. An SBOM inventory creates the historical record that can identify anomalous behavior and catch these security breaches before organizational damage is done. This is a particularly important strategy for dealing with advanced persistent threats (APTs) that are expert at infiltration and stealth. For a real-world example, see our blog on the recent XZ supply chain attack. OSS Licensing Risk Management OSS licenses are currently undergoing the beginning of a new transformation. The highly permissive licenses that came into fashion over the last 20 years are proving to be unsustainable. As prominent open source startups amend their licenses (e.g., Hashicorp, Elastic, Redis, etc.), organizations need to evaluate these changes and how it impacts their OSS supply chain strategy. Similar to the benefits during a security incident, an SBOM inventory acts as the source of truth for OSS licensing risk. As licenses are amended, an organization can quickly evaluate their risk by querying their inventory and identifying who their "critical" OSS suppliers are.  Domain Expertise Risk Management Another emerging use-case of software dependency inventories is the management of domain expertise of developers in your organization. A comprehensive inventory of software dependencies allows organization's to map critical software to individual employee's domain knowledge. This creates a measurement of how well resourced your engineering organization is and who owns the knowledge that could impact business operations. While losing an employee with a particular set of skills might not have the same urgency as a security incident, over time this gap can create instability. An SBOM inventory allows organizations to maintain a list of critical OSS suppliers and get ahead of any structural risks in their organization. What are the benefits of a software dependency inventory? SBOM inventories create a number of benefits for tangential domains, such as, software supply chain security, risk management, etc. but there is one big benefit for the core practices of software development. Reduced engineering and QA time for debugging A software dependency inventory stores metadata about applications and their OSS dependencies over-time in a centralized repository. This datastore is a simple and efficient way to search and answer critical questions about the state of an organization's software development pipeline. Previously, engineering and QA teams had to manually search codebases and commits in order to determine the source of a rogue dependency being added to an application. A software dependency inventory combines a centralized repository of SBOMs with an intuitive search interface. Now, these time consuming investigations can be accomplished in minutes versus hours. What are the benefits of scanning SBOMs for vulnerabilities? There are a number of security benefits that can be achieved by integrating SBOMs and vulnerability scanning. We've highlighted the most important below: Reduce risk by scaling vulnerability scanning for complete coverage One of the side effects of transitioning to DevOps practices was that legacy SCAs couldn't keep up with the software output of modern engineering orgs. This meant that not all applications were scanned before being deployed to production—a risky security practice! Modern SCAs solved this problem by scanning SBOMs rather than applications or codebases. These lightweight SBOM scans are so efficient that they can keep up with the pace of DevOps output. Scanning 100% of applications reduces risk by preventing unscanned software from being deployed into vulnerable environments. Prevent delays in software delivery Overall organizational productivity can be increased by adopting modern, SBOM-powered SCAs that allow organizations to shift security left. When vulnerabilities are uncovered during application design, developers can make informed decisions about the OSS dependencies that they choose.  This prevents the situation where engineering creates a new application or feature but right before it is deployed into production the security team scans the dependencies and finds a critical vulnerability. These last minute security scans can delay a release and create frustration across the organization. Scanning early and often prevents this productivity drain from occurring at the worst possible time. Reduced financial risk during a security incident The faster a security incident is resolved the less risk that an organization is exposed to. The primary metric that organizations track is called mean-time-to-recovery (MTTR). SBOM inventories are utilized to significantly reduce this metric and improve incident outcomes. An application inventory with full details on the software dependencies is a prerequisite for rapid security response in the event of an incident. A single SQL query to an SBOM inventory will return a list of all applications that have exploitable dependencies installed. Recent examples include Log4j and XZ. This prevents the need for manual scanning of codebases or production containers. This is the difference between a zero-day incident lasting a few hours versus weeks. Reduce hours spent on compliance with automation Compliance certifications are powerful growth levers for organizations; they open up new market opportunities. The downside is that they create a lot of work for organizations. Manually confirming that each compliance control is met and providing evidence for the compliance officer to review discourages organizations from pursuing these certifications. Providing automated vulnerability scans from DevSecOps pipelines that integrate SBOM inventories and vulnerability scanners significantly reduces the hours needed to generate and collect evidence for compliance audits. How impactful are these benefits? Many modern enterprises are adopting SBOM-powered SCAs and reaping the benefits outlined above. The quantifiable benefits to any organization are unique to that enterprise but anecdotal evidence is still helpful when weighing how to prioritize a software supply chain security initiative, like the adoption of an SBOM-powered SCA against other organizational priorities. As a leading SBOM-powered SCA, Anchore has helped numerous organizations achieve the benefits of this evolution in the software industry. To get an estimate of what your organization can expect, see the case studies below: NVIDIA Reduced time to production by scanning SBOMs instead of full applications Scaled vulnerability scanning and management program to 100% coverage across 1000s of containerized applications and 100,000s of containers Read the full NVIDIA case study here >> Infoblox 75% reduction in engineering hours spent performing manual vulnerability detection 55% reduction in hours allocated to retroactive remediation of vulnerabilities 60% reduction in hours spent on manual compliance discovery and documentation Read the full Infoblox case study here >> DreamFactory 75% reduction in engineering hours spent on vulnerability management and compliance 70% faster production deployments with automated vulnerability scanning and management Read the full DreamFactory case study here >> Next Steps Hopefully you now have a better understanding of the power of integrating an SBOM inventory into OSS vulnerability management. This "one-two" combo has unlocked novel use-cases, numerous benefits and measurable results for modern enterprises. If you're interested in learning more about how Anchore can help your organization achieve similar results, reach out to our team. Learn the container security best practices to reduce the risk of software supply chain attacks. Download Now ### DreamFactory Achieves 75% Time Savings with Anchore: A Case Study in Secure API Generation As the popularity of APIs has swept the software industry, API security has become paramount, especially for organizations in highly regulated industries. DreamFactory, an API generation platform serving the defense industry and critical national infrastructure, 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 trust. Challenge: Security Across the Gap DreamFactory encountered several critical hurdles in meeting the needs of its high-profile clients, particularly those in the defense community and other highly regulated sectors: Secure deployments without cloud connectivity: Many clients, including the Department of Defense (DoD), required on-premises deployments with air-gapping, breaking the assumptions of modern cloud-based security strategies. Air-gapped vulnerability scans: Despite air-gapping, these organizations still demanded comprehensive vulnerability reporting to protect their sensitive data. Building high-trust partnerships: In industries where security breaches could have catastrophic consequences, establishing trust rapidly was crucial. As Terence Bennett, CEO of DreamFactory, explains, "The data processed by these organizations have the highest national security implications. We needed a solution that could deliver bulletproof security without cloud connectivity." Solution: Anchore Enterprise On-Prem and Air-Gapped  To address these challenges, DreamFactory implemented Anchore Enterprise, which provided: Support for on-prem and air-gapped deployments: Anchore Enterprise was designed to operate in air-gapped environments, aligning perfectly with DreamFactory's needs. Comprehensive vulnerability scanning: DreamFactory integrated Anchore Enterprise into its build pipeline, running daily vulnerability scans on all deployment versions. Automated SBOM generation and management: Every build is now cataloged and stored (as an SBOM), providing immediate transparency into the software's components. "By catching vulnerabilities in our build pipeline, we can inform our customers and prevent any of the APIs created by a DreamFactory install from being leveraged to exploit our customer's network," Bennett notes. "Anchore has helped us achieve this massive value-add for our customers." Results: Developer Time Savings and Enhanced Trust The implementation of Anchore Enterprise transformed DreamFactory's security posture and business operations: 75% reduction in time spent on vulnerability management and compliance requirements 70% faster production deployments with integrated security checks Rapid trust development through transparency "We're seeing a lot of traction with data warehousing use-cases," says Bennett. "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'." Conclusion: A Competitive Edge in High-Stakes Environments 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 generation solutions. In an era where API security is more critical than ever, DreamFactory's success story demonstrates that with the right tools and approach, it's possible to achieve both ironclad security and operational efficiency. Download Now Are you facing similar challenges hardening your software supply chain in order to meet the requirements of the DoD? By designing your DevSecOps pipeline to the DoD software factory standard, your organization can guarantee to meet these sky-high security and compliance requirements. Learn more about the DoD software factory standard by downloading our white paper below. Download Now ### How is Open Source Software Security Managed in the Software Supply Chain? Open source software has revolutionized the way developers build applications, offering a treasure trove of pre-built software "legos" that dramatically boost productivity and accelerate innovation. By leveraging the collective expertise of a global community, developers can create complex, feature-rich applications in a fraction of the time it would take to build everything from scratch. However, this incredible power comes with a significant caveat: the open source model introduces risk. Organizations inherit both the good and bad parts of the OSS source code they don't own. This double-edged sword of open source software necessitates a careful balance between harnessing its productivity benefits and managing the risks. A comprehensive OSS security program is the industry standard best practice for managing the risk of open source software within an organization's software supply chain. Learn the container security best practices to reduce the risk of software supply chain attacks. Download Now What is open source software security? Open source software security is the ecosystem of security tools (some of it being OSS!) that have developed to compensate for the inherent risk of OSS development. The security of the OSS environment was founded on the idea that "given enough eyeballs, all bugs are shallow". The reality of OSS is that the majority of it is written and maintained by single contributors. The percentage of open source software that passes the qualifier of "enough eyeballs" is miniscule. Does that mean open source software isn't secure? Fortunately, no. The OSS community still produces secure software but an entire ecosystem of tools ensure that this is verified—not only trusted implicitly. What is the difference between closed source and open source software security? The primary difference between open source software security and closed source software security is how much control you have over the source code. Open source code is public and can have many contributors that are not employees of your organization while proprietary source code is written exclusively by employees of your organization. The threat models required to manage risk for each of these software development methods are informed by these differences. Due to the fact that open source software is publicly accessible and can be contributed to by a diverse, often anonymous community, its threat model must account for the possibility of malicious code contributions, unintentional vulnerabilities introduced by inexperienced developers, and potential exploitation of disclosed vulnerabilities before patches are applied. This model emphasizes continuous monitoring, rigorous code review processes, and active community engagement to mitigate risks.  In contrast, proprietary software's threat model centers around insider threats, such as disgruntled employees or lapses in secure coding practices, and focuses heavily on internal access controls, security audits, and maintaining strict development protocols.  The need for external threat intelligence is also greater in OSS, as the public nature of the code makes it a target for attackers seeking to exploit weaknesses, while proprietary software relies on obscurity and controlled access as a first line of defense against potential breaches. What are the risks of using open source software? Vulnerability exploitation of your application The bargain that is struck when utilizing OSS is your organization gives up significant amounts of control of the quality of the software. When you use OSS you inherit both good AND bad (read: insecure) code. Any known or latent vulnerabilities in the software become your problem. Access to source code increases the risk of vulnerabilities being discovered by threat actors OSS development is unique in that both the defenders and the attackers have direct access to the source code. This gives the threat actors a leg up. They don't have to break through perimeter defenses before they get access to source code that they can then analyze for vulnerabilities. Increased maintenance costs for DevSecOps function Adopting OSS into an engineering organization is another function that requires management. Data has to be collected about the OSS that is embedded in your applications. That data has to be stored and made available in case of the event of a security incident. These maintenance costs are typically incurred by the DevOps and Security teams. OSS license legal exposure OSS licenses are mostly permissive for use within commercial applications but a non-trivial subset are not, or worse they are highly adversarial when used by a commercial enterprise. Organizations that don't manage this risk increase the potential for legal action to be taken against them. How serious are the risks associated with the use of open source software? Current estimates are that 70-90% of modern applications are composed of open source software. This means that only 10-30% of applications developed by organizations are written by developers employed by the organization. Without having significant visibility into the security of OSS, organization's are handing over the keys to the castle to the community and hoping for the best. Not only is OSS a significant footprint in modern application composition but its growth is accelerating. This means the associated risks are growing just as fast. This is part of the reason we see an acceleration in the frequency of software supply chain attacks. Organizations that aren't addressing these realities are getting caught on their back foot when zero-days are announced like the recent XZ utils backdoor. Why are SBOMs important to open source software security? Software Bills of Materials (SBOMs) serve as the foundation of software supply chain security by providing a comprehensive "ingredient list" of all components within an application. This transparency is crucial in today's software landscape, where modern applications are a complex web of mostly open source software dependencies that can harbor hidden vulnerabilities.  SBOMs enable organizations to quickly identify and respond to security threats, as demonstrated during incidents like Log4Shell, where companies with centralized SBOM repositories were able to locate vulnerable components in hours rather than days. By offering a clear view of an application's composition, SBOMs form the bedrock upon which other software supply chain security measures can be effectively built and validated. The importance of SBOMs in open source software security cannot be overstated. Open source projects often involve numerous contributors and dependencies, making it challenging to maintain a clear picture of all components and their potential vulnerabilities. By implementing SBOMs, organizations can proactively manage risks associated with open source software, ensure regulatory compliance, and build trust with customers and partners.  SBOMs enable quick responses to newly discovered vulnerabilities, facilitate automated vulnerability management, and support higher-level security abstractions like cryptographically signed images or source code. In essence, SBOMs provide the critical knowledge needed to navigate the complex world of open source dependencies by enabling us to channel our inner GI Joe—"knowing is half the battle" in software supply chain security. Best practices for securing open source software? Open source software has become an integral part of modern development practices, offering numerous benefits such as cost-effectiveness, flexibility, and community-driven innovation. However, with these advantages come unique security challenges. To mitigate risks and ensure the safety of your open source components, consider implementing the following best practices: 1. Model Security Scans as Unit Tests Re-branding security checks as another type of unit test helps developers orient to DevSecOps principles. This approach helps developers re-imagine security as an integral part of their workflow rather than a separate, post-development concern. By modeling security checks as unit tests, you can: Catch vulnerabilities earlier in the development process Reduce the time between vulnerability detection and remediation Empower developers to take ownership of security issues Create a more seamless integration between development and security teams Remember, the goal is to make security an integral part of the development process, not a bottleneck. By treating security checks as unit tests, you can achieve a balance between rapid development and robust security practices. 2. Review Code Quality Assessing the quality of open source code is crucial for identifying potential vulnerabilities and ensuring overall software reliability. Consider the following steps: Conduct thorough code reviews, either manually or using automated tools Look for adherence to coding standards and best practices Look for projects developed with secure-by-default principles Evaluate the overall architecture and design patterns used Remember, high-quality code is generally more secure and easier to maintain. 3. Assess Overall Project Health A vibrant, active community and committed maintainers are crucial indicators of a well-maintained open source project. When evaluating a project's health and security: Examine community involvement: Check the number of contributors and frequency of contributions Review the project's popularity metrics (e.g., GitHub stars, forks, watchers) Assess the quality and frequency of discussions in forums or mailing lists Evaluate maintainer(s) commitment: Check the frequency of commits, releases, and security updates Check for active engagement between maintainers and contributors Review the time taken to address reported bugs and vulnerabilities Look for a clear roadmap or future development plans 4. Maintain a Software Dependency Inventory Keeping track of your open source dependencies is crucial for managing security risks. To create and maintain an effective inventory: Use tools like Syft or Anchore SBOM to automatically scan your application source code for OSS dependencies Include both direct and transitive dependencies in your scans Generate a Software Bill of Materials (SBOM) from the dependency scan Your dependency scanner should also do this for you Store your SBOMs in a central location that can be searched and analyzed Scan your entire DevSecOps pipeline regularly (ideally every build and deploy) An up-to-date inventory allows for quicker responses to newly discovered vulnerabilities. 5. Implement Vulnerability Scanning Regular vulnerability scanning helps identify known security issues in your open source components. To effectively scan for vulnerabilities: Use tools like Grype or Anchore Secure to automatically scan your SBOMs for vulnerabilities Automate vulnerability scanning tools directly into your CI/CD pipeline At minimum implement vulnerability scanning as containers are built Ideally scan container registries, container orchestrators and even each time a new dependency is added during design Set up alerts for newly discovered vulnerabilities in your dependencies Establish a process for addressing identified vulnerabilities promptly 6. Implement Version Control Best Practices Version control practices are crucial for securing all DevSecOps pipelines that utilize open source software: Implement branch protection rules to prevent unauthorized changes Require code reviews and approvals before merging changes Use signed commits to verify the authenticity of contributions By implementing these best practices, you can significantly enhance the security of your software development pipeline and reduce the risk intrinsic to open source software. By doing this you will be able to have your cake (productivity boost of OSS) and eat it too (without the inherent risk). How do I integrate open source software security into my development process? DIY a comprehensive OSS security system We've written about the steps to build a OSS security system from scratch in a previous blog post—below is the TL;DR: Integrate dependency scanning, SBOM generation and vulnerability scanning into your DevSecOps pipeline Implement a data pipeline to manage the influx of security metadata Use automated policy-as-code "security tests" to provide rapid feedback to developers Automate remediation recommendations to reduce cognitive load on developers Outsource OSS security to a turnkey vendor Modern software composition analysis (SCA) tools, like Anchore Enterprise, are purpose built to provide you with a comprehensive OSS security system out-of-the-box. All of the same features of DIY but without the hassle of building while maintaining your current manual process. Anchore SBOM: comprehensive dependency scanning, SBOM generation and management Anchore Secure: vulnerability scanning and management Anchore Enforce: automated security enforcement and compliance Whether you want to scale an understaffed security to increase their reach across your organization or free your team up to focus on different priorities, the buy versus build opportunity cost is a straightforward decision. Next Steps Hopefully, you now have a strong understanding of the risks associated with adopting open source software. If you're looking to continue your exploration into the intricacies of software supply chain security, Anchore has a catalog of deep dive content on our website. If you'd prefer to get your hands dirty, we also offer a 15-day free trial of Anchore Enterprise. Learn about the role that SBOMs for the security of your organization in this white paper. Download Now ### SSDF Attestation Template: Battle-tested Compliance Guidance The CISA Secure Software Development Attestation form, commonly referred to as, SSDF attestation, was released earlier this year and with any new compliance framework, knowing the exact wording and details to provide in order to meet the compliance requirements can be difficult. We feel you here. Anchore is heavily invested in the public sector and had to generate our own SSDF attestation for our platform, Anchore Enterprise. Having gone through the process ourselves and working with a number of customers that requested our expertise on this matter, we developed a document that helps you put together an SSDF attestation that will make a compliance officer's heart sing. Our goal with this document is to make SSDF attestation as easy as possible and demonstrate how Anchore Enterprise is an "easy button" that you can utilize to satisfy the majority of evidence needed to achieve compliance. We have already submitted in our own SSDF attestation and been approved, so we have confidence these answers will help get you over the line. You can find our SSDF attestation guide on our docs site. Explore SSDF attestation in-depth with this eBook. Learn the benefits of the framework and how you can benefit from it. Download Now How do I fill out the SSDF attestation form? This is the difficult part, isn't it? The SSDF attestation form looks very simple at a glance, but it has a number of sections that expect evidence to be attached that details how your organization secures both your development environments and production systems. Like all compliance standards, it doesn't specify what will or won't meet compliance for your organization, hence the importance of the evidence. At Anchore, we both experienced this ourselves and helped our customers navigate this ambiguity. Out of these experiences we created a document that breaks down each item and what evidence was able to achieve compliance without being rejected by a compliance officer. We have published this document on our Docs site for all other organizations to use as a template when attempting to meet SSDF attestation compliance. Structure of the SSDF attestation form The SSDF attestation is divided into 3 sections: Section I The first section is very short, it is where you list the type of attestation you are submitting and information about the product that you are attesting to meeting compliance. Section II This section is also short, the form is collecting contact information. CISA wants to be able to know how to get in contact with your organization and who is responsible for any questions or concerns that need to be addressed. Section III For all intents and purposes, Section III is the SSDF attestation form. This is where you will provide all of the technical supporting information to demonstrate that your organization complies with the requirements set out in the SSDF attestation form.  The guide that Anchore has developed is focused specifically on how to fill out this section in a way that will meet the expectations of CISA compliance officers. Where do I submit the SSDF attestation form? If you are a US government vendor you can submit your organization's completed form on the Repository for Software Attestations and Artifacts. You will need an account that can be requested on the login page. It normally takes a few days for the account to be created. Be sure to give yourself at least a week for it to be created. This can be done ahead of time while you're gathering the information to fill out your form. It’s also possible you will receive requests directly to pass along the form. Not every agency will use the repository. It's even possible you will have non-government customers asking for the form. While it’s being mandated by the government, there’s a lot of good evidence in the document. What tooling do I need to meet SSDF attestation compliance? There are many ways in order to meet the technical requirements of SSDF attestation but there is also a well worn path. Anchore utilizes modern DevSecOps practices and assumes that the majority of our customers do as well. Below is a list of common DevSecOps tools that are typically used to help meet SSDF compliance.  Endpoint Protection Description: Endpoint protection tools secure individual devices (endpoints) that connect to a network. They protect against malware, detect and prevent intrusions, and provide real-time monitoring and response capabilities. SSDF Requirement: [3.1] — "Separating and protecting each environment involved in developing and building software" Examples: Jamf, Elastic, SentinelOne, etc. Source Control Description: Source control systems manage changes to source code over time. They help track modifications, facilitate collaboration among developers, and maintain different versions of code. SSDF Requirement: [3.1] — "Separating and protecting each environment involved in developing and building software" Examples: GitHub, GitLab, etc. CI/CD Build Pipeline Description: Continuous Integration/Continuous Deployment (CI/CD) pipelines automate the process of building, testing, and deploying software. They help ensure consistent and reliable software delivery. SSDF Requirement: [3.1] — "Separating and protecting each environment involved in developing and building software" Examples: Jenkins, GitLab, GitHub Actions, etc. Single Sign-on (SSO) Description: SSO allows users to access multiple applications with one set of login credentials. It enhances security by centralizing authentication and reducing the number of attack vectors. SSDF Requirement: [3.1] — "Enforcing multi-factor authentication and conditional access across the environments relevant to developing and building software in a manner that minimizes security risk;" Examples: Okta, Google Workspace, etc. Security Event and Incident Management (SEIM) Description: Monitoring tools provide real-time visibility into the performance and security of systems and applications. They can detect anomalies, track resource usage, and alert on potential issues. SSDF Requirement: [3.1] — "Implementing defensive cybersecurity practices, including continuous monitoring of operations and alerts and, as necessary, responding to suspected and confirmed cyber incidents;" Examples: Elasticsearch, Splunk, Panther, RunReveal, etc. Audit Logging Description: Audit logging captures a record of system activities, providing a trail of actions performed within the software development and build environments. SSDF Requirement: [3.1] — "Regularly logging, monitoring, and auditing trust relationships used for authorization and access: i) to any software development and build environments; and ii) among components within each environment;" Examples: Typically a built-in feature of CI/CD, SCM, SSO, etc. Secrets Encryption Description: Secrets encryption tools secure sensitive information such as passwords, API keys, and certificates used in the development and build processes. SSDF Requirement: [3.1] — "Encrypting sensitive data, such as credentials, to the extent practicable and based on risk;" Examples: Typically a built-in feature of CI/CD and SCM Secrets Scanning Description: Secrets scanning tools automatically detect and alert on exposed secrets in code repositories, preventing accidental leakage of sensitive information. SSDF Requirement: [3.1] — "Encrypting sensitive data, such as credentials, to the extent practicable and based on risk;" Examples: Anchore Secure or other container security platforms OSS Component Inventory (+ Provenance) Description: These tools maintain an inventory of open-source software components used in a project, including their origins and lineage (provenance). SSDF Requirement: [3.3] — "The software producer maintains provenance for internal code and third-party components incorporated into the software to the greatest extent feasible;" Examples: Anchore SBOM or other SBOM generation and management platform Vulnerability Scanning Description: Vulnerability scanning tools automatically detect security weaknesses in code, dependencies, and infrastructure. SSDF Requirement: [3.4] — "The software producer employs automated tools or comparable processes that check for security vulnerabilities. In addition: a) The software producer operates these processes on an ongoing basis and prior to product, version, or update releases;" Examples: Anchore Secure or other software composition analysis (SCA) platform Vulnerability Management and Remediation Runbook Description: This is a process and set of guidelines for addressing discovered vulnerabilities, including prioritization and remediation steps. SSDF Requirement: [3.4] — "The software producer has a policy or process to address discovered security vulnerabilities prior to product release; and The software producer operates a vulnerability disclosure program and accepts, reviews, and addresses disclosed software vulnerabilities in a timely fashion and according to and timelines specified in the vulnerability disclosure program or applicable policies." Examples: This is not necessarily a tool but an organizational SLA on security operations. For reference Anchore has included a screenshot from our vulnerability management guide. Next Steps If your organization currently provides software services to a federal agency or is looking to in the future, Anchore is here to help you in your journey. Reach out to our team and learn how you can integrate continuous and automated compliance directly into your CI/CD build pipeline with Anchore Enterprise. Learn about the importance of both FedRAMP and SSDF compliance for selling to the federal government. Download Now ### How SBOMs Protect Google's Massive Software Supply Chain ### FedRAMP & FISMA Compliance: Key Differences Explained This blog post has been archived and replaced by the supporting pillar page that can be found here: https://anchore.com/wp-admin/post.php?post=987474188&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. ### Adopting the DoD Software Factory Model: Insights & How Tos ### Billington Cybersecurity Summit ### Anchore at Billington CyberSecurity Summit: Automating Defense in the AI Era Are you gearing up for the 15th Annual Billington CyberSecurity Summit? So are we! The Anchore team will be front and center in the exhibition hall throughout the event, ready to showcase how we're revolutionizing cybersecurity in the age of AI. This year's summit promises to be a banger, highlighting the evolution in cybersecurity as the latest iteration of AI takes center stage. While large language models (LLMs) like ChatGPT have been making waves across industries, the cybersecurity realm is still charting its course in this new AI-driven landscape. But make no mistake – this is no time to rest on our laurels. As blue teams explore innovative ways to harness LLMs, cybercriminals are working overtime to weaponize the same technology. If there's one lesson we've learned from every software and AI hype cycle: automation is key. As adversaries incorporate novel automations into their tactics, defenders must not just keep pace—they need to get ahead. At Anchore, we're all-in with this strategy. The Anchore Enterprise platform is purpose-built to automate and scale cybersecurity across your entire software development lifecycle. By automating continuous vulnerability scanning and compliance in your DevSecOps pipeline, we're equipping warfighters with the tools they need to outpace adversaries that never sleep. Ready to see how Anchore can transform your cybersecurity posture in the AI era? Stop by our booth for a live demo. Don't miss this opportunity to stay ahead of the curve—book a meeting (below) with our team and take the first step towards a more secure tomorrow. Anchore at the Billington CyberSecurity Summit Date: September 3–6, 2024 Location: The Ronald Reagan Building and International Trade Center in Washington, DC Book a meeting Our team is looking forward to meeting you! Book a demo session in advance to ensure a preferred slot. Anchore's Showcase: DevSecOps and Automated Compliance We will be demonstrating the Anchore Enterprise platform at the event. Our showcase will focus on: Software Composition Analysis (SCA) for Cloud-Native Environments: Learn how our tools can help you gain visibility into your software supply chain and manage risk effectively. Automated SBOM Generation and Management: Discover how Anchore simplifies the creation and maintenance of Software Bills of Materials (SBOMs), the foundational component in software supply chain security. Continuous Scanning for Vulnerabilities, Secrets, and Malware: See our advanced scanning capabilities in action, designed to protect your applications across the DevSecOps pipeline or DoD software factory. Automated Compliance Enforcement: Experience how Anchore can streamline compliance with key standards such as cATO, RAISE 2.0,  NIST, CISA, and FedRAMP, saving time and reducing human error. We invite all attendees to visit our booth to learn more about how Anchore's DevSecOps and automated compliance solutions can enhance your organization's security posture in the age of AI and cloud computing. Event Highlights Still on the fence about whether to attend? Here is a quick run-down to help get you off of the fence. This year's summit, themed "Advancing Cybersecurity in the AI Age," will feature more than 40 sessions and breakouts, covering critical topics such as: The increasing impact of artificial intelligence on cybersecurity Cloud security challenges and solutions Proactive approaches to technical risk management Emerging cyber risks and defense strategies Data protection against breaches and insider threats The intersection of cybersecurity and critical infrastructure The event will showcase fireside chats with top government officials, including FBI Deputy Director Paul Abbate, Chairman of the Joint Chiefs of Staff General CQ Brown, Jr., and U.S. Cyber Command Commander General Timothy D. Haugh, among others. Next Steps and Additional Resources Join us at the Billington Cybersecurity Summit to network with industry leaders, gain valuable insights, and explore innovative technologies that are shaping the future of cybersecurity. We look forward to seeing you there! If you are interested in the Anchore Enterprise platform and can't wait till the show, here are some resources to help get you started: Learn about best practices that are setting new standards for security in DoD software factories. Download Now ### Enhancing Software Security: August Webinars on DevSecOps, DoD Software Factories, and CMMC Compliance This August Anchore’s webinar series is coming in hot with blazing hot topics on software development and cybersecurity. Stay informed on the latest trends and best practices with our full docket of live webinars that address critical aspects of software supply chain security, DevSecOps, and compliance. Whether you're interested in adopting the Department of Defense (DoD) software factory model, automating CMMC compliance, or optimizing DevSecOps practices, these webinars offer valuable insights from engineers in the field. WEBINAR: Adopting the DoD Software Factory Model: Insights & How Tos Date: August 13, 2024, 10 am PT | 1 pm ET The DoD software factory model has become a cornerstone of innovation and security in national defense and cybersecurity. This webinar will explore the building blocks needed to successfully adopt a software factory model, drawing insights from both Platform One and Black Pearl. This session is perfect for those looking to enhance their understanding of DoD-compliant software development practices and learn how to implement them effectively. Topics covered will include how to standardize secure software development and deployment along with a demo of Anchore Enterprise's capabilities in automating policy enforcement, security checks, and vulnerability scans. Register Here WEBINAR: Automated Policy Enforcement for CMMC with Anchore Enterprise Date: August 27, 2024, 2-2:30 PM EST For organizations required to comply with the Cybersecurity Maturity Model Certification (CMMC), this webinar will offer crucial insights into automating compliance measures. With CMMC's importance in hardening the cybersecurity posture of the defense industrial base, timely compliance is critical for software vendors that work with the federal government. This webinar is invaluable for teams working to achieve CMMC compliance efficiently and effectively. Attendees will learn about the implementation and automation of compliance controls, how to leverage automation for vulnerability scans along with specific controls automated by Anchore Enterprise for CMMC and NIST. Register Here WEBINAR: DevSecOps Editorial Roundtable Date: August 12, 2024, 1-2pm EST As the software industry increasingly adopts and refines practices for secure software development, optimizing DevSecOps processes has become crucial. This roundtable discussion will bring together application development and cybersecurity experts to explore strategies for shifting application security left in the development process. This webinar is ideal for those looking to enhance their DevSecOps practices and create more robust and efficient software supply chains. Those that attend will gain insights on effective DevSecOps integration without slowing down application deployment and how to optimize security measures that developers will embrace. Register Here Wrap-Up Don't miss these opportunities to deepen your understanding of modern software security topics and learn from industry experts. Each webinar offers unique perspectives and practical strategies that can be applied to improve your organization's approach to software security. Also, if you want to stay up-to-date on all of the events that Anchore hosts or participates in be sure to bookmark our events page and check back often! ### Anchore Awarded DoD ESI DevSecOps Phase II Agreement The Department of Defense (DoD) Enterprise Software Initiative (ESI) has awarded Anchore inclusion in its DevSecOps program, which is part of the ESI's DevSecOps Phase II enterprise agreements. The DoD ESI's main objective is to streamline the acquisition process for software and services across the DoD, in order to gain significant cost savings and improve efficiency. Admittance into the ESI program validates Anchore’s commitment to be a trusted partner to the DoD, delivering advanced container vulnerability scanning as well as SBOM management solutions that meet the most stringent compliance and security requirements. Anchore's inclusion in the DoD ESI DevSecOps Phase II agreement is a testament to our commitment to delivering cutting-edge software supply chain security solutions. This milestone enables us to more efficiently support the DoD's critical missions by providing them with the tools they need to secure their software development pipelines. Our continued partnership with the DoD reinforces Anchore's position as a trusted leader in SBOM-powered DevSecOps and container security.—Tim Zeller, EVP Sales & Marketing The agreements also included DevSecOps luminaries Hashicorp and Rancher Government as well as Cloudbees, Infoblox, GitLab, Crowdstrike, F5 Networks; all are now part of the preferred vendor list for all DoD missions that require cybersecurity solutions, generally, and software supply chain security, specifically. Anchore is steadily growing their presence on federal contracts and catalogues such as Iron Patriot & Minerva, GSA, 2GIT, NASA SEWP, ITES and most recently also JFAC (Joint Federated Assurance Center). What does this mean? Similar to the GSA Advantage marketplace, DoD missions can now procure Anchore through the fully negotiated and approved ESI Agreements on the Solutions for Enterprise-Wide Procurement (SEWP) Marketplace.  Anchore's History with DoD This award continues Anchore's deepening relationship with the DoD. Starting in 2020, the DoD has vetted and approved Anchore's container vulnerability scanning tools. Anchore is named in both the DoD Container Image Creation and Deployment Guide and the DoD Container Hardening Process Guide as recommended solutions. The same year, Anchore was selected by the US Air Force's Platform One to become the software supply chain vendor to implement the best practices in the above guides for all software built on the platform. Read our case study on how Anchore partnered with Platform One to build the premier DevSecOps platform for the DoD. The following year, Anchore won the Small Business Innovation Research (SBIR) Phase III contract with Platform One to integrate directly into the Iron Bank container image process. If your image has achieved Iron Bank certification it is because Anchore's solution has given it a passing grade. Read more about this DevSecOps success story in our case study with the Iron Bank. Due to the success of Platform One within the US Air Force, in 2022 Anchore partnered with the US Navy to secure the Black Pearl DevSecOps platform. Similar to Platform One, Black Pearl is the go-to standard for modern software development within the Department of the Navy (DON) software development. As Anchore continued to expand its relationship with the DoD and federal agencies, its offerings became available for purchase through the online government marketplaces and contracts such as GSA Advantage and Second Generation IT Blanket Purchase Agreements (2GIT), NASA SEWP, Iron Patriot/Minerva, ITES and JFAC. The ESI's DevSecOps Phase II award was built on the back of all of the previous success stories that came before it.  Achieving ATO is now easier with the inclusion of Anchore into the DoD ESI. Read our white paper on DoD software factory best practices to reach cATO or RAISE 2.0 compliance in days versus months. We advise on best practices that are setting new standards for security and efficiency in DoD software factories, such as: Hardening container images, automation for policy enforcement and continuous monitoring for vulnerabilities. Download Now ### Anchore Previews Grype Support for Azure Linux 3.0 The Anchore OSS team was on the Microsoft community call for mariner users last week. At this meeting, we got a chance to demo some new grype capabilities for when Azure Linux 3.0 becomes generally available. The Anchore OSS team builds its vulnerability feeds and data sourcing out in the open. It’s important to note that an update to support a new distro release (or naming migration for past releases) can require pull requests in up to three different repositories. Let’s look at the pull requests supporting this new release of Azure Linux and walk through how we can build a local copy of the demo on our machines. Grype ecosystem changes that support new Linux distributions Here are the three pull requests required to get Azure Linux 3.0 working with grype. Grype-db: this change asserts that the new data shape and data mapping is being done correctly when processing the new Azure Linux 3.0 vulnerability data Vunnel: this change sources the vulnerability data from Microsoft and transforms it into a common scheme that grype-db can distribute Grype: this change adds the base distro types used by grype-db, vunnel, and grype so that matching can be correctly associated with both the old mariner and new Azure Linux 3.0 data For this preview, let’s do a quick walkthrough on how a user could test this new functionality locally and get a grype db for just Azure Linux 3.0 setup. When Azure Linux 3.0 is released as generally available, readers can look forward to a more technical post on how the vunnel and grype-db data pipeline works in GitHub actions, what matching looks like, and how syft/grype can discern the different distribution versions.  Let’s get our demo working locally in anticipation of the coming release! Setting up the Demo To get the demo setup readers will want to make sure they have the following installed: Git to clone and interact with the repositories The latest version of Golang A managed version of Python running at 3.12.x. If you need help getting a managed version of python setup we recommend mise. The poetry python dependency manager  Make is also required as part of developing and bootstrapping commands in the three development environments. After the dev dependencies are installed, clone down the three repositories listed above (grype, grype-db, and vunnel) into a local development folder and checkout the branches listed in the above pull requests. I have included a script to do all this for you below. #!/bin/bash # Define the repositories and the branch REPOS=( "https://github.com/anchore/grype.git" "https://github.com/anchore/grype-db.git" "https://github.com/anchore/vunnel.git" ) BRANCH="feat-azure-linux-3-support" FOLDER="demo" # Create the folder if it doesn't exist mkdir -p "$FOLDER" # Change to the folder cd "$FOLDER" || exit # Clone each repository, checkout the branch, and run make bootstrap for REPO in "${REPOS[@]}"; do # Extract the repo name from the URL REPO_NAME=$(basename -s .git "$REPO") # Clone the repository git clone "$REPO" # Change to the repository directory cd "$REPO_NAME" || exit # Checkout the branch git checkout "$BRANCH" # Run make bootstrap make bootstrap # Special handling for grype-db repository if [ "$REPO_NAME" == "grype-db" ]; then # Add the replace directive to go.mod echo 'replace github.com/anchore/grype v0.78.0 => ../grype' >> go.mod # Run go mod tidy go mod tidy fi # Special handling for grype repository if [ "$REPO_NAME" == "grype" ]; then # Run go mod tidy go mod tidy fi # Change back to the parent folder cd .. done echo "All repositories have been cloned, checked out, and built." Pulling the new Azure Linux 3.0 vulnerability data We will be doing all of our work in the vunnel repository. We needed to pull the other two repositories since vunnel can orchestrate and build those binaries to accomplish its data aggregation goals.  To get all the repositories built and usable in vunnel, run the following commands: cd demo/vunnel poetry shell make dev provider="mariner" make update-db That should produce output similar to the following: Entering vunnel development shell... • Configuring with providers: mariner ... • Writing grype config: ./demo/vunnel/.grype.yaml ... • Writing grype-db config: ./demo/vunnel/.grype-db.yaml ... • Activating poetry virtual env: /Library/Caches/pypoetry/virtualenvs/vunnel-0PTQ8JOw-py3.12 ... • Installing editable version of vunnel ... • Building grype ... • Building grype-db ... mkdir -p ./bin Note: development builds grype and grype-db are now available in your path. To update these builds run 'make build-grype' and 'make build-grype-db' respectively. To run your provider and update the grype database run 'make update-db'. Type 'exit' to exit the development shell. .....Records being processed This should lead to a local vulnerability db being built for just the Azure Linux 3.0 data. You can interact with this data and use the locally built grype to see how the data can be used against an older preview image of Azure Linux 3.0. Let’s run the following command to interact with the new Azure Linux 3.0 data and preview grype against an older dev build of the container image to make sure everything is working correctly: ./bin/grype azurelinuxpreview.azurecr.io/public/azurelinux/base/core:3.0.20240401-amd64 ✔ Loaded image azurelinuxpreview.azurecr.io/public/azurelinux/base/core:3.0.20240401-amd64 ✔ Parsed image sha256:3017b52132fb240b9c714bd09e88c4bc1f8e55860de23c74fe2431b8f75981dd ✔ Cataloged contents 9b4fcfdd3a247b97e02cda6011cd6d6858dcdf98d1f95fb8af54d57d2da89d5f ├── ✔ Packages [75 packages] ├── ✔ File digests [1,495 files] ├── ✔ File metadata [1,495 locations] └── ✔ Executables [380 executables] ✔ Scanned for vulnerabilities [17 vulnerability matches] ├── by severity: 0 critical, 8 high, 7 medium, 2 low, 0 negligible └── by status: 17 fixed, 0 not-fixed, 0 ignored NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY expat 2.5.0-1.azl3 0:2.6.2-1.azl3 rpm CVE-2024-28757 High expat 2.5.0-1.azl3 0:2.6.2-1.azl3 rpm CVE-2023-52425 High expat 2.5.0-1.azl3 0:2.6.2-1.azl3 rpm CVE-2023-52426 Medium expat-libs 2.5.0-1.azl3 0:2.6.2-1.azl3 rpm CVE-2024-28757 High expat-libs 2.5.0-1.azl3 0:2.6.2-1.azl3 rpm CVE-2023-52425 High expat-libs 2.5.0-1.azl3 0:2.6.2-1.azl3 rpm CVE-2023-52426 Medium glibc 2.38-3.azl3 0:2.38-6.azl3 rpm CVE-2023-6779 High glibc 2.38-3.azl3 0:2.38-6.azl3 rpm CVE-2023-6246 High glibc 2.38-3.azl3 0:2.38-6.azl3 rpm CVE-2023-5156 High glibc 2.38-3.azl3 0:2.38-6.azl3 rpm CVE-2023-4911 High glibc 2.38-3.azl3 0:2.38-6.azl3 rpm CVE-2023-6780 Medium libgcc 13.2.0-3.azl3 0:13.2.0-7.azl3 rpm CVE-2023-4039 Medium libstdc++ 13.2.0-3.azl3 0:13.2.0-7.azl3 rpm CVE-2023-4039 Medium openssl 3.1.4-3.azl3 0:3.3.0-1.azl3 rpm CVE-2023-6237 Medium openssl 3.1.4-3.azl3 0:3.3.0-1.azl3 rpm CVE-2024-2511 Low openssl-libs 3.1.4-3.azl3 0:3.3.0-1.azl3 rpm CVE-2023-6237 Medium openssl-libs 3.1.4-3.azl3 0:3.3.0-1.azl3 rpm CVE-2024-2511 Low Updating the image Many vulnerable container images can be remediated by consuming the upstream security team’s fixes. Let’s run the same command against the latest preview version released from Microsoft: ./bin/grype azurelinuxpreview.azurecr.io/public/azurelinux/base/core:3.0 ✔ Loaded image azurelinuxpreview.azurecr.io/public/azurelinux/base/core:3.0 ✔ Parsed image sha256:234cac9f296dd1d336eecde7a97074bec0d691c6fd87bd4ff098b5968e579ce1 ✔ Cataloged contents 9964aca715152fb6b14bfb57be5e27c655fb7d733a33dd995a5ba72157c54ee7 ├── ✔ Packages [76 packages] ├── ✔ File digests [1,521 files] ├── ✔ File metadata [1,521 locations] └── ✔ Executables [380 executables] ✔ Scanned for vulnerabilities [0 vulnerability matches] ├── by severity: 0 critical, 0 high, 0 medium, 0 low, 0 negligible └── by status: 0 fixed, 0 not-fixed, 0 ignored No vulnerabilities found Awesome! Microsoft security teams for the Azure Linux 3 preview images have been highly responsive in ensuring up-to-date images containing fixes or remediations to any security findings are published. We’re excited to see the new Azure Linux 3 release when it’s ready! In the meantime, you can grab our latest Grype release and try it on all your other containers. If you have questions or problems, join the Anchore Open Source Team on Discourse or check out one of our weekly Live Streams on YouTube. Automate your SBOM management with Anchore Enterprise. Get instant access with a 15-day free trial. ### Anchore Enterprise 5.8 Adds KEV Enrichment Feed Today we have released Anchore Enterprise 5.8, featuring the integration of the U.S. Cybersecurity and Infrastructure Security Agency's (CISA) Known Exploited Vulnerabilities (KEV) catalog as a new vulnerability feed. Previously, Anchore Enterprise matched software libraries and frameworks inside applications against vulnerability databases, such as, National Vulnerability Database (NVD), the GitHub Advisory Database or individual vendor feeds. With Anchore Enterprise 5.8, customers can augment their vulnerability feeds with the KEV catalog without having to leave the dashboard. In addition, teams can automatically flag exploitable vulnerabilities as software is being developed or gate build artifacts from being released into production.  Before we jump into what all of this means, let's take a step back and get some context to KEV and its impact on DevSecOps pipelines. What is CISA KEV? The KEV (Known Exploited Vulnerabilities) catalog is a critical cybersecurity resource maintained by the U.S. Cybersecurity and Infrastructure Security Agency (CISA). It is a database of exploited vulnerabilities that is current and active in the wild. While addressing these vulnerabilities is mandatory for U.S. federal agencies under Binding Operational Directive 22-01, the KEV catalog serves as an essential public resource for improving cybersecurity for any organization. The primary difference between CISA KEV and a standard vulnerability feed (e.g., the CVE program) are the adjectives, "actively exploited". Actively exploited vulnerabilities are being used by attackers to compromise systems in real-time, meaning now. They are real and your organization may be standing in the line of fire, whereas CVE lists vulnerabilities that may or may not have any available exploits currently. Due to the imminent threat of actively exploited vulnerabilities, they are considered the highest risk outside of an active security incident. The benefits of KEV enrichment The KEV catalog offers significant benefits to organizations striving to improve their cybersecurity posture. One of its primary advantages is its high signal-to-noise ratio. By focusing exclusively on vulnerabilities that are actively being exploited in the wild, the KEV cuts through the noise of countless potential vulnerabilities, allowing developers and security teams to prioritize their efforts on the most critical and immediate threats. This focused approach ensures that limited resources are allocated to addressing the vulnerabilities that pose the greatest risk, significantly enhancing an organization's security efficiency. Moreover, the KEV can be leveraged as a powerful tool in an organization's development and deployment processes. By using the KEV as a trigger for build pipeline gates, companies can prevent exploitable vulnerabilities from being promoted to production environments. This proactive measure adds an extra layer of security to the software development lifecycle, reducing the risk of deploying vulnerable code.  Additionally, while adherence to the KEV is not yet a universal compliance requirement, it represents a security best practice that forward-thinking organizations are adopting. Given the trend of such practices evolving into compliance mandates, integrating the KEV into security protocols can be seen as a form of future-proofing, potentially easing the transition if and when such practices inevitably become compliance requirements. How Anchore Enterprise delivers KEV enrichment With Anchore Enterprise, CISA KEV is now a vulnerability feed similar to any other data feed that gets imported into the system. Anchore Enterprise can be configured to pull this directly from the source as part of the deployment feed service. To make use of the new KEV data, we have an additional rule option in the Anchore Policy Engine that allows a STOP or WARN to be configured when a vulnerability is detected that is on the KEV list. When any application build, registry store or runtime deploy occurs, Anchore Enterprise will evaluate the artifiact's SBOM against the security policy and if the SBOM has been annotated with a KEV entry then the Anchore policy engine can return a STOP value to inform the build pipeline to fail the step and return the KEV as the source of the violation. To configure the KEV feed as a trigger in the policy engine, first select vulnerabilities as the gate then kev list as a trigger. Finally choose an action. After you save the new rule, you will see the kev list rule as part of the entire policy. After scanning a container with the policy that has the kev list rule in it, you can view all dependencies that match the kev list vulnerability feed. Next Steps To stay on top of our releases, sign-up for our monthly newsletter or follow our LinkedIn account. If you are already an Anchore customer, please reach out to your account manager to upgrade to 5.8 and gain access to KEV support. We also offer a 15 day free trial to get hands on with Anchore Enterprise or you can reach out to us for a guided tour. Save your developers time with Anchore Enterprise. Get instant access with a 15-day free trial. START FREE TRIAL ### A Guide to FedRAMP in 2025: FAQs & Key Takeaways This blog post has been archived and replaced by the supporting pillar page that can be found here: https://anchore.com/wp-admin/post.php?post=987473983&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. ### Carahsoft: Automated policy enforcement for CMMC with Anchore ### DevSecOps Evolution: How DoD Software Factories Are Reshaping Federal Compliance Anchore's Vice President of Security, Josh Bressers recently did an interview with Fed Gov Today about the role of automation in DevSecOps and how it is impacting the US federal government. We've condensed the highlights of the interview into a snackable blog post below. Automation is the foundation of DevSecOps Automation isn't just a buzzword but is actually the foundation of DevSecOps. It is what gives meaning to marketing taglines like "shift left". The point of DevSecOps is to create automated workflows that provide feedback to software developers as they are writing the application. This unwinds the previous practice of  artificially grouping all of the "compliance" or "security" tasks into large blocks at the end of the development process. The challenge with this pattern is that it delays feedback and design decisions are made that become difficult to undo after development has completed. By inverting the narrative and automating feedback as design decisions are made, developers are able to prevent compliance or security issues before they become deeply embedded into the software. DoD Software Factories are leading the way in DevSecOps adoption The US Department of Defense (DoD) is at the forefront of implementing DevSecOps through their DoD software factory model. The US Navy's Black Pearl and the Air Force's Platform One are perfect examples of this program. These organizations are leveraging automation to streamline compliance work. Instead of relying on manual documentation ahead of Authority to Operate (ATO) reviews, automated workflows built directly into the software development pipeline provide direct feedback to developers. This approach has proven highly effective, Bressers emphasizes this in his interview: It's obvious why the DoD software factory model is catching on. It's because they work. It's not just talk, it's actually working. There's many organizations that have been talking about DevSecOps for a long time. There's a difference between talking and doing. Software factories are doing and it's amazing. —Josh Bressers, VP of Security, Anchore Benefits of compliance automation By giving compliance the same treatment as security (i.e., automate all the things), tasks that once took weeks or even months, can now be completed in minutes or hours. This dramatic reduction in time-to-compliance not only accelerates development cycles but also allows teams to focus on collaboration and solution delivery rather than getting bogged down in procedural details. The result is a "shift left" approach that extends beyond security to compliance as well. When compliance is integrated early in the development process the benefits cascade down the entire development waterfall. Compliance automation is shifting the policy checks left into the software development process. What this means is that once your application is finished; instead of the compliance taking weeks or months, we're talking hours or minutes. —Josh Bressers, VP of Security, Anchore Areas for improvement While automation is crucial, there are still several areas for improvement in DevSecOps environments. Key focus areas include ensuring developers fully understand the automated processes, improving communication between team members and agencies, and striking the right balance between automation and human oversight. Bressers emphasizes the importance of letting "people do people things" while leveraging computers for tasks they excel at. This approach fosters genuine collaboration and allows teams to focus on meaningful work rather than simply checking boxes to meet compliance requirements. Standardizing communication workflows with integrated developer tools Software development pipelines are primarily platforms to coordinate the work of distributed teams of developers. They act like old-fashioned switchboard operators that connect one member of the development team to the next as they hand-off work in the development production line. Leveraging developer tooling like GitLab or GitHub standardizes communication workflows. These platforms provide mechanisms for different team members to interact across various stages of the development pipeline. Teams can easily file and track issues, automatically pass or fail tests (e.g., compliance tests), and maintain a searchable record of discussions. This approach facilitates better understanding between developers and those identifying issues, leading to more efficient problem-solving and collaboration. The government getting ahead of the private sector: an unexpected narrative inversion In a surprising turn of events, Bressers points out that government agencies are now leading the way in DevSecOps implementation by integrating automated compliance. Historically often seen as technologically behind, federal agencies, through the DoD software factory model, are setting new standards that are likely to influence the private sector. As these practices become more widespread, contractors and private companies working with the government will need to adapt to these new requirements. This shift is evident in recent initiatives like the SSDF attestation questionnaire and White House Executive Order (EO) 14028. These initiatives are setting new expectations for federal contractors, signaling a broader move towards making compliance a native pillar of DevSecOps. This is one of the few instances in recent memory where the government is truly leading the way. Historically the government has often been the butt of jokes about being behind in technology but these DoD software factories are absolutely amazing. The next thing that we're going to see is the compliance expectations that are being built into these DoD software factories will seep out into the private sector. The SSDF attestation and the White House Executive Order are only the beginning. Ironically my expectation is everyone is going to have to start paying attention to this, not just federal agencies. —Josh Bressers, VP of Security, Anchore Next Steps If you're interested to learn more about how to future-proof your software supply chain with compliance automation via the DoD software factory model, be sure to read our white paper. If you'd like to hear the interview in full, be sure to watch it on Fed Gov Today's Youtube channel. Download Now ### Automate Container Vulnerability Scanning in CI with Anchore Achieve container vulnerability scanning nirvana in your CI pipeline with Anchore Enterprise and your preferred CI platform, whether it's GitHub, GitLab, or Jenkins. Identifying vulnerabilities, security issues, and compliance policy failures early in the software development process is crucial. It's certainly preferable to uncover these issues during development rather than having them discovered by a customer or during an external audit. Early detection of vulnerabilities ensures that security and compliance are integrated into your development workflow, reducing the risk of breaches and compliance violations. This proactive approach not only protects your software but also saves time and resources by addressing issues before they escalate. Enabling CI Integration At a high level, the steps to connect any CI platform to Enterprise are broadly the same, with implementation details differing between each vendor. Enable network connectivity between CI and Enterprise Capture Enterprise configuration for AnchoreCTL Craft an automation script to operate after the build process Install AnchoreCTL Capture built container details Use AnchoreCTL to submit container details to Enterprise Once SBOM generation is integrated into the CI pipeline, and they're submitted to Anchore Enterprise, the following features can quickly be leveraged: Known vulnerabilities with severity, and fix availability Search for accidental 'secrets' sharing such as private API keys Scan for malware like trojans and viruses Policy enforcement to comply with standards like FedRAMP, CISA and DISA Remediation by notifying developers and other agents via standard tools like GitHub issues, JIRA, and Slack Scheduled reporting on container insights CI Integration by Example Taking GitHub Actions as an example, we can outline the requirements and settings to get up and running with automated SBOM generation and vulnerability management. Network connectivity AnchoreCTL uses port 8228 for communication with the Anchore Enterprise SBOM ingest and management API. Ensure the Anchore Enterprise host, where this is configured, is accessible on that port from GitHub. This is site specific and may require firewall, VLAN and other site-specific changes. Required configuration AnchoreCTL requires only three environment variables, typically set as GitHub secrets. ANCHORECTL_URL - the URL of the Anchore Enterprise API endpoint. e.g. http://anchore-enterprise.example.com:8228 ANCHORECTL_USERNAME - the user account in Anchore Enterprise, that the anchorectl will authenticate using ANCHORECTL_PASSWORD - the password for the account, set on the Anchore Enterprise instance On the GitHub repository go to Settings -> Secrets and Variables -> Actions. Under the 'Variables' tab, add ANCHORECTL_URL & ANCHORECTL_USERNAME, and set their values. In the 'Secrets' tab, add ANCHORECTL_PASSWORD and set the value. Automation script Below are the sample snippets from a GitHub action that should be placed in the repository under .github/workflows to enable SBOM generation in Anchore Enterprise. In this example, First, our action needs a name: name: Anchore Enterprise Centralized Scan Pick one or more from this next section, depending on when you require the action to be triggered. It could be based on pushes to the main or other named branches, on a timed schedule, or manually. Commonly when configuring an action for the first time, manual triggering is used until proven working, then timed or branch automation is enabled later. on: ## Action runs on a push the branches listed push: branches: - main ## Action runs on a regular schedule schedule: ## Run at midnight every day - cron: '0 0 * * *' ## Action runs on demand build workflow_dispatch: inputs: mode: description: 'On-Demand Build' In the env section we pass in the settings gathered and configured inside the GitHub web UI earlier. Additionally the optional ANCHORECTL_FAIL_BASED_ON_RESULTS boolean defines (if true) whether we want the the entire action to be failed based on scan results. This may be desirable, to block further processing if any vulnerabilities, secrets or malware are identified. env: ANCHORECTL_URL: ${{ vars.ANCHORECTL_URL }} ANCHORECTL_USERNAME: ${{ vars.ANCHORECTL_USERNAME }} ANCHORECTL_PASSWORD: ${{ secrets.ANCHORECTL_PASSWORD }} ANCHORECTL_FAIL_BASED_ON_RESULTS: false Now we start the actual body of the action, which comprises two jobs, 'Build' and 'Anchore'. The 'Build' example here will use externally defined steps to checkout the code in the repo and build a container using docker, then push the resulting image to the container registry. In this case we build and publish to the GitHub Container Registry (ghcr), however, we could publish elsewhere. jobs: Build: runs-on: ubuntu-latest steps: - name: "Set IMAGE environmental variables" run: | echo "IMAGE=${REGISTRY}/${GITHUB_REPOSITORY}:${GITHUB_REF_NAME}" >> $GITHUB_ENV - name: Checkout Code uses: actions/checkout@v3 - name: Log in to the Container registry uses: docker/login-action@v2 with: registry: ${{ env.REGISTRY }} username: ${{ github.actor }} password: ${{ secrets.GITHUB_TOKEN }} - name: Set up Docker Buildx uses: docker/setup-buildx-action@v2 - name: build local container uses: docker/build-push-action@v3 with: tags: ${{ env.IMAGE }} push: true load: false The next job actually generates the SBOM, let's break this down. First, the usualy boilerplate, but note this job depends on the previous 'Build' job having already run. Anchore: runs-on: ubuntu-latest needs: Build steps: The same registry settings are used here as were used in the 'Build' job above, then we checkout the code onto the action runner. The IMAGE variable will be used by the anchorectl command later to submit into Anchore Enterprise. - name: "Set IMAGE environment variables" run: | echo "IMAGE=${REGISTRY}/${GITHUB_REPOSITORY}:${GITHUB_REF_NAME}" >> $GITHUB_ENV - name: Checkout Code uses: actions/checkout@v3 Installing the AnchoreCTL binary inside the action runner is required to send the request to the Anchore Enterprise API. Note the version number specified as the past parameter, should match the version of Enterprise. - name: Install Latest anchorectl Binary run: | curl -sSfL https://anchorectl-releases.anchore.io/anchorectl/install.sh | sh -s -- -b ${HOME}/.local/bin v5.7.0 export PATH="${HOME}/.local/bin/:${PATH}" The Connectivity check is a good way to ensure anchorectl is installed correctly, and configured to connect to the right Anchore Enterprise instance. - name: Connectivity Check run: | anchorectl version anchorectl system status anchorectl feed list Now we actually queue the image up for scanning by our Enterprise instance. Note the use of --wait to ensure the GitHub Action pauses until the backend Enterprise instance completes the scan. Otherwise the next steps would likely fail, as the scan would not yet be complete. - name: Queue Image for Scanning by Anchore Enterprise run: | anchorectl image add --no-auto-subscribe --wait --dockerfile ./Dockerfile --force ${IMAGE} Once the backend Anchore Enterprise has completed the vulnerability, malware, and secrets scan, we use anchorectl to pull the list of vulnerabilities and display them as a table. This can be viewed in the GitHub Action log, if required. - name: Pull Vulnerability List run: | anchorectl image vulnerabilities ${IMAGE} Finally, the image check will pull down the results of the policy compliance as defined in your Anchore Enterprise. This will likely be a significantly shorter output than the full vulnerability list, depending on your policy bundle. If the environment variable ANCHORECTL_FAIL_BASED_ON_RESULTS was set true earlier in the action, or -f is added to the command below, the action will return as a 'failed' run. - name: Pull Policy Evaluation run: | anchorectl image check --detail ${IMAGE} That's everything. If configured correctly, the action will run as required, and directly leverage the vulnerability, malware and secrets scanning of Anchore Enterprise. Not just GitHub While the example above is clearly GitHub specific, a similar configuration can be used in GitLab pipelines, Jenkins, or indeed any CI system that supports arbitrary shell scripts in automation. Conclusion By integrating Anchore Enterprise into your CI pipeline, you can achieve a higher level of security and compliance for your software development process. Automating vulnerability scanning and SBOM management ensures that your software is secure, compliant, and ready for deployment. Automate your SBOM management with Anchore Enterprise. Get instant access with a 15-day free trial. ### High volume image scanning and vulnerability management at the Iron Bank (Platform One) The Iron Bank provides Platform One and any US Department of Defense (DoD) agency with a hardened and centralized container image repository that supports the end-to-end lifecycle needed for secure software development. Anchore and the Iron Bank have been collaborating since 2020 to balance deployment velocity, and policy compliance while maintaining rigorous security standards and adapting to new security threats.  The Challenge 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. They face difficult tasks such as: Providing hardened components for downstream applications across the DoD Meeting rigorous security standards crucial for military systems Improving deployment frequency while maintaining policy compliance Reducing the burden of false positives on the development team Camdon Cady, Chief Technology Officer at Platform One: People want to be security minded, and they want to do the right thing. But 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. The Solution Anchore’s engineering team is deeply embedded with the Iron Bank infrastructure and development team to improve and maintain DevSecOps standards. Anchore Enterprise is the software supply chain security tool of choice as it provides:  An on-premise, distributed container image scanner A turnkey SBOM (Software Bill of Materials) generation and management solution An automated policy engine to evaluate and enforce security standards and compliance The Results: Sustainable security at DevOps speed The partnership between Iron Bank and Anchore has yielded impressive results: Reduced False Positives: The introduction of an exclusion feed captured over 12,000 known false positives, significantly reducing the security assessment load. Improved SBOM Accuracy: Custom capabilities like SBOM Hints and SBOM Corrections allow for more precise component identification and vulnerability mapping. Standardized Compliance: A jointly developed custom policy enforces the DoD Container Hardening requirements consistently across all images. Enhanced Scanning Capabilities: Additions like time-based allowlisting, content hints, and image scanning have expanded Iron Bank's security coverage. Streamlined Processes: The standardized scanning process adheres to the DoD's Container Hardening Guide while delivering high-quality vulnerability and compliance findings. 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 Download the full case study to learn more about how Anchore Enterprise can help your organization achieve a proactive security stance while maintaining development velocity. Download Now ### How Infoblox Scaled Product Security and Compliance with Anchore Enterprise In today's fast-paced software development world, maintaining the highest levels of security and compliance is a daunting challenge. Our new case study highlights how Infoblox, a leader in Enterprise DDI (DNS, DHCP, IPAM), successfully scaled their product security and compliance efforts using Anchore Enterprise. Let's dive into their journey and the impressive results they achieved. The Challenge: Scaling security in high-velocity Environments Infoblox faced several critical challenges in their product security efforts: Implementing "shift-left" security at scale for 150 applications developed by over 600 engineers with a security team of 15 (a 40:1 ratio!) Managing vulnerabilities across thousands of containers produced monthly Maintaining multiple compliance certifications (FedRAMP, SOC 2, StateRAMP, ISO 27001) Integrating seamlessly into existing DevOps workflows "When I first started, I was manually searching GitHub repos for references to vulnerable libraries," recalls Sukhmani Sandhu, Product Security Engineer at Infoblox. This manual approach was unsustainable and prone to errors. The Solution: Anchore Enterprise To address these challenges, Infoblox turned to Anchore Enterprise to provide: Container image scanning with low false positives Comprehensive vulnerability and CVE management Native integrations with Amazon EKS, Harbor, and Jenkins CI A FedRAMP, SOC 2, StateRAMP, and ISO compliant platform Chris Wallace, Product Security Engineering Manager at Infoblox, emphasizes the importance of accuracy: "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." Impressive Results The implementation of Anchore Enterprise transformed Infoblox's product security program: 75% reduction in time for manual vulnerability detection tasks 55% reduction in hours allocated to retroactive vulnerability remediation 60% reduction in hours spent on compliance tasks Empowered the product security team to adopt a proactive, "shift-left" security posture These improvements allowed the Infoblox team to focus on higher-value initiatives like automating policy and remediation. Developers even began self-adopting scanning tools during development, catching vulnerabilities before they entered the build pipeline. "We effectively had no tooling before Anchore. Everything was manual. We reduced the amount of time on vulnerability detection tasks by 75%," says Chris Wallace. Conclusion: Scaling security without compromise Infoblox's success story demonstrates that it's possible to scale product security and compliance efforts without compromising on development speed or accuracy. By leveraging Anchore Enterprise, they transformed their security posture from reactive to proactive, significantly reduced manual efforts, and maintained critical compliance certifications. Are you facing similar challenges in your organization? Download the full case study and take the first step towards a secure, compliant, and efficient development environment. Or learn more about how Anchore's container security platform can help your organization. Download Now ### Introduction to the DoD Software Factory Fast Facts A DoD Software Factory is a DevSecOps-based development pipeline adapted to the DoD’s high-threat environment, reflecting the government’s broader push for software and cybersecurity modernization. DoD software factories typically include code repositories, CI/CD build pipelines, artifact repositories, and runtime orchestrators and platforms. Use pre-existing software factories or roll out your own by following DoD best practices like continuous vulnerability scanning and automated policy checks. SCA tools like Anchore Enterprise address the unique security, compliance, and operational needs of DoD Software Factories by delivering end-to-end software supply chain security and automated compliance. In the rapidly evolving landscape of national defense and cybersecurity, the concept of a Department of Defense (DoD) software factory has emerged as a cornerstone of innovation and security. These software factories represent an integration of the principles and practices found within the DevSecOps movement, tailored to meet the unique security requirements of the DoD and Defense Industrial Base (DIB).  By fostering an environment that emphasizes continuous monitoring, automation, and cyber resilience, DoD Software Factories are at the forefront of the United States Government's push towards modernizing its software and cybersecurity capabilities. This initiative not only aims to enhance the velocity of software development but also ensures that these advancements are achieved without compromising on security, even against the backdrop of an increasingly sophisticated threat landscape. Building and running a DoD software factory is so central to the future of software development that "Establish a Software Factory" is the one of the explicitly named plays from the DoD DevSecOps Playbook. On top of that, the compliance capstone of the authorization to operate (ATO) or its DevSecOps infused cousin the continuous ATO (cATO) effectively require a software factory in order to meet the requirements of the standard. In this blog post, we'll break down the concept of a DoD software factory and a high-level overview of the components that make up one. Watch Now What is a DoD software factory? A Department of Defense (DoD) Software Factory is a software development pipeline that embodies the principles and tools of the larger DevSecOps movement with a few choice modifications that conform to the extremely high threat profile of the DoD and DIB. It is part of the larger software and cybersecurity modernization trend that has been a central focus for the United States Government in the last two decades. The goal of a DoD Software Factory is aimed at creating an ecosystem that enables continuous delivery of secure software that meet the needs of end-users while ensuring cyber resilience (a DoD catchphrase that emphasizes the transition from point-in-time security compliance to continuous security compliance). In other words, the goal is to leverage automation of software security tasks in order to fulfill the promise of the DevSecOps movement to increase the velocity of software development. What is an example of a DoD software factory? Platform One is the canonical example of a DoD software factory. Run by the US Air Force, it offers both a comprehensive portfolio of software development tools and services. It has come to prominence due to its hosted services like Repo One for source code hosting and collaborative development, Big Bang for a end-to-end DevSecOps CI/CD platform and the Iron Bank for centralized container storage (i.e., container registry). These services have led the way to demonstrating that the principles of DevSecOps can be integrated into mission critical systems while still preserving the highest levels of security to protect the most classified information. If you're interested to learn more about how Platform One has unlocked the productivity bonus of DevSecOps while still maintaining DoD levels of security, watch our webinar with Camdon Cady, Chief of Operations and Chief Technology Officer of Platform One. Watch Now Who does it apply to? Federal Service Integrators (FSI) Any organization that works with the DoD as a federal service integrator will want to be intimately familiar with DoD software factories as they will either have to build on top of existing software factories or, if the mission/program wants to have full control over their software factory, be able to build their own for the agency. Department of Defense (DoD) Mission Any Department of Defense (DoD) mission will need to be well-versed on DoD software factories as all of their software and systems will be required to run on a software factory as well as both reach and maintain a cATO. What are the components of a DoD Software Factory? A DoD software factory is composed of both high-level principles and specific technologies that meet these principles. Below are a list of some of the most significant principles of a DoD software factory: Principles of DevSecOps embedded into a DoD software factory Breakdown organizational silos This principle is borrowed directly from the DevSecOps movement, specifically the DoD aims to integrate software development, test, deployment, security and operations into a single culture with the organization. Open source and reusable code Composable software building blocks is another principle of the DevSecOps that increases productivity and reduces security implementation errors from developers writing secure software packages that they are not experts in. Immutable Infrastructure-as-Code (IaC) This principle focuses on treating the infrastructure that software runs on as ephemeral and managed via configuration rather than manual systems operations. Enabled by cloud computing (i.e., hardware virtualization) this principle increases the security of the underlying infrastructure through templated secure-by-design defaults and reliability of software as all infrastructure has to be designed to fail at any moment. Microservices architecture (via containers) Microservices are a design pattern that creates smaller software services that can be built and scale independently of each other. This principle allows for less complex software that only performs a limited set of behavior. Shift Left Shift left is the DevSecOps principle that re-frames when and how security testing is done in the software development lifecycle. The goal is to begin security testing while software is being written and tested rather than after the software is "complete". This prevents insecure practices from cascading into significant issues right as software is ready to be deployed. Continuous improvement through key capabilities The principle of continuous improvement is a primary characteristic of the DevSecOps ethos but the specific key capabilities that are defined in the DoD DevSecOps playbook are what make this unique to the DoD. Define a DevSecOps pipeline A DevSecOps pipeline is the system that utilizes all of the preceding principles in order to create the continuously improving security outcomes that is the goal of the DoD software factory program. Cyber resilience Cyber resiliency is the goal of a DoD software factory, is it defined as, "the ability to anticipate, withstand, recover from, and adapt to adverse conditions, stresses, attacks, or compromises on the systems that include cyber resources.” Common tools and systems of a DoD software factory Code Repository (e.g., Repo One) Where software source code is stored, managed and collaborated on. CI/CD Build Pipeline (e.g., Big Bang) The system that automates the creation of software build artifacts, tests the software and packages the software for deployment. Artifact Repository (e.g., Iron Bank) The storage system for software components used in development and the finished software artifacts that are produced from the build process. Runtime Orchestrator and Platform (e.g., Big Bang) The deployment system that hosts the software artifacts pulled from the registry and keeps the software running so that users can access it. How do I meet the security requirements for a DoD Software Factory? (Best Practices) Use a pre-existing software factory The benefit of using a pre-existing DoD software factory is the same as using a public cloud provider; someone else manages the infrastructure and systems. What you lose is the ability to highly customize your infrastructure to your specific needs. What you gain is the simplicity of only having to write software and allow others with specialized skill sets to deal with the work of building and maintaining the software infrastructure. When you are a car manufacturer, you don't also want to be a civil engineering firm that designs roads. To view existing DoD software factories, visit the Software Factory Ecosystem Coalition website. Roll your own by following DoD best practices  If you need the flexibility and customization of managing your own software factory then we'd recommend following the DoD Enterprise DevSecOps Reference Design as the base framework. There are a few software supply chain security recommendations that we would make in order to ensure that things go smoothly during the authorization to operate (ATO) process: Continuous vulnerability scanning across all stages of CI/CD pipeline Use a cloud-native vulnerability scanner that can be directly integrated into your CI/CD pipeline and called automatically during each phase of the SDLC Automated policy checks to enforce requirements and achieve ATO Use a cloud-native policy engine in tandem with your vulnerability scanner in order to automate the reporting and blocking of software that is a security threat and a compliance risk Remediation feedback Use a cloud-native policy engine that can provide automated remediation feedback to developers in order to maintain a high velocity of software development Compliance (Trust but Verify) Use a reporting system that can be directly integrated with your CI/CD pipeline to create and collect the compliance artifacts that can prove compliance with DoD frameworks (e.g., CMMC and cATO) Air-gapped system Utilize a cloud-native software supply chain security platform that can be deployed into an air-gapped environment in order to maintain the most strict security for classified missions Is a software factory required in order to achieve cATO? Technically, no. Effectively, yes. A cATO requires that your software is deployed on an Approved DoD Enterprise DevSecOps Reference Design not a software factory specifically. If you build your own DevSecOps platform that meets the criteria for the reference design then you have effectively rolled your own software factory. How Anchore can help The easiest and most effective method for achieving the security guarantees that a software factory is required to meet for its software supply chain are by using:  An SBOM generation and management tool that integrates directly into your software development pipeline A container vulnerability scanner that integrates directly into your software development pipeline A policy engine that integrates directly into your software development pipeline A centralized database to store all of your software supply chain security logs A query engine that can continuously monitor your software supply chain and automate the creation of compliance artifacts These are the primary components of both Anchore Enterprise and Anchore Federal cloud native, SBOM-powered software composition analysis (SCA) platforms that provide an end-to-end software supply chain security to holistically protect your DevSecOps pipeline and automate compliance. This approach has been validated by the DoD, in fact the DoD's Container Hardening Process Guide specifically named Anchore Federal as a recommended container hardening solution. Learn more about how Anchore fuses DevSecOps and DoD software factories. Conclusion and Next Steps DoD software factories can come off as intimidating at first but hopefully we have broken them down into a more digestible form. At their core they reflect the best of the DevSecOps movement with specific adaptations that are relevant to the extreme threat environment that the DoD has to operate in, as well as, the intersecting trend of the modernization of federal security compliance standards. If you're looking to dive deeper into all things DoD software factory, we have a white paper that lays out the 6 best practices for container images in highly secure environments. Download the white paper below. Download Now ### AnchoreCTL Setup and Top Tips Introduction Welcome to the beginners guide to AnchoreCTL, a powerful command-line tool designed for seamless interaction with Anchore Enterprise via the Anchore API. Whether you're wrangling SBOMs, managing Kubernetes runtime inventories, or ensuring compliance at scale, AnchoreCTL is your go-to companion. Overview AnchoreCTL enables you to efficiently manage and inspect all aspects of your Anchore Enterprise deployments. It serves both as a human-readable configuration tool and a CLI for automation in CI/CD environments, making it indispensable for DevOps, security engineers, and developers. If you’re familiar with Syft and Grype, AnchoreCTL will be a valuable addition to your toolkit. It offers enhanced capabilities to manage tens, hundreds, or even thousands of images and applications across your organization. In this blog series, we’ll explore top tips and practical use cases to help you leverage AnchoreCTL to its fullest potential. In this part, we'll review the basics of getting started with AnchoreCTL. In subsequent posts, we will dive deep on container scanning, SBOM Management and Vulnerability Management. We'll start by getting AnchoreCTL installed and learning about its configuration and use. I'll be using AnchoreCTL on my macOS laptop, connected to a demo of Anchore Enterprise running on another machine. Get AnchoreCTL AnchoreCTL is a command-line tool available for macOS, Linux and Windows. The AnchoreCTL Deployment docs cover installation and deployment in detail. Grab the release of AnchoreCTL that matches your Anchore Enterprise install. At the time of writing, the current release of AnchoreCTL and Anchore Enterprise is v5.6.0. Both are updated on a monthly cadence, and yours may be newer or older than what we're using here. The AnchoreCTL Release Notes contain details about the latest, and all historical releases of the utility. You may have more than one Anchore Enterprise deployment on different releases. As AnchoreCTL is a single binary, you can install multiple versions on a system to support all the deployments in your landscape. macOS / Linux This following snippet will install the binary in a directory of your choosing. On my personal workstation, I use $HOME/bin, but anywhere in your $PATH is fine. Placing the application binary in /usr/local/bin/ makes sense in a shared environment. $ # Download the macOS or Linux build of anchorectl $ curl -sSfL  https://anchorectl-releases.anchore.io/anchorectl/install.sh  | sh -s -- -b $HOME/bin v5.6.0 Windows The Windows install snippet grabs the zip file containing the binary. Once downloaded, unpack the zip and copy the anchorectl command somewhere appropriate. $ # Download the Windows build of anchorectl $ curl -o anchorectl.zip https://anchorectl-releases.anchore.io/anchorectl/v5.6.0/anchorectl_5.6.0_windows_amd64.zip Setup Quick check Once AnchoreCTL is installed, check it's working with a simple anchorectl version. It should print output similar to this: $ # Show the version of the anchorectl command line tool $ anchorectl version Application: anchorectl Version: 5.6.0 SyftVersion: v1.4.1 BuildDate: 2024-05-27T18:28:23Z GitCommit: 7c134b46b7911a5a17ba1fa5f5ffa4e3687f170b GitDescription: v5.6.0 Platform: darwin/arm64 GoVersion: go1.21.10 Compiler: gc Configure The anchorectl command has a --help option that displays a lot of useful information beyond just the list of command line options reference. Below are the first 15 lines to illustrate what you should see. The actual output is over 80 lines, so we've snipped it down here. $ # Show the top 15 lines of the help $ anchorectl --help | head -n 15 Usage: anchorectl [command] Application Config: (search locations: .anchorectl.yaml, anchorectl.yaml, .anchorectl/config.yaml, ~/.anchorectl.yaml, ~/anchorectl.yaml, $XDG_CONFIG_HOME/anchorectl/config.yaml) # the URL to the Anchore Enterprise API (env var: "ANCHORECTL_URL") url: "" # the Anchore Enterprise username (env var: "ANCHORECTL_USERNAME") username: "" # the Anchore Enterprise user's login password (env var: "ANCHORECTL_PASSWORD") On launch, the anchorectl binary will search for a yaml configuration file in a series of locations shown in the help above. For a quick start, just create .anchorectl.yaml in your home directory, but any of the listed locations are fine. Here is my very basic .anchorectl.yaml which has been configured with the minimum values of url, username and password to get started. I've pointed anchorectl at the Anchore Enterprise v5.6.0 running on my Linux laptop 'ziggy', using the default port, username and password. We'll see later how we can create new accounts and users. $ # Show the basic config file $ cat .anchorectl.yml url: "http://ziggy.local:8228" username: "admin" password: "foobar" Config Check The configuration can be validated with anchorectl -v. If the configuration is syntactically correct, you'll see the online help displayed, and the command will exit with return code 0. In this example, I have truncated the lengthy anchorectl -v output. $ # Good config $ cat .anchorectl.yml url: "http://ziggy.local:8228" username: "admin" password: "foobar" $ anchorectl -v [0000]  INFO anchorectl version: 5.6.0 Usage:  anchorectl [command] ⋮       --version         version for anchorectl Use "anchorectl [command] --help" for more information about a command. $ echo $? 0 In this example, I omitted a closing quotation mark on the url: line, to force an error. $ # Bad config $ cat .anchorectl.yml url: "http://ziggy.local:8228 username: "admin" password: "foobar" $ anchorectl -v ⋮ error: invalid application config: unable to parse config="/Users/alan/.anchorectl.yml": While parsing config: yaml: line 1: did not find expected key $ echo $? 1 Connectivity Check Assuming the configuration file is syntactically correct, we can now validate the correct url, username and password are set for the Anchore Enterprise system with an anchorectl system status. If all is going well, we'll get a report similar to this: The output of anchore system status shows the services running on my Anchore Enterprise. Multiple Configurations You may also use the -c or --config option to specify the path to a configuration file. This is useful if you communicate with multiple Anchore Enterprise systems. $ # Show the production configuration file $ cat ./production.anchore.yml url: "http://remotehost.anchoreservers.com:8228" username: "admin" password: "foobar" $ # Show the development configuration file, which points to a diff PC $ cat ./development.anchore.yml url: "http://workstation.local:8228" username: "admin" password: "foobar" $ # Connect to remote production instance $ anchorectl -c ./production.anchorectl.yml system status  ✔ Status system⋮ $ # Connect to developer workstation $ anchorectl -c ./development.anchorectl.yml system status  ✔ Status system⋮ Environment Variables Note from the --help further up that AnchoreCTL can be configured with environment variables instead of the configuration file. This can be useful when the tool is deployed in CI/CD environments, where these can be set using the platform 'secret storage'. So, without any configuration file, we can issue the same command but setting options via environment variables. I've truncated the output below, but note the ✔ Status system indicating a successful call to the remote system. $ # Delete the configuration to prove we aren't using it $ rm .anchorectl.yml $ anchorectl system status  ⠋ error: 1 error occurred:  * no enterprise URL provided $ # Use environment variables instead $ ANCHORECTL_URL="http://ziggy.local:8228" \ ANCHORECTL_USERNAME="admin" \ ANCHORECTL_PASSWORD="foobar" \ anchorectl system status  ✔ Status system⋮ Of course, in a CI/CD environment such as GitHub, GitLab, or Jenkins, these environment variables would be set in a secure store and only set up as the job running anchorectl it initiated. Users Viewing Accounts & Users In the examples above, I've been using the default username and password for a demo Anchore Enterprise instance. AnchoreCTL can be used to query and manage the system's accounts and users. Documentation for these activities can be found in the user management section of the docs. $ # Show list of accounts on the remote instance $ anchorectl account list  ✔ Fetched accounts ┌───────┬─────────────────┬─────────┐ │ NAME  │ EMAIL           │ STATE   │ ├───────┼─────────────────┼─────────┤ │ admin │ admin@myanchore │ enabled │ └───────┴─────────────────┴─────────┘ We can also list existing users on the system: $ # Show list of users (if any) in the admin account $ anchorectl user list --account admin  ✔ Fetched users ┌──────────┬──────────────────────┬───────────────────────┬────────┬──────────┬────────┐ │ USERNAME │ CREATED AT           │ PASSWORD LAST UPDATED │ TYPE   │ IDP NAME │ SOURCE │ ├──────────┼──────────────────────┼───────────────────────┼────────┼──────────┼────────┤ │ admin    │ 2024-06-10T11:48:32Z │ 2024-06-10T11:48:32Z  │ native │          │        │ └──────────┴──────────────────────┴───────────────────────┴────────┴──────────┴────────┘ Managing Acounts AnchoreCTL can be used to add (account add), enable (account enable), disable (account disable) and remove (account delete) accounts from the system: $ # Create a new account $ anchorectl account add dev_team_alpha  ✔ Added account Name: dev_team_alpha Email: State: enabled $ # Get a list of accounts $ anchorectl account list  ✔ Fetched accounts ┌────────────────┬─────────────────┬─────────┐ │ NAME           │ EMAIL           │ STATE   │ ├────────────────┼─────────────────┼─────────┤ │ admin          │ admin@myanchore │ enabled │ │ dev_team_alpha │                 │ enabled │ │ dev_team_beta │                 │ enabled │ └────────────────┴─────────────────┴─────────┘ $ # Disable an account before deleting it $ anchorectl account disable dev_team_alpha  ✔ Disabled accountState: disabled $ # Delete the account $ anchorectl account delete dev_team_alpha  ✔ Deleted account No results $ # Get a list of accounts $ anchorectl account list  ✔ Fetched accounts ┌────────────────┬─────────────────┬──────────┐ │ NAME           │ EMAIL           │ STATE    │ ├────────────────┼─────────────────┼──────────┤ │ admin          │ admin@myanchore │ enabled  │ │ dev_team_alpha │                 │ deleting │ │ dev_team_beta │                 │ enabled │ └────────────────┴─────────────────┴──────────┘ Managing Users Users exist within accounts, but usernames are globally unique since they are used for authenticating API requests. Any user in the admin account can perform user management in the default Anchore Enterprise configuration using the native authorizer.  For more information on configuring other authorization plugins, see Authorization Plugins and Configuration in our documentation. Users can also be managed via AnchoreCTL. Here we create a new dev_admin_beta user under the dev_team_beta account and give then the role full-control as an administrator of the team. We'll set a password of CorrectHorseBatteryStable for the admin user, but pass that via the environment rather than echo it out in the command line. $ # Create a new user from the dev_team_beta account $ ANCHORECTL_USER_PASSWORD=CorrectHorseBatteryStable \ anchorectl user add --account dev_team_beta dev_admin_beta \ --role full-control  ✔ Added user    dev_admin_beta Username: dev_admin_beta Created At: 2024-06-12T10:25:23Z Password Last Updated: 2024-06-12T10:25:23Z Type: native IDP Name: Source: Let's check that worked: $ # Check that the new user was created $ anchorectl user list --account dev_team_beta  ✔ Fetched users ┌────────────────┬──────────────────────┬───────────────────────┬────────┬──────────┬────────┐ │ USERNAME       │ CREATED AT           │ PASSWORD LAST UPDATED │ TYPE   │ IDP NAME │ SOURCE │ ├────────────────┼──────────────────────┼───────────────────────┼────────┼──────────┼────────┤ │ dev_admin_beta │ 2024-06-12T10:25:23Z │ 2024-06-12T10:25:23Z  │ native │          │        │ └────────────────┴──────────────────────┴───────────────────────┴────────┴──────────┴────────┘ That user is now able to use the API. $ # List users from the dev_team_beta account $ ANCHORECTL_USERNAME=dev_admin_beta \ ANCHORECTL_PASSWORD=CorrectHorseBatteryStable \ ANCHORECTL_ACCOUNT=dev_team_beta \ anchorectl user list  ✔ Fetched users ┌────────────────┬──────────────────────┬───────────────────────┬────────┬──────────┬────────┐ │ USERNAME       │ CREATED AT           │ PASSWORD LAST UPDATED │ TYPE   │ IDP NAME │ SOURCE │ ├────────────────┼──────────────────────┼───────────────────────┼────────┼──────────┼────────┤ │ dev_admin_beta │ 2024-06-12T10:25:23Z │ 2024-06-12T10:25:23Z  │ native │          │        │ └────────────────┴──────────────────────┴───────────────────────┴────────┴──────────┴────────┘ Using AnchoreCTL We now have AnchoreCTL set-up to talk to our Anchore Enterprise, and a user other than admin to connect as let's actually use it to scan a container. We have two options here, 'Centralized Analysis' and 'Distributed Analysis'. In Centralized Analysis, any container we request will be downloaded and analyzed by our Anchore Enterprise. If we choose Distributed Analysis, the image will be analyzed by anchorectl itself. This is covered in much more detail in the Vulnerability Management section of the docs. Currently we have no images submitted for analysis: $ # Query Enterprise to get a list of container images and their status $ ANCHORECTL_USERNAME=dev_admin_beta \ ANCHORECTL_PASSWORD=CorrectHorseBatteryStable \ ANCHORECTL_ACCOUNT=dev_team_beta \ anchorectl image list  ✔ Fetched images ┌─────┬────────┬──────────┬────────┐ │ TAG │ DIGEST │ ANALYSIS │ STATUS │ ├─────┼────────┼──────────┼────────┤ └─────┴────────┴──────────┴────────┘ Let's submit the latest Debian container from Dockerhub to Anchore Enterprise for analysis. The backend Anchore Enterprise deployment will then pull (download) the image, and analyze it. $ # Request that enterprise downloads and analyzes the debian:latest image $ ANCHORECTL_USERNAME=dev_admin_beta \ ANCHORECTL_PASSWORD=CorrectHorseBatteryStable \ ANCHORECTL_ACCOUNT=dev_team_beta \ anchorectl image add docker.io/library/debian:latest  ✔ Added Image       docker.io/library/debian:latest  Image:    status:           not-analyzed (active)    tag:              docker.io/library/debian:latest    digest:           sha256:820a611dc036cb57cee7...    id:               7b34f2fc561c06e26d69d7a5a58... Initially the image starts in a state of not-analyzed. Once it's been downloaded, it'll be queued for analysis. When the analysis begins, the status will change to analyzing after which it will change to analyzed. We can check the status with anchorectl image list. $ # Check the status of the container image we requested $ ANCHORECTL_USERNAME=dev_admin_beta \ ANCHORECTL_PASSWORD=CorrectHorseBatteryStable \ ANCHORECTL_ACCOUNT=dev_team_beta \ anchorectl image list  ✔ Fetched images ┌─────────────────────────────────┬────────────────────────────────┬───────────┬────────┐ │ TAG                             │ DIGEST                         │ ANALYSIS  │ STATUS │ ├─────────────────────────────────┼────────────────────────────────┼───────────┼────────┤ │ docker.io/library/debian:latest │ sha256:820a611dc036cb57cee7... │ analyzing │ active │ └─────────────────────────────────┴────────────────────────────────┴───────────┴────────┘ After a short while, the image has been analyzed. $ # Check the status of the container image we requested $ ANCHORECTL_USERNAME=dev_admin_beta \ ANCHORECTL_PASSWORD=CorrectHorseBatteryStable \ ANCHORECTL_ACCOUNT=dev_team_beta \ anchorectl image list  ✔ Fetched images ┌─────────────────────────────────┬────────────────────────────────┬───────────┬────────┐ │ TAG                             │ DIGEST                         │ ANALYSIS  │ STATUS │ ├─────────────────────────────────┼────────────────────────────────┼───────────┼────────┤ │ docker.io/library/debian:latest │ sha256:820a611dc036cb57cee7... │ analyzed  │ active │ └─────────────────────────────────┴────────────────────────────────┴───────────┴────────┘ Results Once analysis is complete, we can inspect the results, again with anchorectl. Container contents First, let’s see what Operating System packages Anchore found in this container with anchorectl image content docker.io/library/debian:latest -t os anchorectl reporting the full OS package list from this Debian image. (the list is too large to show here) SBOM We can also pull the Software Bill of Materials (SBOM) for this image from Anchore with anchorectl image sbom docker.io/library/debian:latest -o table. We can use -f to write this to a file, and -o syft-json (for example) to output in a different format. $ # Get a list of OS packages in the image $ ANCHORECTL_USERNAME=dev_admin_beta \ ANCHORECTL_PASSWORD=CorrectHorseBatteryStable \ ANCHORECTL_ACCOUNT=dev_team_beta \ anchorectl image sbom docker.io/library/debian:latest -o table  ✔ Fetched SBOM  docker.io/library/debian:latest NAME                    VERSION                TYPE adduser                 3.134                  deb apt                     2.6.1                  deb base-files              12.4+deb12u6           deb ⋮ util-linux              2.38.1-5+deb12u1       deb util-linux-extra        2.38.1-5+deb12u1       deb zlib1g                  1:1.2.13.dfsg-1 deb Vulnerabilities Finally let's have a quick look to see if any OS vulnerabilities were found in this image with anchorectl image vulnerabilities docker.io/library/debian:latest -t os. This is a lot of super-wide output, click through to see the full size image. Conclusion So far we've introduced AnchoreCTL, shown it's is easy to install, configure and test. It can be used both locally on developer workstations, and in CI/CD environments such as GitHub, GitLab and Jenkins. We'll cover the integration of AnchoreCTL with source forges in a later post. AnchoreCTL is a powerful tool which can be used to automate the management of scanning container contents, generating SBOMs, and analyzing for vulnerabilities. Find out more about AnchoreCTL in our documentation, and request a demo of Anchore Enterprise. ### Modernizing FedRAMP: GSA's Roadmap to Streamline Authorization If you've ever thought that the FedRAMP (Federal Risk and Authorization Management Program) authorization process is challenging and laborious, things may be getting better. The General Services Administration’s (GSA) has publicly committed to improving the authorization process by publishing a public roadmap to modernize FedRAMP.  The purpose of FedRAMP is to act as a central intermediary between federal agencies and cloud service providers (CSP) in order to make it easier for agencies to purchase software services and for CSPs to sell software services to agencies. By being the middleman, FedRAMP creates a single marketplace that reduces the amount of time it takes for an agency to select and purchase a product. From the CSP perspective, FedRAMP becomes a single standard that they can target for compliance and after achieving authorization they get access to 200+ agencies that they can sell to—a win-win. Unfortunately, that promised land wasn't the typical experience for either side of the exchange. Since FedRAMP's inception in 2011, the demand for cloud services has increased significantly. Cloud was still in its infancy at the birth of FedRAMP and the majority of federal agencies still procured software with perpetual licenses rather than as a cloud service (e.g., SaaS). In the following 10+ years that have passed, that preference has inverted and now the predominant delivery model is infrastructure/platform/software-as-a-service. This has led to an environment where new cloud services are popping up every year but federal agencies don't have access to them via the streamlined FedRAMP marketplace. On the other side of the coin, CSPs want access to the market of federal agencies that are only able to procure software via FedRAMP but the process of becoming FedRAMP certified is a complex and laborious process that reduces the opportunity cost of access to this market. Luckily, the GSA isn't resting on its laurels. Due to feedback from all stakeholders they are prioritizing a revamp of the FedRAMP authorization process to take into account the shifting preferences in the market. To help you get a sense of what is happening, how quickly you can expect changes and the benefits of the initiative, we have compiled a comprehensive FAQ. Watch Now Frequently Asked Questions (FAQ) How soon will the benefits of FedRAMP modernization be realized? Optimistically changes will be rolling out over the next 18 months and be completed by the end of 2025. See the full rollout schedule on the public roadmap. Who does this impact? Federal agencies Cloud service providers (CSP) Third-party assessment organization (3PAO) What are the benefits of the FedRAMP modernization initiative? TL;DR—For agencies Increased vendor options within the FedRAMP marketplace Reduced wait time for CSPs in authorization process TL;DR—For CSPs Reduced friction during the authorization process More clarity on how to meet security requirements Less time and cost spent on the authorization process TL;DR—For 3PAOs Reduced friction between 3PAO and CSP during authorization process Increased clarity on how to evaluate CSPs What prompted the GSA to improve FedRAMP now? GSA is modernizing FedRAMP because of feedback from stakeholders. Both federal agencies and CSPs levied complaints about the current FedRAMP process. Agencies wanted more CSPs in the FedRAMP marketplace that they could then easily procure. CSPs wanted a more streamlined process so that they could get into the FedRAMP marketplace faster. The point of friction was the FedRAMP authorization process that hasn't evolved at the same pace as the transition from the on-premise, perpetual license delivery model to the rapid, cloud services model. How will GSA deliver on its promises to modernize FedRAMP? The full list of initiatives can be found in their public product roadmap document but the highlights are: Taking a customer-centric approach that reduces friction in the authorization process based on customer interviews Publishing clear guidance on how to meet core security requirements Streamlining authorization process to reduce bottlenecks based on best practices from agencies that have developed a strong authorization process Moving away from lengthy documents and towards a data-first foundation to enable automation of the authorization process for CSPs and 3PAOs Wrap-Up The GSA has made a commitment to being transparent about the improvements to the modernization process. Anchore, as well as, the rest of the public sector stakeholders will be watching and holding the GSA accountable. Follow this blog or the Anchore LinkedIn page to stay updated on progress.If the 18 month timeline is longer than you're willing to wait, Anchore is already an expert in supporting organizations that are seeking FedRAMP authorization. Anchore Enterprise is a modern, cloud-native software composition analysis (SCA) platform that both meets FedRAMP compliance standards and helps evaluate whether your software supply chain is FedRAMP compliant. If you're interested to learn more, download "FedRAMP Requirements Checklist for Container Vulnerability Scanning" or learn more about how Anchore Enterprise has helped organizations like Cisco achieve FedRAMP compliance in weeks versus months. Download Now ### Add SBOM Generation to Your GitHub Project with Syft According to the latest figures, GitHub has over 100 million developers working on over 420 million repositories, with at least 28M being public repos. Unfortunately, very few software repos contain a Software Bill of Materials (SBOM) inventory of what's been released. SBOMs (Software Bill of Materials) are crucial in a repository as they provide a comprehensive inventory of all components, improving transparency and traceability in the software supply chain. This allows developers and security teams to quickly identify and address vulnerabilities, enhancing overall security and compliance with regulatory standards. Anchore developed the sbom-action GitHub Action to automatically generate an SBOM using Syft. Developers can quickly add the action via the GitHub Marketplace and pretty much fire and forget the setup. What is an SBOM? Anchore developers have written plenty over the years about What is an SBOM, but here is the tl;dr: An SBOM (Software Bill of Materials) is a detailed list of all software project components, libraries, and dependencies. It serves as a comprehensive inventory that helps understand the software's structure and the origins of its components. An SBOM in your project enhances security by quickly identifying and mitigating vulnerabilities in third-party components. Additionally, it ensures compliance with regulatory standards and provides transparency, essential for maintaining trust with stakeholders and users. Introducing Anchore's SBOM GitHub Action Adding an SBOM is a cinch with the GitHub Action for SBOM Generation provided by Anchore. Once added to a repo the action will execute a Syft scan in the workspace directory and upload a workflow artefact SBOM in SPDX format. The SBOM Action can scan a Docker image directly from the container registry with or without registry credentials specified. Alternatively, it can scan a directory full of artifacts or a specific single file. The action will also detect if it's being run during the GitHub release and upload the SBOM as a release asset. Easy! How to Add the SBOM GitHub Action to Your Project Assuming you already have a GitHub account and repository setup, adding the SBOM action is straightforward. Navigate to the GitHub Marketplace Search for "Anchore SBOM Action" or visit Anchore SBOM Action directly Add the action to your repository by clicking the green "Use latest version" button Configure the action in your workflow file That's it! Example Workflow Configuration Here's a bare-bones configuration for running the Anchore SBOM Action on each push to the repo. name: Generate SBOM on: [push] jobs: build: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v2 - name: Anchore SBOM Action uses: anchore/sbom-action@v0.16.0 There are further options detailed on the GitHub Marketplace page for the action. For example, use output-file to specify the resulting SBOM file name and format to select whether to build an SPDX or CycloneDX formatted SBOM. Results and Benefits After the GitHub action is set up, the SBOM will start being generated on each push or with every release - depending on your configuration. Once the SBOM is published on your GitHub repo, users can analyze it to identify and address vulnerabilities in third-party components. They can also use it to ensure compliance with security and regulatory standards, maintaining the integrity of the software supply chain. Additional Resources The SBOM action is open source and is available under the Apache 2.0 License in the sbom-action repository. It relies on Syft which is available under the same license, also on GitHub. We welcome contributions to both sbom-action and Syft, as well as Grype, which can consume and process these generated SBOMs. Join us on Discourse to discuss all our open source tools. ### Easy Compliance is Continuous Compliance ### DevSecOps - Editorial Roundtable ### Reduce risk in your software supply chain: 5 tips for container security Rising threats to the software supply chain and increasing use of containers are causing organizations to focus on container security. Containers bring many unique security challenges due to their layered dependencies and the fact that many container images come from public repositories. Our new white paper, Reduce Risk for Software Supply Chain Attacks: Best Practices for Container Security, digs into 5 tips for securing containers. It also describes how Anchore Enterprise simplifies implementation of these critical best practices, so you don’t have to. 5 best practices to instantly strengthening container security Use SBOMs to build a transparent foundation SBOMs—Software Bill of Materials—create a trackable inventory of the components you use, which is a precursor for identifying security risks, meeting regulatory requirements and assessing license compliance. Get recommendations on the best way to generate, store, search and share SBOMs for better transparency.   Identify vulnerabilities early with continuous scanning Security issues can arise at any point in the software supply chain. Learn why shifting left is necessary, but not sufficient for container security. Understand the role SBOMs are critical when responding to zero-day vulnerabilities. Automate policy enforcement and security gates Find out how to use automated policies to identify which vulnerabilities should be fixed and enforce regulatory requirements. Learn how a customizable policy engine and out-of-the-box policy packs streamline your compliance efforts.  Reduce toil in the developer experience Integrating with the tools developers use, minimizing false positives, and providing a path to faster remediation will keep developers happy and your software development moving efficiently.  See how Anchore Enterprise makes it easy to provide a good developer experience Protect your software supply chain with security controls To protect your software supply chain, you must ensure that the code you bring in from third-party sources is trusted and vetted. Implement vetting processes for open-source code that you use. Download Now ### Four Years of Syft Development in 4 Minutes at 4K Our open-source SBOM and vulnerability scanning tools Syft and Grype, recently turned four years old. So I did what any nerd would do: render an animated visualization of the development using the now-venerable Gource. Initially, I wanted to render these videos at 120Hz framerate, but that didn't go well. Read on to find out how that panned out. My employer (perhaps foolishly) gave me the keys to our Anchore YouTube and Anchore Vimeo accounts. You can find the video I rendered on YouTube or embedded below. For those unaware, Gource is a popular open-source project by Andrew Caudwell. Its purpose is to visualize development with pretty OpenGL-rendered videos. You may have seen these animated glowing renders before, as Gource has been around for a while now. Syft is Anchore's command-line tool and library for generating a software bill of materials (SBOM) from container images and filesystems. Grype is our vulnerability scanner for container images and filesystems. They're both fundamental components of our Anchore Enterprise platform but are also independently famous. Generating the video Plenty of guides online cover how to build Gource visualizations, which are pretty straightforward. Gource analyses the git log of changes in a repository to generate frames of animation which can be viewed or saved to a video. There are settings to control various aspects of the animation, which are well documented in the Gource Wiki. By default, while Gource is running, a window displaying the animation will appear on your screen. So, if you want to see what the render will look like, most of the defaults are fine when running Gource directly. Tweak the defaults I wanted to limit the video duration, and render at a higher resolution than my laptop panel supports. I also wanted the window to be hidden while the process runs. tl;dr Here's the full command line I used to generate and encode the 4K video in the background. $ /usr/bin/xvfb-run --server-num=99 -e /dev/stdout \ -s '-screen 0 4096x2160x24 ' /usr/bin/gource \ --max-files 0 --font-scale 4 --output-framerate 60 \ -4096x2160 --auto-skip-seconds 0.1 --seconds-per-day 0.16 \ --bloom-multiplier 0.9 --fullscreen --highlight-users \ --multi-sampling --stop-at-end --high-dpi \ --user-image-dir ../faces/ --start-date 2020-05-07 \ --title 'Syft Development https://github.com/anchore/syft' \ -o - \ ffmpeg -y -r 60 -f image2pipe -vcodec ppm -i - \ -vcodec libx264 -preset veryfast -pix_fmt yuv420p \ -crf 1 -threads 0 -bf 0 ../syft-4096x2160-60.mkv Let's take a step back and examine the preparatory steps and some interesting points to note. Preparation The first thing to do is to get Gource and ffmpeg. I'm using Ubuntu 24.04 on my ThinkPad Z13, so a simple sudo apt install gource ffmpeg works. Grab the Syft and/or Grype source code. $ mkdir -p ~/Videos/gource/ $ cd ~/Videos/gource $ git clone https://github.com/anchore/syft $ git clone https://github.com/anchore/grype Gource can use avatar images in the videos which represent the project contributors. I used gitfaces for this. Gitfaces is available from PyPI, so can be installed with pip install -U gitfaces or similar. Once installed, generate the avatars from within the project folder. $ cd ~/Videos/gource/syft $ mkdir ../faces $ gitfaces . ../faces Do this for each project you wish to render out. I used a central ../faces folder as there would be some duplication between the projects I'm rendering. However, not everyone has an avatar, so they'll show up as an anonymous "head and shoulders" in the animation. Test render Perform a quick test to ensure Gource is installed correctly and the avatars are working. $ cd ~/Videos/gource/syft $ /usr/bin/gource --user-image-dir ../faces/  A default-sized window of 1052x834 should appear with nicely rendered blobs and lines. If you watch it for any appreciable length, you'll notice it can be boring in the gaps between commits. Gource has some options to improve this. The --auto-skip-seconds option defines when Gource will skip to the next entry in the git log while there is no activity. The default is 3 seconds, which can be reduced. With --seconds-per-day we can set the render speed so we don't get a very long video. I used 0.1 and 0.16, respectively. The result is a shorter, faster, more dynamic video. The Gource Wiki details many other options for Gource. Up the resolution! While the default 1052x834 video size is fine for a quick render, I wanted something much bigger. Using the '4 years in 4 minutes at 4K' heading would be fun, so I went for 4096x2160. My laptop doesn't have a 4K display (it's 2880x1800 natively), so I decided to render it in the background, saving it to a video. To run it in the background, I used xvfb-run from the xvfb package on my Ubuntu system. A quick sudo apt install xvfb installed it. To run Gource inside xvfb we simply prefix the command line like this: (this is not the full command, just a snippet to show the xvfb syntax) $ /usr/bin/xvfb-run --server-num=99 -e /dev/stdout \ -s '-screen 0 4096x2160x24 ' /usr/bin/gource -4096x2160 Note that the XServer's resolution matches the video's, and we use the fullscreen option in Gource to use the whole virtual display. Here we also specify the color bit-depth of the XServer - in this case 24. Create the video Using ffmpeg—the Swiss army knife of video encoding—we can turn Gource's output into a video. I used the x264 codec with some reasonable options. We can run these as two separate commands: one to generate a (huge) series of ppm images and the second to compress that into a reasonable file size. $ /usr/bin/xvfb-run --server-num=99 -e /dev/stdout \ -s '-screen 0 4096x2160x24 ' /usr/bin/gource \ --max-files 0 --font-scale 4 --output-framerate 60 \ -4096x2160 --auto-skip-seconds 0.1 --seconds-per-day 0.16 \ --bloom-multiplier 0.9 --fullscreen --highlight-users \ --multi-sampling --stop-at-end --high-dpi \ --user-image-dir ../faces/ --start-date 2020-05-07 \ --title 'Syft Development: https://github.com/anchore/syft' \ -o ../syft-4096x2160-60.ppm $ ffmpeg -y -r 60 -f image2pipe -vcodec ppm \ -i ../syft-4096x2160-60.ppm -vcodec libx264 \ -preset veryfast -pix_fmt yuv420p -crf 1 \ -threads 0 -bf 0 ../syft-4096x2160-60.mkv Four years of commits as uncompressed 4K60 images will fill the disk pretty fast. So it's preferable to chain the two commands together so we save time and don't waste too much disk space. $ /usr/bin/xvfb-run --server-num=99 -e /dev/stdout \ -s '-screen 0 4096x2160x24 ' /usr/bin/gource \ --max-files 0 --font-scale 4 --output-framerate 60 \ -4096x2160 --auto-skip-seconds 0.1 --seconds-per-day 0.16 \ --bloom-multiplier 0.9 --fullscreen --highlight-users \ --multi-sampling --stop-at-end --high-dpi \ --user-image-dir ../faces/ --start-date 2020-05-07 \ --title 'Syft Development: https://github.com/anchore/syft' \ -o - ffmpeg -y -r 60 -f image2pipe -vcodec ppm -i - \ -vcodec libx264 -preset veryfast -pix_fmt yuv420p \ -crf 1 -threads 0 -bf 0 ../syft-4096x2160-60.mkv On my ThinkPad Z13 equipped with an AMD Ryzen 7 PRO 6860Z CPU, this takes around 42 minutes and generates a ~10GB mkv video. Here's what the resource utilisation looks like while this is running. Fully maxed out all the CPU cores. Toasty! Challenges More frames Initially, I considered creating a video at 120fps rather than the default 60fps that Gource generates. However, Gource is limited in code to 25, 30, and 60fps. As an academic exercise, I patched Gource (diff below) to generate visualizations at the higher frame rate. I'm not a C++ developer, nor do I play one on TV! But with a bit of grep and a small amount of trial and error, I modified and rebuilt Gource to add support for 120fps. diff --git a/src/core b/src/core --- a/src/core +++ b/src/core @@ -1 +1 @@ -Subproject commit f7fa400ec164f6fb36bcca5b85d2d2685cd3c7e8 +Subproject commit f7fa400ec164f6fb36bcca5b85d2d2685cd3c7e8-dirty diff --git a/src/gource.cpp b/src/gource.cpp index cf86c4f..755745f 100644 --- a/src/gource.cpp +++ b/src/gource.cpp @@ -153,7 +153,7 @@ Gource::Gource(FrameExporter* exporter) { root = 0; //min physics rate 60fps (ie maximum allowed delta 1.0/60) - max_tick_rate = 1.0 / 60.0; + max_tick_rate = 1.0 / 120.0; runtime = 0.0f; frameskip = 0; framecount = 0; @@ -511,7 +511,7 @@ void Gource::setFrameExporter(FrameExporter* exporter, int video_framerate) { this->frameskip = 0; //calculate appropriate tick rate for video frame rate - while(gource_framerate<60) { + while(gource_framerate<120) { gource_framerate += video_framerate; this->frameskip++; } I then re-ran Gource with --output-framerate 120 and ffmpeg with -r 120, which successfully generated the higher frame-rate files. $ ls -lh -rw-rw-r-- 1 alan alan 7.3G Jun 15 21:42 syft-2560x1440-60.mkv -rw-rw-r-- 1 alan alan 8.9G Jun 15 22:14 grype-2560x1440-60.mkv -rw-rw-r-- 1 alan alan  13G Jun 16 22:56 syft-2560x1440-120.mkv -rw-rw-r-- 1 alan alan  16G Jun 16 22:33 grype-2560x1440-120.mkv As you can see and probably expect on some test renders, with these settings, double the frames means double the size. I could have fiddled with ffmpeg to use better-optimized options, or a different codec, but decided against it. There's an even more significant issue here. There are precious few places to host high-frame-rate videos; few people have the hardware, bandwidth, and motivation to watch them. So, I rolled back to 60fps for subsequent renders. More pixels While 4K (4096x2160) is fun and fits the story of "4 years in 4 minutes at 4K", I did consider trying to render out at 8K (7680×4320). After all, I had time on my hands at the weekend and spare CPU cycles, so why not? Sadly, the hardware x264 encoder in my ThinkPad Z13 has a maximum canvas size of 4096x4096, which is far too small for 8K. I could have encoded using software rather than hardware acceleration, but that would have been ludicrously more time-consuming. I do have an NVIDIA card but don't believe it's new enough to do 8K either, being a 'lowly' (these days) GTX 2080Ti. My work laptop is an M3 MacBook Pro. I didn't attempt rendering there because I couldn't fathom getting xvfb working to do off-screen rendering in Gource on macOS. I have another four years to figure this out before my ‘8 years of Syft in 8 minutes at 8K’ video, though! Minor edits Once Gource and ffmpeg did their work, I used Kdenlive to add some music and our stock "top and tail" animated logo to the video and then rendered it for upload. The default compression settings in Kdenlive dramatically reduced the file size to something more manageable and uploadable! Conclusion Syft and Grype are - in open source terms - relatively young, with a small, dedicated team working on them. As such, the Gourse renders aren't as busy or complex as more well-established projects with bigger teams. We certainly welcome external contributions over on the Syft and Grype repositories. We also have a new Anchore Community Discourse where you can discuss the projects and this article. If you'd like to see how Syft and Grype are integral to your SBOM generation, vulnerability and policy enforcement tools, contact us and watch the guided tour. I always find these renders technically neat, beautiful and relaxing to watch. The challenges of rendering them also led me down some interesting technical paths. I'd love to hear feedback and suggestions over on the Anchore Community Discourse ### Balancing the Scale: Software Supply Chain Security and APTs Note: This is a multi-part series primer on the intersection of advanced persistent threats (APTs) and software supply chain security (SSCS). This blog post is the first in the series. We will update this blog post with links to the additional parts of the series as they are published.• Part 1 | With Great Power Comes Great Responsibility: APTs & Software Supply Chain Security• Part 2 | David and Goliath: the Intersection of APTs and Software Supply Chain Security• Part 3 (This blog post) Last week we dug into the details of why an organization's software supply chain is a ripe target for well-resourced groups like APTs and the potential avenues that companies have to combat this threat. This week we're going to highlight the Anchore Enterprise platform and how it provides a turnkey solution for combating threats to any software supply chain. How Anchore Can Help Anchore was founded on the belief that a security platform that delivers deep, granular insights into an organization's software supply chain, covers the entire breadth of the SDLC and integrates automated feedback from the platform will create a holistic security posture to detect advanced threats and allow for human interaction to remediate security incidents. Anchore is trusted by Fortune 100 companies and the most exacting federal agencies across the globe because it has delivered on this promise. The rest of the blog post will detail how Anchore Enterprise accomplishes this. Depth: Automating Software Supply Chain Threat Detection Having deeper visibility into an organization's software supply chain is crucial for security purposes because it enables the identification and tracking of every component in the software's construction. This comprehensive understanding helps in pinpointing vulnerabilities, understanding dependencies, and identifying potential security risks. It allows for more effective management of these risks by enabling targeted security measures and quicker response to potential threats. Essentially, deeper visibility equips an organization to better protect itself against complex cyber threats, including those that exploit obscure or overlooked aspects of the software supply chain. Anchore Enterprise accomplishes this by generating a comprehensive software bill of materials (SBOM) for every piece of software (even down to the component/library/framework-level). It then compares this detailed ingredients list against vulnerability and active exploit databases to identify exactly where in the software supply chain there are security risks. These surgically precise insights can then be fed back to the original software developers, rolled-up into reports for the security team to better inform risk management or sent directly into an incident management workflow if the vulnerability is evaluated as severe enough to warrant an "all-hands on deck" response. Developers shouldn’t have to worry about manually identifying threats and risks inside your software supply chain. Having deep insights into your software supply chain and being able to automate the detection and response is vital to creating a resilient and scalable solution to the risk of APTs. Breadth: Continuous Monitoring in Every Step of Your Software Supply Chain The breadth of instrumentation in the Software Development Lifecycle (SDLC) is crucial for securing the software supply chain because it ensures comprehensive security coverage across all stages of software development. This broad instrumentation facilitates early detection and mitigation of vulnerabilities, ensures consistent application of security policies, and allows for a more agile response to emerging threats. It provides a holistic view of the software's security posture, enabling better risk management and enhancing the overall resilience of the software against cyber threats. Powered by a 100% feature complete platform API, Anchore Enterprise integrates into your existing DevOps pipeline. Anchore Enterprise Integrations with Popular DevOps Tools Anchore has been supporting the DoD in this effort since 2019. Commonly referred to as "overwatch" for the DoD's software supply chain. Anchore Enterprise continuously monitors how risk is evolving based on the ingesting of tens of thousands of runtime containers, hundreds of source code repositories and alerting on malware-laced images submitted to the registry. Monitoring every stage of the DevOps pipeline, source to build to registry to deploy, to gain a holistic view of when and where threats enter the software development lifecycle. Feedback: Alerting on Breaches or Critical Events in Your Software Supply Chain Integrating feedback from your software supply chain and SDLC into your overall security program is important because it allows for real-time insights and continuous improvement in security practices. This integration ensures that lessons learned and vulnerabilities identified at any stage of the development or deployment process are quickly communicated and addressed. It enhances the ability to preemptively manage risks and adapt to new threats, thereby strengthening the overall security posture of the organization. How would you know if something is wrong in a system? Create high-quality feedback loops, of course. If there is a fire in your house, you typically have a fire alarm. That is a great source of feedback. It's loud and creates urgency. When you investigate to confirm the fire is legitimate and not a false alarm; you can see fire, you can feel fire. Software supply chain breaches are more similar to carbon monoxide leaks. Silent, often undetected, and potentially lethal. If you don’t have anything in place to specifically alert for that kind of threat then you could pay severely.  Anchore Enterprise was designed specifically as both a set of sensors that can be deployed both deeply and broadly into your software supply chain AND a system of feedback that uses the sensors in your supply chain to detect and alert on potential threats that are silently emitting carbon monoxide in your warehouse. Anchore Enterprise's feedback mechanisms come in three flavors; automatic, recommendations and informational. Anchore Enterprise utilizes a policy engine to enable automatic action based on the feedback provided by the software supply chain sensors. If you want to make sure that no software is ever deployed into production (or any environment) with an exploitable version of Log4j the Anchore policy engine can review the security metadata created by the sensors for the existence of this software component and stop a deployment in progress before it ever becomes accessible to attackers. Anchore Enterprise can also be configured to make recommendations and provide opinionated actions based on security signals. If a vulnerability is discovered in a software component but it isn't considered urgent, Anchore Enterprise can instead provide a recommendation to the software developer to fix the vulnerability but still allow them to continue to test and deploy their software. This allows developers to become aware of security issues very early in the SDLC but also provide flexibility for them to fix the vulnerability based on their own prioritization. Finally, Anchore Enterprise offers informational feedback that alerts developers, the security team or even the executive team to potential security risks but doesn't offer a specific solution. These types of alerts can be integrated into any development, support or incident management systems the organization utilizes. Often these alerts are for high risk vulnerabilities that require deeper organizational analysis to determine the best course of action in order to remediate. Conclusion Due to the asymmetry between APTs and under-resourced security teams, the goal isn't to create an impenetrable fortress that can never be breached. The goal is instead to follow security best practices and instead litter your SDLC with sensors and automated feedback mechanisms. APTs may have significantly more resources than your security team but they are still human and all humans make mistakes. By placing low-effort tripwires in as many locations as possible, you reverse the asymmetry of resources and instead allow the well-resourced adversary to become their own worst enemy. APTs are still software developers at the end of the day and no one writes bug-free code in the long run. By transforming your software supply chain into a minefield of best practices, you create a battlefield that requires your adversaries to slow down and carefully disable each individual security mechanism. None are impossible to disarm but each speed bump creates another opportunity for your adversary to make a mistake and reveal themselves. If the zero-trust architecture has taught us anything, it is that an impenetrable perimeter was never the best strategy. ### How to Secure Your Kubernetes Software Supply Chain at Scale SBOM & Vulnerability Scanning with Anchore and Palette ### Improving Syft’s Binary Detection You, too, can help make Syft better! As you’re probably aware, Syft is a software composition analysis tool which is able to scan a number of sources to find software packages in container images and the local filesystem. Syft detects packages from a number of things such as source code and package manager metadata, but also from arbitrary files it encounters such executable binaries. Today we’re going to talk about how some of Syft’s binary detection works and how easy it is to improve. Just recently, we were made aware of this vulnerability and it seemed like something we’d want to surface in Syft’s companion tool, Grype… but Fluent Bit wasn’t something that Syft was already detecting. Let’s look at how we added support for it! Download Now Syft binary matching Before we get into the details, it’s important to understand how Syft’s binary detection works today: Syft scans a filesystem, and a binary cataloger looks for files matching a particular name pattern and uses a regular expression to find a version string in the binary. Although this isn’t the only thing Syft does, this has proven to be a simple pattern that works fairly well for finding information about arbitrary binaries, such as the Fluent Bit binary we’re interested in. In order to add support for additional binary types in Syft, the basic process is this: Find a binary Add a matching rule Add tests Getting started Starting with a local fork of the Syft repository, let’s work in the binary cataloger’s test-fixtures directory: $ cd syft/pkg/cataloger/binary/test-fixtures Here you’ll find a Makefile and a config.yaml. These are the main things of importance — and you can run make help to see extra commands available. The first thing we need to do is find somewhere to get one of the binaries from — we need something to test that we’re actually detecting the right thing! The best way to do this is using a publicly available container image. Once we know an image to use, the Makefile has some utilities to make the next steps fairly straightforward. After a short search online, we found that there is indeed a public docker image with exactly what we were looking for: https://hub.docker.com/r/fluent/fluent-bit. Although we could pick just about any version, we somewhat arbitrarily chose this one. We can use more than one, but for now we’re just going to use this as a starting point. Adding a reference to the binary After finding an image, we need to identify the particular binary file to look at. Luckily, the Fluent Bit documentation gave a pretty good pointer – this was part of the docker command the documentation said to run: /fluent-bit/bin/fluent-bit! It may take a little more sleuthing to figure out what file(s) within the image we need; often you can run an image with a shell to figure this out... but chances are, if you can run the command with a --version flag and get the version printed out, we can figure out how to find it in the binary. For now, let’s continue on with this binary. We need to add an entry that describes where to find the file in question in the syft/pkg/cataloger/binary/test-fixtures/config.yaml: - version: 3.0.2 images: - ref: fluent/fluent-bit:3.0.2-amd64@sha256:7e6fe8efd51dda0739e355f58bf5e3b1623cbf2d4a23c06c7a365d9553e2d242 platform: linux/amd64 paths: - /fluent-bit/bin/fluent-bit There are lots of examples in that file already, and hopefully the fields are straightforward but note the version — this is what we’ve ascertained should be reported and it will drive some functions later. Also, we’ve included the full sha256 hash, so even if the tags change, we’ll get the expected image. Then just run make: $ make go run ./manager download --skip-if-covered-by-snippet ... fluent-bit@3.0.2 ✔ pull image fluent/fluent-bit:3.0.2-amd64@sha256:7e6fe8efd51dda0739e355f58bf5e3b1623cbf2d4a23c06c7a365d9553e2d242 (linux/amd64) ✔ extract /fluent-bit/bin/fluent-bit This pulled the image locally and extracted the file we told it to…but so far we haven’t really done much that you couldn’t do with standard container tools. Finding the version Now we need to figure out what type of expression should reliably find the version. There are a number of binary inspection tools, many of which can make this easier and perhaps you have some favorites — by all means use those! But we’re going to stick with the tools at hand. Let’s take a look at what the binary has matching the version we indicated earlier by running make add-snippet:  $ make add-snippet go run ./manager add-snippet running: ./capture-snippet.sh classifiers/bin/fluent-bit/3.0.2/linux-amd64/fluent-bit 3.0.2 --search-for 3\.0\.2 --group fluent-bit --length 100 --prefix-length 20 Using binary file: classifiers/bin/fluent-bit/3.0.2/linux-amd64/fluent-bit Searching for pattern: 3\.0\.2 Capture length: 120 bytes Capture prefix length: 20 bytes Multiple string matches found in the binary: 1) 3.0.2 2) 3.0.2 3) CONNECT {"verbose":false,"pedantic":false,"ssl_required":false,"name":"fluent-bit","lang":"c","version":"3.0.2"} Please select a match: Follow the prompts to inspect the different sections of the binary. Each of these actually looks like it could be something usable, but we want one that hopefully is simple to match across different versions. The third match has JSON, which possibly could get reordered. Looking at the second we can see something that has a string containing only 3.0.2 but let’s take a closer look at the first match. If we look at 1, we see something like the second that has a string containing only the version, 3.0.2, but we also see %sFluent Bit, nearby. This looks promising! Let’s capture this snippet by following the prompts: Please select a match: 1 006804fc: 2525 2e25 6973 0a00 252a 733e 2074 7970 %%.%is..%*s> typ 0068050c: 653a 2000 332e 302e 3200 2573 466c 7565 e: .3.0.2.%sFlue 0068051c: 6e74 2042 6974 2076 2573 2573 0a00 2a20 nt Bit v%s%s..* 0068052c: 6874 7470 733a 2f2f 666c 7565 6e74 6269 https://fluentbi 0068053c: 742e 696f 0a0a 0069 6e76 616c 6964 2063 t.io...invalid c 0068054c: 7573 746f 6d20 706c 7567 696e 2027 2573 ustom plugin '%s 0068055c: 2700 696e 7661 6c69 6420 696e 7075 7420 '.invalid input 0068056c: 706c 7567 696e 2027 plugin ' Does this snippet capture what you need? (Y/n/q) y wrote snippet to "classifiers/snippets/fluent-bit/3.0.2/linux-amd64/fluent-bit" How could we tell the NULL terminators? What’s going on here? Looking at the readable text on the right, we see: .3.0.2., but the bytes are also displayed in the same position: 00 332e 302e 3200 and we know 00 is a NULL character because we’ve done quite a lot of these expressions. This is the hardest part, believe me! But if you’re still following along, let’s wrap this up by putting everything we’ve found together in a rule. Adding a rule to Syft Edit the syft/pkg/cataloger/binary/classifiers.go and add an entry for this binary: { Class: "fluent-bit-binary", FileGlob: "**/fluent-bit", EvidenceMatcher: FileContentsVersionMatcher( // [NUL]3.0.2[NUL]%sFluent Bit `\x00(?P[0-9]+\.[0-9]+\.[0-9]+)\x00%sFluent Bit`, ), Package: "fluent-bit", PURL: mustPURL("pkg:github/fluent/fluent-bit@version"), CPEs: singleCPE("cpe:2.3:a:treasuredata:fluent_bit:*:*:*:*:*:*:*:*"), }, We’ve put the information we know about this in the entry: the FileGlob should find the file, as we’ve seen earlier, the FileContentsVersionMatcher takes a regular expression to extract the version. And I went ahead and looked up the format for the CPE and PURL this package should use and included these here, too. Once we’ve added this, you can test it out right away by running your modified Syft code from the base directory of your git clone: $ go run ./cmd/syft fluent/fluent-bit:3.0.2-amd64 ✔ Pulled image ✔ Loaded image fluent/fluent-bit:3.0.2-amd64 ✔ Parsed image sha256:2007231667469ee1d653bdad65e55cc5f300985f10d7c4dffd6de0a5e76ff078 ✔ Cataloged contents d3a6e4b5bc02c65caa673a2eb3508385ab27bb22252fa684061643dbedabf9c7 ├── ✔ Packages [39 packages] ├── ✔ File digests [1,771 files] ├── ✔ File metadata [1,771 locations] └── ✔ Executables [313 executables] NAME VERSION TYPE base-files 11.1+deb11u9 deb ca-certificates 20210119 deb fluent-bit 3.0.2 binary libatomic1 10.2.1-6 deb ... Great! It worked! If we try this out on some different versions, it looks like 3.0.1-amd64 works as well but this definitely did not work for 2.2.1-arm64 or 2.1.10, so we just repeat the process a bit and find out that we just need to make our expression a bit better to account for the variance in the arm64 versions having a couple extra NULL characters and the older versions not having the %s part. Eventually, this expression seemed to do the trick for the images I tried: x00(?P[0-9]+.[0-9]+.[0-9]+)x00[^d]*Fluent. We could have made this simpler — to just find , but there are quite a few strings in the various binaries that match this pattern and we want to try our best to find the one that looks like it’s the specific version string we want. When we looked at the various bytes across a number of versions both the version and the name of the project showed up together like this. Having done a number of these classifiers in the past, I can say this is a fairly common type of thing to look for. Testing Since we already captured a test snippet, the last thing to do is add a test. If you recall, when we used the add-snippet command, it told us:  wrote snippet to u0022classifiers/snippets/fluent-bit/3.0.2/linux-amd64/fluent-bitu0022 This is what we’re going to want to reference. So let’s add a test case to syft/pkg/cataloger/binary/classifier_cataloger_test.go, the very large Test_Cataloger_PositiveCases test: { logicalFixture: "fluent-bit/3.0.2/linux-amd64", expected: pkg.Package{ Name: "fluent-bit", Version: "3.0.2", Type: "binary", PURL: "pkg:github/fluent/fluent-bit@3.0.2", Locations: locations("fluent-bit"), Metadata: metadata("fluent-bit-binary"), }, }, Wrapping up Now that we have: 1) identified a binary 2) added a rule to Syft, and 3) added a test case with a small snippet, we’re done coding! Submit a pull request and sit back, knowing you’ve made the world a better place! Watch Now ### David and Goliath: the Intersection of APTs and Software Supply Chain Security Note: This is a multi-part series primer on the intersection of advanced persistent threats (APTs) and software supply chain security (SSCS). This blog post is the second in the series. If you'd like to start from the beginning, you can find the first blog post here. Last week we set the stage for discussing APTs and the challenges they pose for software supply chain security by giving a quick overview of each topic. This week we will dive into the details of how the structure of the open source software supply chain is a uniquely ripe target for APTs. The Intersection of APTs and Software Supply Chain Security The Software Ecosystem: A Ripe Target APT groups often prioritize the exploitation of software supply chain vulnerabilities. This is due to the asymmetric structure of the software ecosystem. By breaching a single component, such as a build system, they can gain access to any organization using the compromised software component. This creates an inversion in the cost benefit of the effort involved in the research and development effort needed to discover a vulnerability and craft an exploit for the vulnerability. Before APTs were focused primarily on targets where the pay off could warrant the investment or vulnerabilities that were so wide-spread that the attack could be automated. The complex interactions of software dependencies allows APTs to scale their attack due to the structure of the ecosystem. The Software Supply Chain Security Dynamic: An Unequal Playing Ground The interesting challenge with software supply chain security is that securing the supply chain requires even more effort than an APT would take to exploit it. The rub comes because each company that consumes software has to build a software supply chain security system to protect their organization. An APT investing in exploiting a popular component or system gets the benefit of access to all of the software built on top of it. Given that security organizations are at a structural disadvantage, how can organizations even the odds? How Do I Secure My Software Supply Chain from APTs? An organization's ability to detect the threat of APTs in its internal software supply chain comes down to three core themes that can be summed up as "go deep, go wide and integrate feedback". Specifically this means, the deeper the visibility into your organization's software supply chain the less surface area an attack has to slip in malicious software. The wider this visibility is deployed across the software development lifecycle, the earlier an attacker will be caught. Neither of the first two points matter if the feedback produced isn't integrated into the overall security program that can act on the signals surfaced. By applying these three core principles to the design of a secure software supply chain, an organization can ensure that they balance the playing field against the structural advantage APTs possess. How Can I Easily Implement a Strategy for Securing My Software Supply Chain? The core principles of depth, breadth and feedback are powerful touchstones to utilize when designing a secure software supply chain that can challenge APTs but they aren't specific rules that can be easily implemented. To address this, Anchore has created the open source VIPERR Framework to provide specific guidance on how to achieve the core principles of software supply chain security. VIPERR is a free software supply chain security framework that Anchore created for organizations to evaluate and improve the security posture of their software supply chain. VIPERR stands for visibility, inspection, policy enforcement, remediation, and reporting.  Utilizing the VIPERR Framework an organization can satisfy the three core principles of software supply chain security; depth, breadth and feedback. By following this guide, numerous Fortune 500 enterprises and top federal agencies have transformed their software supply chain security posture and become harder targets for advanced persistent threats. If you're looking to design and run your own secure software supply chain system, this framework will provide a shortcut to ensure the developed system will be resilient.  How Can I Comprehensively Implement a Strategy for Securing My Software Supply Chain? There are a number of different comprehensive initiatives to define best practices for software supply chain security. Organizations ranging from the National Institute of Standards and Technology (NIST) with standards such as SP 800-53, SP 800-218, and SP 800-161. The Cloud Native Computing Foundation (CNCF) to Open Source Security Foundation (OpenSSF) have created detailed documentation on their recommendations to achieve a comprehensive supply chain security program, such as, the SLSA framework and Secure Supply Chain Consumption Framework (S2C2F) Project. Be aware that these are not quick and dirty solutions for achieving a "reasonably" secure software supply chain. They are large undertakings for any organization and should be given the resources needed to achieve success.  We don't have the time to go over each in this blog post but we have broken each down in our complete guide to software supply chain security. This is the second in a series of blog posts focused on the intersection of APTs and software supply chain security. This blog post highlighted the reasons that APTs focus their efforts on software supply chain exploits and the potential avenues that companies have to combat this threat. Next week we will discuss the Anchore Enterprise solution as a turnkey platform to implement the strategies outlined above. ### Anchore Enterprise 5.6: Improved Remediation & Visibility with Account Context Switcher The Anchore Enterprise 5.6 release features updates to account management that enable administrators to context switch fast; analyzing and troubleshooting multiple datasets across multiple accounts. And allow users to share data across accounts easily and safely. Improve data isolation and performance with accounts and role-based access controls  Accounts are the highest level object in the Anchore Enterprise system. Each account has its own SBOM assets, users, policies, and reports that are siloed from other accounts in the system. Admins can separate their environment into different accounts based on teams, business units, projects, or products. With accounts, admins can isolate data to meet data security requirements or create workflows that are customized to the data flowing into that account.  Accounts allow secure data sharing in a single system. On top of that it enables performance improvements by reducing the total amount of data that is processed when updating records or generating reports. Each account can have users and roles assigned. Admins create users and set identification as well as permissions. Users have roles assigned that may have custom rights or privileges to data that can be viewed and managed within the account. Leveraging account context to improve remediation and visibility   In Anchore Enterprise an account object is a collection of settings and permissions that allow a user to access, maintain and manage data. Anchore Enterprise is a multi-tenancy system that consists of three logical components (accounts, users and permissions) providing flexibility for users to access and manage their data. On occasion users may need to access information that resides outside of their own account. To investigate or troubleshoot issues and to manage data visibility across teams, allowing account context is crucial. Within the Anchore Enterprise UI, the Account Context option enables “context switching” to view SBOMs, analysis, and reports of different accounts while still retaining the specific user profile. Also standard users are now provided with an additional level and vector of access control. Adding Account Context in the URL Until now the URLs in Anchore did not include account context which caused limitations to sharing data across accounts. Different users within the same account or users who were not part of the same account had to manually navigate to resources that were shared.  In Anchore 5.6, account context is now included in the URL. This simplifies the workflow for sharing reports among users who have access to shared resources within the same or across different accounts. Example Scenario 1. Create an account TestAccount and added a user TestUser1 2. Analyze the latest tag for Ubuntu under TestAccount context as username admin. http://localhost:3000/TestAccount/artifacts/image/docker.io/ubuntu/latest/sha256:d21429c4635332e96a4baae3169e3f02ac8e24e6ae3d89a86002d49a1259a4f7 3. Log out of username admin 4. Paste the URL for the image analysis page above 5. Log in as username TestUser1 6. You will now be directly navigated to the Image analysis page 7. Verify top right that you are under username TestUser1 8. If you are trying to access a link without having access to the resource, you will receive an error message on the top right corner of the UI. Please feel free to review our release notes for other notable updates and bug fixes in Anchore Enterprise 5.6. Demo Request ### How Cisco Umbrella Achieved FedRAMP Compliance in Weeks Implementing compliance standards can be a daunting task for IT and security teams. The complexity and volume of requirements, increased workload, and resource constraints make it challenging to ensure compliance without overwhelming those responsible. Our latest case study, "How Cisco Umbrella Achieved FedRAMP Compliance in Weeks," provides a roadmap for overcoming these challenges, leading to a world of streamlined compliance with low cognitive overhead. Challenges Faced by Cisco Umbrella Cisco Umbrella for Government, a cloud-native cybersecurity solution tailored for federal, state, and local government agencies, faced a tight deadline to meet FedRAMP vulnerability scanning requirements. They needed to integrate multiple security functions into a single, manageable solution while ensuring comprehensive protection across various environments, including remote work settings. Key challenges included: Meeting all six FedRAMP vulnerability scanning requirements Maintaining and automating STIG & FIPS compliance for Amazon EC2 virtual machines Integrating end-to-end container security across the CI/CD pipeline, Amazon EKS, and Amazon ECS Meeting SBOM requirements for White House Executive Order (EO 14028) Solutions Implemented To overcome these challenges, Cisco Umbrella leveraged Anchore Enterprise, a leading software supply chain security platform specializing in container security and vulnerability management. Anchore Enterprise integrated seamlessly with Cisco's existing infrastructure, providing: A distributed container security scanner An automated policy engine for security and compliance evaluation and enforcement Turnkey SBOM generation and management An on-prem cloud deployment model These features enabled Cisco Umbrella to secure their software supply chain, ensuring compliance with FedRAMP, STIG, FIPS, and EO 14028 within a short timeframe. Remarkable Results By integrating Anchore Enterprise, Cisco Umbrella achieved: FedRAMP, FIPS, and STIG compliance in weeks versus months Reduced implementation time and improved developer experience Proactive vulnerability detection in development, saving hours of developer time Simplified security data management with a complete SBOM management solution Download the Case Study Today Navigating the complexity and volume of compliance requirements can be overwhelming for IT and security teams, especially with increased workloads and resource constraints. Cisco Umbrella’s experience shows that with the right tools, achieving compliance can be streamlined and manageable. Discover how you can implement these strategies in your organization by downloading our case study, "How Cisco Umbrella Achieved FedRAMP Compliance in Weeks," and take the first step towards streamlined compliance today. Download Now ### Using the Common Form for SSDF Attestation: What Software Producers Need to Know The release of the long-awaited Secure Software Development Attestation Form on March 18, 2024 by the Cybersecurity and Infrastructure Agency (CISA) increases the focus on cybersecurity compliance for software used by the US government. With the release of the SSDF attestation form, the clock is now ticking for software vendors and federal systems integrators to comply with and attest to secure software development practices. This initiative is rooted in the cybersecurity challenges highlighted by Executive Order 14028, including the SolarWinds attack and the Colonial Pipeline ransomware attack, which clearly demonstrated the need for a coordinated national response to the emerging threats of a complex software supply chain. Attestation to Secure Software Development Framework (SSDF) requirements using the new Common Form is the most recent, and likely not the final, step towards a more secure software supply chain for both the United States and the world at large. We will take you through the details of what this form means for your organization and how to best approach it. Download Now Overview of the SSDF attestation SSDF attestation is part of a broader effort derived from the Cybersecurity EO 14028 (formally called “Improving the Nation's Cybersecurity). As a result of this EO, the Office of Management and Budget (OMB) issued two memorandums, M-22-18 “Enhancing the Security of the Software Supply Chain through Secure Software Development Practices” and M-23-16 “Update to Memorandum M-22-18”. These memos require the Federal agencies to obtain self-attestation forms from software suppliers. Software suppliers have to attest to complying with a subset of the Secure Software Development Framework (SSDF). Before the publication of the SSDF attestation form, the SSDF was a software development best practices standard published by the National Institute of Standards and Technology (NIST) based on industry best practices like OWASP's BSIMM and SAMM, a useful resource for organizations that valued security intrinsically and wanted to run secure software development without any external incentives like formal compliance requirements. Now, the SSDF attestation form requires software providers to self-attest to having met a subset of the SSDF best practices. There are a number of implications to this transition from secure software development as being an aspiration standard to a compliance standard that we will cover below. The most important thing to keep in mind is that while the Attestation Form doesn't require a software provider to be formally certified before they can transaction with a federal agency like FedRAMP does, there are retroactive punishments that can be applied in cases of non-compliance. Who/What is Affected? Software providers to federal agencies Federal service integrators Independent software vendor Cloud service providers Federal agencies and DoD programs who use any of the above software providers Included New software: Any software developed after September 14, 2022 Major updates to existing software: A major version change after September 14, 2022 Software-as-a-Service (SaaS) Exclusions First-party software: Software developed in-house by federal agencies. SSDF is still considered a best practice but does not require self-attestation Free and open-source software (FOSS): Even though FOSS components and end-user products are excluded from self-attestation the SSDF requires that specific controls are in place to protect against software supply chain security breaches Key Requirements of the Attestation Form There are two high-level requirements for meeting compliance with the SSDF attestation form; Meet the technical requirements of the form Note: NIST SSDF has 19 categories and 42 total requirements. The self-attestation form has 4 categories which are a subset of the full SSDF Self-attest to compliance with the subset of SSDF Sign and return the form Timeline The timeline for compliance with the SSDF self-attestation form involves two critical dates: Critical software: Jun 11, 2024 (3 months after approval on March 11) All software: Sep 11, 2024 (6 months after approval on March 11) Implications Now that CISA has published the final version of the SSDF attestation form there are a number of implications to this transition. One is financial and the other is potentially criminal. The financial penalty of not attesting to secure software development practices via the form can be significant. Federal agencies are required to stop using the software, potentially impacting your revenue,  and any future agencies you want to work with will ask to see your SSDF attestation form before procurement. Sign the form or miss out on this revenue. The second penalty is a bit scarier from an individual perspective. An officer of the company has to sign the attestation form to state that they are responsible for attesting to the fact that all of the form's requirements have been met. Here is the relevant quote from the form: "Willfully providing false or misleading information may constitute a violation of 18 U.S.C. § 1001, a criminal statute." It is also important to realize that this isn't an unenforceable threat. There is evidence that the DOJ Civil Cyber Fraud Initiative is trying to crack down on government contractors failing to meet cybersecurity requirements. They are bringing False Claims Act investigations and enforcement actions. This will likely weigh heavily on both the individual that signs the form and who is chosen at the organization to sign the form. Given this, most organizations will likely opt to utilize a third-party assessment organization (3PAO) to sign the form in order to shift liability off of any individual in the organization. Challenges and Considerations Do I still have to sign if I have a 3PAO do the technical assessment? No. As long as the 3PAO is FedRAMP-certified.  What if I can't comply in time? You can draft a plan of action and milestones (POA&M) to fill the gap while you are addressing the gaps between your current system and the system required by the attestation form. If the agency is satisfied with the POA&M then they can continue to use your software. But they have to request either an extension of the deadline from OMB or a waiver in order to do that. Can only the CEO and COO sign the form? The wording in the draft form that was published required either the CEO or COO but new language was added to the final form that allows for a different company employee to sign the attestation form. Conclusion Cybersecurity compliance is a journey not a destination. SSDF attestation is the next step in that journey for secure software development. With the release of the SSDF attestation for, the SSDF standard is not transformed from a recommendation into a requirement. Given the overall trend of cybersecurity modernization that was kickstarted with FISMA in 2002, it would be prudent to assume that this SSDF attestation form is an intermediate step before the requirements become a hard gate where compliance will have to be demonstrated as a prerequisite to utilizing the software. If you're interested to get a deep-dive into what is technically required to meet the requirements of the SSDF attestation form, read all of the nitty-gritty details in our eBook, "SSDF Attestation 101: A Practical Guide for Software Producers".  If you're looking for a solution to help you achieve the technical requirements of SSDF attestation quickly, take a look at Anchore Enterprise. We have helped hundreds of enterprises achieve SSDF attestation in days versus months with our automated compliance platform. Download Now ### With Great Power Comes Great Responsibility: APTs & Software Supply Chain Security Note: This is a multi-part series primer on the intersection of advanced persistent threats (APTs) and software supply chain security (SSCS). This blog post is the first in the series. We will update this blog post with links to the additional parts of the series as they are published.• Part 1 (This blog post)• Part 2• Part 3 In the realm of cybersecurity, the convergence of Advanced Persistent Threats (APTs) and software supply chain security presents a uniquely daunting challenge for organizations. APTs, characterized by their sophisticated, state-sponsored or well-funded nature, focus on stealthy, long-term data theft, espionage, or sabotage, targeting specific entities. Their effectiveness is amplified by the asymmetric power dynamics of a well funded attacker versus a resource constrained security team. Modern supply chains inadvertently magnify the impact of APTs due to the complex and interconnected dependency network of software and hardware components. The exploitation of this weakness by APTs not only compromises the targeted organizations but also poses a systemic risk to all users of the compromised downstream components. The infamous Solarwinds exploit exemplifies the far-reaching consequences of such breaches. This landscape underscores the necessity for an integrated approach to cybersecurity, emphasizing depth, breadth, and feedback to create a holistic software supply chain security program that can withstand even adversaries as motivated and well-resourced as APTs. Before we jump into how to create a secure software supply chain that can resist APTs, let's understand our adversary a bit better first. Know Your Adversary: Advanced Persistent Threats (APTs) What is an Advanced Persistent Threats (APT)? An Advanced Persistent Threat (APT) is a sophisticated, prolonged cyberattack, usually state-sponsored or executed by well-funded criminal groups, targeting specific organizations or nations. Characterized by advanced techniques, APTs exploit zero-day vulnerabilities and custom malware, focusing on stealth and long-term data theft, espionage, or sabotage. Unlike broad, indiscriminate cyber threats, APTs are highly targeted, involving extensive research into the victim's vulnerabilities and tailored attack strategies. APTs are marked by their persistence, maintaining a foothold in a target's network for extended periods, often months or years, to continually gather information. They are designed to evade detection, blending in with regular network traffic, and using methods like encryption and log deletion. Defending against APTs requires robust, advanced security measures, continuous monitoring, and a proactive cybersecurity approach, often necessitating collaboration with cybersecurity experts and authorities. High-Profile APT Example: Operation Triangulation The recent Operation Triangulation campaign disclosed by Kaspersky researchers is an extraordinary example of an APT in both its sophistication and depth. The campaign made use of four separate zero-day vulnerabilities, utilized a highly targeted approach towards specific individuals at Kaspersky, combined a multi-phase attack pattern and persisted over a four year period. Its complexity, implied significant resources possibly from a nation-state, and the stealthy, methodical progression of the attack, align closely with the hallmarks of APTs. Famed security researcher, Bruce Schneier, writing on his blog, Schneier on Security, wasn't able to contain his surprise upon reading the details of the campaign, "[t]his is nation-state stuff, absolutely crazy in its sophistication." What is the impact of APTs on organizations? Ignoring the threat posed by Advanced Persistent Threats (APTs) can lead to significant impact for organizations, including extensive data breaches and severe financial losses. These sophisticated attacks can disrupt operations, damage reputations, and, in cases involving government targets, even compromise national security. APTs enable long-term espionage and strategic disadvantage due to their persistent nature. Thus, overlooking APTs leaves organizations exposed to continuous, sophisticated cyber espionage and the multifaceted damages that follow. Now that we have a good grasp on the threat of APTs, we turn our attention to the world of software supply chain security to understand the unique features of this landscape. Setting the Stage: Software Supply Chain Security What is Software Supply Chain Security? Software supply chain security is focused on protecting the integrity of software through its development and distribution. Specifically it aims to prevent the introduction of malicious code into software that is utilized as components to build widely-used software services. The open source software ecosystem is a complex supply chain that solves the problem of redundancy of effort. By creating a single open source version of a web server and distributing it, new companies that want to operate a business on the internet can re-use the generic open source web server instead of having to build its own before it can do business. These new companies can instead focus their efforts on building new bespoke software on top of a web server that does new, useful functions for users that were previously unserved. This is typically referred to as compostable software building blocks and it is one of the most important outcomes of the open source software movement. But as they say, "there are no free lunches". While open source software has created this incredible productivity boon comes responsibility.  What is the Key Vulnerability of the Modern Software Supply Chain Ecosystem? The key vulnerability in the modern software supply chain is the structure of how software components are re-used, each with its own set of dependencies, creating a complex web of interlinked parts. This intricate dependency network can lead to significant security risks if even a single component is compromised, as vulnerabilities can cascade throughout the entire network. This interconnected structure makes it challenging to ensure comprehensive security, as a flaw in any part of the supply chain can affect the entire system. Modern software is particularly vulnerable to software supply chain attacks because 70-90% of modern applications are open source software components with the remaining 10-30% being the proprietary code that implements company specific features. This means that by breaching popular open source software frameworks and libraries an attacker can amplify the blast radius of their attack to effectively reach significant portions of internet based services with a single attack. If you're looking for a deeper understanding of software supply chain security we have written a comprehensive guide to walk you through the topic in full. High-Profile Software Supply Chain Exploit Example: SolarWinds In one of the most sophisticated supply chain attacks, malicious actors compromised the update mechanism of SolarWinds' Orion software. This breach allowed the attackers to distribute malware to approximately 18,000 customers. The attack had far-reaching consequences, affecting numerous government agencies, private companies, and critical infrastructure. Looking at the example of SolarWinds, the lesson we should take away is not to put a focus on prevention. APTs has a wealth of resources to draw upon. Instead the focus should be on monitoring the software we consume, build, and ship for unexpected changes. Modern software supply chains come with a great deal of responsibility. The software we use and ship need to be understood and monitored. This is the first in a series of blog posts focused on the intersection of APTs and software supply chain security. This blog post highlighted the contextual background to set the stage for the unique consequences of these two larger forces. Next week, we will discuss the implications of the collision of these two spheres in the second blog post in this series. ### Anchore's June Line-Up: Essential Events for Software Supply Chain Security and DevSecOps Enthusiasts Summer is beginning to ramp up, but before we all check out for the holidays, Anchore has a sizzling hot line-up of events to keep you engaged and informed. This June, we are excited to host and participate in a number of events that cater to the DevSecOps crowd and the public sector. From insightful webinars to hands-on workshops and major conferences, there's something for everyone looking to enhance their knowledge and connect with industry leaders. Join us at these events to learn more about how we are driving innovation in the software supply chain security industry. WEBINAR: How the US Navy is enabling software delivery from lab to fleet Date: Jun 4, 2024 Register Here The US Navy’s DevSecOps platform, Party Barge, has revolutionized feature delivery by significantly reducing onboarding time from 5 weeks to just 1 day. This improvement enhances developer experience and productivity through actionable findings and fewer false positives, while maintaining high security standards with inherent policy enforcement and Authorization to Operate (ATO). As a result, development teams can efficiently ship applications that have achieved cyber-readiness for Navy Authorizing Officials (AOs). In an upcoming webinar, Sigma Defense and Anchore will provide an in-depth look at the secure pipeline automation and security artifacts that expedite application ATO and production timelines. Topics will include strategies for removing silos in DevSecOps, building efficient development pipeline roles and component templates, delivering critical security artifacts for ATO (such as SBOMs, vulnerability reports, and policy evidence), and streamlining operations with automated policy checks on container images. WORKSHOP: VIPERR — Actionable Framework for Software Supply Chain Security Date: Jun 17, 2024 from 8:30am - 2:00pm ET Location: Carahsoft office in Reston, VA Register Here Anchore, in partnership with Carahsoft, is offering an exclusive in-person workshop to walk security practitioners through the principles of the VIPERR framework. Learn the framework hands-on from the team that originally developed the industry leading software supply chain security framework. In case you're not familiar, the VIPERR framework enhances software supply chain security by enabling teams to evaluate and improve their security posture. It offers a structured approach to meet popular compliance standards. VIPERR stands for visibility, inspection, policy enforcement, remediation, and reporting, focusing on actionable strategies to bolster supply chain security. The workshop covers building a software bill of materials (SBOM) for visibility, performing security checks for vulnerabilities and malware during inspection, enforcing compliance with both external and internal standards, and providing recommendations and automation for quick issue remediation. Additionally, timely reporting at any development stage is emphasized, along with a special topic on achieving STIG compliance. EVENT: Carahsoft DevSecOps Conference 2024 Date: Jun 18, 2024 Location: The Ronald Reagan Building and International Trade Center in Washington, DC Book a meeting If you're planning to be at the show, our team is looking forward to meeting you.  You can book a demo session with us in advance! On top of offering the VIPERR workshop, the Anchore team will be attending Carahsoft's 2nd annual DevSecOps Conference in Washington, DC, a comprehensive forum designed to address the pressing technological, security, and innovation challenges faced by government agencies today. The event aims to explore innovative approaches such as DoD software factories, which drive efficiency and enhance the delivery of citizen-centric services, and DevSecOps, which integrates security into the software development lifecycle to combat evolving cybersecurity threats. Through a series of panels and discussions, attendees will gain valuable knowledge on how to leverage these cutting-edge strategies to improve their operations and service delivery. EVENT: AWS Summit Washington, DC Dates:  June 26-27, 2024 Location: Walter E. Washington Convention Center in Washington, DC Book a meeting If you're planning to be at the show, our team is looking forward to meeting you.  You can book a demo session with us in advance! To round out June, Anchore will also be attending AWS Summit Washington, DC. The event highlights how AWS partners can help public sector organizations meet the needs of federal agencies. Anchore is an AWS Public Sector Partner and a graduate of the AWS ISV Accelerate program. See how Anchore helped Cisco Umbrella for Government achieve FedRAMP compliance by reading the co-authored blog post on the AWS Partner Network (APN) Blog. Or better yet, drop by our booth and the team can give you a live demo of the product. VIRTUAL EVENT: Life after the xz utils backdoor hack with Josh Bressers Date: Wednesday, June 5, from 12:35 PM - 1:20 PM EDT Register Here The xz utils hack was a significant breach that profoundly undermined trust within the open source community. The discovery of the backdoor revealed vulnerabilities in the software supply chain. As a member of both the open source community and a solution provider for the software supply chain security field, we at Anchore have strong opinions about XZ specifically, and open source security generally. Anchore's VP of Security,  Josh Bressers will be speaking publicly about this topic at Upstream 2024. Be sure to catch the live stream of "Life after the xz utils backdoor hack," a panel discussion featuring Josh Bressers. The panel will cover the implications of the recent xz utils backdoor hack and how the attack deeply impacted trust within the open source community. In keeping with the Upstream 2024 theme of “Unusual Ideas to Solve the Usual Problems'', Josh will be presenting the "unusual" solution that Anchore has developed to keep these types of hacks from impacting the industry. The discussion will include insights from industry experts such as Shaun Martin of BlackIce, Jordan Harband, prolific JavaScript maintainer, Rachel Stephens from RedMonk, and Terrence Fischer from Boeing. Wrap-Up Don't miss out on these exciting opportunities to connect with Anchore and learn about the latest advancements in software supply chain security and DevSecOps. Whether you join us for a webinar, participate in our in-person VIPERR workshop, or visit us at one of the major conferences, you'll gain valuable insights and practical knowledge to enhance your organization's security posture. We're looking forward to engaging with you and helping you navigate the evolving digital landscape. See you in June! Also, if you want to stay up-to-date on all of the events that Anchore hosts or participates in be sure to bookmark our events page and check back often! ### VIPERR Workshop The Actionable Framework for Software Supply Chain Security  ### Navigating the Updates to cATO: Critical Changes & Practical Advice for DoD Programs On April 11, the US Department of Defense (DoD)'s Chief Information Officer (CIO) released the DevSecOps Continuous Authorization Implementation Guide, marking the next step in the evolution of the DoD's efforts to modernize its security and compliance ecosystem. This guide is part of a larger trend of compliance modernization that is transforming the US public sector and the global public sector as a whole. It aims to streamline and enhance the processes for achieving continuous authorization to operate (cATO), reflecting a continued push to shift from traditional, point-in-time authorizations to operate (ATOs) to a more dynamic and ongoing compliance model. The new guide introduces several significant updates, including the introduction of specific security and development metrics required to achieve cATO, comprehensive evaluation criteria, practical advice on how to meet cATO requirements and a special emphasis on software supply chain security via software bills of material (SBOMs). We break down the updates that are important to highlight if you're already familiar with the cATO process. If you're looking for a primer on cATO to get yourself up to speed, read our original blog post or click below to watch our webinar on-demand. Continuous Authorization Metrics A new addition to the corpus of information on cATO is the introduction of specific security and software development metrics that are required to be continuously monitored. Many of these come from the private sector DevSecOps best practices that have been honed by organizations at the cutting edge of this field, such as Google, Microsoft, Facebook and Amazon. We've outlined the major ones below. Mean Time to Patch Vulnerabilities: Description: Average time between the identification of a vulnerability in the DevSecOps Platform (DSOP) or application and the successful production deployment of a patch. Focus: Emphasis on vulnerabilities with high to moderate impact on the application or mission. Trend Metrics: Description: Metrics associated with security guardrails and control gates PASS/FAIL ratio over time. Focus: Show improvements in development team efforts at developing secure code with each new sprint and the system's continuous improvement in its security posture. Feedback Communication Frequency: Description: Metrics to ensure feedback loops are in place, being used, and trends showing improvement in security posture. Effectiveness of Mitigations: Description: Metrics associated with the continued effectiveness of mitigations against a changing threat landscape. Security Posture Dashboard Metrics: Description: Metrics showing the stage of application and its security posture in the context of risk tolerances, security control compliance, and security control effectiveness results. Container Metrics: Description: Measure the age of containers against the number of times they have been used in a subsystem and the residual risk based on the aggregate set of open security issues. Test Metrics: Description: Percentage of test coverage passed, percentage of passing functional tests, count of various severity level findings, percentage of threat actor actions mitigated, security findings compared to risk tolerance, and percentage of passing security control compliance. The overall thread with the metrics required is to quickly understand whether the overall security of the application is improving. If they aren't this is a sign that something within the system is out of balance and is in need of attention. Comprehensive and detailed evaluation criteria Tucked away in Appendix B. "Requirements" is a detailed table that spells out the individual requirements that need to be met in order to achieve a cATO. This table is meant to improve the cATO process so that the individuals in a program that are implementing the requirements know the criteria they will be evaluated against. The goal being to reduce the amount of back-and-forth between the program and the Authorizing Official (AO) that is evaluating them. Practical Implementation Advice The ecosystem for DSOPs has evolved significantly since cATO was first announced in February 2022. Over the past 2+ years, a number of early adopters, such as Platform One have blazed a trail and learned all of the painful lessons in order to smooth the path for other organizations that are now looking to modernize their development practices. The advice in the implementation guide is a high-signal, low-noise distillation of these hard won lessons learned. DevSecOps Platform (DSOP) Advice If you're more interested in writing software than operating a DSOP then you'll want to focus your attention on pre-existing DSOP's, commonly called DoD software factories. We have written both a primer for understanding DoD software factories and an index of additional content that can quickly direct you to deep dives in specific content you're interested in. If you love to get your hands dirty and would rather have full control over your development environment, just be aware that this is specifically recommended against: Build a new DSOP using hardened components (this is the most time-consuming approach and should be avoided if possible). DevSecOps Culture Advice While the DevSecOps culture and process advice is well-known in the private sector, it is still important to emphasize in the federal context that is currently transitioning to the modern software development paradigm. Bring the security team at the start of development and keep them involved throughout. Create secure agile processes to support the continued delivery of value without the introduction of unnecessary risk Continuous Monitoring (ConMon) Advice Ensure that all environments are continuously monitored (e.g., development, test and production). Utilize the security data collected from these environments to power and inform thresholds and triggers for active incident response. ConMon and ACD are separate pillars of cATO but need to be integrated so that information is flowing to the systems that can make best use of it. It is this integrated approach that delivers on the promise of significantly improved security and risk outcomes. Active Cyber Defense (ACD) Advice Both a Security Operations Center (SOC) and external CSSP are needed in order to achieve the Active Cyber Defense (ACD) pillar of cATO. On top of that, there also has to be a detailed incident response plan and personnel trained on it. While cATO's goal is to automate as much of the security and incident response system as possible to reduce the burden of manual intervention. Humans in the loop are still an important component in order to tune the system and react with appropriate urgency. Software Supply Chain Security (SSCS) Advice The new implementation guide is very clear that a DSOP creates SBOMs for itself and any applications that pass through it. This is a mega-trend that has been sweeping over the software supply chain security industry for the past decade. It is now the consensus that SBOMs are the best abstraction and practice for securing software development in the age of composible and complex software. The 3 (+1) Pillars of cATO While the 3 pillars of cATO and its recommendation for SBOMs as the preferred software supply chain security tool were called out in the original cATO memo, the recently published implementation guide again emphasizes the importance of the 3 (+1) pillars of cATO. The guide quotes directly from the memo: In order to prevent any combination of human errors, supply chain interdictions, unintended code, and support the creation of a software bill of materials (SBOM), the adoption of an approved software platform and development pipeline(s) are critical. This is a continuation of the DoD specifically, and the federal government generally, highlighting the importance of software supply chain security and software bills of material (SBOMs) as "critical" for achieving the 3 pillars of cATO. This is why Anchore refers to this as the "3 (+1) Pillars of cATO". Continuous Monitoring (ConMon) Active Cyber Defense (ACD) DevSecOps (DSO) Reference Design Secure Software Supply Chain (SSSC) Wrap-up The release of the new DevSecOps Continuous Authorization Implementation Guide marks a significant advancement in the DoD's approach to cybersecurity and compliance. With a focus on transitioning from traditional point-in-time Authorizations to Operate (ATOs) to a continuous authorization model, the guide introduces comprehensive updates designed to streamline the cATO process. The goal being to ease the burden of the process and help more programs modernize their security and compliance posture. If you're interested to learn more about the benefits and best practices of utilizing a DSOP (i.e., DoD software factory) in order to transform cATO compliance into a "switch flip". Be sure to pick up a copy of our "DevSecOps for a DoD Software Factory: 6 Best Practices for Container Images" white paper. Click below to download. DOWNLOAD NOW ### A Guide to Air Gapping: Balancing Security and Efficiency in Classified Environments Not every organization needs to protect their data from spies that can infiltrate Petagon-level security networks with printable masks but there are more organizations than you think that utilize air gapping to protect their most classified. This blog dives into the concept of air gapping, its benefits, and its drawbacks. Finally, we will highlight how Anchore Enterprise/Federal can be deployed into an air gapped network and provide organization's that require this level of security to benefit from the best of both worlds; the extraordinary security of an air gapped network and the automation of a Cloud-Native software composition analysis tool to protect their software supply chain. What is an air gap? An air gap is exactly what it sounds like; a literal gap filled with air between a network and the greater internet. It is a network security practice where a computer (or network) is physically isolated from any external networks. This isolation is achieved by ensuring that the system has no physical or wireless connections to other networks, creating a secure environment that is highly resistant to external cyber threats. By maintaining this separation, air gapped systems protect sensitive data and critical operations from potential intrusions, malware, and other forms of cyber attacks. This method is commonly used in high-security environments such as government agencies, financial institutions, and critical infrastructure facilities to safeguard highly confidential and mission-critical information. If you count yourself as part of the defense industrial base (DIB), then you're likely very familiar with IT systems that have an air-gapped component. Typically, highly classified data storage systems require air-gapping as part of their defense-in-depth strategy. Benefits of air gapping The primary benefit of utilizing air gapping is that it eliminates an entire class of security threats. This brings a significant reduction in risk to the systems and the data that the system processes.  Beyond that there are also a number of secondary benefits that come from running an air gapped network. The first is that it gives the DevSecOps team running the system complete control over the security and architecture of the system. Also, any software that is run on an air gapped network inherits both the security and compliance of the network. For 3rd-party software where the security of the software is in question, being able to run it in a fully isolated environment reduces the risk associated with this ambiguity. Similar to how anti-virus software creates sandboxes to safely examine potential malicious files, an air gapped network creates a physical sandbox that both protects the isolated system from remote threats and from internal data from being pushed out to remote systems. Drawback of air gapping As with most security solutions, there is always a tradeoff between security and convenience, and air gapping is no different. While air gapping provides a high level of security by isolating systems from external networks, it comes at the cost of significant inconvenience. For instance, accessing and transferring data on air gapped systems requires physical presence and manual procedures, such as using USB drives or other removable media. This can be time-consuming and labor-intensive, especially in environments where data needs to be frequently updated or accessed by multiple users. Additionally, the lack of network connectivity means that software updates, patches, and system maintenance tasks cannot be performed remotely or automatically. This increases the complexity of maintaining the system and ensuring it remains up-to-date with the latest security measures. How Anchore enables air gapping for the DoD and DIB As the leading Cloud-Native software composition analysis (SCA) platform, Anchore Enterprise/Federal offers an on-prem deployment model that integrates seamlessly with air gapped networks. This is a proven model with countless deployments into IL4 to IL6  (air-gapped and classified) environments. Anchore supports public sector customers like the US Department of Defense (DoD), North Atlantic Treaty Organization (NATO), US Air Force, US Navy, US Customs and Border Protection, Australian Government Department of Defence and more.  Architectural Overview In order to deploy Anchore Enterprise or Federal in an air gapped environment, a few architectural considerations need to be made. At a very basic level, two deployments of Anchore need to be provisioned.  The deployment in the isolated environment will be deployed as normal with some slight modifications. When Anchore is deployed normally, the feed service will be reaching out to a dozen or so specified endpoints to compile and normalize vulnerability data and then it will compile that into a single feed dataset and store that in the feeds database either deployed in the cluster or on an external instance or managed database if configured.  When deploying in an air gapped environment, it’s necessary to set Anchore to run in “apiOnly” mode. This will prevent the feeds service from making unnecessary calls to the internet that will inevitably time out due to being in an isolated environment.  A second skeleton deployment of Anchore will need to be deployed in a connected environment to sync the feeds. This deployment doesn’t need to spin up any of the services that will scan images or generate policy results and can therefore be done on a smaller instance. This deployment will reach out to the internet and build the feeds database.  The only major consideration that needs to be taken into consideration with this connected deployment is it needs to be running on the same version of PostgreSQL as the disconnected deployment in order to ensure complete compatibility. Workflow Once the two deployments are provisioned, the general workflow will be the following: First, allow the feeds to sync on the connected environment. Once the feeds are synced, dump out the entire feeds database and transfer it to the disconnected environment through the method typically used for your environment.  When the file is available on the high-side, transfer it to the feed database instance Anchore uses. When it’s finished transferring, perform a PostgreSQL restore and the feeds will be available. Automation Process To mimic how Anchore syncs feeds in a connected environment, many people choose to automate some of all of the workflow described previously. A cronjob can be set up to run the backup along with a push to an automated cross domain solution like those available in AWS GovCloud. From there, the air gapped deployment can be scheduled to look at that location and perform the feed restore on a regular cadence. Wrap-Up While not every organization counts the Impossible Missions Force (IMF) as an adversary, the practice of air gapping remains a vital strategy for many entities that handle highly sensitive information. By deploying Anchore Enterprise/Federal in an air gapped network, organizations can achieve an optimal balance between the robust security of air gapping and the efficiency of automated software composition analysis. This combination ensures that even the most secure environments can benefit from cutting-edge software supply chain security. Air gapping is only one of a catalog security practices that are necessary for systems that handle classified government data. If you're interested to learn more about the other requirements, check out our white paper on best practices for container images in DoD-grade environments. DOWNLOAD NOW ### Carahsoft DevSecOps Conference 2024 ### Best Practices for DevSecOps in DoD Software Factories: A White Paper The Department of Defense's (DoD) Software Modernization Implementation Plan, unveiled in March 2023, represents a significant stride towards transforming software delivery timelines from years to days. This ambitious plan leverages the power of containers and modern DevSecOps practices within a DoD software factory. Our latest white paper, titled "DevSecOps for a DoD Software Factory: 6 Best Practices for Container Images," dives deep into the security practices for securing container images in a DoD software factory. It also details how Anchore Federal—a pivotal tool within this framework—supports these best practices to enhance security and compliance across multiple DoD software factories including the US Air Force's Platform One, Iron Bank, and the US Navy's Black Pearl. Key Insights from the White Paper Securing Container Images: The paper outlines six essential best practices ranging from using trusted base images to continuous vulnerability scanning and remediation. Each practice is backed by both DoD guidance and relevant NIST standards, ensuring alignment with federal requirements. Role of Anchore Federal: As a proven tool in the arena of container image security, Anchore Federal facilitates these best practices by integrating seamlessly into DevSecOps workflows, providing continuous scanning, and enabling automated policy enforcement. It's designed to meet the stringent security needs of DoD software factories, ready for deployment even in classified and air-gapped environments. Supporting Rapid and Secure Software Delivery: With the DoD's shift towards software factories, the need for robust, secure, and agile software delivery mechanisms has never been more critical. Anchore Federal is the turnkey solution for automating security processes and ensuring that all container images meet the DoD's rigorous security and compliance requirements. Download the White Paper Today Empower your organization with the insights and tools needed for secure software delivery within the DoD ecosystem. Download our white paper now and take a significant step towards implementing best-in-class DevSecOps practices in your operations. Equip your teams with the knowledge and technology to not just meet, but exceed the modern security demands of the DoD's software modernization efforts. DOWNLOAD NOW ### A tale of Scale & Speed: How the US Navy is Enabling Software Delivery from Lab to Fleet ### RMF and ATO with RAISE 2.0 — Navy's DevSecOps solution for Rapid Delivery In November 2022, the US Department of Navy (DON) released the RAISE 2.0 Implementation Guide to support its Cyber Ready initiative, pivoting from a time-intensive compliance checklist and mindset to continuous cyber-readiness with real-time visibility. RAISE 2.0 embraces a “shift left” philosophy, performing security checks at all stages of the SDLC and ensuring security issues are found as early as possible when they are faster and easier to fix. Save a Seat 3 Things to Know about RAISE 2.0  RAISE 2.0 provides a way to automate the Implement, Assess, and Monitor phases of the Risk Management Framework (RMF). New containerized applications can be developed using an existing DevSecOps platform (DSOP) that already has an Authorization to Operate (ATO) and meets the RAISE requirements. This eliminates the need for a new application to get its own separate ATO because it inherits the ATO of the DSOP. There are three primary things you need to know about RAISE 2.0: Who must follow RAISE 2.0?  RAISE 2.0 only applies to applications delivered via containers RAISE 2.0 requires all teams starting or upgrading containerized software applications to use a pre-vetted DevSecOps platform called a RAISE Platform of Choice (RPOC) What is an RPOC? RPOC is a designation that a DevSecOps Platform (DSOP) receives after its inheritable security controls have received an ATO A DSOP that wants to become an RPOC must follow the process outlined in the Implementation Guide How does an RPOC accelerate ATO? The containerized application will be assessed and incorporated into the existing RPOC ATO and is not required to have a separate ATO What are the requirements of RAISE? The RAISE 2.0 Implementation Guidelines outline the requirements for an RPOC. They represent best practices for DevSecOps platforms and incorporate processes and documentation required by the US government.   The guidelines also define the application owner's ongoing responsibilities, which include overseeing the entire software development life cycle (SDLC) of the application running in the RPOC.  RPOC Requirements The requirements for the RPOC include standard DevSecOps best practices and specifically call out tooling, such as: CI/CD pipeline Container Orchestrator Container Repository Code Repository It also requires specific processes, such as: Continuous Monitoring (ConMon) Ongoing vulnerability scans Ad-hoc vulnerability reporting and dashboard Penetration testing Ad-hoc auditing via a cybersecurity dashboard If you're looking for a comprehensive list of RPOC requirements, you can find them in the RAISE 2.0 Implementation Guide on the DON website. Application Owner Requirements Separate from the RPOC, the application owner that deploys their software via an RPOC has their own set of requirements. The application owner's requirements are focused less on the DevSecOps tooling and more on the implementation of the tooling specific to their application. Important callouts are: Maintain a Security Requirements Guide (SRG) and Security Technical Implementation Guide (STIG) for their application CI/CD implementation Repository of vulnerability scans (e.g., SBOMs, container security scans, SAST scans, etc.) Again, if looking for a comprehensive list of application owner requirements, you can find them in the RAISE 2.0 Implementation Guide on the DON website. Meet Raise 2.0 requirements with Anchore Federal Anchore Federal is the leading software supply chain security platform supporting public sector agencies and military programs worldwide. It helps RPOCs and applications owners meet RAISE 2.0 requirements by offering an SBOM management platform, container vulnerability scanner, flexible policy engine and comprehensive reporting dashboard. Anchore Federal integrates seamlessly with CI/CD pipelines and enables teams to meet essential RPOC requirements, including RPOC requirements 4, 5, 15, 19, 20, and 24. The reporting capabilities also assist in the Quarterly Reviews, fulfilling QREV requirements 6 and 7. Finally it helps application owners to meet requirements APPO 7, 8, 9, and 10.   Continuous container monitoring in production Anchore Federal includes the anchore-k8s-inventory tool, which continuously monitors selected Kubernetes clusters and namespaces and identifies the container images running in production. This automated tool that integrates directly with any standard Kubernetes distribution allows RPOCs to meet "RPOC 4: Must support continuous monitoring". The Anchore Federal UI provides dashboards summarizing vulnerabilities and your compliance posture across all your clusters. You can drill down into the details for an individual cluster or namespace and filter the dashboard. For example, selecting only high and critical vulnerabilities will only show the clusters and namespaces with those vulnerabilities. If a zero-day or new vulnerability arises, you can easily see the impacted clusters and containers to assess the blast radius. Security gates that directly integrate into CI/CD pipeline Anchore Federal automates required security gates for RPOCs and application owners (i.e., "RPOC 5: Must support the execution of Security Gates" and "APPO 9: Application(s) deployments must successfully pass through all Security Gates"). It integrates seamlessly into the CI/CD pipeline and the container registry, automatically generates SBOMs, and scans containers for vulnerabilities and secrets/keys (Gates 2, 3, and 4 in the RAISE 2.0 Implementation Guide). Anchore's security gating feature is backed by a flexible policy engine that allows both RPOCs and application owners to collaborate on the security gates that need to be passed for any container going through a CI/CD pipeline and customized gates specific to the application. The Anchore Policy Engine accelerates the move to RAISE 2.0 by offering pre-configured policy  packs, including NIST SP 800-53, and extensive docs for building custom policies. It is already used by DevSecOps platforms across the DON, including Black Pearl, Party Barge, and Lighthouse installations, and is ready to deploy in classified and air-gapped environments, including IL4 and IL6.  Production container inventory On top of continuously monitoring production for vulnerabilities in containers, the anchore-k8s-inventory tool can be utilized to create an inventory of all containers in production which can then be queried by the container registry in order to meet "RPOC 15: Must retain every image that is currently deployed". This easily automates this requirement and keeps DON programs compliant with no additional manual work. Single-pane-of-glass security dashboard Anchore Federal maintains a complete repository of SBOMs, vulnerabilities, and policy evaluations. Dashboards and reports provide auditability that containers have met the necessary security gates to meet "RPOC 20: Must ensure that the CI/CD pipeline meets security gates". Customizable vulnerability reporting and comprehensive dashboard Anchore Federal comes equipped with a customizable report builder for regular vulnerability reporting and a vulnerability dashboard for ad hoc reviews. This ensures that RPOCs and application owners meet the "RPOC 24: Must provide vulnerability reports and/or vulnerability dashboards for Application Owner review" requirement. Aggregated vulnerability reporting Not only can Anchore Federal generate application specific reporting, it can provide aggregated reporting for vulnerabilities for all applications and containers on the RPOC. This is vital functionality for meeting the "QREV 6: Consolidated vulnerabilities report of all applications deployed, via the RAISE process" requirement. Generate and store security artifacts Anchore Federal both generates and stores security artifacts from the entire CI/CD pipeline. This meets the software supply chain security requirements of "QREV 7: Application Deployment Artifacts". Specifically this includes, SBOMs (i.e., dependency reports), container security scans, SRG/STIG scans. Anchore Federal produces a number of the required reports, including STIG results, container security scan reports, and SBOMs, along with pass/fail reports of policy controls. STIG results are generated by Anchore's Static STIG Checker tool. This automates STIG scanning and makes STIG compliance a breeze.  Remediation recommendations and automated allowlists RAISE 2.0 requires that Application Owners remediate or mitigate all vulnerabilities with a severity of high or above within 21 calendar days. Anchore Federal helps speed remediation efforts to meet the 21-day deadline. It suggests recommended fixes and includes an Action Workbench where security reviewers can specify an Action Plan detailing what developers should do to remediate each vulnerability.  Anchore Federal also provides time-based allowlists to enforce the 21-day timeline. With the assistance of remediation recommendations and automated allowlists, application owners knows that their applications are always in compliance with "APPO 7: Must review and remediate, or mitigate, all findings listed in the vulnerabilities report per the timelines defined within this guide". Automate STIG checks in CI/CD pipeline The RPOC ISSM and the Application Owner must work together to determine what SRGs and STIGs to implement. Anchore’s Static STIG Checker tool automates STIG checks on Kubernetes environments and then uploads the results to Anchore Federal through a compliance API. That allows users to leverage additional functionality like reporting and correlating the runtime environment to images that have been analyzed. This automated workflow specifically addresses the "APPO 10: Must provide and continuously maintain a complete Security Requirements Guide (SRG) and Security Technical Implementation Guide (STIG)" requirement. Getting to RAISE 2.0 with Anchore Federal Anchore Federal is a complete software supply chain security solution that gets RPOCs and application owners to RAISE 2.0 faster and easier. It is already proven in many Navy programs and across the DoD. With Anchore Federal you can: Automate RAISE requirements Meet required security gates Generate recurring reports Integrate with existing DSOPs Anchore Federal was designed specifically to automate compliance with Federal and Department of Defense (DoD) compliance standards (e.g., RAISE, cATO, NIST SSDF, NIST 800-53, etc.) for application owners and DSOPs that would rather utilize a turnkey solution to software supply chain security rather than DIY a solution. The easiest way to achieve RAISE 2.0 is by adopting a DoD software factory which is the general version of the Navy's RPOC. If you're interested to learn more about how Anchore can help your organization embed DevSecOps tooling and principles into your software development process, click below to read our white paper. Download Now ### Navigate SSDF Attestation with this Practical Guide The clock is ticking again for software producers selling to federal agencies. In the second half of 2024, CEOs or their designees must begin providing an SSDF attestation that their organization adheres to secure software development practices documented in NIST SSDF 800-218.  Download our latest ebook to navigate through SSDF attestation quickly and adhere to timelines.  SSDF attestation covers four main areas from NIST SSDF including:  Securing development environments,  Using automated tools to maintain trusted source code supply chains,  Maintaining provenance (e.g., via SBOMs) for internal code and third-party components, and  Using automated tools to check for security vulnerabilities.   This new requirement is not to be taken lightly. It applies to all software producers, regardless of whether they provide a software end product as SaaS or on-prem, to any federal agency. The SSDF attestation deadline is June 11, 2024, for critical software and September 11, 2024, for all software. However, on-prem software developed before September 14, 2022, will only require SSDF attestation when a new major version is released. The bottom line is that most organizations will need to comply by 2024. Companies will make their SSDF attestation through an online Common Form that covers the minimum secure software development requirements that software producers must meet. Individual agencies can add agency-specific instructions outside of the Common Form.  Organizations that want to ensure they meet all relevant requirements can submit a third-party assessment instead of a CEO attestation. You must use a Third-Party Assessment Organization (3PAO) that is FedRAMP-certified or approved by an agency official.  This option is a no-brainer for cloud software producers who use a 3PAO for FedRAMP. Details over details - so we put together a practical guide to the SSDF attestation requirements and how to meet them “SSDF Attestation 101: A Practical Guide for Software Producers”. We also included how Anchore Enterprise automates the SSDF attestation compliance by directly integrating into your software development pipeline and utilizing continuous policy scanning to detect issues before they hit production. DOWNLOAD NOW ### Zero Trust Webinar with Security Boulevard ### Anchore Enterprise 5.5: Vulnerability Feed Service Improvements Today, we are announcing the release of Anchore Enterprise 5.5, the fifth in our regular minor monthly releases. There are a number of improvements to GUI performance, multi-tenancy support and AnchoreCTL but with the uncertainty at NVD continuing, the main news is updates to our feed drivers which help customers adapt to the current situation at NIST. The NIST NVD interruption and backlog  A few weeks ago, Anchore alerted the security community to the changes at the National Vulnerability Database (NVD) run by the US National Institute of Standards and Technology (NIST). As of February 18th, there was a massive decline in the number of records published with metadata such as severity and CVSS records. Less publicized but no less problematic has been that the service availability of the API that enables access to NVD records has also been erratic during the same period.   While the uncertainty around NVD continues and recognizing that it continues to be a federally mandated data source (e.g., within FedRAMP), Anchore has updated its drivers to give customers flexibility in how they interact with its data.  In a typical Anchore Enterprise deployment, NVD data has served two functions. The first is a catalog of CVEs that can be correlated with advisories from other vendors to help provide more context around an issue. The second is as a matching source of last resort for surfacing vulnerabilities where no other vulnerability data exists. This often comes with a caveat that the expansiveness of the NVD database means there is variable data quality which can lead to false positives. See it in action! To see the latest features in action, please join our webinar “Adapting to the new normal at NVD with Anchore Vulnerability Feed” on May 7th at 10am PT/1pm EST. Register Now. Improvements to the Anchore Vulnerability Feed Service The Exclusion feed Anchore released its own Vulnerability Feed with v4.1 which provided an ‘Exclusion Feed’ to avoid NVD false positives by preventing matches against vulnerability records that were known to be inaccurate.  As of v5.5, we have extended the Anchore Vulnerability Feed service to provide two additional data features.  Simplify network management with 3rd party vulnerability feed  The first is the ability to download a copy of 3rd party vulnerability feed data sets, including NVD, directly from Anchore, so that transient service availability issues don’t generate alerts. This simplifies network management by only requiring one firewall rule to be created to enable the retrieval of any vulnerability data for use with Anchore Enterprise. This proxy-mode is the default in 5.5 for the majority of feeds but customers who want to continue to benefit from autonomous operations that don’t rely on Anchore and contact NVD and other vendor endpoints directly can continue to use the direct-mode as before. Enriched data The second change is that Anchore is continuing to add new CVE records from the NVD database that customers use while providing Enriched Data to the records, specifically for CPE information which helps map affected versions. While Anchore can’t provide NVD severity or CVSS records, which by definition have to be provided by NVD themselves, these records and metadata will continue to allow customers to reference CVEs. This data is available by default in the proxy-mode mentioned above or as a configuration option with the Direct Mode. How it works For the 3rd party vulnerability data, Anchore is running the same feed service software that customers would run in their local site which periodically retrieves the data from all of its available sources and structures the data into a format ready to be downloaded by customers. Using the existing feed drivers in their local feed service (NVD, GitHub, etc) customers download the entire database in one atomic operation. This contrasts with the API based approach in the direct-mode which means that individual records are retrieved one at a time which can take time. This can be enabled on a driver-by-driver basis.  For the enriched data, Anchore is running a service which looks for new CVE records from other upstream sources, for example the CVE5 database hosted by MITRE and custom data added by Anchore engineers. The database tables that host the NVD records are then populated with these CVE updates. CPE data is sourced from vendor records (e.g., Red Hat Security Advisories) and added to the NVD records to enable matching logic. Looking forward Throughout the year, we will be looking to make additional improvements to the Anchore Vulnerability Feed to help customers not just navigate through the uncertainty at NVD but reduce their false positive and false negative count in general. See it in action! Join our webinar Adapting to the new normal at NVD with Anchore Vulnerability Feed.May 7th at 10am PT/1pm EST Register Now ### Modeling Software Security as Unit Tests: A Mental Model for Developers Modern software development is complex to say the least. Vulnerabilities often lurk within the vast networks of dependencies that underpin applications. A typical scenario involves a simple app.go source file that is underpinned by a sprawling tree of external libraries and frameworks (check the go.mod file for the receipts). As developers incorporate these dependencies into their applications, the security risks escalate, often surpassing the complexity of the original source code. This real-world challenge highlights a critical concern: the hidden vulnerabilities that are magnified by the dependencies themselves, making the task of securing software increasingly daunting. Addressing this challenge requires reimagining software supply chain security through a different lens. In a recent webinar with the famed Kelsey Hightower, he provides an apt analogy to help bring the sometimes opaque world of security into focus for a developer. Software security can be thought of as just another test in the software testing suite. And the system that manages the tests and the associated metadata is a data pipeline. We'll be exploring this analogy in more depth in this blog post and by the end we will have created a bridge between developers and security. The Problem: Modern software is built on a tower Modern software is built from a tower of libraries and dependencies that increase the productivity of developers but with these boosts comes the risks of increased complexity. Below is a simple 'ping-pong' (i.e., request-response) application written in Go that imports a single HTTP web framework: package main import ( "net/http" "github.com/gin-gonic/gin" ) func main() { r := gin.Default() r.GET("/ping", func(c *gin.Context) { c.JSON(http.StatusOK, gin.H{ "message": "pong", }) }) r.Run() }package main import ( "net/http" "github.com/gin-gonic/gin" ) func main() { r := gin.Default() r.GET("/ping", func(c *gin.Context) { c.JSON(http.StatusOK, gin.H{ "message": "pong", }) }) r.Run() } With this single framework comes a laundry list of dependencies that are needed in order to work. This is the go.mod file that accompanies the application: module app go 1.20 require github.com/gin-gonic/gin v1.7.2 require ( github.com/gin-contrib/sse v0.1.0 // indirect github.com/go-playground/locales v0.13.0 // indirect github.com/go-playground/universal-translator v0.17.0 // indirect github.com/go-playground/validator/v10 v10.4.1 // indirect github.com/golang/protobuf v1.3.3 // indirect github.com/json-iterator/go v1.1.9 // indirect github.com/leodido/go-urn v1.2.0 // indirect github.com/mattn/go-isatty v0.0.12 // indirect github.com/modern-go/concurrent v0.0.0-20180228061459-e0a39a4cb421 // indirect github.com/modern-go/reflect2 v0.0.0-20180701023420-4b7aa43c6742 // indirect github.com/ugorji/go/codec v1.1.7 // indirect golang.org/x/crypto v0.0.0-20200622213623-75b288015ac9 // indirect golang.org/x/sys v0.0.0-20200116001909-b77594299b42 // indirect gopkg.in/yaml.v2 v2.2.8 // indirect )module app go 1.20 require github.com/gin-gonic/gin v1.7.2 require ( github.com/gin-contrib/sse v0.1.0 // indirect github.com/go-playground/locales v0.13.0 // indirect github.com/go-playground/universal-translator v0.17.0 // indirect github.com/go-playground/validator/v10 v10.4.1 // indirect github.com/golang/protobuf v1.3.3 // indirect github.com/json-iterator/go v1.1.9 // indirect github.com/leodido/go-urn v1.2.0 // indirect github.com/mattn/go-isatty v0.0.12 // indirect github.com/modern-go/concurrent v0.0.0-20180228061459-e0a39a4cb421 // indirect github.com/modern-go/reflect2 v0.0.0-20180701023420-4b7aa43c6742 // indirect github.com/ugorji/go/codec v1.1.7 // indirect golang.org/x/crypto v0.0.0-20200622213623-75b288015ac9 // indirect golang.org/x/sys v0.0.0-20200116001909-b77594299b42 // indirect gopkg.in/yaml.v2 v2.2.8 // indirect ) The dependencies for the application end up being larger than the application source code. And in each of these dependencies is the potential for a vulnerability that could be exploited by a determined adversary. Kelsey Hightower summed this up well, "this is software security in the real world". Below is an example of a Java app that hides vulnerabile dependencies inside the frameworks that the application is built off of. As much as we might want to put the genie back in the bottle, the productivity boosts of building on top of frameworks are too good to reverse this trend. Instead we have to look for different ways to manage security in this more complex world of software development. If you're looking for a solution to the complexity of modern software vulnerability management, be sure to take a look at the Anchore Enterprise platform and the included container vulnerability scanner. The Solution: Modeling software supply chain security as a data pipeline Software supply chain security is a meta problem of software development. The solution to most meta problems in software development is data pipeline management.  Developers have learned this lesson before when they first build an application and something goes wrong. In order to solve the problem they have to create a log of the error. This is a great solution until you've written your first hundred logging statements. Suddenly your solution has become its own problem and a developer becomes buried under a mountain of logging data. This is where a logging (read: data) pipeline steps in. The pipeline manages the mountain of log data and helps developers sift the signal from the noise. The same pattern emerges in software supply chain security. From the first run of a vulnerability scanner on almost any modern software, a developer will find themselves buried under a mountain of security metadata.  $ grype dir:~/webinar-demo/examples/app:v2.0.0 ✔ Vulnerability DB [no update available] ✔ Indexed file system ~/webinar-demo/examples/app:v2.0.0 ✔ Cataloged contents 889d95358bbb68b88fb72e07ba33267b314b6da8c6be84d164d2ed425c80b9c3 ├── ✔ Packages [16 packages] └── ✔ Executables [0 executables] ✔ Scanned for vulnerabilities [11 vulnerability matches] ├── by severity: 1 critical, 5 high, 5 medium, 0 low, 0 negligible └── by status: 11 fixed, 0 not-fixed, 0 ignored NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY github.com/gin-gonic/gin v1.7.2 1.7.7 go-module GHSA-h395-qcrw-5vmq High github.com/gin-gonic/gin v1.7.2 1.9.0 go-module GHSA-3vp4-m3rf-835h Medium github.com/gin-gonic/gin v1.7.2 1.9.1 go-module GHSA-2c4m-59x9-fr2g Medium golang.org/x/crypto v0.0.0-20200622213623-75b288015ac9 0.0.0-20211202192323-5770296d904e go-module GHSA-gwc9-m7rh-j2ww High golang.org/x/crypto v0.0.0-20200622213623-75b288015ac9 0.0.0-20220314234659-1baeb1ce4c0b go-module GHSA-8c26-wmh5-6g9v High golang.org/x/crypto v0.0.0-20200622213623-75b288015ac9 0.0.0-20201216223049-8b5274cf687f go-module GHSA-3vm4-22fp-5rfm High golang.org/x/crypto v0.0.0-20200622213623-75b288015ac9 0.17.0 go-module GHSA-45x7-px36-x8w8 Medium golang.org/x/sys v0.0.0-20200116001909-b77594299b42 0.0.0-20220412211240-33da011f77ad go-module GHSA-p782-xgp4-8hr8 Medium log4j-core 2.15.0 2.16.0 java-archive GHSA-7rjr-3q55-vv33 Critical log4j-core 2.15.0 2.17.0 java-archive GHSA-p6xc-xr62-6r2g High log4j-core 2.15.0 2.17.1 java-archive GHSA-8489-44mv-ggj8 Medium$ grype dir:~/webinar-demo/examples/app:v2.0.0 ✔ Vulnerability DB [no update available] ✔ Indexed file system ~/webinar-demo/examples/app:v2.0.0 ✔ Cataloged contents 889d95358bbb68b88fb72e07ba33267b314b6da8c6be84d164d2ed425c80b9c3 ├── ✔ Packages [16 packages] └── ✔ Executables [0 executables] ✔ Scanned for vulnerabilities [11 vulnerability matches] ├── by severity: 1 critical, 5 high, 5 medium, 0 low, 0 negligible └── by status: 11 fixed, 0 not-fixed, 0 ignored NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY github.com/gin-gonic/gin v1.7.2 1.7.7 go-module GHSA-h395-qcrw-5vmq High github.com/gin-gonic/gin v1.7.2 1.9.0 go-module GHSA-3vp4-m3rf-835h Medium github.com/gin-gonic/gin v1.7.2 1.9.1 go-module GHSA-2c4m-59x9-fr2g Medium golang.org/x/crypto v0.0.0-20200622213623-75b288015ac9 0.0.0-20211202192323-5770296d904e go-module GHSA-gwc9-m7rh-j2ww High golang.org/x/crypto v0.0.0-20200622213623-75b288015ac9 0.0.0-20220314234659-1baeb1ce4c0b go-module GHSA-8c26-wmh5-6g9v High golang.org/x/crypto v0.0.0-20200622213623-75b288015ac9 0.0.0-20201216223049-8b5274cf687f go-module GHSA-3vm4-22fp-5rfm High golang.org/x/crypto v0.0.0-20200622213623-75b288015ac9 0.17.0 go-module GHSA-45x7-px36-x8w8 Medium golang.org/x/sys v0.0.0-20200116001909-b77594299b42 0.0.0-20220412211240-33da011f77ad go-module GHSA-p782-xgp4-8hr8 Medium log4j-core 2.15.0 2.16.0 java-archive GHSA-7rjr-3q55-vv33 Critical log4j-core 2.15.0 2.17.0 java-archive GHSA-p6xc-xr62-6r2g High log4j-core 2.15.0 2.17.1 java-archive GHSA-8489-44mv-ggj8 Medium All of this from a single innocuous include statements to your favorite application framework.  Again the data pipeline comes to the rescue and helps manage the flood of security metadata. In this blog post we'll step through the major functions of a data pipeline customized for solving the problem of software supply chain security. Modeling SBOMs and vulnerability scans as unit tests I like to think of security tools as just another test. A unit test might test the behavior of my code. I think this falls in the same quality bucket as linters to make sure you are following your company's style guide. This is a way to make sure you are following your company's security guide. Kelsey Hightower This idea from renowned developer, Kelsey Hightower is apt, particularly for software supply chain security. Tests are a mental model that developers utilize on a daily basis. Security tooling are functions that are run against your application in order to produce security data about your application rather than behavioral information like a unit test. The first two foundational functions of software supply chain security are being able to identify all of the software dependencies and to scan the dependencies for known existing vulnerabilities (i.e., 'testing' for vulnerabilities in an application).  This is typically accomplished by running an SBOM generation tool like Syft to create an inventory of all dependencies followed by running a vulnerability scanner like Grype to compare the inventory of software components in the SBOM against a database of vulnerabilities. Going back to the data pipeline model, the SBOM and vulnerability database are the data sources and the vulnerability report is the transformed security metadata that will feed the rest of the pipeline. $ grype dir:~/webinar-demo/examples/app:v2.0.0 -o json ✔ Vulnerability DB [no update available] ✔ Indexed file system ~/webinar-demo/examples/app:v2.0.0 ✔ Cataloged contents 889d95358bbb68b88fb72e07ba33267b314b6da8c6be84d164d2ed425c80b9c3 ├── ✔ Packages [16 packages] └── ✔ Executables [0 executables] ✔ Scanned for vulnerabilities [11 vulnerability matches] ├── by severity: 1 critical, 5 high, 5 medium, 0 low, 0 negligible └── by status: 11 fixed, 0 not-fixed, 0 ignored { "matches": [ { "vulnerability": { "id": "GHSA-h395-qcrw-5vmq", "dataSource": "https://github.com/advisories/GHSA-h395-qcrw-5vmq", "namespace": "github:language:go", "severity": "High", "urls": [ "https://github.com/advisories/GHSA-h395-qcrw-5vmq" ], "description": "Inconsistent Interpretation of HTTP Requests in github.com/gin-gonic/gin", "cvss": [ { "version": "3.1", "vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N", "metrics": { "baseScore": 7.1, "exploitabilityScore": 2.8, "impactScore": 4.2 }, "vendorMetadata": { "base_severity": "High", "status": "N/A" } } ], . . . $ grype dir:~/webinar-demo/examples/app:v2.0.0 -o json ✔ Vulnerability DB [no update available] ✔ Indexed file system ~/webinar-demo/examples/app:v2.0.0 ✔ Cataloged contents 889d95358bbb68b88fb72e07ba33267b314b6da8c6be84d164d2ed425c80b9c3 ├── ✔ Packages [16 packages] └── ✔ Executables [0 executables] ✔ Scanned for vulnerabilities [11 vulnerability matches] ├── by severity: 1 critical, 5 high, 5 medium, 0 low, 0 negligible └── by status: 11 fixed, 0 not-fixed, 0 ignored { "matches": [ { "vulnerability": { "id": "GHSA-h395-qcrw-5vmq", "dataSource": "https://github.com/advisories/GHSA-h395-qcrw-5vmq", "namespace": "github:language:go", "severity": "High", "urls": [ "https://github.com/advisories/GHSA-h395-qcrw-5vmq" ], "description": "Inconsistent Interpretation of HTTP Requests in github.com/gin-gonic/gin", "cvss": [ { "version": "3.1", "vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N", "metrics": { "baseScore": 7.1, "exploitabilityScore": 2.8, "impactScore": 4.2 }, "vendorMetadata": { "base_severity": "High", "status": "N/A" } } ], . . . This was previously done just prior to pushing an application to production as a release gate that would need to be passed before software could be shipped. As unit tests have moved forward in the software development lifecycle as DevOps principles have won the mindshare of the industry, so has security testing "shifted left" in the development cycle. With self-contained, open source CLI tooling like Syft and Grype, developers can now incorporate security testing into their development environment and test for vulnerabilities before even pushing a commit to a continuous integration (CI) server. From a security perspective this is a huge win. Security vulnerabilities are caught earlier in the development process and fixed before they come up against a delivery due date. But with all of this new data being created, the problem of data overload has led to a different set of problems. Vulnerability overload; Uncovering the signal in the noise Like the world of application logs that came before it, at some point there is so much information that an automated process generates that finding the signal in the noise becomes its own problem. How Anchore Enterprise manages SBOMs and vulnerability scans Centralized management of SBOMs and vulnerability scans can end up being a massive headache. No need to come up with your own storage and data management solution. Just configure the AnchoreCTL CLI tool to automatically submit SBOMs and vulnerability scans as you run them locally. Anchore Enterprise stores all of this data for you. On top of this, Anchore Enterprise offers data analysis tools so that you can search and filter SBOMs and vulnerability scans by version, build stage, vulnerability type, etc. Combining local developer tooling with centralized data management creates a best of both worlds environment where engineers can still get their tasks done locally with ease but offload the arduous management tasks to a server. Added benefit, SBOM drift detection Another benefit of distributed SBOM generation and vulnerability scanning is that this security check can be run at each stage of the build process. It would be ideal to believe that the software that is written on in a developers local environment always makes it through to production in an untouched, pristine state but this is rarely the case. Running SBOM generation and vulnerability scanning at development, on the build server, in the artifact registry, at deploy and during runtime will create a full picture of where and when software is modified in the development process and simplify post-incident investigations or even better catch issues well before they make it to a production environment. This historical record is a feature provided by Anchore Enterprise called Drift Detection. In the same way that an HTTP cookie creates state between individual HTTP requests, Drift detection is security metadata about security metadata (recursion, much?) that allows state to be created between each stage of the build pipeline.  Being the central store for all of the associated security metadata makes the Anchore Enterprise platform the ideal location to aggregate and scan for these particular anomalies. Policy as a lever Being able to filter through all of the noise created by integrating security checks across the software development process creates massive leverage when searching for a particular issue but it is still a manual process and being a full-time investigator isn't part of the software engineer job description. Wouldn't it be great if we could automate some if not the majority of these investigations? I'm glad we're of like minds because this is where policy comes into picture. Returning to Kelsey Hightower's original comparison between security tools as linters, policy is the security guide that is codified by your security team that will allow you to quickly check whether the commit that you put together will meet the standards for secure software. By running these checks and automating the feedback, developers can quickly receive feedback on any potential security issues discovered in their commit. This allows developers to polish their code before it is flagged by the security check in the CI server and potentially failed. No more waiting on the security team to review your commit before it can proceed to the next stage. Developers are empowered to solve the security risks and feel confident that their code won't be held up downstream. Policies-as-code supports existing developer workflows Anchore Enterprise designed its policy engine to ingest the individual policies as JSON objects that can be integrated directly into the existing software development tooling. Create a policy in the UI or CLI, generate the JSON and commit it directly to the repo. This prevents the painful context switching of moving between different interfaces for developers and allows engineering and security teams to easily reap the rewards of version control and rollbacks that come pre-baked into tools like version control. Anchore Enterprise was designed by engineers for engineers which made policy-as-code the obvious choice when designing the platform. Remediation automation integrated into the development workflow Being able to be alerted when a commit is violating your company's security guidelines is better than pushing insecure code and waiting for the breach to find out that you forgot to sanitize the user input. Even after you get alerted to a problem, you still need to understand what is insecure and how to fix it. This can be done by trying to Google the issue or starting up a conversation with your security team. But this just ends up creating more work for you before you can get your commit into the build pipeline. What if you could get the answer to how to fix your commit in order to make it secure directly into your normal workflow? Anchore Enterprise provides remediation recommendations to help create actionable advice on how to resolve security alerts that are flagged by a policy. This helps point developers in the right direction so that they can resolve their vulnerabilities quickly and easily without the manual back and forth of opening a ticket with the security team or Googling aimlessly to find the correct solution. The recommendations can be integrated directly into GitHub Issues or Jira tickets in order to blend seamlessly into the workflows that teams depend on to coordinate work across the organization. Wrap-Up From the perspective of a developer it can sometimes feel like the security team is primarily a frustration that only slows down your ability to ship code. Anchore has internalized this feedback and has built a platform that allows developers to still move at DevOps speeds and do so while producing high quality, secure code. By integrating directly into developer workflows (e.g., CLI tooling, CI/CD integrations, source code repository integrations, etc.) and providing actionable feedback Anchore Enterprise removes the traditional roadblock mentality that has typically described the relationship between development and security. If you're interested to see all of the features described in this blog post via a hands-on demo, check out the webinar by clicking on the screenshot below and going to the workshop hosted on GitHub. If you're looking to go further in-depth with how to build and secure containers in the software supply chain, be sure to read our white paper: The Fundamentals of Container Security. ### Upstream - a Tidelift expedition ### Adapting to the new normal at NVD with Anchore Vulnerability Feed ### AWS Summit ### Streamlining FedRAMP Compliance: How Anchore Enterprise Simplifies the Process FedRAMP compliance is hard, not only because there are hundreds of controls that need to be reviewed and verified. On top of this, the controls can be interpreted and satisfied in multiple different ways. It is admirable to see an enterprise achieve FedRAMP compliance from scratch but most of us want to achieve compliance without spending more than a year debating the interpretation of specific controls. This is where turnkey solutions like Anchore Enterprise come in.  Anchore Enterprise is a cloud-native software composition analysis platform that integrates SBOM management, vulnerability scanning and policy enforcement into a single platform to provide a comprehensive solution for software supply chain security. Overview of FedRAMP, who it applies to and the challenges of compliance FedRAMP, or the Federal Risk and Authorization Management Program, is a federal compliance program that standardizes security assessment, authorization, and continuous monitoring for cloud products and services. As with any compliance standard, FedRAMP is modeled from the "Trust but Verify" security principle. FedRAMP standardizes how security is verified for Cloud Service Providers (CSP). One of the biggest challenges with achieving FedRAMP compliance comes from sorting through the vast volumes of data that make up the standard. Depending on the level of FedRAMP compliance you are attempting to meet, this could mean complying with 125 controls in the case of a FedRAMP low certification or up to 425 for FedRAMP high compliance. While we aren't going to go through the entire FedRAMP standard in this blog post, we will be focusing on the container security controls that are interleaved into FedRAMP. FedRAMP container security requirements 1) Hardened Images FedRAMP requires CSPs to adhere to strict security standards for hardened images used by government agencies. The standard mandates that: Only essential services and software are included in the images Updated with the latest security patches Configuration settings meet secure baselines CIS benchmarks or DISA STIGs Disabling unnecessary ports and services Managing user accounts securely Implementing encryption Maintaining logging and monitoring practices Regular vulnerability scanning and prompt remediation If you want to go in-depth with how to create hardened images that meet FedRAMP compliance, download our white papers: DevSecOps for a DoD Software Factory: 6 Best Practices for Container Images Download Now Complete Guide to Hardening Containers with STIG Download Now 2) Container Build, Test, and Orchestration Pipelines FedRAMP sets stringent requirements for container build, test, and orchestration pipelines to protect federal agencies. These include: Hardened base images (see above)  Automated build processes with integrity checks Strict configuration management Immutable containers Secure artifact management Containers security testing Comprehensive logging and monitoring 3) Vulnerability Scanning for Container Images FedRAMP mandates rigorous vulnerability scanning protocols for container images to ensure their security within federal cloud deployments. This includes:  Comprehensive scans integrated into CI/CD pipelines  Prioritize remediation based on severity Re-scanning policy post-remediation  Detailed audit and compliance reports  Checks against secure baselines (i.e., CIS or STIG) 4) Secure Sensors FedRAMP requires continuous management of the security of machines, applications, and systems by identifying vulnerabilities.  Authorized scanning tools Authenticated security scans to simulate threats Reporting and remediation Scanning independent of developers Direct integration with configuration management to track vulnerabilities 5) Registry Monitoring While not explicitly called out in FedRAMP as either a control or a control family, there is still a requirement that the images stored in a container registry are scanned at least every 30-days if the images are deployed to production. 6) Asset Management and Inventory Reporting for Deployed Containers FedRAMP mandates thorough asset management and inventory reporting for deployed containers to ensure security and compliance. Organizations must maintain detailed inventories including: Container images Source code Versions Configurations  Continuous monitoring of container state  7) Encryption FedRAMP mandates robust encryption standards to secure federal information, requiring the use of NIST-approved cryptographic methods for both data at rest and data in transit. It is important that any containers that store data or move data through the system meet FIPS standards. How Anchore helps organizations comply with these requirements Anchore is the leading software supply chain security platform for meeting FedRAMP compliance. We have helped hundreds of organizations meet FedRAMP compliance by deploying Anchore Enterprise as the solution for achieving container security compliance. Below you can see an overview of how Anchore Enterprise integrates into a FedRAMP compliant environment. For more details on how each of these integrations meet FedRAMP compliance keep reading. 1) Hardened Images Anchore Enterprise integrates multiple tools in order to meet the FedRAMP requirements for hardened container images. We provide compliance policies that scan specifically for compliance with container hardening standards, such as, STIG and CIS. These tools were custom built to perform the checks necessary to meet the two relevant standards or both! Anchore’s Static STIG Checker (SSC) tool Anchore’s CIS policy bundle enforces Docker CIS benchmark checks 2) Container Build, Test, and Orchestration Pipelines Anchore integrates directly into your CI/CD pipelines either the Anchore Enterprise API or pre-built plug-ins. This tight integration meets the FedRAMP standards that require all container images are hardened, all security checks are automated within the build process and all actions are logged and audited. Anchore's FedRAMP policy specifically checks to make sure that any container in any stage of the pipeline will be checked for compliance. Anchore integrates into your CI/CD pipelines Anchore’s FedRAMP policy bundle enforces NIST 800-53 controls 3) Vulnerability Scanning for Container Images Anchore Enterprise can be integrated into each stage of the development pipeline, offer remediation recommendations based on severity (e.g., CISA's KEV vulnerabilities can be flagged and prioritized for immediate action), enforce re-scanning of containers after remediation and produce compliance artifacts to automate compliance. This is accomplished with Anchore's container scanner, direction pipeline integration and FedRAMP policy. 4) Secure Sensors Anchore Enterprise's container vulnerability scanner and Kubernetes inventory agent are both authorized scanning tools. The container vulnerability scanner is integrated directly into the build pipeline whereas the k8s agent is run in production and scans for non-compliant containers at runtime. 5) Registry Monitoring Anchore Enterprise is able to scan an artifact registry continuously for potentially non-compliant containers. It is configured to watch each unique image in image registries. It will automatically scan images that get pushed to these registries. 6) Asset Management and Inventory Reporting for Deployed Containers Anchore Enterprise includes a full software component inventory workflow. It can scan all software components, generate Software Bill of Materials (SBOMs) to keep track of the component and centrally store all SBOMs for analysis. Anchore Enterprises's Kubernetes inventory agent can perform the same service for the runtime environment. 7) Encryption Anchore Enterprise Static STIG tool can ensure that all containers are maintaining NIST & FIPS encryption standards. Verifying that containers are encrypting data at-rest and in-transit for each of thousands of containers is a difficult chore but easily automated via Anchore Enterprise. The benefits of the shift left approach of Anchore Enterprise Shift compliance left and prevent violations Detect and remediate FedRAMP compliance violations early in the development lifecycle to prevent production/high-side violations that will threaten your hard earned compliance. Use Anchore's “developer-bundle” in the integration phase to take immediate action on potential compliance violations. This will ensure vulnerabilities with fixes available and CISA KEV vulnerabilities are addressed before they make it to the registry and you have to report these non-compliance issues. Below is an example of a workflow in GitLab of how Anchore Enterprise's SBOM generation, vulnerability scanning and policy enforcement can catch issues early and keep your compliance record clean. Automate Compliance Reporting Automate monthly/annual reporting using Anchore’s reporting. Have these reports set up to auto generate based on the compliance reporting needs of FedRAMP. Manage POA&Ms Given that Anchore Enterprise centrally stores and manages vulnerability information for an organization, it can also be utilized to manage Plan Of Action & Milestones (POA&Ms) for any portions of the system that aren't yet FedRAMP compliant but have a planned due date. Using Allowlists in Anchore Enterprise to centrally manage POA&Ms and assessed/justifiable findings. Prevent Production Compliance Violations Practice good production registry hygiene by utilizing Anchore Enterprise to scan stored images regularly. Anchore Enterprise’s Kubernetes runtime inventory will identify images that do not meet FedRAMP compliance or have not been used in the last ~7 days (company defined) to remove from your production registry. Conclusion Achieving FedRAMP compliance from scratch is an arduous process and not a key differentiator for many organizations. In order to maintain organizational priority on the aspects of the business that differentiate an organization from its competitors, strategic outsourcing of non-core competencies is always a recommended strategy. Anchore Enterprise aims to be that turnkey solution for organizations that want the benefits of FedRAMP compliance without developing the internal expertise, specifically for the container security aspect. By integrating SBOM generation, vulnerability scanning, and policy enforcement into a single platform, Anchore Enterprise not only simplifies the path to compliance but also enhances overall software supply chain security. Through the deployment of Anchore Enterprise, companies can achieve and maintain compliance more quickly and with greater assurance. If you're looking for an even deeper look at how to achieve all 7 of the container security requirements of FedRAMP with Anchore Enterprise, read our playbook: FedRAMP Pre-Assessment Playbook For Containers. ### From Chaos to Compliance: Revolutionizing License Management with Automation The ascent of both containerized applications and open-source software component building blocks has dramatically escalated the complexity of software and the burden of managing all of the associated licenses. Modern applications are often built from a mosaic of hundreds, if not thousands, of individual software components, each bound by its own potential licensing pitfalls. This intricate web of dependencies, akin to a supply chain, poses significant challenges not only for legal teams tasked with mitigating financial risks but also for developers who manage these components' inventory and compliance. Previously license management was primarily a manual affair, software wasn't as complex in the past and more software was proprietary 1st party software that didn't have the same license compliance issues. These original license management techniques haven't kept up with the needs of modern, cloud-native application development. In this blog post, we're going to discuss how automation is needed to address the challenges of continuing to manage licensing risk in modern software. The Problem Modern software is complex. This is fairly well known at this point but in case you need a quick visual reminder, we've inserted to images to quickly reinforce this idea: Applications can be constructed from 10s or 100s or even 1000s of individual software components each with their own license for how it can be used. Modern software is so complex that this endlessly nested collection of dependencies are typically referred to as a metaphorical supply chain and there is an entire industry that has grown to provide security solutions for this quagmire called software supply chain security.  This is a complexity nightmare for legal teams that are tasked with managing the financial risk of an organization. It's also a nightmare for the developers who are tasked with maintaining an inventory of all of the software dependencies in an organization and the associated license for each component. Let's provide an example of how this normally manifests in a software startup. Assuming business is going well, you have a product and there are customers out in the world that are interested in purchasing your software. During the procurement cycle, your customer's legal team will be tasked with assessing the risk of using your software. In order to create this assessment they will do a number of things and one of them will be to determine if your software is safe from a licensing perspective to use. In order to do this they will normally send over a document that looks like this: As a software vendor, it will be your job to fill this out so that legal can approve the purchasing of your software and you can take that revenue to the bank. Let's say you manually fill this entire spreadsheet out. A developer would need to go through each dependency that is utilized in the software that you sell and "scan" the codebase for all of the licensing metadata. Component name, version number, OSS license (i.e., MIT, GPL, BSD, etc.), etc. It would take some time and be quite tedious but not an insurmountable task. In the end they would produce something like this: This is great in the world of once-in-a-while deployments and updates. This becomes exhausting in the world of continuous integration/delivery that the DevOps movement has created. Imagine having to produce a new document like this everytime you push to production. DevOps has allowed for some times to push to production multiple times per day.  Requiring that a document is manually created for all of your customers' legal teams for each release would almost eliminate all of the velocity gains that moving to the DevOps architecture created. The Solution The solution to this problem is the automation of the license discovery process. If software can scan your codebase and produce a document that will exhaustively cover all of the building blocks of your application this unlocks the potential to both have your DevOps cake and eat it too. To this end, Anchore has created and open sourced a tool that does just this. Introducing Grant: Automated License Discovery Grant is an open-source command line tool that scans and discovers the software licenses of all dependencies in a piece of open-source software. If you want to get a quick primer on what you can do with Grant, read our announcement blog post. Or if you're ready to dive straight in, you can view all of the Grant documentation on its GitHub repo. How does Grant Integrate into my Development Workflow? As a software license scanner, Grant operates on a software inventory artifact like an SBOM or directly on a container image. Let's continue with the example from above to bring this to life. In the legal review example above you are a software developer that has been tasked with manually searching and finding all of the OSS license files to provide to your customer's legal team for review. Not wanting to do this manually by hand, you instead open up your CLI and install Grant. From there you navigate to your artifact registry and pull down the latest image of your application's production build. Right before you run the Grant license scan on your production container image you notice that your team has been following software supply chain best practices and have already created an SBOM with a popular open-source tool called Syft. Instead of running the container through Grant which could take some time to scan the image, you instead pipe the SBOM into Grant which is already a JSON object of the entire dependency inventory of the application. A few seconds later you have a full report of all of the licenses in your application.   From here you export the full component inventory with the license enrichment into a spreadsheet and send this off to the customer's legal team for review. A process that might have taken a full day or even multiple days to do by hand was finished in seconds with the power of open-source tooling. Automating License Compliance with Policy Grant is an amazing tool that can automate much of the most tedious work of protecting an organization from legal consequences but when used by a developer as a CLI tool, there is still a human in the loop which can cause traffic jams to occur. With this in mind, our OSS team made sure to launch Grant with support for policy-based filters that can automate the execution and alerting of license scanning.  Let's say that your organization's legal team has decided that using any GPL components in 1st party software is too risky. By writing a policy that fails any software that includes GPL licensed components and integrating the policy check as early as the staging CI environment or even allowing developers to run Grant in a one-off fashion during design as they prototype the initial idea, the potential for legally risky dependencies infiltrating into production software drops precipitously. How Anchore Can Help Grant is an amazing tool that automates the license compliance discovery process. This is great for small projects or software that does irregular releases. Things get much more complicated in the cloud-native, continuous integration/deployment paradigm on DevSecOps where there are new releases multiple times per day. Having Grant generate the license data is great but suddenly you will have an explosion of data that itself needs to be managed. This is where Anchore Enterprise steps in to fill this gap. The Anchore Enterprise platform is an end-to-end data management solution that not only incorporates all of Anchore's open-source tooling that generates artifacts like SBOMs, vulnerability scans and license scans. It also manages the massive amount of data that a high speed DevSecOps pipeline will create as part of its regular operation and on top of that apply a highly customizable policy engine that can then automate decision-making around the insights derived from the software supply chain artifacts like SBOMs, vulnerability scans and license scans.  Want to make sure that no GPL license OSS components ever make it into your SDLC? No problem. Grant will uncover all components that have this license, Anchore Enterprise will centralize these scans and the Anchore policy engine will alert the developer who just integrated a new GPL licensed OSS component into their development environment that they need to find a different component or they won't be able to push their branch to staging. The shift left principle of DevSecOps can be applied to LegalOps as well.  Conclusion The advent of tools like Grant, an open-source license discovery solution developed by Anchore, marks a significant advancement in the realm of open-source license management. By automating the tedious process of license verification, Grant not only enhances operational efficiency but also integrates seamlessly into continuous integration/continuous delivery (CI/CD) environments. This capability is crucial in modern DevOps practices, which demand frequent and fast-paced updates. Grant's ability to quickly generate comprehensive licensing reports transforms a potentially day-long task into a matter of seconds. Anchore Enterprise extends this functionality by managing the deluge of data from continuous deployments and integrating a policy engine that automates compliance decisions. This ecosystem not only streamlines the process of license management but also empowers developers and legal teams to preemptively address compliance issues, thereby embedding legal safeguards directly into the software development lifecycle. This proactive approach ensures that as the technological landscape evolves, businesses remain agile yet compliant, ready to capitalize on opportunities without being bogged down by legal liabilities. If you're interested to hear about the topics covered in this blog post directly from the lips of Anchore's CTO, Dan Nurmi, and the maintainer of Grant, Christopher Phillips, you can watch the on-demand webinar here. Or join the Anchore Community Discourse forum to speak with our team directly. We look forward to hearing from you and reviewing your pull requests! ### An Outline for Getting Up to Speed on the DoD Software Factory This blog post is meant as a gateway to all things DoD software factory. We highlight content from across the Anchore universe that can help anyone get up to speed on what a DoD software factory is, why to use it and how to build one. This blog post is meant as an index to be scanned for the topics that are most interesting to you as the reader with links to more detailed content. What is a DoD Software Factory? The short answer is a DoD Software Factory is an implementation of the DoD Enterprise DevSecOps Reference Design. A slightly longer answer comes from our DoD software factory primer: A Department of Defense (DoD) Software Factory is a software development pipeline that embodies the principles and tools of the larger DevSecOps movement with a few choice modifications that conform to the extremely high threat profile of the DoD and DIB. Note that the diagram below looks like a traditional DevOps pipeline. The difference being that there are security controls layered into this environment that automate software component inventory, vulnerability scanning and policy enforcement to meet the requirements to be considered a DoD software factory. Got the basics down? Go deeper and learn how Anchore can help you put the Sec into DevSecOps Reference Design by reading our DoD Software Factory Best Practices white paper. Why do I want to utilize a DoD Software Factory? For DoD programs, the primary reason to utilize a DoD software factory is that it is a requirement for achieving a continuous authorization to operation (cATO). The cATO standard specifically calls out that software is developed in a system that meets the DoD Enterprise DevSecOps Reference Design. A DoD software factory is the generic implementation of this design standard. For Federal Service Integrators (FSIs), the biggest reason to utilize a DoD software factory is that it is a standard approach to meeting DoD compliance and certification standards. By meeting a standard, such as CMMC Level 2, you expand your opportunity to work with DoD programs. Continuous Authorization to Operate (cATO) If you're looking for more information on cATO, Anchore has written a comprehensive guide on navigating the cATO process that can be found on our blog: DevSecOps for a DoD Software Factory: 6 Best Practices for Container Images The shift from traditional software delivery to DevSecOps in the Department of Defense (DoD) represents a crucial evolution in how software is built, secured, and deployed with a focus on efficiencies and speed. Our white paper advises on best practices that are setting new standards for security and efficiency in DoD software factories. Cybersecurity Maturity Model Certification (CMMC) The CMMC is the certification standard that is used by the DoD to vet FSIs from the defense industrial base (DIB). This is the gold standard for demonstrating to the DoD that your organization takes security seriously enough to work with the highest standards of any DoD program. The security controls that the CMMC references when determining certification are outlined in NIST 800-171. There are 17 total families of security controls that an organization has to meet in order to meet the CMMC Level 2 certification and a DoD software factory can help check a number of these off of the list. The specific families of controls that a DoD software factory helps meet are: Access Control (AC) Audit and Accountability (AU) Configuration Management (CM) Incident Response (IR) Maintenance (MA) Risk Assessment (RA) Security Assessment and Authorization (CA) System and Communications Protection (SC) System and Information Integrity (SI) Supply Chain Risk Management (SR) If you're looking for more information on how apply software supply chain security to meet the CMMC, Anchore has published two blog posts on the topic: NIST SP 800-171 & Controlled Unclassified Data: A Guide in Plain English NIST SP 800-171 is the canonical list of security controls for meeting CMMC Level 2 certification. Anchore has broken down the entire 800-171 standard to give you an easy to understand overview. Automated Policy Enforcement for CMMC with Anchore Enterprise Policy Enforcement is the backbone of meeting the monitoring, enforcement and reporting requirements of the CMMC. In this blog post, we break down how Anchore Federal can meet a number of the controls specifically related to software supply chain security that are outlined in NIST 800-171. How do I meet the DevSecOps Reference Design requirements? The easy answer is by utilizing a DoD Software Factory Managed Service Provider (MSP). Below in the User Stories section, we deep dive into the US Air Force's Platform One given they are the preeminent DoD software factory. The DIY answer involves carefully reading and implementing the DoD Enterprise DevSecOps Reference Design. This document is massive but there are a few shortcuts you can utilize to help expedite your journey.  Container Hardening Deciding to utilize software containers in a DevOps pipeline is almost a foregone conclusion at this point. What is less well known is how to secure your containers, especially to meet the standards of a DoD software factory. The DoD has published two guides that can help with this. The first is the DoD Container Hardening Guide, and the second is the Container Image Creation and Deployment Guide. Both name Anchore Federal as an approved container hardening scanner. Anchore has published a number of blogs and even a white paper that condense the information in both of these guides into more digestible content. See below: Container Security for U.S. Government Information Systems This comprehensive white paper breaks down how to achieve a container build and deployment system that is hardened to the standards of a DoD software factory. Enforcing the DoD Container Image and Deployment Guide with Anchore Federal This blog post is great for those who are interested to see how Anchore Federal can turn all of the requirements of the DoD Container Hardening Guide and the Container Image Creation and Deployment Guide into an easy button. Deep Dive into Anchore Federal’s Container Image Inspection and Vulnerability Management This blog post deep dives into how to utilize Anchore Federal to find container vulnerabilities and alert or report on whether they are violating the security compliance required to be a DoD software factory. Policy-based Software Supply Chain Security and Compliance The power of a policy-based approach to software supply chain security is that it can be integrated directly into a DevOps pipeline and automate a significant amount of alerting, reporting and enforcement work. The blog posts below go into depth on how this automated approach to security and compliance can uplevel a DoD software factory: A Policy Based Approach to Container Security & Compliance This blog details how a policy-based platform works and how it can benefit both software supply chain security and compliance.  The Power of Policy-as-Code for the Public Sector This follow-up to the post above shows how the policy-based security platform outlined in the first blog post can have significant benefits to public sector organizations that have to focus on both internal information security and how to prove they are compliant with government standards. Benefits of Static Image Inspection and Policy Enforcement Getting a bit more technical this blog details how a policy-based development workflow can be utilized as a security gate with deployment orchestration systems like Kubernetes. Getting Started With Anchore Policy Bundles An even deeper dive into what is possible with the policy-based security system provided by Anchore Enterprise, this blog gets into the nitty-gritty on how to configure policies to achieve specific security outcomes. Unpacking the Power of Policy at Scale in Anchore This blog shows how a security practitioner can extend the security signals that Anchore Enterprise collects with the assistance of a more flexible data platform like New Relic to derive more actionable insights. Security Technical Implementation Guide (STIG) The Security Technical Implementation Guides (STIGs) are fantastic technical guides for configuring off the shelf software to DoD hardening standards. Anchore being a company focused on making security and compliance as simple as possible has written a significant amount about how to utilize STIGs and achieve STIG compliance, especially for container-based DevSecOps pipelines. Exactly the kind of software development environments that meet the standards of a DoD software factory. View our previous content below: 4 Ways to Prepare your Containers for the STIG Process In this blog post, we give you four quick tips to help you prepare for the STIG process for software containers. Think of this as the amuse bouche to prepare you for the comprehensive white paper that comes next. Navigating STIG Compliance for Containers As promised, this is the extensive document that walks you through how to build a DevSecOps pipeline based on containers that is both high velocity and secure. Perfect for organizations that are aiming to roll their own DoD software factory. User Stories Anchore has been supporting FSIs and DoD programs to build DevSecOps programs that meet the criteria to be called a DoD software factory for the past decade. We can write technical guides and best practices documents till time ends but sometimes the best lessons are learned from real-life stories. Below are user stories that help fill in all of the details about how a DoD software factory can be built from scratch: DoD's Pathway to Secure Software Join Major Camdon Cady of Platform One and Anchore's VP of Security, Josh Bressers as they discuss the lessons learned from building a DoD software factory from the ground up. Watch this on-demand webinar to get all of the details in a laid back and casual conversation between two luminaries in their field. Development at Mach Speed If you prefer a written format over video, this case study highlights how Platform One utilized Red Hat OpenShift and Anchore Federal to build their DoD software factory that has become the leading Managed Service Provider for DoD programs. Conclusion Similar to how Cloud has taken over the infrastructure discussion in the enterprise world, DoD software factories are quickly becoming the go-to solution for DoD programs and the FSIs that support them. Delivering on the promise of the DevOps movement of high velocity development without compromising security, a DoD software factory is the one-stop shop to upgrade your software development practice into the modern age and become compliant as a bonus! If you're looking for an easy button to infuse your DevOps pipeline with security and compliance without the headache of building it yourself, take a look at Anchore Federal and how it helps organizations layer software supply chain security into a DoD software factory and achieve a cATO. ### 4 Ways to Prepare your Containers for the STIG Process 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. Learn more about putting your containers through the STIG process in our new white paper entitled Navigating STIG Compliance for Containers! ### Software Security in the Real World ### We don’t know how to fix the xz problem, but we can detect it A very impressive and scary attack against the xz library was uncovered on Friday, which made for an interesting weekend for many of us. There has been a lot written about the technical aspects of this attack, and more will be uncovered over the next few days and weeks. It’s likely we’re not done learning new details about this attack. This doesn’t appear to affect as many organizations as Log4Shell did, but it’s a pretty big deal. Especially what this sort of attack means for the larger ecosystem of open source. Trying to explain the details isn’t the point of this blog post. There’s another angle of this story that’s not getting much attention. How can we solve problems like this (we can’t), and what can we do going forward? The unsolvable problem Sometimes reality can be harsh, but the painful truth about this sort of attack is that there is no solution. Many projects and organizations are happy to explain how they keep you safe, or how you can prevent supply chain attacks, by doing this one simple thing. However, the industry as it stands today lacks the ability to prevent an attack created by a motivated and resourced threat actor. If we want to use an analogy, preventing an attack like xz is the equivalent of the pre-crime science fiction dystopian stories. The idea behind pre-crime is to use data or technology to predict when a crime is going to happen, then stopping it. This leads to a number of problems in any society that adopts such a thing as one can probably imagine. If there is a malicious open source maintainer, we lack the tools and knowledge to prevent this sort of attack, as you can’t actually stop such behavior until after it happens. It may be possible there’s no way to stop something like this before it happens. HOWEVER, that doesn’t mean we are helpless. We can take a page out of the playbook of the observability industry. Sometimes we're able to see problems as they happen or after they happen, then use that knowledge from the past to improve the future, that is a problem we can solve. And it’s a solution that we can measure. If you have a solid inventory of your software, looking for affected versions of xz becomes simple and effective. Today and Tomorrow Of course looking for a vulnerable version of xz, specifically versions 5.6.0 and 5.6.1, is something we should all be doing. If you’ve not gone through the software you’re running you should go do this right now. See below for instructions on how to use Syft and Anchore Enterprise to accomplish this. Finding two specific versions of xz is a very important task right now, there’s also what happens tomorrow. We’re all very worried about these two specific versions of xz, but we should prepare for what happens next. It’s very possible there will be other versions of xz that end up having questionable code that needs to be removed or downgraded. There could be other libraries that have problems (everyone is looking for similar attacks now). We don’t really know what’s coming next. The worst part of being in the middle of attacks like this are the unknowns. But there are some things we do know. If you have an accurate inventory of your software, figuring out what software or packages you need to update becomes trivial. Creating an inventory If you’re running Anchore Enterprise the good news is you already have an inventory of your software. You can create a report that will look for images affected by CVE-2024-3094. The above image shows how a report in Anchore Enterprise can be created.  Another feature of Anchore Enterprise allows you to query all of your SBOMs for instances of specified software via an API call, by package name.  This is useful for gaining insights about the location, ubiquity, and the version spread of the software, present in your environment. The package names in question are the liblzma5 and xz-libs packages, which cover the common naming across rpm, dpkg, and apkg based Linux distributions.  For example:     See the Anchore Enterprise API Browser for more information about the API, and the Anchore Enterprise Documentation for more details on reporting, vulnerability scanning, and other functions of the system. If you’re using Syft, it’s a little bit more complicated, but still a very solvable problem. The first thing to do is generate SBOMs for the software you’re using. Let’s create SBOMs for container images in this example. It’s important to keep those SBOMs you just created somewhere safe. If we then find out in a few days or weeks that other versions of xz shouldn’t be trusted, or if a different open source library has a similar problem, we can just run a query against those files to understand how or if we are affected. Now that we have a directory full of SBOMs, we can run a query similar to these to figure out which SBOMs have a version of xz in them. While the example looks for xz, if the need to quickly look for other packages arises in the near future, it’s easy to adjust your query. It’s even easier if you store the SBOMs in some sort of searchable database. What now? There’s no doubt it’s going to be a very interesting couple of weeks for many of us. Anyone who has been watching the news is probably wondering what wild supply chain story will happen next. The pace of solving open source security problems hasn’t kept pace with the growth of open source. There will be no quick fixes. The only way we get out of this one is a lot of hard questions and even more hard work. But in the meantime, we can focus on understanding and defending what we have. Sometimes the best defense is a good defense. Want a primer on software suppy chain security? Get our whitepaper here. ### Navigating the NVD Quagmire The global cybersecurity community has been in a state of uncertainty since the National Vulnerability Database (NVD) has degraded service starting in mid-February. There has been a lot of coverage of this incident this month and Anchore has been at the center of much of it. If you haven't been keeping up, this blog post is here to recap what has happened so far and how the community has been responding to this incident. Our VP of Security, Josh Bressers has been leading the charge to educate and organize the community. First with his Open Source Security podcast that goes through what is happening with NVD and why it is important. On top of that, last week he participated in a livestream with Chainguard Co-founder Dan Lorenc on the Resilient Cyber Show hosted by Chris Hughes on the implications of the current delay with NVD service. We've condensed the topics from these resources into a blog post that will cover the issues created by the delay in NVD service, a background on what has happened so far, a potential open-source solution to the problem and a call to action for advocacy. Continue reading for the good stuff. The problem Federal agencies mandate NVD is used as the primary data source of truth even if there could be higher quality data sources available. This mainly comes down to the fact that the severity scores, meaning the Common Vulnerability Scoring System (CVSS), determines when an agency or organization is out of compliance with a federal security standard. Given that compliance standards are created by the US government, only NVD can score a vulnerability and determine the appropriate action in order to stay in compliance. That's where the problem starts to come in, you've got a whole bunch of government agencies on one hand saying, 'you must use this data'. And then another government agency that says, "No, you can't rely on this for anything". This leaves folks working with the government in a bit of a pickle. –Dan Lorenc, Co-Founder, Chainguard If NVD isn't assigning severities to vulnerabilities, it’s not clear what that means for maintaining compliance and they could be exposing themselves to significant risk. For example, there could be high severity vulnerabilities being published by organizations that are unaware because this vital review and scoring process has been removed. Background on NVD and the current state of affairs NVD is the canonical source of truth for software vulnerabilities for the federal government, specifically for 10+ federal compliance standards. It has also become a go-to resource for the worldwide security community even if individual organizations in the wider community aren't striving to meet a United States compliance standard. NVD adds a number of enrichments to CVE data but there are two of particular importance; first, it adds a severity score to all CVEs and two, it adds information of which versions of the software are impacted by the CVE. The National Institute of Standards and Technology (NIST) has been providing this service to the security community for over 20 years through the NVD. That changed last month: Timeline Feb 12: NVD dramatically reduces the number of CVEs that are being enriched: Feb 15: NVD posts message about delay of enrichment on NVD Website Mar 08: Anchore publishes National Vulnerability Database: Opaque changes and unanswered questions when delay continues for almost a month Mar 21: Livestream of the Resilient Cyber Show's "Untangling NVD Chaos" is broadcast Mar 27: NVD session at VulnCon; potential announcement from NVD about future state of database Read a comprehensive background in our original blog post, National Vulnerability Database: Opaque changes and unanswered questions. Developing an Open-Source Solution The Anchore team developed and maintains an open-source vulnerability scanner called Grype that utilizes the NVD as one of many vulnerability feeds as well as a software supply chain security platform called Anchore Enterprise that incorporates Grype. Given that both products use data from NVD, it was particularly important for Anchore to engage in the current crisis. While there is nothing that Anchore can do about the missing severity scores, the other highlighted missing enrichment was the versions of the software that are impacted by the CVE, aka, Common Platform Enumeration (CPE). The matching logic ends up being the more important signal during impact analysis because it is an objective measure of impact rather than severity scoring which can be debated (and is, at length). Given Anchore's history with the open-source software community, creating an OSS project to fill a gap in the NVD enrichment seemed the logical choice. The goal of going the OSS route is to leverage the transparent process and rapid iteration that comes from building software publicly. Anchore is excited to collaborate with the community to: Ingest CVE data Analyze CVEs Improve the CVE-to-versioning mapping process  Everyone is being crushed by the unrelenting influx of vulnerabilities. It's not just NVD. It's not one organization. We can either sit in our silos and be crushed to death or we can work together. –Josh Bressers, VP of Security at Anchore If you're looking to utilize this data and software as a backfill while NVD continues delaying analysis or want to contribute to the project, please join us on GitHub!  Cybersecurity Awareness and Advocacy It might seem strange that the cybersecurity community would need to convince the US government that investing in the cybersecurity ecosystem is a net positive investment given that the federal government is the largest purchaser of software in the world and is probably the largest target for threat actors. But given how NIST has decided to degrade the service of NVD and provide only opaque guidance on how to fill the gap in the meantime, it doesn't appear that the right hand is talking with the left. Whether the federal government intended to or not, by requiring that organizations and agencies utilize NVD in order to meet a number of federal compliance standards, it effectively became the authority on the severity of software vulnerabilities for the global cybersecurity ecosystem. By providing a valuable and reliable service to the community, the US garnered the trust of the ecosystem. The current state of NVD and the manner in which it was rolled out has degraded that trust.  It is unknown whether the US will cede its authority to another organization, the EU may attempt to fill this vacuum with its own authoritative database but in the meantime, advocacy for cybersecurity awareness within the government is paramount. It is up to the community to create the pressure that will demonstrate the urgency with the current strategy around a vital community resource like NVD.  Conclusion Anchore is committed to keeping the community up-to-date on this incident as it unfolds. To stay informed, be sure to follow us on LinkedIn or Twitter/X. If you'd like to watch the livestream in all its glory, click on the image below to go to the VOD. Also, if you're looking for more in-depth coverage of the NVD incident, Josh Bressers has a security podcast called, Open Source Security that covers the NVD incident and the history of NVD. ### Tracking License Compliance Made Easy: Intro to Grant (OSS) ### Spring Webinar Update: Expand Your Knowledge with Our Expert-Led Sessions In our continuous effort to bring valuable insights and tools to the world of software supply chain security, we are thrilled to announce two upcoming webinars and one recently held webinar now available for on-demand access. Whether you're looking to enhance your understanding of software security, explore open-source tools to automate OSS licensing management, or navigate the complexities of compliance with federal standards, our expert-led webinars are designed to equip you with the knowledge you need. Here's what's on the agenda: Tracking License Compliance Made Easy: Intro to Grant (OSS) Date: Mar 26, 2024 at 2pm EDT  (11am PDT) Join us as Anchore CTO, Dan Nurmi and Grant Maintainer, Christopher Phillips discuss the challenges of managing software licenses within production environments, highlighting the complexity and ongoing nature of tracking open-source licenses. They will introduce Grant, an open-source tool designed to alleviate the burden of OSS license inspection by demonstrating how to scan for licenses within SBOMs or container images, simplifying a typically manual process. The session will cover the current landscape of software licenses, the difficulties of compliance checks, and a live demo of Grant's features that automate this previously laborious process. Save a Seat Software Security in the Real World with Kelsey Hightower and Dan Perry Date: April 4th, 2024 at 2pm EDT  (11am PDT) In our upcoming webinar, experts Kelsey Hightower and Dan Perry will delve into the nuances of securing software in cloud-native, containerized applications. This in-depth session will explore the criteria for vulnerability testing success or failure, offering insights into security testing and compliance for modern software environments.  Through a live demonstration of Anchore Enterprise, they'll provide a comprehensive look at visibility, inspection, policy enforcement, and vulnerability remediation, equipping attendees with a deeper understanding of software supply chain security, proactive security strategies, and practical steps to embark on a software security journey.  The discussion will continue after the webinar on X/Twitter with Kelsey Hightower. Save a Seat FedRAMP and SSDF Compliance: How to Sell to the Federal Government This webinar explores how Anchore aids in navigating the complex compliance requirements for selling software to the federal government, focusing on FedRAMP vulnerability scanning and SSDF compliance. Led by Josh Bressers, VP of Security and Connor Wynveen, Senior Solutions Engineer it will detail evaluating FedRAMP controls for software containers and adhering to SSDF guidelines.  Key takeaways include strategies to streamline FedRAMP and SSDF compliance efforts, leveraging SBOMs for efficiency, the critical role of automated vulnerability scans, and how Anchore's policy pack can assist organizations in meeting compliance standards. Watch On-Demand Accessing the Webinars Don't miss out on the opportunity to expand your knowledge and skills with these sessions. To register for the upcoming webinars or to access the on-demand webinar, visit our webinar landing page. Whether you're looking to stay ahead of the curve in software security, explore funding opportunities for your open-source projects, or break into the federal market, our webinars are designed to provide you with the insights and tools you need. We look forward to welcoming you to our upcoming webinars. Stay informed, stay ahead! ### National Vulnerability Database: Opaque changes and unanswered questions A short history lesson on the NVD Founded in 2005, The National Vulnerability Database, or NVD, is a collection of vulnerability data by the National Institute of Standards and Technology (NIST) in the United States. As of today, many companies rely on NVD data for their security operations and vulnerability research. NVD describes itself as: The NVD is the U.S. government repository of standards based vulnerability management data represented using the Security Content Automation Protocol (SCAP). This data enables automation of vulnerability management, security measurement, and compliance. The NVD includes databases of security checklist references, security related software flaws, product names, and impact metrics. The primary role of the NVD is adding data to vulnerabilities that have been assigned a CVE ID. They include additional metadata such as severity levels via Common Vulnerability Scoring System (CVSS), and affected data via Common Platform Enumeration (CPE). NIST is responsible for maintaining the NVD as each CVE ID can require additional modifications or maintenance as the nature of vulnerabilities can change daily. This is a service NVD has been providing for nearly 20 years. The graph below shows a historical trend of CVE IDs that have been published in the CVE program (green), alongside the analysis data provided by NVD (red), since 2005. Key: Green is all CVE IDs in NVD. Red is IDs with a CPE attached We can see nearly every CVE has been enriched by NVD during this time. A problematic website notice from the NVD On February 15th 2024, a banner appeared on the NVD website stating: NIST is currently working to establish a consortium to address challenges in the NVD program and develop improved tools and methods. You will temporarily see delays in analysis efforts during this transition. We apologize for the inconvenience and ask for your patience as we work to improve the NVD program. It’s not entirely clear what this message means for the data provided by NVD or what the public should expect.  While attempting to research the meaning behind this statement, Anchore engineers have discovered that as of February 15, 2024, NIST has almost completely stopped updating NVD with analysis for CVE IDs. The graph below shows the trend of CVE IDs that have been published in the CVE program (green), alongside the analysis data provided by NVD (red), since early January 1, 2024. Key: Green is all CVE IDs in NVD. Red is IDs with a CPE attached Starting February 12th, thousands of CVE IDs have been published without any record of analysis by NVD. Since the start of 2024 there been a total of 6,171 total CVE IDs with only 3,625 being enriched by NVD. That leaves a gap of 2,546 (42%!) IDs. NVD has become an industry standard for organizations and security products to rely on their data for security operations, such as prioritizing vulnerability remediation and securing infrastructures. CVE IDs are constantly being added and updated, but those IDs are missing key analytical data provided by NVD. Any organizations that depend on NVD for vulnerability data such as CVSS scores are no longer receiving updates to the CVE data. This means that organizations relying on this data are left in the dark with new vulnerabilities, imposing greater risk and unmanaged attack surface for their environment. Wait and see? How to fill the gap of this missing data has not yet been addressed by NVD. There are other vulnerability databases such as the GitHub Advisory Database and the CVE5 database that contain severity ratings and affected products, but by definition, those databases cannot provide NVD severity scores. Anchore is investigating options to create a public repository of identifiers to fill this gap. We invite members of the security community to join us at our next meetup on March 14th 2024 as we research options. Details for the meetup are available on GitHub.  In the meantime, we will continue to look for updates from NIST and hope that they are more transparent about their service situation soon. Adapting to the new normal at NVD with Anchore Vulnerability Feed SAVE A SEAT ### Syft Reaches v1.0! Early in 2020 we started work on Syft, an SBOM generator that is easy to install and use and supports a variety of SBOM formats. In late September of 2020 we released the first version of Syft with seven ecosystems supported. Since then we’ve had 168 releases made up of the work from 134 contributors, collectively adding an additional 18 ecosystems -- a total of over 40 package catalogers.  Today we’re going one step further: we’re thrilled to announce the release of Syft v1.0.0! 🎉 What is Syft? At a high level, Syft answers the seemingly simple question:  “what is in my application?”. To a finer point, Syft is a standalone CLI tool and library that scans container images and file systems in order to generate an SBOM: the Software Bill of Materials that describes what software components were found. While Syft’s capability to generate a detailed SBOM is useful in its own right, we consider Syft to be a foundational tool that supports both our growing list of open-source offerings as well as dozens of other OSS projects. Ultimately it delivers a way for users to both generate SBOM material for their projects as well as use those same SBOMs for other important functions such as vulnerability scanning, OSS license reporting, tracking components at various stages of the application lifecycle, and other custom use cases. Some of the important dimensions of Syft are: Sources: types of software applications and artifacts that can be scanned by Syft to produce an SBOM, such as docker container images, source code directories, and more. Catalogers: functions that are implemented for a given type of software artifact / packaging ecosystem, such as Java JAR files, RPMs, Go modules, and more. Output Formats: interchangeable formats to put the SBOM material into, post-SBOM generation, such as the Syft-native JSON, SPDX (multiple versions), CycloneDX (multiple versions), and user-customizable formats via templating. Over time, we’ve seen the list of sources, catalogers, and output formats continue to grow, and we are looking forward to adding even more capabilities as the project continues forward.   Capabilities of Syft To start with, Syft needs to know how to read what you're giving it. There are a number of different types of sources Syft supports: directories, individual files, archives, and - of course - container images! And there are a lot of options such as letting you choose what scope you want to be cataloged within an image. By default we consider a squashed layer scope, which is most like what the filesystem will look like when a container is created from the image. But we also allow for looking at all layers within the container image, which would include contents that are distributed but not available when a container is created. In future versions we want to expand these selections to support even more use cases. When scanning a source we have several catalogers scouring for packaging artifacts, covering several ecosystems: Alpine (apk) C/C++ (conan) Dart (pubs) Debian (dpkg) Dotnet (deps.json) Objective-C (cocoapods) Elixir (mix) Erlang (rebar3) Go (go.mod, Go binaries) Haskell (cabal, stack) Java (jar, ear, war, par, sar, nar, native-image) JavaScript (npm, yarn) Jenkins Plugins (jpi, hpi) Linux kernel module and archives (ko & vmlinz) Nix (outputs in /nix/store) PHP (composer) Python (wheel, egg, poetry, requirements.txt) Red Hat (rpm) Ruby (gem) Rust (cargo.lock) Swift (cocoapods, swift-package-manager) Wordpress Plugins We don’t blindly run all catalogers against all kinds of input sources though – we tailor the catalogers used to create the most accurate SBOM possible based on what is being analyzed. For example, when scanning images, we enable the alpm-db-cataloger but don’t enable the cocoapods-cataloger: If there is a set of catalogers that you must / must not use for whatever reason, you can always tailor the set that runs with --override-default-catalogers and --select-catalogers to meet your needs. If you’re using Syft as an API, you can go further and implement your own package cataloger and provide it to Syft when creating an SBOM. When it comes to SBOM formats, we are unopinionated about which format might be best for your use case -- so we support as many as we can, including the most popular formats: SPDX and CycloneDX. This is a core decision point for us -- this way you can pivot between SBOM formats and not be locked into a format based on a tooling decision. You can even select which version of a format to output (even output multiple at once!): syft scan alpine:latest -o cyclonedx-json@1.2syft scan alpine:latest -o cyclonedx-json@1.2 syft scan alpine:latest -o cyclonedx-json@1.5syft scan alpine:latest -o cyclonedx-json@1.5 syft scan alpine:latest -o spdx-json@2.2syft scan alpine:latest -o spdx-json@2.2 syft scan alpine:latest -o spdx-json@2.3=./alpine.spdx.json -o cyclonedx-json=./alpine.cdx.jsonsyft scan alpine:latest -o spdx-json@2.3=./alpine.spdx.json -o cyclonedx-json=./alpine.cdx.json From the beginning, Syft was designed to lean into the Unix philosophies: do one thing and one thing well, allowing for it to plug into downstream tooling easily. For instance, to use your SBOM to get a vulnerability analysis, pipe the results to Grype:  Or to discover software licenses and check for compliance, pipe the results to Grant: What does v1 mean to us?  Version 1 primarily signals a stabilization of the CLI and API. Moving forward you can expect that breaking changes will always coincide with a major version bump of Syft. Some specific guarantees we wanted to call out explicitly are: We version our JSON schema of the syft JSON output separately than that of Syft, the application. In the past in a v0 state this has meant that breaking changes to the JSON schema would only result in a minor version bump of syft. Moving forward the JSON schema version used for the default JSON output of Syft will never include breaking changes. We’ve implicitly supported the ability to decode any previous version of the Syft JSON model, however, moving forward this will be an explicit guarantee -- If you have a Syft JSON document of any version, then you will be able to convert it into the latest Syft JSON version. Stereoscope, our library for parsing container images and crafting squashed filesystem representations (critical to the functionality of Syft), will now be versioned at each release and have release tags. What does this mean for the average user? In short: probably nothing! We will continue to ship enhancements and fixes every few weeks while remaining compatible with legacy SBOM document schemas. So are we done?... …Not even close 🤓. As the SBOM landscape keeps changing our goal is to grow Syft in terms of what can be cataloged, the accuracy of the results, the formats that can be expressed, and its usefulness in more use cases.  Have an ecosystem you need that we don’t support yet? Let us know, and let’s build it together! Found an issue or have a feature idea? Open an issue and let’s talk about it! Looking to contribute and are looking for a good place to start? We have some issues set aside just for you! Curious as to what we’re looking to work on next? Check out our ever-growing roadmap! And always, come join us every-other week at our community office hours chats if you want to meet with us and talk about topical issues regarding our OSS projects. ### FedRAMP and SSDF Compliance: How to Sell to the Federal Government ### Anchore Enterprise 5.1: Token-Based Authentication In Anchore 5.1, we have added the functionality of using token-based authentication through our API keys. Now with Anchore Enterprise 5.1, an administrator can create a token for a user so that they can use API keys rather than a username or credential. Let's dive into the details of what this means. Token-based authentication is a protocol that provides an extra layer of security when users want to access an API. It allows users to verify their identity, and in return receive a unique access token for the specific service. Tokens have a lifespan and as long as it is used within that duration, users can access the application with that same token without having to continuously log in. We list the step-by-step mechanism for a token-based authentication protocol: A user will send its credentials to the client.  The client sends the credentials to an authorization server where it will generate a unique token for that specific user’s credentials.  The authorization server sends the token to the client.  The client sends the token to the resource server The resource server sends data/resource to the client for the duration of the token’s lifespan. Token-Based Authentication in Anchore 5.1 Now that we've laid the groundwork, in the following sections we'll walk through how to create API keys and use them in AnchoreCTL. Creating API Keys In order to generate an API key, navigate to the Enterprise UI and click on the top right button and select ‘API Keys’: Clicking ‘API Keys’ will present a dialog that lists your active, expired and revoked keys: To create a new API key, click on the ‘Create New API Key’ on the top right. This will open another dialog where it asks you for relevant details for the API key: You can specify the following fields: Name: The name of your API key. This is mandatory and the name should be unique (you cannot have two API keys with the same name). Description: An optional text descriptor for your API key. Expiry Date: An expiry date for your API key, you cannot specify a date in the past and it cannot exceed 365 days by default. This is the lifespan you are configuring for your token. Click save and the UI will generate a Key Value and display the following output of the operation: NOTE: Make sure you copy the Key Value as there is no way to get this back once you close out of this window. Revoking API Keys If there is a situation where you feel your API key has been compromised, you can revoke an active key. This prevents the key from being used for authentication. To revoke a key, click on the ‘Revoke’ button next to a key: NOTE: Be careful revoking a key as this is an irreversible operation i.e. you cannot mark it active later. The UI by default only displays active API keys. If you want to see your revoked and expired keys, check the toggle to ‘Show only active API keys’ on the top right: Managing API Keys as an Admin As an account admin you can manage API keys for all users in the account you are administered in. A global admin can manage API keys across all accounts and all users. To access the API keys as an admin, click on the ‘System’ icon and navigate to ‘Accounts’: Click ‘Edit’ for the account you want to manage keys for and click on the ‘Tools’ button against the user you wish to manage keys for: Using API Keys in AnchoreCTL Generating API Keys as an SAML (SSO) User API keys for SAML (SSO) users are disabled by default. To enable API keys for SAML users, please update your helm chart values file with the following:     user_authentication:          allow_api_keys_for_saml_users: true NOTE: API keys are an additional authentication mechanism for SAML users that bypasses the authentication control of the IDP. When access has been revoked at the IDP, it does not automatically disable the user or revoke all API keys for the user. Therefore, when access has been revoked for a user, the system admin is responsible to manually delete the Anchore User or revoke any API key which was created for that user. Using API Keys API keys are authenticated using basic auth. In order to use API keys, you need to use a special username _api_key and the password is the Key Value that was the output when you created the API key. curl -u '_api_key:' http://localhost:8228/v2/images   url: "http://localhost:8228"   username: "_api_key"   password: Caveats for API Keys API Keys generally inherit the permissions and roles of the user they were generated for, but there are certain operations you cannot perform using API keys regardless of which user they were generated for: You cannot Add/Edit/Remove Accounts, Users and Credentials. You cannot Add/Edit/Remove Roles and Role Members. You cannot Add/Edit/Revoke API Keys. We invite you to learn more about Anchore Enterprise 5.0 with a free 15 day trial. Or, if you’ve got other questions, set up a call with one of our specialists. Learn more from Anchore: User Management in Anchore Enterprise  User Authentication with API Keys AnchoreCTL Configurations  ### Introducing Grant: A new OSS project from Anchore for inspecting and checking license compliance from SBOMs Today Anchore has released Grant, a tool to help users discover and reason about software licenses. Grant represents our latest efforts to build OSS tools oriented around the fundamental idea of creating SBOMs as part of your development process, so that they can be used for multiple purposes. We maintain Syft for generating SBOMs, and Grype for taking an SBOM and performing a vulnerability scan. Now with Grant, that same SBOM can also be used for performing license checks. Knowing what licenses you have is critical to ensure the delivery of your software. It’s important to account for all of the licenses that you are beholden to in your transitive dependencies before introducing new dependencies (and well before shipping to production!). For example, you might want to know the package under which a GPL (General Public License) is discovered within the dependencies of a certain software before releasing, or what license a new software library might require. This evaluation tends to not be a one-time decision: you need to continually ensure that the dependencies you are using are not swapping to different licenses after you initially brought that dependency into your codebase. Grant aims to aid in solving the above issues through the use of its check and list commands. Grant - Design and Launch Features Grant takes either a Software Bills of Material (SBOM), a filesystem with a collection of license files, or a container image as input. Grant can either generate an SBOM for the different provided inputs or read an SBOM provided as input. Grant has two primary commands: list: show me discovered licenses check: evaluate a list of licenses to ensure your artifacts are compliant to a given policy List  The list command can display licenses discovered from the SBOM and their related packages. It can also filter licenses to show which licenses are not OSI approved, which licenses are not associated with a package, and which packages were found with no associated license. Users can use the list to show the discovered licenses for a given container image. Here is an example using grant to display all the licenses found for the latest redis image: You can also get more detailed information about the licenses from the json output by using the -o json flag. This flag provides a json formatted output which shows the locations of the discovered license, if it has an SPDX expression, and the packages and locations of those packages for which it was discovered Check The check command can evaluate given inputs for license compliance relative to the provided license rules. One thing users can look out for when trying to understand their license posture is if a license that was previously permissive has changed. Check allows the user to express simple policies that will pass/fail the command depending on what Grant discovers: rules: - pattern: "*gpl*" name: "deny-gply" mode: "deny" reason: "GPL licenses are not allowed" Here is grant running check with the above configuration against the same redis image as the list example Users can also use a -o json option to return a more detailed and machine readable view. This output allows users to see more detailed license information if a license is matched to an official SPDX ID. This includes text of the license, references to its clauses, and sections or rules showing if a license was not found for a package. Grant can be configured to accept multiple sources, including those from container images, directories, licenses, and software bills of materials. Grant stitches these sources into a report that can then display the license contents of each source. This report of licenses can be optionally paired with a policy file that gates/limits an execution (pass/fail) on the presence or lack of a predetermined set of licenses. Policy files have the ability to include exceptions for packages that are not used or that organizations deem are not applicable to their compliance policy. Grant’s approach to license identification Grant takes a simplified approach to asserting on and establishing a license’s presence. It first tries to match all discoveries when possible to the SPDX license list. For sources with more complex expressions, grant will try to break those expressions into the individual license IDs. This should allow the user to make decisions about which licenses are relevant to the project they are working on. An example of this is something like the SPDX expression `LGPL-2.1-only OR MIT OR BSD-3-Clause`discovered for the package `foobar`. If this expression was discovered then the 3 different licenses would be associated with the package. If users need an exception they can then construct a policy that allows them to exclude non permissive licenses from the statement: pattern: "LGPL-2.1" name: "deny-LGPL-2.1" mode: "deny" reason: "LGPL-2.1 licenses are not allowed by new corporate policy" exclusions: - "foobar" One notable inclusion in the code is grants use of the license classifier from google to recognize licenses that are input to the tool and assign them a confidence level. Further enhancements are planned to allow for SBOMs that provide the original license text to also be run against the classifier. SPDX license compatibility The landscape of open source licenses is vast and complex with various licenses having different terms and conditions. It can be challenging to understand and manage the obligations associated with each license. While grant makes no claim on establishing if licenses are compatible with each other, it can establish if a discovered license has an ID found in the latest SPDX license list. Users can use the grant list command with the --non-spdx flag to get an idea of which licenses were unable to be matched to a corresponding SPDX ID. This should allow users to find gaps where Grant might not be making the right choice for SPDX ID association, while also pointing out interesting one off licenses and their locations that might be private or custom to a certain vendor: Conclusion Grant is another open source tool from Anchore that can help improve your software processes. Simply by generating SBOMs for your software and making them available, you can now easily gate incoming code changes and steps of your delivery pipeline that are sensitive to licensing concerns. Go download Grant here and try it for yourself! ### NIST 800-53: The Important Things to Know ### Anchore's VIPERR Framework ### Introducing VIPERR: The First Software Supply Chain Security Framework for All Today Anchore announces the VIPERR software supply chain security framework. This framework distills our lessons learned from supporting the most challenging software supply chain environments across government agencies and the defense industrial base. The framework is a blueprint for organizations to implement that reliably creates secure software supply chains with the least possible lift. Previously security teams had to wade through massive amounts of literature on software supply chain security and spend countless hours of their teams time digesting those learnings into concrete processes and controls that integrated with their specific software development process. This typically absorbed massive amounts of time and resources and it wasn't always clear at the end that an organization's security had improved significantly. Now organizations can utilize the VIPERR framework as a trusted industry resource to confidently improve their security posture and reduce the possibility of a breach due to a supply chain incident without the lengthy research cycle that frequently comes before the implementation phase of a software supply chain solution. If you're interested to see how Anchore works with customers to apply the framework via the Anchore Enterprise platform take the free guided walkthrough of the VIPERR framework. Alternatively, you can view our on demand webinar for a thorough walk through the framework. Finally, if you would like a more hands-on experience to try out the VIPERR framework then you can try our Anchore Enterprise Free Trial.   Frequently Asked Questions What is the VIPERR framework? VIPERR is a free software supply chain security framework that Anchore created for organizations to evaluate and improve the security posture of their software supply chain. VIPERR stands for visibility, inspection, policy enforcement, remediation, and reporting.  While working alongside developers and security teams within some of the most challenging architectures and threat landscapes, Anchore field engineers developed the VIPERR framework to both contextualize lessons learned and prevent live threats. VIPERR is meant to be a practical self-assessment playbook that organizations can regularly reuse to evaluate and harden their software supply chain security posture. By following this guide, numerous Fortune 500 enterprises and top federal agencies have transformed their software supply chain security posture and become hard targets for advanced persistent threats. Why did Anchore create the VIPERR framework? There are already a number of frameworks that have been developed to help organizations improve their software supply chain security but most of them focus on giving general guidance that is flexible enough that most specific implementations of the guidance will yield compliance. This is great for general standards because it allows organizations to find the best fit for their environment, but by keeping guidance general, it is difficult to always know the best specific implementation that delivers real-world results. The VIPERR framework was designed to fill this gap. VIPERR is a framework that can be used to fulfill compliance standards for software supply chain security that is opinionated on how to achieve the controls of most of the popular standards. It can be paired with Anchore's turnkey offering Anchore Enterprise so that organizations can opt for a solution that accomplishes the entire VIPERR framework without having to build a system from scratch. Access an interactive 50 point checklist or a pdf version to guide you through each step of the VIPERR framework, or share it with your team to introduce the model for learning and awareness. How do I begin identifying the gaps in my software supply chain security program?  "I have no budget. My boss doesn’t think it’s a priority. I lack resources." These are all common refrains when we speak with security teams working with us via our open source community or commercial enterprise offering. There is a ton of guidance available between SSDF, SLSA, NIST, and S2C2F. A lot of this is contextualized in a manner difficult to digest. As mentioned in the previous question VIPERR was created to be highly actionable by finding the right balance between giving guidance that is flexible and providing opinions that reduce options to help organizations make decisions faster. The VIPERR framework will be available in a formatted 50 point, self-assessment checklist in the coming weeks, check back here for updates on that. By completing the forthcoming checklist you will produce a prioritized list of action items to harden your organization's software supply chain security with the least amount of effort.  How do I build a solution that closes the gaps that VIPERR uncovers? As stated, VIPERR is a framework, not a solution. Anchore has worked with companies that have implemented VIPERR by building an in-house solution with a collection of open source tools (e.g. Syft, Grype, and other open source tools) or using a combination of multiple security tools. If you want to get an idea of the components involved in building a solution by self-hosting open-source tools and tying all of these systems together with first-party code, we wrote about that approach here.  If I don't want to build a solution, are there any turnkey solutions available? Yes. Anchore Enterprise was designed as a turnkey solution to implement the VIPERR framework. Anchore Enterprise also automates the 50 security controls of the framework by integrating directly into an organization's SDLC toolset (i.e., developer environments, CI/CD build pipelines, artifact registry and production environments). This provides the ability for organizations to know at any point in time if their software supply chain has been compromised and how to remediate the exploit. If you’d like to learn more about the Anchore Enterprise platform or speak with a member of our team, feel free to book a time to speak with one of our specialists. ### How Speed and Agility Are Transforming Platform One ### NIST CSF 2.0: Key Takeaways and Implementation Strategies This blog post has been archived and replaced by the supporting pillar page that can be found here: https://anchore.com/wp-admin/post.php?post=987473315&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. ### Anchore Enterprise 5.0: New, Free Self-Service Trial This week we’re proud to announce the immediate availability of the Anchore Enterprise 5.0 free trial.  If you’ve been curious about how the platform works, or wondering how it can complement your application security measures, now you can have access to a 15 day free trial.  To get started, just click here, fill out a short form, and you will immediately receive instructions via email on how to spin up your free 15 day trial in your own AWS account.  Please note that only AWS is supported at this time, so if you’d like to launch a trial on-prem or with another cloud provider, please reach out to us directly. With just a few clicks, you’ll be up and running with the latest release of Anchore Enterprise which includes a new API, improvements to our reporting interface, and so much more.  In fact, we have pre-populated the trial with data that will allow you to explore the many features Anchore Enterprise has to offer. Take a look at the below screenshots for a glimpse behind the scenes. Malware Scanning Secret Key Search Kubernetes Runtime Integration Vulnerability Reports We invite you to learn more about Anchore Enterprise 5.0 with a free 15 day trial here. Or, if you’ve got other questions, set up a call with one of our specialists here. ### Scanner Safari: Surveying Vulnerability Scanners in the Wild ### Unpacking the Power of Policy at Scale in Anchore Generating a software bill of materials (SBOM) is starting to become common practice. Is your organization using them to their full potential? Here are a couple questions Anchore can help you answer with SBOMs and the power of our policy engine: How far off are we from meeting the security requirements that Iron Bank, NIST, CIS, and DISA put out around container images? How can I standardize the way our developers build container images to improve security without disrupting the development team's output? How can I best prioritize this endless list of security issues for my container images? I’m new to containers. Where do I start on securing them? If any of those questions still need answering at your organization and you have five minutes, you’re in the right place. Let’s dive in. If you’re reading this you probably already know that Anchore creates developer tools to generate SBOMs, and has been since 2016. Beyond just SBOM generation, Anchore truly shines when it comes to its policy capabilities. Every company operates differently — some need to meet strict compliance standards while others are focused on refining their software development practices for enhanced security. No matter where you’re at in your container security journey today, Anchore’s policy framework can help improve your security practices. Anchore Enterprise has a tailored approach to policy and enforcement that means whether you're a healthcare provider abiding by stringent regulations or a startup eager to fortify its digital defenses, Anchore has got you covered. Our granular controls allow teams to craft policies that align perfectly with their security goals. Exporting Policy Reports with Ease Anchore also has a nifty command line tool called anchorectl that allows you to grab SBOMs and policy results related to those SBOMs. There are a lot of cool things you can do with a little bit of scripting and all the data that Anchore Enterprise stores. We are going to cover one example in this blog. Once Anchore has created and stored an SBOM for a container image, you can quickly get policy results related to that image. The anchorectl command that will evaluate an image against the docker-cis-benchmark policy bundle: anchorectl image details -p docker-cis-benchmark That command will return the policy result in a few seconds. Let’s say your organization develops 100 images and you want to meet the CIS benchmark standard. You wouldn’t want to assess each of these images individually, that sounds exhausting.  To solve this problem, we have created a script that can iterate over any number of images, merge the results into a single policy report, and export that into a csv file. This allows you to make strategic decisions about how you can most effectively move towards compliance with the CIS benchmark (or any standard). In this example, we ran the script against 30 images in my Anchore deployment. Now take a look holistically at how far off we are from CIS compliance. Here are a few metrics that standout: 26 of the 30 images are running as ‘root’ 46.9% of our total vulnerabilities have fixes available (4978 /10611) ADD instructions are being used in 70% of our images Health checks missing in 80% of our images 14 secrets (all from the same application team) 1 malware hit (Cryptominer Casey is at it again) As a security team member, we didn’t write any of this code myself, which means I need to work with my developer colleagues on the product/application teams to clear up these security issues. Usually this means an email that educates my colleagues on how to utilize health checks, prefer COPY instead over ADD in Dockerfiles, declaring a non-privileged user instead of root, and methods to upgrade packages with fixes available (e.g., Dependabot). Finally, we would prioritize investigating how that malware made its way into that image for myself. This example illustrates how storing SBOMs and applying policy rules against them at scale can streamline your path to your container security goals. Visualizing Your Aggregated Policy Reports While this raw data is useful in and of itself, there are times when you may want to visualize the data in a way that is easier to understand.  While Anchore Enterprise does provide some dashboarding capabilities, it is not and does not aim to be a versatile dashboarding tool. This is where utilizing an observability vendor comes in handy. In this example, I’ll be using New Relic as they provide a free tier that you can sign up for and begin using immediately. However, other providers such as Datadog and Grafana would also work quite well for this use case.  Importing your Data Download the tsv-to-json.py script Save the data produced by the policy-report.py script as a TSV file We use TABs as a separator because commas are used in many of the items contained in the report. Run the tsv-to-json.py script against the TSV file: python3 tsv-to-json.py aggregated_output.tsv > test.json Sign-up for a New Relic account here Find your New Relic Account ID and License Key Your New Relic Account ID can be seen in your browser’s address bar upon logging in to New Relic, and your New Relic License Key can be found on the right hand side of the screen upon initial login to your New Relic account. Use curl to push the data to New Relic: gzip -c test.json | curl \ -X POST \ -H "Content-Type: application/json" \ -H "Api-Key: " \ -H "Content-Encoding: gzip" \ https://insights-collector.newrelic.com/v1/accounts//events \ --data-binary @- Visualizing Your Data New Relic uses the New Relic Query Language (NRQL) to perform queries and render charts based on the resulting data set.  The tsv-to-json.py script you ran earlier converted your TSV file into a JSON file compatible with New Relic’s event data type.  You can think of each collection of events as a table in a SQL database.  The tsv-to-json.py script will automatically create an event type for you, combining the string "Anchore" with a timestamp. To create a dashboard in New Relic containing charts, you’ll need to write some NRQL queries.  Here is a quick example: FROM Anchore1698686488 SELECT count(*) FACET severity This query will count the total number of entries in the event type named Anchore1698686488 and group them by the associated vulnerability’s severity. You can experiment with creating your own, or start by importing a template we have created for you here. Wrap-Up The security data that your tools create is only as good as the insights that you are able to derive from them. In this blog post, we covered a way to help security practitioners turn a mountain of security data into actionable and prioritized security insights. That can help your organization to improve its security posture and meet compliance standards quicker. That being said this blog is dependent on you already being a customer of Anchore Enterprise. 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: Intro to DoD Software Factory Outline for Getting Up to Speed on the DoD Software Factory How Anchore Secures Software Factories ### Introducing Anchore Enterprise 5.0 Today, we are pleased to announce the release of Anchore Enterprise 5.0 which is now Generally Available for download. This is a major release representing a step change from the Anchore Enterprise 4.x code base, which contains several new features and improvements to the foundational API.  It’s been over a year and a half since Anchore Enterprise 4.0 was released and it’s been a tumultuous time in software security. The rate of critical flaws being discovered in open source software has been ever increasing and the regulatory response driven by the U.S. government’s Executive Order is now being felt in the market. We’ve always been proud of our customer base and have worked hard to ensure that we are delivering real value to them in response to these dynamics. The improvements to security posture usually come less from novel techniques than just making the existing hard tasks easier. We’d like to thank all our customers who contributed their feedback and insights into making 5.0 the foundation for their security workflows. Anchore Enterprise 5.0 continues our mission of delivering new features on a fast and regular cadence to our customers while also giving us the opportunity to redesign some of the core parts of the product to make the day to day life of operators and users easier. 5.0 will now be the foundation for a series of major new features we are planning over the next 12 months.  Simplified Reporting  We have introduced a new design to the reporting section of the graphical user interface. The underlying functionality is the same as with 4.x but the UI now features a more intuitive layout to create and manage your reports. New reports start with a clean layout where new filters can be added and then saved as a template. Scheduled and unscheduled reports are summarized in a single clean overview. Single, unified API and Helm Chart for simpler operations Previously Anchore exposed its capabilities through multiple API endpoints making it hard to create integration workflows. 5.0 now unifies them under the new v2 API and makes them available under a single endpoint. This new API makes it easier to create scripts and code without coding to different endpoints.  In addition, we've created a new streamlined Helm chart for deploying Anchore in Kubernetes environments to ensure that all configuration options are easily accessed in a single location. Easier Vulnerability Matching Logic Reducing false positives is an ever-present goal for every security team. Based on Syft and Grype, our flagship open source projects, we are continually evaluating the best logic and vulnerability feeds for the highest quality results. With 5.0, we’ve made it easier for users to control which vulnerability feeds should be used for which language ecosystems. New sources such as Github’s Advisory Database often provide a higher quality experience for Java which continues to be ubiquitous in the enterprise.  We invite you to learn more about Anchore Enterprise 5.0 in a demo call with one of our specialists or sign up for a free 15 day trial here. ### SBOMs & Vulnerability Scanners: Better Together In the world of software development, two mega-trends have emerged in the past decade that have reshaped the industry. First the practice of building applications with a foundation of open-source software components and, second, the adoption of DevOps principles to automate the build and delivery of software. While these innovations have accelerated the pace of software getting into the hands of users, they've also introduced new challenges, particularly in the realm of security.  As software teams race to deliver applications at breakneck speeds, security often finds itself playing catch-up, leading to potential vulnerabilities and risks. But what if there was a way to harmonize rapid software delivery with robust security measures?  In this post, we'll explore the tension between engineering and security, the transformative role of Software Bill of Materials (SBOMs), and how modern approaches to software composition analysis (SCA) are paving the way for a secure, efficient, and integrated software development lifecycle. Two Mega-Trends and the History of the Tension Between Engineering and Security The rise of open-source software ushered in an era where developers had innumerable off-the-shelf components to construct their applications from. These building blocks eliminated the need to reinvent the wheel, allowing developers to focus on innovating on top of the already existing foundation that had been built by others. By leveraging pre-existing, community-tested components, software teams could drastically reduce development time, ensuring faster product releases and more efficient engineering cycles. However, this boon also brought about a significant challenge: blindspots. Developers often found themselves unaware of all the ingredients that made up their software. Enter the second mega-trend DevOps tools, with special emphasis on CI/CD build pipelines. These tools promised (and delivered) faster, more reliable software testing, building, and delivery. Which ultimately meant not only was the creation of software accelerated via open-source components but the build process of manufacturing the software into a state that a user could consume was also sped up. But, as Uncle Ben reminds us, “with great power comes great responsibility”. The accelerated delivery meant that any security issues, especially those lurking in the blindspots, found their way into production at the new accelerated pace that was enabled through open-source software components and DevOps tooling. The Strain on Legacy Security Tools in the Age of Rapid Development This double-shot of productivity boosts to engineering teams began to strain their security oriented counterparts. The legacy security tools that security teams had been relying on were designed for a different era. They were created when software development lifecycles were measured in quarters or years rather than weeks or months. Because of this they could afford to be leisurely with their process.  The tools that were originally developed to ensure that an application’s supply chain was secure were called software composition analysis (SCA) platforms. They were originally developed as a method for scanning open source software for licensing information to prevent corporations from running into legal issues as their developers used open-source components. They scanned every software artifact in its entirety—a painstakingly slow process. Especially if you wanted to run a scan during every step of software integration and delivery (e.g. source, build, stage, delivery, production).  As the wave of open-source software and DevOps principles took hold, a tug-of-war between security teams, who wanted thoroughness, and software teams, who were racing against time began to form. Organizations found themselves at a crossroads, choosing between slowing down software delivery to manage security risks or pushing ahead and addressing security issues reactively. SBOMs to the Rescue! But what if there was a way to bridge this gap? Enter the Software Bill of Materials (SBOM). An SBOM is essentially a comprehensive list of components, libraries, and modules that make up a software application. Think of it as an ingredient list for your software, detailing every component and its origin. In the past, security teams had to scan each software artifact during the build process for vulnerabilities, a method that was not only time-consuming but also less efficient. With the sheer volume and complexity of modern software, this approach was akin to searching for a needle in a haystack. SBOMs, on the other hand, provide a clear and organized view of all software components. This clarity allows security teams to swiftly scan their software component inventory, pinpointing potential vulnerabilities with precision. The result? A revolution in the vulnerability scanning process. Faster scans meant more frequent checks. And with the ability to re-scan their entire catalog of applications whenever a new vulnerability is discovered, organizations are always a step ahead, ensuring they're not just reactive but proactive in their security approach. In essence, organizations could now enjoy the best of both worlds: rapid software delivery without compromising on security. With SBOMs, the balance between speed and security isn't just achievable; it's the new standard. How do I Implement an SBOM-powered Vulnerability Scanning Program? Okay, we have the context (i.e. the history of how the problem came about), we have a solution, the next question then becomes how do you bring this all together to integrate this vision of the future with the reality of your software development lifecycle? Below we outlined the high-level steps of how an organization might begin to adopt this solution into their software integration and delivery processes: Research and select the best SBOM generation and vulnerability scanning tools. (Hint: We have some favorites!) Educate your developers about SBOMs. Need guidance? Check out our detailed post on getting started with SBOMs. Store the generated SBOMs in a centralized repository. Create a system to pull vulnerability feeds from reputable sources. If you’re looking for a way to get started here, read our post on how to get started. Regularly scan your catalog of SBOMs for vulnerabilities, storing the results alongside the SBOMs. Integrate your SBOM generation and vulnerability scanning tooling into your CI/CD build pipeline to automate this process. Implement a query system to extract insights from your catalog of SBOMs. Create a tool to visualize your software supply chain’s security health. Create a system to alert on for newly discovered vulnerabilities in your application ecosystem. Integrate a policy enforcement system into your developers' workflows, CI/CD pipelines, and container orchestrators to automatically prevent vulnerabilities from leaking into build or production environments. Maintain the entire system and continue to improve on it as new vulnerabilities are discovered, new technologies emerge and development processes evolve. Alternatively, consider investing in a comprehensive platform that offers all these features, either as a SaaS or on-premise solution instead of building this entire system yourself. If you need some guidance trying to determine whether it makes more sense to build or buy, we have put together a post outlining the key signs to watch for when considering when to outsource this function. How Anchore can Help you Achieve your Vulnerability Scanning Dreams The previous section is a bit tongue-in-cheek but it is also a realistic portrait of how to build a scalable vulnerability scanning program in the Cloud Native-era. Open-source software and container pipelines have changed the face of the software industry for the better but as with any complex system there are always unintended side effects. Being able to deliver software more reliably at a faster cadence was an amazing step forward but doing it securely got left behind.  Anchore Enterprise was built specifically to address this challenge. It is the manifestation of the list of steps outlined in the previous section on how to build an SBOM-powered software composition analysis (SCA) platform. Integrating into your existing DevOps tools, Anchore Enterprise is a turnkey solution for the management of software supply chain security. If you’d rather buy than build and save yourself the blood, sweat and tears that goes into designing an end-to-end SCA platform, we’re looking forward to talking to you.If you’d like to learn more about the Anchore Enterprise platform or speak with a member of our team, feel free to book a time to speak with one of our specialists. ### Guide to SBOMs: What They are and Their Role in Cybersecurity In the dynamic landscape of software development, the past decade has witnessed two transformative shifts that have redefined the industry's trajectory. The first is the widespread adoption of open-source software components, providing developers with a vast repository of pre-built modules to streamline their work. The second is the embrace of DevOps principles, automating and accelerating the software build and delivery process. Together, these shifts promised unprecedented efficiency and speed. However, they also introduced a labyrinth of complexity, with software compositions becoming increasingly intricate and opaque.  This complexity, coupled with the relentless pace of modern development cycles, created a pressing need for a solution that could offer clarity amidst the chaos. This is the backdrop against which the Software Bill of Materials (SBOM) emerged. This guide delves into the who, what, why and how of SBOMs. Whether you're a developer, a security professional, or simply someone keen on understanding the backbone of modern software security, this guide offers insights that will equip you with the knowledge to navigate all of the gory details of SBOMs. What is a Software Bill of Materials (SBOM)?  A software bill of materials (SBOM) is a structured list of software components, modules, and libraries that are included in an application. Similar to the nutrition labels on the back of the foods that you buy, SBOMs are a list of ingredients that the software is composed of. We normally think of SBOMs as an artifact of the software development process. As a developer is building an application using different open-source components they are also creating a list of ingredients, an SBOM is the digital artifact of this list. To fully extend the metaphor, creating a modern software application is analogous to crafting a gourmet dish. When you savor a dish at a restaurant, what you experience is the final, delicious result. Behind that dish, however, is a complex blend of ingredients sourced from various producers, each contributing to the dish's unique flavor profile. Just as a dish might have tomatoes from Italy, spices from India, olive oil from Spain, and fresh herbs from a local garden, a software application is concocted from individual software components (i.e., software dependencies). These components, like ingredients in a dish, are meticulously combined to create the final product. Similarly, while you interact with a seamless software interface, behind the scenes, it's an intricate assembly of diverse open source software components working in harmony. Why are SBOMs important? SBOMs are one of the most powerful security tools that you can use. Large-scale software supply chain attacks that affected SolarWinds, Codecov, and Log4j highlight the need for organizations to understand the software components—and the associated risk—of the software they create or use. SBOMs are critical not only for identifying security vulnerabilities and risks in software. They are also key for understanding how that software changes over time, potentially introducing new risks or threats.  Knowing what’s in software is the first step to securing it. Increasingly organizations are developing and using cloud-native software that runs in containers. Consider the complexity of these containerized applications that have hundreds—sometimes thousands—of components from commercial vendors, partners, custom-built software, and open source software (OSS). Each of these pieces is a potential source of risk and vulnerabilities. Generating SBOMs enables you to create a trackable inventory of these components. Yet, despite the importance of SBOMs for container security practices, only 36% of the respondents to the Anchore 2022 Software Supply Chain Report produce an SBOM for the containerized apps they build, and only 27% require an SBOM from their software suppliers. SBOMs Use-Cases An organization can use SBOMs for many purposes. The data inside an SBOM has internal uses such as: Compliance review Security assessments License compliance Quality assurance Additionally, you can share an SBOM externally for compliance and customer audits. Within the security and development role, SBOMs serve a similar purpose as a bill of materials in other industries. For example, automotive manufacturers must track the tens of thousands of parts coming from a wide range of suppliers when manufacturing a modern car. All it takes is one faulty part to ruin the final product. Cloud-native software faces similar challenges. Modern applications use significant amounts of open source software that depends on other open source software components which in turn incorporate further open source components. They also include internally developed code, commercial software, and custom software developed by partners.  Combining components and code from such a wide range of sources introduces additional risks and potential for vulnerabilities at each step in the software development lifecycle. As a result, SBOMs become a critical foundation for getting a full picture of the “ingredients” in any software application over the course of the development lifecycle. Collecting SBOMs from software suppliers and generating SBOMs throughout the process to track component inventory changes and identify security issues is an integral first step to ensuring the overall security of your applications. Security and development teams can either request SBOMs from their software suppliers or generate an SBOM themselves. Having the ability to generate SBOMs internally is currently the more optimal approach. This way teams can produce multiple SBOMs throughout the development process to track component changes and search for vulnerabilities as new issues become known in software. SBOMs can help to alleviate the challenges faced by both developers and security teams by: Understanding risk exposure inherent in open source and third-party tools Reduce development time and cost through exposing and remediating issues earlier in the cycle Identifying license and compliance requirements Ultimately, SBOMs are a source of truth. To ensure product integrity, development and security teams must quickly and accurately establish: Specific versions of the software in use Location of the software in their builds and existing products SBOM Security Benefits There are many SBOM security benefits for your organization. Any effective solution to securing your software supply chain is transparency. Let’s dive into what SBOM security means with regards to these ingredients and why transparency is so vital.  Transparency = Discovering What is in There It all starts with knowing what software is being used. You need an accurate list of “ingredients” (such as libraries, packages, and files) that are included in a piece of software. This list of “ingredients” is known as a software bill of materials. Once you have an SBOM for any piece of software you create or use, you can begin to answer critical questions about the security of our software supply chain. It’s important to note that SBOMs themselves can also serve as input to other types of analyses. A noteworthy example of this is vulnerability scanning. Typically, vulnerability scanning is a term for discovering known security problems with a piece of software based on previously published vulnerability reports. Detecting and mitigating vulnerabilities goes a long way toward preventing security incidents. In the case of software deployed in containers, developers can use SBOMs and vulnerability scans together to provide better transparency into container images. When performing these two types of analyses within a CI/CD pipeline, you need to realize two things: Each time you create a new container image (i.e. an image with a unique digest), you only need to generate an SBOM once. And that SBOM can be forever associated with that unique image.  Even though that unique image never changes, it’s vital to continually scan for vulnerabilities. Many people scan for vulnerabilities once an image is built, and then move on. But new vulnerabilities are discovered and published every day (literally) — so it’s vital to periodically scan any existing images you’re already consuming or distributing to identify if they are impacted by new vulnerabilities. Using an SBOM means you can quickly and confidently scan an application for new vulnerabilities. Why SBOMs Matter for Software Supply Chain Security Today’s software is complex, that is why SBOMs have become the foundation of  software supply chain security. The role of an SBOM is to provide transparency about the software components of an application, providing a foundation for vulnerability analysis and other security assessments.  For example, organizations that have a comprehensive SBOM for every software application they buy or build can instantly identify the impact of new zero-day vulnerabilities, such as the Log4Shell vulnerability in Log4j, and discern its exact location for faster remediation. Similarly, they can evaluate the provenance and operational risk of open source components to comply with internal policies or industry standards. These are critical capabilities when it comes to maintaining and actively managing a secure software supply chain.  The importance of the SBOM was highlighted in the 2021 U.S. Executive Order to Improve the Nation’s Cybersecurity. The Executive Order directs federal agencies to “publish minimum SBOM standard” and define criteria regarding “providing a purchaser a software bill of materials (SBOM) directly or publish to a public website.” This Executive Order is having a ripple effect across the industry, as software suppliers that sell to the U.S. federal government will increasingly need to provide SBOMs for the software they deliver. Over time these standards will spread as companies in other industries begin to mirror the federal requirements in their own software procurement efforts. If you’re looking for a deep dive into the world of software supply chain security, we have written a comprehensive guide to the subject. What is an SBOM made of? What’s inside?  Each modern software application typically includes a large number of open source and commercial components coming from a wide range of sources. An SBOM is a structured list of components, modules, and libraries that are included in a given piece of software that provides the developer with visibility into that application. Think of an SBOM like a list of ingredients that evolves throughout the software development lifecycle as you add new code or components. An example of items included in a SBOM are: A data format that catalogs all the software in an application, including deeply nested dependencies Data tracked includes details such as dependency name, version, and language ecosystem SBOM data files can catalog files not associated with the operating system or included dependency Anchore Enterprise supports SPDX, CycloneDX, and Syft formats. This is a continually evolving space with new formats introduced periodically. To learn about the latest on SBOM formats see the Anchore blog here.  Who needs SBOMs?  When it comes to who needs SBOMs, they are mainly used by DevSecOps practitioners and compliance teams for audits, license monitoring, and to comply with industry-specific regulations. However, with the rise of software supply chain attacks (like the SolarWinds hack and the recent Log4Shell vulnerability in Log4j) SBOM use is now on the radar for both security and development teams alike. Security Teams SBOMs play a critical role for security teams, especially when it comes to vulnerability scanning. It is much quicker and easier to scan a library of SBOMs than it is to scan all of your software applications, and in the event of a zero-day vulnerability, every minute counts.  SBOMs can also be leveraged by security teams to prioritize issues for remediation based on their presence and location and to create policies specific to software component attributes such as vendor, version, or package type. Development Teams Development teams use SBOMs to track the open source, commercial, and custom-built software components that they use across the applications they develop, manage, and operate. This assists development teams by reducing time spent on rework by helping to manage dependencies, identify security issues for remediation early, and ensure that developers are using approved code and sources. Fueling the cross-functional use of SBOMs, is the Executive Order on Improving the Nation’s Cybersecurity, where President Biden issued an SBOM requirement that plays a prominent role in securing software supply chains.  The Current State of SBOMs The current state of SBOMs is complex and evolving. The risks of software supply chain attacks are real, with almost two-thirds of enterprises impacted by a software supply chain attack in the last year according to the Anchore 2022 Software Supply Chain Report.  To stem these rising threats, the Executive Order outlines new requirements for SBOMs along with other security measures for software used by federal agencies. Until now, the use of SBOMs by cybersecurity teams has been limited to the largest, most advanced organizations. However, as a consequence of these two forces, the use of SBOMs is on the cusp of a rapid transformation. With governments and large enterprises leading the way, standardized SBOMs are poised to become a baseline requirement for all software as it moves through the supply chain. As a result, organizations that produce or consume software need the ability to generate, consume, manage, and leverage SBOMs as a foundational element of their cybersecurity efforts. In recent years we have seen threat actors shift their focus to third-party software suppliers. Rather than attacking their targets directly, they aim to compromise software at the build level, introducing malicious code that can later be executed once that software has been deployed, giving the attacker access to new corporate networks. Now, instead of taking down one target, supply chain attacks can potentially create a ripple effect that could affect hundreds, even thousands, of unsuspecting targets.  Open source software can also be an attack vector if it contains un-remediated vulnerabilities. SBOMs are a critical foundation for securing against software supply chain attacks. By generating SBOMs into the development cycle, developers and security teams can identify and manage the software in their supply chains and catch these bad actors early before they reach runtime and wreak havoc. Additionally, SBOMs allow organizations to create a data trail that can provide an extended view of the supply chain history of a particular product. Additional SBOM Resources Learn more about what goes into an SBOM with Anchore's guide to SBOM format, standards, examples, and more Generate SBOMs for free with open source tools Read about SBOM federal requirements ### Say Goodbye to False Positives You might be in for a bit of a surprise when running the latest version of Grype – potential vulnerabilities you may have become accustomed to seeing are no longer there! Keep calm. This is a good thing – we made your life easier! Today, we released an improvement to Grype that is the culmination of months of work and testing, which will dramatically improve the results you see, in fact some ecosystems can see up to an 80% reduction of false positives! If you’re reading this, you may have used Grype in the past and seen things you weren’t expecting, or you may just be curious to see how we’ve achieved an improvement like this. Let’s dig in. The surprising source of false positives The process of scanning for vulnerabilities involves several different factors, but, without a doubt, one of the most important is for Grype to have accurate data: both when identifying software artifacts and also when applying vulnerability data against those artifacts. To address the latter, Anchore provides a database (GrypeDB), which aggregates multiple data sources that Grype uses to assess whether components are vulnerable or not. This data includes the GitHub Advisory Database and the National Vulnerability Database (NVD), along with several other more specific data sources like those provided by Debian, Red Hat, Alpine, and more. Once Grype has a set of artifacts identified, vulnerability matching can take place. This matching works well, but inevitably may result in certain vulnerabilities being incorrectly excluded (false negatives) or incorrectly included (false positives). False results are not great, either way, and the false positives certainly constitute a number of issues reported against Grype over the years. One of the biggest problems we’ve encountered is the fact that the data sources used to build the Grype database use different identifiers – for example, GitHub Advisory Database uses data that includes a package’s ecosystem, name, and version; while NVD uses the Common Platform Enumeration (CPE). These identifiers have some trade-offs, but the most important of which is how accurate it is for a package to be matched against the vulnerability record. In particular, the GitHub Advisory Database data is partitioned by ecosystems such as npm or Python whereas the NVD data does not generally have this distinction. The result of this is a situation where a Python package named “foo” might match vulnerabilities against another “foo” in another ecosystem. When taking a closer look at reports by the community, it is apparent that the most common reason for reported false positives is due to CPEs matching. Learn how to automate container vulnerability scanning in Harbor registry with Anchore Enterprise. A webinar with the experts from Anchore. Watch Now Focusing on the negative After experimenting with a number of options for improving vulnerability matching, ultimately one of the simplest solutions proved most effective: stop matching with CPEs. The first question you might ask is: won’t this result in a lot of false negatives? And, secondly, if we’re not matching against CPEs, what are we matching against? Grype has already been using GitHub Advisory Database data for vulnerability matching, so we simply leaned into this. Thankfully, we already have a way to test that this change isn’t resulting in a significant change in false negatives: the Grype quality gate. One of the things we’ve put in place for Grype is a quality gate, which uses manually labeled vulnerability information to validate that a change in Grype hasn’t significantly affected the vulnerability match results. Every pull request and push to main runs the quality gate, which compares the previously released version of Grype against the newly introduced changes to ensure the matching hasn’t become worse. In our set of test data, we have been able to reduce false positive matches by 2,000+, while only seeing 11 false negatives. Instead of focusing on how we reduce the false positives, we can now focus on a much smaller set of false negatives to see why they were missed. In our sample data set, this is due to 11 Java JARs that don’t have Maven group, artifact, or version information, which brings up the next area of improvement: Java artifact identification. When first exploring the option to stop CPE matching there were a lot more than 11 false negatives, but it was still a manageable number – less than 200 false negatives are a lot easier to handle than thousands of false positives. Focusing on these, we found almost all of these were cases where Java JARs were not being identified properly, so we improved this, too. Today, it’s still not perfect – the main reason being that some JARs simply don’t have enough information to identify accurately without using some sort of external data (and we have some ideas for handling these cases, too). However, the majority of JARs do have enough information to accurately be identified. To make sure we weren’t regressing on this front, we downloaded gigabytes (25+ GB) of JARs, scanned, and validated that we are finding the right information to correctly extract the correct names and versions from these JARs. And much of this information ends up being included in the labeled vulnerability data we use to test every commit to Grype. This change doesn’t mean all CPE matching is turned off by default, however. There are some types of artifacts that Grype still needs to use CPE matching for. Binaries, for example, are not present in the GitHub Advisory Database and Alpine only provides entries for things that are fixed, so we need to continue using CPE matching to determine the vulnerabilities before querying for fix information there. But, for ecosystems supported by the GitHub Advisory Database, we can confidently use this data and prevent the plethora of false positives associated with CPE matching. GitHub + Grype for the win The next question you might ask is: how is the GitHub Advisory Database better? There are many reasons that the GitHub data is great, but the things that are most important for Grype are data quality, updatability, and community involvement. The GitHub Advisory Database is already a well-curated, machine-readable collection of vulnerability data. A surprising amount of public vulnerability data that exists isn’t very machine readable or high quality, and while a large volume of data that needs updates isn’t a problem by itself, it is a problem when the ability to provide such updates is nearly impossible. GitHub can review the existing public vulnerability data and update it with relevant details by correcting descriptions, package names, version information, and inaccurate severities along with all the rest of the captured information. Being able to update the data quickly and easily is vital to maintain a quality data set. And it’s not just GitHub that can contribute to these data corrections – because the GitHub Advisory Database is stored in a public GitHub repository, anyone with a GitHub account can submit updates. If you notice an incorrect version or spelling mistake in the description, the fix is one pull request away. Since GitHub repositories are historical archives, in addition to just submitting fixes, is the ability to look back in time at discussions, decisions, and questions. Much of the public vulnerability data today lacks transparency. Decisions might be made in private or by a single person, with no record of why. With the GitHub Advisory Database, we can see who did what, when, and why. Having a strong community makes open source work and using the open source model with vulnerability data works great too. We've got your back We believe this change will be a significant improvement for all Grype users, but we don’t know everyone’s situation. Since Grype is a versatile tool, it’s easy to enable CPE matching, if that’s something you still want to do. Just add the appropriate options to your .grype.yaml file or use the appropriate environment variables (see the Grype configuration for all the options), for example: We want to ensure Grype is the best vulnerability scanner that exists, which is a lofty goal. Today we made a big stride towards this goal. There will always be more work to do: better package detection, better vulnerability detection, and better vulnerability data. Grype and the GrypeDB are open source projects, so if you would like to help please join us. But today, we celebrate saying goodbye to lots of false positives, so keep calm and scan on, your list of vulnerabilities just got shorter! ### Detecting Exploits within your Software Supply Chain SBOMs. What are they good for? At Anchore, we see SBOMs (software bills of material) as the foundation of an application’s supply chain hierarchy. Upon this foundation you can build a lot of powerful features, such as, the ability to detect vulnerabilities in your open source dependencies before they are pushed to production. An unintended side effect of giving users the power to easily see deeply into their application’s dependencies and detect the vulnerabilities in those dependencies is that there can sometimes be hundreds of vulnerabilities discovered in the process.  We’ve seen customer applications that generate up to 400+ known vulnerabilities! This creates an information overload that typically ends in the application developer ignoring the results because it is too much effort to triage and remediate each one. Knowing that an application is riddled with vulnerabilities is better than not but excessive information does not lead to actionable insights.  Anchore Enterprise solves this challenge by pairing vulnerability data (e.g. CVEs, etc) with exploit data (e.g. KEV, etc). By combining these two data sources we can create actionable insight by showing users both the vulnerabilities in their applications and which vulnerabilities are actually being exploited. Actively exploited vulnerabilities are significantly higher risk and can be prioritized for triage and remediation first. In this blog post, we’ll discuss how we do that and how it can save both your security team and application developers time. How Does Anchore Enterprise Help You Find Exploits in Your Application Dependencies? What is an Exploited Vulnerability? “Exploited” is an important distinction because it means that not only does a vulnerability exist but a payload also exists that can reliably trigger the vulnerability and cause an application to execute unintended functionality (e.g. leaking all of the contents of a database or deleting all of the data in a database). For instance, almost all bank vaults in the world are vulnerable to an asteroid strike “deleting” all of the contents of the safe but no one has developed a system to reliably cause an asteroid to strike bank vaults. Maybe Elon Musk can make this happen in a few more years but today this vulnerability isn’t exploitable. It is important for organizations to prioritize exploited vulnerabilities because the potential for damage is significantly greater. Source High-Quality Data on Exploits In order to find vulnerabilities that are exploitable, you need high-quality data from security researchers that are either crafting exploits to known vulnerabilities or analyzing attack data for payloads that are triggering an exploit in a live application. Thankfully, there are two exceedingly high-quality databases that publish this information publicly and regularly; the Known Exploited Vulnerability (KEV) Catalog and the Exploit Database (Exploit-DB). The KEV Catalog is a database of known exploited vulnerabilities that is published and maintained by the US government through the Cybersecurity and Infrastructure Security Agency, CISA. It is updated regularly; they typically add 1-5 new KEVs every week.  While not an exploit database itself, the National Vulnerability Database (NVD) is an important source of exploit data because it checks all of the vulnerabilities that it publishes and maintains against the Exploit-DB and embeds the relevant identifiers when a match is found. Anchore Enterprise ingests both of these data feeds and stores the data in a centralized repository. Once this data is structured and available to your organization it can then be used to determine which applications and their associated dependencies are exploitable. Map Data on Exploits to Your Application Dependencies Now that you have a quality source of data on known exploited vulnerabilities, you need to determine if any of these exploits exist in your applications and/or the dependencies that they are built with. The industry-standard method for storing information on applications and their dependency supply chain is via a software bill of materials (SBOM).  After you have an SBOM for your application you can then cross-reference the dependencies against both a list of known vulnerabilities and a list of known exploited vulnerabilities. The output of this is a list of all of the applications in your organization that are vulnerable to exploits. If done manually, via something like a spreadsheet this can quickly become a tedious process. Anchore Enterprise automates SBOM management by generating SBOMs for all of your applications and running scans of the SBOMs against vulnerability and exploit databases.  How Does Anchore Enterprise Help You Prioritize Remediation of Exploits in Your Application Dependencies? Once we’ve used Anchore Enterprise to detect CVEs in our containers that are also exploitable through the KEV or ExploitDB lists, then we can take the severity score back into account with more contextual evidence. We need to know two things for each finding: what is the severity of the finding and can I accept the risk associated with leaving that vulnerable code in my application or container.  If we look back to the Log4J event in December of 2021, that particular vulnerability scored a 10 on the CVSS. That score alone provides us little detail on how dangerous that vulnerability is. If a CVE is discovered against any given piece of software and the NVD researchers cannot reach the authors of the code, then it’s assigned a score of 10 and the worst case is assumed.  However, if we have applied our KEV and ExploitDB bundles and determined that we do indeed have a critical vulnerability that has active known exploits and evidence that it is being exploited in the wild AND the severity exceeds our personal or organizational risk thresholds then we know that we need to take action immediately.  Everyone has questioned the utility of the SBOM but Anchore Enterprise is making this an afterthought. Moving past the basics of just generating an SBOM and detecting CVE’s, Anchore Enterprise is automatically mapping exploit data to specific packages in your software supply chain allowing you to generate reports and notifications for your teams. By analyzing this higher quality information, you can determine  which vulnerabilities actually pose a threat to your and in turn make more intelligent decisions about which to fix and which to accept, saving your organization time and money. Wrap Up Returning to our original question, “what are SBOMs good for”? It turns out the answer is scaling the process of finding and prioritizing vulnerabilities in your organization’s software supply chain. In today's increasingly complex software landscape, the importance of securing your application's supply chain cannot be overstated. Traditional SBOMs have empowered organizations to identify vulnerabilities but often left them inundated with too much information, rendering the data less actionable. Anchore Enterprise revolutionizes this process by not only automating the generation of SBOMs but also cross-referencing them against reputable databases like KEV Catalog and Exploit-DB to isolate actively exploited vulnerabilities. By focusing on the vulnerabilities that are actually being exploited in the wild, your security team can prioritize remediation efforts more effectively, saving both time and resources.  Anchore Enterprise moves beyond merely detecting vulnerabilities to providing actionable insights, enabling organizations to make intelligent decisions on which risks to address immediately and which to monitor. Don't get lost in the sea of vulnerabilities; let Anchore Enterprise be your compass in navigating the choppy waters of software security. If you’d like to learn more about the Anchore Enterprise platform or speak with a member of our team, feel free to book a time to speak with one of our specialists ### Introducing Grype Explain Since releasing Grype 3 years ago (in September 2020), one of the most frequent questions we’ve gotten is, “why is image X vulnerable to vulnerability Y?” Today, we’re introducing a new sub-command to help users answer this question: Grype Explain. Now, when users are surprised to see some CVE they’ve never heard of in their Grype output, they can ask Grype to explain itself: grype -o json alpine:3.7 | grype explain --id CVE-2021-42374. We're asking the community to please give it a try, and if you have feedback or questions, let us know. The goal of Grype Explain is to help operators evaluate a reported vulnerability so that they can decide what, if any, action to take. To demonstrate, let’s look at a simple scenario. First, an operator who deploys a file called fireline.hpi into production sees some vulnerabilities: ❯ grype fireline.hpi| grep Critical ✔ Vulnerability DB                [no update available] ✔ Indexed file system ✔ Cataloged packages              [35 packages] ✔ Scanned for vulnerabilities     [36 vulnerabilities] ├── 10 critical, 14 high, 9 medium, 3 low, 0 negligible └── 14 fixed bcel                 6.0-SNAPSHOT  6.6.0     java-archive    GHSA-97xg-phpr-rg8q  Critical commons-collections  3.1           3.2.2     java-archive    GHSA-fjq5-5j5f-mvxh  Critical dom4j                1.6.1         2.0.3     java-archive    GHSA-hwj3-m3p6-hj38  Critical fastjson             1.2.9         1.2.31    java-archive    GHSA-xjrr-xv9m-4pw5  Critical fastjson             1.2.9                   java-archive    CVE-2022-25845       Critical fastjson             1.2.9                   java-archive    CVE-2017-18349       Critical log4j-core           2.11.1        2.12.2    java-archive    GHSA-jfh8-c2jp-5v3q  Critical log4j-core           2.11.1        2.12.2    java-archive    GHSA-7rjr-3q55-vv33  Critical log4j-core           2.11.1                  java-archive    CVE-2021-45046       Critical log4j-core           2.11.1                  java-archive    CVE-2021-44228       Critical Wait, isn’t CVE-2021-44228 log4shell? I thought we patched that! The operator asks for an explanation of the vulnerability: ❯ grype -q -o json fireline.hpi| grype explain --id CVE-2021-44228 [0000]  WARN grype explain is a prototype feature and is subject to change CVE-2021-44228 from nvd:cpe (Critical) Apache Log4j2 2.0-beta9 through 2.15.0 (excluding security releases 2.12.2, 2.12.3, and 2.3.1) JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. From version 2.16.0 (along with 2.12.2, 2.12.3, and 2.3.1), this functionality has been completely removed. Note that this vulnerability is specific to log4j-core and does not affect log4net, log4cxx, or other Apache Logging Services projects. Related vulnerabilities:     - github:language:java GHSA-jfh8-c2jp-5v3q (Critical) Matched packages:     - Package: log4j-core, version: 2.11.1       PURL: pkg:maven/org.apache.logging.log4j/log4j-core@2.11.1       Match explanation(s):           - github:language:java:GHSA-jfh8-c2jp-5v3q Direct match (package name, version, and            ecosystem) against log4j-core (version 2.11.1).           - nvd:cpe:CVE-2021-44228 CPE match on `cpe:2.3:a:apache:log4j:2.11.1:*:*:*:*:*:*:*`.       Locations:           - /fireline.hpi:WEB-INF/lib/fireline.jar:lib/firelineJar.jar:log4j-core-2.11.1.jar URLs:     - https://nvd.nist.gov/vuln/detail/CVE-2021-44228     - https://github.com/advisories/GHSA-jfh8-c2jp-5v3q Right away this gives us some information an operator might need: Where’s the vulnerable file? /fireline.hpi:WEB-INF/lib/fireline.jar:lib/firelineJar.jar:log4j-core-2.11.1.jar Seeing the location inside a jar inside the .hpi file tells the operator that a jar inside a jar inside the .hpi file is responsible for the vulnerability. How was it matched? Seeing both a CPE match on cpe:2.3:a:apache:log4j:2.11.1:*:*:*:*:*:*:* and a GHSA match on pkg:maven/org.apache.logging.log4j/log4j-core@2.11.1 gives the operator confidence that this is a real match.  What’s the URL where I can read more about it? Links to the NVD and GHSA sites for the vulnerability are printed out so the operator can easily learn more. Based on this information, the operator can assess the severity of the issue, and know what to patch. We hope that Grype Explain will help users better understand and respond faster to vulnerabilities in their applications. Do you have feedback on how Grype Explain could be improved? Please let us know! ### Fireside Chat with NVIDIA: Scaling Software Security ### How to Scan Your Containers for Vulnerabilities with Free Open Source Tools This blog post has been archived and replaced by the supporting pillar page that can be found here: https://anchore.com/wp-admin/post.php?post=987473420&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. ### NIST's Comprehensive Approach to Software Supply Chain Security The National Institute of Standards and Technology (NIST) has always been at the forefront of setting benchmarks and standards for industry. They recently released a draft publication, 800-240D, titled “Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD pipelines.” This document is exciting as it's a testament to their commitment to evolving with the times and addressing challenges with supply chain security. It should be noted that this current document is a draft. NIST is seeking guidance from stakeholders in order to write the final draft. Anyone who has input on this topic can and should contribute suggestions. NIST guidance is not produced in a bubble, it’s important we all help collaborate on these documents. Understanding the Significance of the Supply Chain Before we explain the purpose of the document, it's important to understand the software supply chain's complexity. When we think of "supply chain" we have historically imagined lines of code, software packages, and developer tools. However, it's a complex system that spans the foundational hardware, operating systems that run on them, developer workstations where software is crafted, and even the systems that distribute our software to users worldwide. Each node in this chain presents unique challenges with the idea of security. A great deal of previous guidance has been heavily focused on the development and procurement of software that goes into products. NIST 800-240D is a document that focuses on continuous integration and continuous delivery (CI/CD) systems. The security of a CI/CD system is no less important than the security of the packages that go into your software. NIST's Holistic Approach With 800-240D, NIST isn't merely adding another document to the pile. NIST recently released 800-218 or the Security Software Development Framework; they maintain NIST 800-53, the granddaddy of most other cybersecurity compliance frameworks. NIST is signaling they want to help move the goal in how the industry should approach software supply chain security. In this instance by emphasizing CI/CD pipelines, NIST is highlighting the importance of the processes that drive software development and deployment, rather than just the end product. While there's no shortage of guidance on CI/CD pipelines, much of the existing literature is either outdated or too narrow in scope. This is where NIST's intervention should make us pay attention. Their comprehensive approach ensures that every aspect of the software supply chain, from code creation to deployment, is under scrutiny. Comparing with Existing Content The CNCF supply chain security white paper serves as an example. A few years ago, this document was hailed as a significant step forward. It provided a detailed overview of supply chain concerns and offered solutions to secure them. However, the document hasn’t seen an update in over two years. The tech landscape is ever-evolving. What was relevant two years ago might not hold today. This rapid evolution underscores the need for regularly updated guidance. Maintaining and updating such comprehensive documents is no small feat. It requires expertise, resources, and a commitment to staying on top of industry developments. NIST, who has been providing guidance like this for decades, is uniquely positioned to take on this challenge. Their track record of maintaining and updating documents over extended periods is unparalleled. The Promise of Modern Initiatives Modern projects like SLSA and S2C2F have shown promise. They represent the industry's proactive approach to addressing supply chain security challenges. However, they face inherent challenges that NIST does not. The lack of consistent funding and a clear mandate means that their future is less certain than a NIST document. Key personnel changes, shifts in organizational priorities, or a myriad of other factors could unexpectedly derail their progress. NIST, with its government backing, doesn't face these challenges. NIST guidance is not only assured of longevity but also of regular updates to stay relevant. This longevity ensures that even as projects like SLSA or S2C2F evolve or new initiatives emerge, there's a stable reference point that the industry can rely on. Of course, something becoming a NIST standard doesn’t solve all problems, sometimes NIST guidance can become outdated and isn’t updated as often as it should be. Given the rash of government mandates around security lately, this is not expected to happen for supply chain related guidance. The NIST Advantage NIST's involvement goes beyond just providing guidance. Their reputation and credibility mean that their publications carry significant weight. Organizations, both public and private, pay attention when NIST speaks. The guidance NIST has been providing to the United States since its inception has helped the industry in countless ways. Everything from safety, to measurements, even keeping our clocks running! This influence ensures that best practices and recommendations are more likely to be adopted, leading to a more secure and robust software supply chain. However, it's essential to temper expectations. While NIST's guidance is invaluable, it's not magic. Some NIST standards become outdated, some are difficult for small businesses or individuals to follow. Not all recommendations can be universally applicable. However given the current global focus on supply chain security, we can expect NIST to be proactive in updating their guidance. It should also be noted that NIST guidance has a feedback mechanism. In the case of 800-240D, the document is a draft. NIST wants feedback. The current document will change between the current draft and the final version. Good feedback is a way we can all ensure the guidance is high quality. Looking Ahead The broader message from NIST's involvement is clear: broad supply chain security is important. It's not about isolated solutions or patchwork fixes. The industry needs a comprehensive approach that addresses risk at every stage of the software supply chain. In NIST's proactive approach, there is hope. Their commitment to providing long-lasting, influential guidance, combined with their holistic view of the supply chain, promises a future where supply chain security is not just an afterthought but an integral part of software development and deployment. NIST's 800-240D is more than just a publication. It's a call for the industry to come together, adopt best practices, and work towards a future where software supply chain security is robust, reliable, and resilient. If you’d like to learn more about how Anchore can help with NIST compliance, feel free to book a time to speak with one of our specialists. Josh Bressers Josh Bressers is vice president of security at Anchore where he guides security feature development for the company’s commercial and open source solutions. He serves on the Open Source Security Foundation technical advisory council and is a co-founder of the Global Security Database project, which is a Cloud Security Alliance working group that is defining the future of security vulnerability identifiers. ### Scaling Software Security with NVIDIA Personal computing and Apple in the 80s. The modern internet and Netscape in the 90s. Open source and Red Hat in the 2000s. Cloud and Amazon Web Services in the 2010s. Certain companies tend to define the computing paradigm of a decade. And so it is with AI and Nvidia in the 2020s. With its advanced GPU hardware, NVIDIA has enabled stunning advances in machine learning and AI models. That, in turn, has enabled services such as GitHub CoPilot and ChatGPT.  However, AI/ML is not just a hardware and data story. Software continues to be the glue that enables the use of large data sets with high-performance hardware. Like Intel before them, NVIDIA is as much a software solution vendor as a hardware company, with applications like CUDA and others being how developers interact with NVIDIA’s GPUs. Building on the trends of previous decades, much of this software is built from open source and designed to run on the cloud.  Unfortunately, the less welcome trend over the past decade has been increased software insecurity and novel attack vectors targeted at open source and the supply chain in general. For the past few years, we’ve been proud to partner with NVIDIA to ensure that the software they produce is secure and also secure for end users to run on their NVIDIA GPU Cloud (NGC). This has not only been a question of high-quality security scanning but ensuring that scanning can happen at scale and in a cost-effective manner.  We’re inviting the Anchore community to join us for a webinar with NVIDIA where we cover the use-case, architecture, and policies used by one of the most cutting-edge companies in technology. Those interested can learn more and save your seat here.  ### Automated Policy Enforcement for CMMC with Anchore Enterprise The Cyber Maturity Model Certification (CMMC) is an important program to harden the cybersecurity posture of the defense industrial base. Its purpose is to validate that appropriate safeguards are in place to protect controlled unclassified information (CUI). Many of the organizations that are required to comply with CMMC are Anchore customers. They have the responsibility to protect the sensitive, but not classified data, of US military and government agencies as they support the various missions of the United States.  CMMC 2.0 Levels Level 1 Foundation: Safeguard federal contract information (FCI); not critical to national security. Level 2 Advanced:  This maps directly to NIST Special Publication (SP) 800-171. Its primary goal is to ensure that government contractors are properly protecting controlled unclassified information (CUI). Level 3 Expert: This maps directly to NIST Special Publication (SP) 800-172. Its primary goal is to go beyond the base-level security requirements defined in NIST 800-171. NIST 800-172 provides security requirements that specifically defend against advanced persistent threats (APTs). This is of critical importance as these organizations leverage common place DevOps tooling to build their software. Additionally, these large organizations may be working with smaller subcontractors or suppliers who are building software in tandem or partnership.  For example, a mega-defense contractor is working alongside a small mom-and-pop shop to develop software for a classified government system. Lots of questions we should have here: How can my company as a mega-defense contractor validate what software built by my partner is not using blacklisted software packages? How can my company validate software supplied to me is free of malware? How can I validate that the software supplied to me is in compliance with licensing standards and vulnerability compliance thresholds of my security team? How do I validate that the software I’m supplying is compliant not only against NIST 800-171 and CMMC, but against the compliance standards of my government end user (Such as NIST 800-53 or NIST 800-161)? Validating Security between DevSecOps Pipelines and Software Supply Chain At any major or small contractor alike, everyone has taken steps to build internal DevSecOps (DSO) pipelines. However, the defense industrial base (DIB) commonly involves daily relationships in which smaller defense contractors supply software to a larger defense contractor for a program or DSO pipeline that consumes and implements that software. With Anchore Enterprise, we can now validate if that software supplied is compliant with CMMC controls as specified in NIST 800-171. Looking to learn more about how to achieve CMMC Level 2 or NIST 800-171 compliance? 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. Intro to DoD Software Factory Outline for Getting Up to Speed on the DoD Software Factory How Anchore Secures Software Factories Which Controls does Anchore Enterprise Automate? 3.1.7 - Restrict Non-Privileged Users and Log Privileged Actions Related NIST 800-53 Controls: AC-6 (10) Description: Prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit logs.  Implementation: Anchore Enterprise can scan the container manifests to determine if the user is being given root privileges and implement an automated policy to prevent build containers from entering a runtime environment. This prevents a scenario where any privileged functions can be utilized in a runtime environment. 3.4.1 - Maintain Baseline Configurations & Inventories Related NIST 800-53 Controls: CM-2(1), CM-8(1), CM-6 Description: Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles. Implementation: Anchore Enterprise provides a centralized inventory of all containers and their associated manifests at each stage of the development pipeline. All manifests, images and containers are automatically added to the central tracking inventory so that a complete list of all artifacts of the build pipeline can be tracked at any moment in time. 3.4.2 - Enforce Security Configurations Related NIST 800-53 Controls: CM-2 (1) & CM-8(1) & CM-6 Description: Establish and enforce security configuration settings for information technology products employed in organizational systems. Implementation: Implementation: Anchore Enterprise scans all container manifest files for security configurations and publishes found vulnerabilities to a centralized database that can be used for monitoring, ad-hoc reporting, alerting and/or automated policy enforcement. 3.4.3 - Monitor and Log System Changes with Approval Process Related NIST 800-53 Controls: CM-3 Description: Track, review, approve or disapprove, and log changes to organizational systems. Implementation: Anchore Enterprise provides a centralized dashboard that tracks all changes to applications which makes scheduled reviews simple. It also provides an automated controller that can apply policy-based decision making to either automatically approve or reject changes to applications based on security rules. 3.4.4 - Run Security Analysis on All System Changes Related NIST 800-53 Controls: CM-4 Description: Analyze the security impact of changes prior to implementation. Implementation: Anchore Enterprise can scan changes to applications for security vulnerabilities during the build pipeline to determine the security impact of the changes. 3.4.6 - Apply Principle of Least Functionality Related NIST 800-53 Controls: CM-7 Description: Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities. Implementation: Anchore Enterprise can scan all applications to ensure that they are uniformly applying the principle of least functionality to individual applications. If an application does not meet this standard then Anchore Enterprise can be configured to prevent an application from being deployed to a production environment. 3.4.7 - Limit Use of Nonessential Programs, Ports, and Services Related NIST 800-53 Controls: CM-7(1), CM-7(2) Description: Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services. Implementation: Anchore Enterprise can be configured as a gating agent that will scan for specific security violations and prevent these applications from being deployed until the violations are remediated. 3.4.8 - Implement Blacklisting and Whitelisting Software Policies Related NIST 800-53 Controls: CM-7(4), CM-7(5) Description: Apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or deny-all, permit-by-exception (whitelisting) policy to allow the execution of authorized software. Implementation: Anchore Enterprise can be configured as a gating agent that will apply a security policy to all scanned software. The policies can be configured in a black- or white-listing manner. 3.4.9 - Control and Monitor User-Installed Software Related NIST 800-53 Controls: CM-11 Description: Control and monitor user-installed software. Implementation: Anchore Enterprise scans all software in the development pipeline and records all user-installed software. The scans can be monitored in the provided dashboard. User-installed software can be controlled (allowed or denied) via the gating agent. 3.5.10 - Store and Transmit Only Cryptographically-Protected Passwords Related NIST 800-53 Controls: IA-5(1) Description: Store and transmit only cryptographically-protected of passwords. Implementation: Anchore Enterprise can scan for plain-text secrets in build artifacts and prevent exposed secrets from being promoted to the next environment until the violation is remediated. This prevents unauthorized storage or transmission of unencrypted passwords or secrets. See screenshot below to see this protection in action. 3.11.2 - Scan for Vulnerabilities Related NIST 800-53 Controls: RA-5, RA-5(5) Description: Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified. Implementation: Anchore Enterprise is designed to scan all systems and applications for vulnerabilities continuously and alert when any changes introduce new vulnerabilities. See screenshot below to see this protection in action. 3.11.3 - Remediate Vulnerabilities Respective to Risk Assessments Related NIST 800-53 Controls: RA-5, RA-5(5) Description: Remediate vulnerabilities in accordance with risk assessments. Implementation: Anchore Enterprise can be tuned to allow or deny changes based on a risk scoring system. 3.12.2 - Implement Plans to Address System Vulnerabilities Related NIST 800-53 Controls: CA-5 Description: Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems. Implementation: Anchore Enterprise automates the process of ensuring all software and systems are in compliance with the security policy of the organization.  3.13.4 - Block Unauthorized Information Transfer via Shared Resources Related NIST 800-53 Controls: SC-4 Description: Prevent unauthorized and unintended information transfer via shared system resources. Implementation: Anchore Enterprise can be configured as a gating agent that will scan for unauthorized and unintended information transfer and prevent violations from being transferred between shared system resources until the violations are remediated. 3.13.8 - Use Cryptography to Safeguard CUI During Transmission Related NIST 800-53 Controls: SC-8 Description: Transmission Confidentiality and Integrity: Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards. Implementation: Anchore Enterprise can be configured as a gating agent that will scan for CUI and prevent violations of organization defined policies regarding CUI from being disclosed between systems. 3.14.5 - Periodically Scan Systems and Real-time Scan External Files Related NIST 800-53 Controls: SI-2 Description: Perform periodic scans of organizational systems and real-time scans of files from external sources as files are downloaded, opened, or executed. Implementation: Anchore Enterprise can be configured to scan all external dependencies that are built into software and provide information about relevant security vulnerabilities in the software development pipeline. See screenshot below to see this protection in action. Wrap-Up In a world increasingly defined by software solutions, the cybersecurity posture of defense-related industries stands paramount. The CMMC, a framework with its varying levels of compliance, underscores the commitment of the defense industrial base to fortify its cyber defenses.  As a multitude of organizations, ranging from the largest defense contractors to smaller mom-and-pop shops, work in tandem to support U.S. missions, the intricacies of maintaining cybersecurity standards grow. The questions posed exemplify the necessity to validate software integrity, especially in complex collaborations.  Anchore Enterprise solves these problems by automating software supply chain security best practices. It not only automates a myriad of crucial controls, ranging from user privilege restrictions to vulnerability scanning, but it also empowers organizations to meet and exceed the benchmarks set by CMMC and NIST.  In essence, as defense entities navigate the nuanced web of software development and partnerships, tools like Anchore Enterprise are indispensable in safeguarding the nation's interests, ensuring the integrity of software supply chains, and championing the highest levels of cybersecurity. If you’d like to learn more about the Anchore Enterprise platform or speak with a member of our team, feel free to book a time to speak with one of our specialists. ### Breaking Down NIST SSDF: Spotlight on P0.1 - Prepare the Organization After the last blog post about SSDF, I decided to pick something much easier to write about, and it happens to be at the top of the list. We’ll cover PO.1 this time, it’s the very first control in the SSDF. The PO stands for Prepare the Organization. The description is Define Security Requirements for Software Development (PO.1): Ensure that security requirements for software development are known at all times so that they can be taken into account throughout the SDLC and duplication of effort can be minimized because the requirements information can be collected once and shared. This includes requirements from internal sources (e.g., the organization’s policies, business objectives, and risk management strategy) and external sources (e.g., applicable laws and regulations). How hard can it be to prepare the organization? Just tell them we’re doing it and it’s a job well done! This is actually one of the most important steps, and one of the hardest steps when creating a secure development program. When we create a secure development program we really only get one chance with developers. What I mean by that is if we try to keep changing what we're asking developers to do we create an environment that lacks trust, empathy, and cooperation. This is why the preparation stage is such an important step when trying to deploy the SSDF in your organization. We all work for a company whose primary mission isn't to write secure software, the actual mission is to provide a product or service to our customers. Writing security software is one of the tools that can help with the primary mission. Sometimes as security professionals we forget this very important point. Security isn't the purpose, security is part of what we do or at least it should be part of what we do. It's important that we integrate into the existing process and procedures that our organization has. One of the reference documents for PO.1 is NIST 800-161, or Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations. It’s worth reading the first few sections of NIST 800-161 not for the security advice, but the organizational aspect. It stresses the importance of cooperation and getting the company to buy into a supply chain risk management program. We could say the days of security-making mandates are over, but they probably never really existed. The steps to prepare the organization The PO step of the SSDF is broken into three pieces. The first two sections explain how to document the process we're going to have to create and implement. The third section revolves around communicating these documented processes. This seems obvious, but the reality is it's something that doesn't happen on a regular basis. It's really easy for a security team to create a process, but never tell anyone about it. Telling people about the process is harder than creating the process in many instances. It’s much harder to bring that process and policy to another group and collect their feedback on it and make sure they buy into it. PO.1.1: Infrastructure security requirements The first section is about documenting the internal infrastructure and process. There's also a mention in the first control to maintain this documentation over time. It’s possible your organization already has these documents in place, if so, good job! If not, there’s no better time to start than now. SANS has a nice library of existing security policy documents that can help get things moving. The intention of these isn’t to take them as is and declare it your new security policy. You have to use existing documents as a guide and make sure you have agreement and understanding from the business. Security can’t show up with a canned document they didn’t write and declare it the new policy. That won’t work. PO.1.2: Software security requirements The second section revolves around how we're going to actually secure our software and services. It’s important to note this control isn’t about the actual process of securing the software, but documenting what that process will look like. One of the difficulties of securing the software you build is there are no two organizations that are the same. Documenting how we're going to build secure software or how we're going to secure our environment is a lot of work. OWASP has a nice toolbox they call SAMM, or Software Assurance Maturity Model, that can help with this stage. There’s no shortcut to building a secure development program. It’s a lot of hard work and there will be plenty of trial and error. The most important aspect will be getting cooperation and buy in from all the stakeholders. Security can’t do this alone. PO.1.3: Communicate the requirements The third section talks about communicating these requirements to the organization. How hard can communication be? A security team can create documentation and policy that is fantastic, but then they put it somewhere that the rest of the company might not know exists or in some cases, the rest of the company might not even be able to access. This is obviously a problem because it has to be something that everyone in the organization is aware of and they know where to find it they know how to get help and they know what it is so it can't be stressed how truly important this stage is. If you tell your developers that they have to follow your policy and it's not well written or they can't find it or they don't understand why something is happening, those are developers that aren't going to engage and they aren't going to want to work with you  Next steps If you’re on a journey to implement SSDF, or you’re just someone looking to start formalizing your secure development program, these are some steps you can start taking today. This blog series uses SSDF as our secure development standard. You can start by reading the content NIST has published on their site Secure Software Development Framework. You can follow up on the SSDF content with a tour of the SANS policy templates. Most of these templates shouldn’t be used without customization. Every company and every development team will have unique processes and needs. The CSA has a nice document called CAIQ, or Consensus Assessment Initiative Questionnaire that can help create some focus on what you need. Combining this with a SAMM assessment would be a great place to start. And lastly, whatever standard you choose, and whatever internal process you create, it’s important to keep in mind this is a fluid and ever-changing space. You will have to revisit decisions and assumptions on a regular basis. The SSDF standard will change, your business will change, everything will change. It’s the old joke that the only constant is change. Want to better understand how Anchore can help? Schedule a demo here. Josh Bressers Josh Bressers is vice president of security at Anchore where he guides security feature development for the company’s commercial and open source solutions. He serves on the Open Source Security Foundation technical advisory council and is a co-founder of the Global Security Database project, which is a Cloud Security Alliance working group that is defining the future of security vulnerability identifiers. ### NIST SP 800-53, the Control Catalog: A Guide in Plain English This blog post has been archived and replaced by the supporting pillar page that can be found here: https://anchore.com/wp-admin/post.php?post=987473301&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. ### NIST 800-37, the Risk Management Framework: A Guide in Plain English This blog post has been archived. It is replaced by the supporting pillar page, found here: https://anchore.com/wp-admin/post.php?post=987473296&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. ### Four Signs You’re Ready to Upgrade from DIY Supply Chain Security to Anchore Enterprise Build versus buy is always a complex decision for most organizations. Typically there is a tipping point that is hit when the friction of building and running your own tooling outweighs the cost benefits of abstaining from adding yet another vendor to your SaaS bill. The signals that point to when an organization is approaching this moment varies based on the tool you’re considering. In this blog post, we will outline some of the common signals that your organization is approaching this event for managing software supply chain risk. Whether your developers have self-adopted software development best practices like creating software bills of material (SBOMs) and now you’re drowning in an ocean of valuable but scattered security data, or you’re ready to start scaling your shift left security strategy across your entire software development life cycle, we will cover all of these scenarios and more. Challenge Type: Scaling SBOM Management Managing SBOMs is getting out of hand. Each day there is more SBOM data to sort and store. SBOM generation is by far the easiest capability to implement today. It’s free, extremely lightweight (low learning curve for engineers to adopt, unlike some enterprise products), and it's fast…blazing fast! As a result of this, teams can quickly generate hundreds, thousands (even millions!) of SBOMs over the course of a fiscal year. This is great from a data security perspective but creates its own problems. Once the friction of creating SBOMs becomes trivial, teams typically struggle with good ways to store and manage all of this new data. Just like any other context, questions arise about how long to retain data, query the data for security related issues, or even integrate all of that data with third party tooling to glean actionable security insights. Once teams have fully adopted SBOM generation in a few areas, it is a good practice to consider the best way to manage the data so your developers’ time is not in vain.  Anchore Enterprise helps in a variety of ways, not just to manage SBOMs but to detect SBOM drift in the build process and alert security teams to changes in SBOMs so they can be assessed for risks or malicious activity. Challenge Type: Regulatory Compliance Let’s say that you just got a massive policy compliance mandate dropped in your lap from your manager. It’s your job to implement the parameters within the allotted deadline, and you’re not sure where to start. As we’ve talked about in other posts, meeting compliance standards is more than a full-time job. Organizations have to make the decision to either DIY compliance or work with third parties that have expertise in specific standards. With the debut of revision 5 of NIST 800-53, the “Control Catalog”, more and more compliance standards require companies to implement controls that specifically address software supply chain security. This is due to the fact that many federal compliance standards build off of the “Control Catalog” as the source of truth for secure IT systems. Whether it’s FedRAMP, a compliance framework related to NIST 800-53, or something as simple as a CIS benchmark, Anchore can help. The Anchore Enterprise SBOM management solutions offer automated policy enforcement in your software supply chain. It serves to enforce compliance frameworks on your source code repos, images in development, and runtime Kubernetes clusters. Challenge Type: Zero-Day Response When a zero-day vulnerability is discovered, how do you answer the question “Am I vulnerable?” Depending on how well you have structured your security practice that question can take anywhere from an hour to a week or more. The longer that window the more risk your organization accrues. Once a zero-day incident occurs, it is very easy to spot the organizations that are prepared and those that are not.  If you haven’t figured it out yet, the retention and centralized management of SBOM’s are probably one of the most useful tools in modern incident response plans for identification and triage of zero-day incidents impacting organizations. Even though software teams are empowered to make decentralized decision making they can still adhere to security principles that can benefit from a centralized data storage solution. This type of centralization allows organizations to answer critical questions with speed at critical moments in the life of an organization. Anchore Enterprise helps answer the question “Am I vulnerable?” and it does it in minutes rather than days or weeks. By creating a centralized store of software supply chain data (via SBOMs) Anchore Enterprise allows organizations to quickly query this information and get back precise information on if a vulnerable package exists within the organization and exactly where to focus the remediation efforts. We also provide hands-on training that takes our customers through table top exercises in a controlled environment. By simulating a zero-day incident we test how well an organization is prepared to handle an uncontrolled threat environment and identify the gaps that could lead to extended uncertainty. Challenge Type: Scaling a Shift Left Security Culture  The shift left security movement was based on the principle that organizations can preempt security incidents by implementing secure development practices earlier in the software development lifecycle. The problem with this approach arises as you attempt to scale it. The more gates that you put in to catch security vulnerabilities earlier in the life cycle slows the software development process and requires more security resources. In order to scale shift left security practices organizations will need to adopt software-based solutions to automate these checks and allow developers to self-diagnose and remediate vulnerabilities without significant intervention from the security team. The earlier in the software development process that vulnerabilities are caught the faster secure software can be shipped.  Anchore enables organizations to scale their shift left security strategy by automating security checks at multiple points in the development life cycle. On top of that, due to the speed that Anchore can run its security scans, organizations can check every software artifact in the development pipeline without adding significant friction. Checking every deployed image during integration (CI), storage (registry) and runtime (CD) allows Anchore to scale a continuous security program that significantly reduces the potential for a vulnerable application to find its way to production where it can be exploited by a malicious adversary. The Anchore Enterprise runtime monitoring capabilities allow you to see what is running in your environment, detect issues within those images, and prevent images that fail policy checks from being deployed in your cluster or runtime environment. Wrap-Up The landscape of software supply chain security is increasingly complex, underscored by the rapid proliferation of SBOMs, rising compliance standards, and evolving security threats. Organizations today face the dilemma of scaling in-house security tools or seeking more streamlined and comprehensive solutions. As highlighted in this post, many of the above signals might indicate that it's time for your organization to transition from DIY methods to a more robust solution.  Anchore Enterprise was developed to overcome the challenges that are most common to organizations. With its focus on aiding organizations in scaling their shift-left security strategies, Anchore not only ensures compliance but also facilitates faster and safer software deployment. Even though each organization has its own set of unique challenges pertaining to software supply chain security, Anchore Enterprise is ready to enable organizations to mitigate and respond to these challenges. If you’d like to learn more about the Anchore Enterprise platform or speak with a member of our team, feel free to book a time to speak with one of our specialists. ### Software Supply Chain Hierarchy of Needs: SBOMs as the Foundation Software serves as a powerful tool that simplifies complex and technical concepts but with the incredible power of software comes an interconnected labyrinth of software dependencies that often form the foundation for innovative applications. These dependencies are not without their pitfalls, as we've learned from incidents like Log4Shell. As we try to navigate the ever-evolving landscape of software supply chain security, we need to ensure that our applications are built on strong foundations. In this blog post, we delve into the concept of a Software Bill of Materials (SBOM) as a foundational requirement for a secure software supply chain. Just as a physical supply chain is scrutinized to ensure the quality and safety of a product, a software supply chain also requires critical evaluation. What's at stake isn't just the functionality of an application, but the security of information that the application has access to. Let's dive into the world of software supply chains and explore how SBOMs could serve as the bedrock for a more resilient future in software development and security. What are Software Supply Chain Attacks? Supply chain attacks are malicious strikes that target the suppliers of components of an application rather than the application itself. Software supply chains are similar to physical supply chains. When you purchase an iPhone all you see is the finished product. Behind the final product is a complex web of component suppliers that are then assembled together to produce an iPhone. Displays and camera lenses from a Japanese company, CPUs from Arizona, modems from San Diego, lithium ion batteries from a Canadian mine; all of these pieces come together in a Shenzhen assembly plant to create a final product that is then shipped straight to your door. In the same way that an attacker could target one of the iPhone suppliers to modify a component before the iPhone is assembled, a software supply chain threat actor could do the same but target an open source package that is then built into a commercial application. This is a problem when 70-90% of modern applications are built utilizing open source software components. GIven this the supply chain is only as secure as its weakest link. The image below of the iceberg has become a somewhat overused meme of software supply chain security but it has become overused precisely because it explains the situation so well. Below is the same idea but without the floating ice analogy. Each layer is another layer of abstraction that is far removed from “Your App”. All of these dependencies give your software developers the superpower to build extremely complex applications, very quickly but with the unintentional side-effect that they cannot possibly understand all of the ingredients that are coming together. This gives adversaries their opening. A single compromised package allows attackers to manipulate all of the packages “downstream” of their entrypoint. This reality was viscerally felt by the software industry (and all industries that rely on the software industry, meaning all industries) during the Log4j incident. Log4Shell Impact Log4Shell is the poster child for the importance of software supply chain security. We’re not going to go deep on the vulnerability in this post. We have actually done this in a number of other posts. Instead we’re going to focus on the impact of the incident for organizations that had instances of Log4j in their applications and what they had to go through in order to remediate this vulnerability. First let’s brush up on the timeline: The vulnerability in log4j was originally privately disclosed on November 24. Five days later a pull request was published to close the vulnerability and a week after that the new package was released. The official public disclosure happened on December 10. This is when the mayhem began and companies began the work of determining whether they were vulnerable and figuring out how to remediate the vulnerability. On average, impacted individuals spent ~90 hours dealing with the Log4j incident. Roughly 20% of that time was spent identifying where the log4j package was deployed into an application.  From conversations with our customers and prospects the primary culprit for why this took up such a large portion of time was whether or not an organization had a central repository of metadata about the software dependencies that had been utilized in building their applications. For customers that did have a central repository and a way to query this database, the step of identifying which applications had the log4j vulnerability present took 1-2 hours instead of 20+ hours as seen with the other organizations. This is the power of having SBOMs in place for all of the software and a tool to help with SBOM management. What is a Software Bill of Materials? Similar to the nutrition labels on the back of the foods that you buy, SBOMs are a list of ingredients that go into the software that your applications consume. We normally think of SBOMs as an artifact of the development process. As a developer is manufacturing their application using different dependencies they are also building a recipe based on the ingredients. In reality, an SBOM can (and should) be generated at all steps of the build pipeline. Source, builds, images, and production software can all be used to generate an SBOM. Similar to Maslow’s hierarchy of needs, software supply chain management has an analogous hierarchy of needs.  At the base of the pyramid are the contents of the application, in other words, SBOMs about the application. The diagram below shows all of the layers of the proposed hierarchy of software supply chains. By using an SBOM as the foundation of the pyramid, organizations can ensure that all of the additional security features they layer on to this foundation will stand the test of time. We can only know that our software is free from known vulnerabilities if we have confidence in the process that was used to generate the “ingredients” label. Signing software to prove that a package hasn’t been tampered with is only valid if the signed software is both free of known vulnerabilities. Signing a vulnerabile package or image only proves that software hasn’t been tampered with from that point forward. It can’t look back retrospectively and validate that the packages that came before are secure without the help of an SBOM or a vulnerability scanner. What are the Benefits of this Approach? Utilizing Software Bills of Materials (SBOMs) as the foundational element of software supply chain security brings several substantial benefits: Transparency: SBOMs provide a comprehensive view of all the components used in an application. They reveal the 'ingredients' that make up the software, enabling teams to understand the entire composition of their applications, including all dependencies. No more black box dependencies and the associated risk that comes with it. Risk Management: With the transparency provided by SBOMs, organizations can identify potential security risks within the components of their software and address them proactively. This includes detecting vulnerabilities in dependencies or third-party components. SBOMs allow organizations to standardize their software supply chain which allows for an automated approach to vulnerability management and impacts risk management. Quick Response to Vulnerabilities: When a new vulnerability is discovered in a component used within the software, SBOMs can help quickly identify all affected applications. This significantly reduces the time taken to respond and remediate these vulnerabilities, minimizing potential damages. When an incident occurs, NOT if, an organization is able to rapidly respond to the breach and limit the impact.  Regulatory Compliance: Regulations and standards are increasingly requiring SBOMs for demonstrating software integrity. By incorporating SBOMs, organizations can ensure they meet these cybersecurity compliance requirements. Especially when working with highly regulated industries like the federal government, financial services and healthcare. Trust and Verification: SBOMs facilitate trust and confidence in software products by allowing users to verify the components used. They serve as a 'proof of integrity' to customers, partners, and regulators, showcasing the organization's commitment to security. They also enable higher level security abstractions like signed images or source code to inherit the underlying foundation security guarantees provided by SBOMs. By putting SBOMs at the base of software supply chain security, organizations can build a robust structure that's secure, resilient, and efficient. Building on a Strong Foundation The utilization of Software Bills of Materials (SBOMs) as the bedrock for secure software supply chains provides a fundamental shift towards increased transparency, improved risk management, quicker responses to vulnerabilities, heightened regulatory compliance, and stronger trust in software products. By unraveling the complex labyrinth of dependencies in software applications, SBOMs offer the necessary insight to identify and address potential weaknesses, thus creating a resilient structure capable of withstanding potential security threats. In the face of incidents like Log4Shell, the industry needs to adopt a proactive and strategic approach, emphasizing the creation of a secure foundation that can stand the test of time. By elevating the role of SBOMs, we are taking a crucial step towards a future of software development and security that is not only innovative but also secure, trustworthy, and efficient. In the realm of software supply chain security, the adage "knowing is half the battle" couldn't be more accurate. SBOMs provide that knowledge and, as such, are an indispensable cornerstone of a comprehensive security strategy. If you’re interested in learning about how to integrate SBOMs into your software supply chain the Anchore team of supply chain security specialists are ready and willing to discuss. ### Customizing Grype Vulnerability Reports With Templates If you’ve used Grype to scan your images and SBOMs for vulnerabilities, you might be familiar with some of the output formats that Grype can produce. The standard output is a simple tabular format. If you want more detail, or if you want to produce a machine-parsable output, you can use the “-o” option to get reports in a more comprehensive Grype JSON output, or reports based on the CycloneDX standard in either JSON or XML. If those aren’t suitable for your needs, there is another option, “-o template”, which allows you to specify your own completely customized template based on the Go templating language. If you have developed a useful template that you’d like to share with others, we have a place for community-contributed templates in the Grype source code on GitHub. How to Build a Template To create a template, create a text file describing your desired output using the Go template syntax. There are a couple of simple templates included in the Grype source code that you can use as a starting point, including the standard table-based output you see when you run Grype without setting an output format. The template that generates the table is here: templates/table.tmpl There is also a very simple template that generates CSV (comma separated values): templates/csv.tmpl "Package","Version Installed","Vulnerability ID","Severity" {{- range .Matches}} "{{.Artifact.Name}}","{{.Artifact.Version}}","{{.Vulnerability.ID}}","{{.Vulnerability.Severity}}" {{- end}} This template produces this output: "Package","Version Installed","Vulnerability ID","Severity" "coreutils","8.30-3ubuntu2","CVE-2016-2781","Low" "libc-bin","2.31-0ubuntu9","CVE-2016-10228","Negligible" "libc-bin","2.31-0ubuntu9","CVE-2020-6096","Low" ... Grype also includes the utility templating functions from the standard golang text/template module, so if you need to do more processing in your template, you can. In addition to the standard golang functions, Grype also includes the utility functions from sprig. (Please note that templates can access information about the system they are running on, such as environment variables. You should never run untrusted templates.) Contribute Your Own Templates Have you developed a template for Grype’s output that you have found useful? If you think other people might also benefit from it, consider sending us a pull request to include it in Grype’s user-contributed templates directory. Come chat with us on Discourse or join our community meeting every other week if you have questions or suggestions. ### Anchore OSS Now Supports Microsoft’s Azure Linux Recently, Microsoft  announced the general availability of Azure Linux, a new open source Linux distribution maintained by Microsoft. A core principle of this new offering is to keep the set of OS packages small and light-weight, in support of some of the key characteristics of the distribution as described in the Azure Linux GA Announcement and Azure Linux Intro pages. As a Linux distribution that prominently highlights security in its list of core benefits, the Anchore team was thrilled to collaborate with Microsoft. Through the open source community, we’re bringing support for Azure Linux into Anchore's open source tool set, for end-to-end support for Azure Linux that includes: New capabilities in Syft to generate SBOMs from Azure Linux OS container images and hosts. A new provider for Vunnel that ingests Microsoft’s open vulnerability data feed for Azure Linux, ensuring accurate package-level vulnerability matching for their new operating system. Assurance that Azure Linux SBOMs, whether generated directly or shared between organizations can be used to generate vulnerability reports with information about available fixes from Microsoft, using Grype. Syft, Grype and Vunnel support an ever growing set of operating systems, but as new significant OS releases are infrequent, we want to highlight the concepts and technical process involved when bringing a new operating system into Anchore's OSS toolset. In this post, we’ll learn how Syft detects a supported OS and then catalogs that particular OS’s software package type, and critically, how to teach Grype to recognize vulnerabilities for a new distribution. NOTE: throughout this post, you might see 'mariner' used in technical areas that involve the name of the OS distribution. While the formal name of the new OS is Azure Linux, the internal data sources (/etc/os-release, vulnerability namespaces) use 'mariner' to identify the OS name. How does Grype recognize vulnerabilities in a new distribution? In order to scan an image (or other filesystem) for vulnerabilities, Syft and Grype work together. Syft generates a Software Bill of Materials (SBOM), which is a manifest of all the packages we can detect in the image, and Grype reports vulnerabilities by comparing this list with a database of known vulnerabilities. But where does this database come from? The first piece of the puzzle is a vulnerability feed. A vulnerability feed is a feed of new information, similar in many ways to how blogs and podcasts might have RSS feeds. The maintainers of a distribution often publish vulnerabilities to one of these feeds as they learn of them. However, there is a lot of variety in how these vulnerabilities are reported: how often are new vulnerabilities posted? How is the vulnerable software described? How does the feed reflect that a vulnerability has been fixed in a newer version? In order to use these vulnerability feeds, Grype needs an aggregated and normalized view of the data they report. Enter Vunnel. Vunnel is a new, open source vulnerability feed aggregation tool from Anchore. When we need to add data from a new set of vulnerabilities to Grype, the first step is to build a provider for the feed in Vunnel. A Vunnel provider is a Python module inside Vunnel that knows how to download and normalize the vulnerabilities from a particular feed. So in today’s announcement, when we say we Grype supports Azure Linux, what we mean is that Vunnel now has a vulnerability feed provider that pulls in vulnerabilities relating to Azure Linux and its packages, and makes them available to Grype. Let’s take a look at what went into adding this support end-to-end. Detecting the Distro Azure Linux is a Redhat Package Manager (RPM) based Linux distribution. Since Syft has long standing support for other RPM based distributions, we need to ensure that when an Azure Linux system is scanned and that the distro identifiers are picked up. This allows Syft to know how to correctly catalog the software installed using regular distro packaging mechanisms (in addition to non-distro software). This information will be used later by Grype during a vulnerability scan.  Last year, support for Mariner was added to Syft via contributions from the community here, here and here! (Can we just say, the open source community is awesome!)   We can see what this looks like by inspecting the ‘distro’ section of an SBOM generated against a mariner linux container image, like so: $ syft -q -o json mcr.microsoft.com/cbl-mariner/base/core:2.0 | jq '.distro'{  "prettyName": "CBL-Mariner/Linux",  "name": "Common Base Linux Mariner",  "id": "mariner",  "version": "2.0.20230518",  "versionID": "2.0",  "homeURL": "https://aka.ms/cbl-mariner",  "supportURL": "https://aka.ms/cbl-mariner",  "bugReportURL": "https://aka.ms/cbl-mariner"} Cataloging the Distro Software Now that we have the distro, and Syft knows that this particular distro uses RPM to manage packages, Syft will now automatically find and catalog any discovered RPMs, and add them to the ‘artifacts’ section of the generated SBOM. We won’t show all of the package metadata that is captured by Syft during analysis here (it’s quite a lot!), but importantly we can see that the Mariner RPMs are being identified correctly: $ syft -q -o json mcr.microsoft.com/cbl-mariner/base/core:2.0 | jq '.artifacts[0].metadata' | more{  "name": "bash",  "version": "5.1.8",  "epoch": null,  "architecture": "aarch64",  "release": "1.cm2",  "sourceRpm": "bash-5.1.8-1.cm2.src.rpm",  …  …} Understanding the Vulnerability Data Grype has logic that it uses to determine what the best vulnerability data source is for any given software element in a provided SBOM. In the case of operating system managed software, where the OS maintainer additionally provides a high quality vulnerability data feed (as is the case for Azure Linux), we need to find and understand that data source (both in terms of access, as well as format and data characteristics). For Azure Linux, we collaborated with the Azure team who let us know that this repository on GitHub is one place where feeds that are appropriate for this use case are made available. Add a Provider to Vunnel The last step in this journey is to implement a provider in Vunnel that takes vulnerability feed data on one side and normalizes the data into an intermediate form that the Grype DB system understands, which then ultimately gets packaged up and made available to all users of Grype. Because of the way syft -> vunnel -> grype-db -> grype are designed, as long as there is agreement between the ‘distro’ that Syft is storing, and the ‘namespace’ that ultimately ends up in the grype vulnerability DB, then Grype will automatically begin matching any ‘mariner distro RPMs’ to the ‘mariner vulnerability data’, to get the most accurate results available. Take a look at this thread in grype and related links to vunnel to look at the discussion and resulting provider implementation. Once completed, we can see the new vunnel provider doing its work when asked to create a normalized set of data that grype-db can understand: $ vunnel run mariner[INFO ] running mariner provider[INFO ] wrote 4025 entries[INFO ] recording workspace state Verify Matching in Grype With all the pieces in hand, now all that’s left is to see all the pieces come together - using a very old mariner linux container image (so that we have some examples of vulnerabilities that have since fixed) shows a successful outcome: $ grype -q mcr.microsoft.com/cbl-mariner/base/core@sha256:e20e222517e903144f01f4503ca6d5ab5f575669f7ac402bb85e2a1917511bf0…curl            7.82.0-1.cm2   0:7.86.0-1.cm2   rpm   CVE-2022-35252  Lowcurl-libs       7.82.0-1.cm2   0:7.86.0-1.cm2   rpm   CVE-2022-35252  Low… With that final step, showing the culmination of Syft, Vunnel, and Grype interoperating to provide a distro-aware vulnerability scan of mariner linux systems, our journey of adding support for a new Linux distribution is complete! Grype Now Supports the Azure Linux Vulnerability Feed Azure Linux, also known as Mariner Linux, is an open source Linux distribution from Microsoft, optimized for performance on Azure. In this post, we’ve described the process of adding the Azure Linux vulnerability feed to Vunnel, Anchore’s open source tool for importing and normalizing different vulnerability feeds. This allows Grype to scan for vulnerabilities from this feed. Versions of Grype 0.62.0 and later support this new feed, and can find vulnerabilities reported against Azure Linux packages. It’s great to see Anchore’s Syft and Grype add support for Azure Linux. Having accurate vulnerability data is critical for our customers, and these tools provide comprehensive open source options. – Jim Perrin, Principal PM, Azure Linux So if you’re using, or planning to use, Azure Linux, try out Syft and Grype for your SBOM and vulnerability scanning needs! Finally, as the full end-to-end stack of syft, vunnel, grype-db, grype, Azure Linux itself and Azure Linux Vulnerability Feeds are all open source, we hope that this post can be used to encourage community members to build providers for new vulnerability feeds just as described here, so that Grype can detect vulnerabilities from those feeds as well.  To get started, please open an issue and read the DEVELOPING.md from Vunnel. ### Deep Dive Into the CISA and NSA Best Practices for CI/CD Environments ### From Code to Cloud: Anchore Delivers SBOM-Powered SCA Anchore was launched in 2016 to address the software complexity that was growing exponentially as a result of the increasing use of container-based applications. To provide insight into the security status of containers, Anchore focused on generating the most complete picture of the contents in the container. This includes (but is not limited to) generating a high-fidelity software bill of materials (SBOM). Traditionally, generating SBOMs has been an implicit function of tools known as software composition analysis (SCA). These tools were originally developed in the late 90s/early 00s to focus on software licenses checks in source code. Vulnerability management for source code was bolted on later. However, the SCA approach from this era no longer works. There is too much software, shipping too rapidly, with too much complexity for them to scan adequately. Now, software is modified and shipped multiple times a day. Open source software now forms the majority content of any modern application. Attackers are using innovative supply chain attacks such as registry spoofing to obfuscate content. Containers are the default. And, finally, new compliance controls driven by the US government, are putting additional burdens on software transparency. Today, we are launching our new website to address this new reality with a modern, SBOM-powered SCA product that offers a more effective approach to the challenges of software transparency. This approach has been recognized by major Fortune 500 enterprises and leaders in the public sector across the US, UK, and Australia. Anchore Enterprise is focused on cloud-native applications. At Anchore we recognize that SBOMs have to be generated and scanned at every step of the process from CI/CD to registry to production. That’s why we put federal compliance at the heart of our policy engine. This approach enables a variety of solutions. Whether you are trying to modernize your team with DevSecOps practices, address board-level concerns about the software supply chain after Log4j, or sell to the U.S. government in the wake of the Biden Executive Order, we have you covered. Contact us to today for more info on how Anchore Enterprise can work for you. ### Ask Me Anything: Roadblocks to SBOMs ### Amazon ECS and Anchore Enterprise: Big Updates Until now, Anchore’s primary runtime focus has been enabling deep vulnerability analysis through the generation of Software Bill of Materials (SBOMs) for images that are built and deployed in Kubernetes. Kubernetes is one of the most widely used container orchestration platforms in the industry, but Anchore has recognized that there are other platforms that our customers are using. Amazon Elastic Container Service (ECS) is another powerful container orchestration platform that, until now, was limited in its API functionality to allow container scanning outside of the AWS ecosystem. Before this major update to Anchore Enterprise 4.8, those who were using ECS for their runtime environment were unable to perform vulnerability analysis for the images unless they were hosted in Amazon Elastic Container Registry (ECR). Now that the proper updates have been implemented by AWS to their API, users can gather their inventory of images in use from ECS and run vulnerability scans via our new anchore-ecs-inventory agent (downloadable here) for any registry. Explore the code more in-depth here. How to Deploy `anchore-ecs-inventory` just like `anchore-k8s-inventory` can be deployed via a helm chart into any kubernetes environment with access to AWS and your Anchore deployment. You can install the chart via: helm repo add anchore https://charts.anchore.io helm install ecs-inventory anchore/ecs-inventory An example of values.yaml can be found here. The ECS runtime agent gathers data via the AWS API so there is no need for it to be collocated with your runtime environment. However, should you want to have the agent run directly on ECS and report back to Anchore Enterprise, we have an example task definition in our documentation that can be used in the docs here. Subscribe to Watch ECS Inventory to Auto Analyze It's possible to create a subscription to watch for new ECS Inventory that is reported to Anchore and automatically schedule those images for analysis. A subscription can be created by sending a POST to /v1/subscriptions with the following payload: {   "subscription_key": "",   "subscription_type": "runtime_inventory" } Curl example: curl -X POST -u USERNAME:PASSWORD --url ANCHORE_URL/v1/subscriptions --header 'Content-Type: application/json' --data '{   "subscription_key": "arn:aws:ecs:eu-west-2:123456789012:cluster/myclustername",   "subscription_type": "runtime_inventory" }' The subscription_key can be set to any part of an ECS ClusterARN. For example, setting the subscription_key to the: full ClusterARN arn:aws:ecs:us-east-1:012345678910:cluster/telemetry will create a subscription that only watches this cluster partial ClusterARN arn:aws:ecs:eu-west-2:988505687240 will result in a subscription that watches every cluster within the account 988505687240 After a subscription has been created it needs to be activated. This can be achieved with anchorectl. anchorectl subscription activate runtime_inventory To verify that you are tracking ECS Inventory you can access inventory results with the command anchorectl inventory list and look for results where the TYPE is ecs. Reporting If you navigate to the Reportings tab in the Anchore Enterprise UI, you will now be able to see the new “Vulnerabilities by ECS Container” report under the Templates section. Once selected, you will be able to adjust the specific filters and criteria you want to set for your report. After saving your template, you will be able to query the template and generate a report. We hope this post provides you with the insights needed to get started with conducting vulnerability analysis in your ECS runtime environment. ### Breaking Down NIST SSDF: Spotlight on PW.6 - Build Systems This is part two of control PW.6. Part one was Breaking Down NIST SSDF: Spotlight on PW.6 Compilers and Interpreter Security. In this part of the long running series breaking down NIST Secure Software Development Framework (SSDF), also known as the standard NIST 800-218, we are going to discuss the build system portion of PW.6. To review the text of PW.6 PW.6.1: Use compiler, interpreter, and build tools that offer features to improve executable security. PW.6.2: Determine which compiler, interpreter, and build tool features should be used and how each should be configured, then implement and use the approved configurations. We covered compilers and interpreters last time, we will focus on build systems this time. PW.6.1 Example 1: Use up-to-date versions of compiler, interpreter, and build tools. Example 2: Follow change management processes when deploying or updating compiler, interpreter, and build tools, and audit all unexpected changes to tools. Example 3: Regularly validate the authenticity and integrity of compiler, interpreter, and build tools. See PO.3. PW.6.2 Example 1: Enable compiler features that produce warnings for poorly secured code during the compilation process. Example 2: Implement the “clean build” concept, where all compiler warnings are treated as errors and eliminated except those determined to be false positives or irrelevant. Example 3: Perform all builds in a dedicated, highly controlled build environment. Example 4: Enable compiler features that randomize or obfuscate execution characteristics, such as memory location usage, that would otherwise be predictable and thus potentially exploitable. Example 5: Test to ensure that the features are working as expected and are not inadvertently causing any operational issues or other problems. Example 6: Continuously verify that the approved configurations are being used. Example 7: Make the approved tool configurations available as configuration-as-code so developers can readily use them. If we review the references you will find there’s a massive swath of suggestions. Everything from code signing, to obfuscating binaries, to handling compiler warnings, to threat modeling. The net was cast wide on this one. Every environment is different. Every project or product uses its own technology. There’s no way to “one size fits all” this control. This is one of the challenges that has made compliance for developers so very difficult in the past, and it remains extremely difficult today. We have to determine how this applies to our environment, and the way we apply this finding will be drastically different than the way someone else applies it. We’re splitting this topic along the lines of build environments and compiler/interpreter security. The first blog focused on compiler security, which is an easy topic to understand. For this post, we are going to focus on what SSDF means for build tools, which is not at all well defined or obvious. Of course you will have to review the guidance and understand what makes sense for your environment, everything we discuss here is for example purposes only. The build system guidance isn’t very complete at all. None of the suggested standards have a huge focus on build systems. We don’t even get a definition of what a build system is, just that we need one. Many of us have a continuous integration and continuous delivery/continuous deployment (CI/CD) system now, that’s basically what counts as our build system in most instances. However, if you looked at two different CI/CD configurations they will almost certainly be drastically different. This is a really hard topic to discuss in a sensible manner, it’s easy to see why the SSDF sort of hand waives this one away. We’ve historically focused on secure development while ignoring much of what happens before and after development. This is starting to change, especially with things like SSDF, but there’s still a long way to go. There’s a reason build systems are often attacked yet have so little hardening guidance available. Build systems are incredibly complicated, poorly understood, and hard to lock down. One of the only resources that specifically addresses the build system is the Cloud Native Computing Foundation Software Supply Chain Security Paper (CNCFSSCP). It hasn’t been updated in over two years at the time of this post. We will also use a standard known as Supply-chain Levels for Software Artifacts, or SLSA ("salsa") for this discussion; it's being actively worked on as part of the Open Source Security Foundation (OpenSSF). While SLSA is one way to measure build systems standards, SLSA is very new, we will need more data on which controls are effective and which are not. Much of this guidance lacks scientific rigor at this point, but there are sensible things we can do to avoid attacks against our build systems. The honest reality is trying to secure a build system is still in its infancy, that’s why the SSDF guidance is so squishy. It will get better, many people are working on these problems. Keep this in mind as you hear advice and suggestions around security build systems. Much of the current guidance is conjecture. Secure the build After that intro, what possible advice is there to give? Things sound pretty rough out there. Let’s split this guidance into two pieces. The security of the build system, as in the actual computers and software that run the build system. And the scripts and programs that are the build system. For the security of the hardware, let someone else do the hard work. This sounds like sort of weird advice, but it’s the best there is. You can get access to many CI systems that are run by well experienced professionals. If you’re a GitHub customer, which many of us are, they have GitHub actions you can use at no added cost. There are too many options for CI systems to even try to list a few. All of these systems help us remove the burden of locking down our build systems. Locking down and monitoring build systems is a really hard job. Securing the build system, the scripts and programs that build our software, is a much different and less obvious challenge. Building an application could be everything from turning source code into a binary to packaging up HTML into a container image. Even SLSA and the CNCFSSCP don’t really give concrete guidance here. SLSA has a nugget of wisdom here which they refer to as provenance. They define provenance as “Attestation (metadata) describing how the outputs were produced, including identification of the platform and external parameters.” If we turn that into something easier to understand, let's call it “log everything”. We’re not really at a point of technology or understanding how to secure build systems without gigantic teams doing a lot of heavy lifting. There are organizations that have secure build infrastructure. But that security is in spite of the tooling, not because of it. Don’t prevent, detect When we think about securing our build systems, how to prevent attacks seems like the obvious goal. Today prevention is not possible without standards to describe where to even start. We might not be able to focus on prevention, but we can focus on detection today. If you have a log of your build, that log can be revisited at a later date. If an indicator of compromise emerges in the future, logs can be revisited. As new technologies and practices emerge, old logs can be analyzed. Use those logs to look for attacks, or mistakes, or just bad practices that need to be fixed. Conclusion This post unfortunately doesn’t have a lot of concrete advice in it. There just isn’t a lot of great guidance today. It’s being worked on but no doubt part of the reason it’s taking time is because of how new, hard, and broad this topic is. Sometimes it’s exciting being an early adopter and sometimes it’s frustrating. It would be easy to end this post by making up some advice and guidance that sounds good. There are things we can do that sound good but can be dangerous due to second order problems and unexpected outcomes. Remember when everyone thought changing passwords every 30 days was a good idea? Sometimes it’s better to wait and see than it is to jump right in. This is certainly one of those instances. Josh Bressers Josh Bressers is vice president of security at Anchore where he guides security feature development for the company’s commercial and open source solutions. He serves on the Open Source Security Foundation technical advisory council and is a co-founder of the Global Security Database project, which is a Cloud Security Alliance working group that is defining the future of security vulnerability identifiers. ### SSDF: Myths vs Reality ### New Syft Feature: R Package Cataloging Syft can now identify and catalog R packages and include them in the resulting Software Bill of Materials. R is a popular software environment for statistical computing and graphics. To use Syft's new R cataloging support, point Syft at a directory, image, or container that has some R packages installed. For instance, you can scan the r-base image provided by Docker: $ syft r-base ✔ Parsed image ✔ Cataloged packages [305 packages] NAME VERSION TYPE KernSmooth 2.23-20 R-package MASS 7.3-58.2 R-package Matrix 1.5-3 R-package apt 2.6.0 deb base 4.3.0 R-package ... This feature is new in Syft 0.81. Please let us know if you have any questions or problems with this new cataloger by filing an issue in our GitHub. If you want to extend Syft and write your own cataloger for a new kind of package, check out our contributor's guide. ### New Syft Feature: Location Annotations One of Syft's most important jobs is identifying operating system packages on your container images or filesystems. This list of packages and other software is the raw material for the resulting Software Bill of Materials (SBOM). A common question when you see a package in an SBOM is “how did Syft come to the conclusion that this package exists?”  To answer this question, we implemented a new feature in Syft 0.78.0 that can “show its work” and include information in the SBOM of the files that Syft has detected as evidence of the package. This is called location annotation. Here is an example from an SBOM in JSON format, generated by scanning an image that uses dpkg package management: [ { "id": "3e9282034226b93f", "name": "adduser", "version": "3.118", "type": "deb", "foundBy": "dpkgdb-cataloger", "locations": [ { "path": "/var/lib/dpkg/status", "layerID": "sha256:ec09eb83ea031896df916feb3a61cefba9facf449c8a55d88667927538dca2b4", "annotations": { "evidence": "primary" } } { "path": "/usr/share/doc/adduser/copyright", "layerID": "sha256:ec09eb83ea031896df916feb3a61cefba9facf449c8a55d88667927538dca2b4", "annotations": { "evidence": "supporting" } }, { "path": "/var/lib/dpkg/info/adduser.conffiles", "layerID": "sha256:ec09eb83ea031896df916feb3a61cefba9facf449c8a55d88667927538dca2b4", "annotations": { "evidence": "supporting" } }, ... You can see several items in the locations array. These are some of the specific files that Syft has used to identify the adduser package, version 3.118. There are two kinds of evidence in this array: primary and supporting. Primary evidence are the files that are used to determine a package’s existence on the system being scanned, and supporting evidence is additional data not necessarily fundamental to the package’s existence, but providing additional information. We additionally raise up locations that are annotated as primary evidence as package-to-file relationships in the SBOM so that this information can be used across more SBOM formats in a portable way. You can read through the pull request for this feature for more technical details. If you’re interested in learning more, implementing location annotations for a new package cataloger, or if you have any questions about the new feature, please join us on Discourse! ### Why Traditional SCA Just Doesn't Cut It Software Composition Analysis, or SCA, is a term that has been around for some time. But actually understanding… ### Build Your Own Custom Data Provider for Grype with Vunnel Several weeks ago we announced that we open sourced the process to create a vulnerability database for Grype. A new tool called Vunnel (“vulnerability data funnel”) is the first part of the pipeline. Vunnel takes vulnerability data from an external service like an OS distribution's vulnerability database or API, transforms it into an intermediary format, and makes it available to Grype-DB. Here’s a sketch of the general architecture: Grype's database builder pipeline relies on Vunnel as a key component. Vunnel's main function is to transform software vulnerability data into a standardized format that other tools can utilize. Vunnel's Providers, written in Python, are responsible for translating vulnerability information from various sources and formats into a common format. In this post we’ll walk through an example provider we have written, called “Awesome”, and show how it is put together, and how to build your own. We will assume that you have some Python development knowledge and are at least somewhat familiar with Grype already. A Quick Tour of a New Provider First, check out the example “Awesome” provider on GitHub: README.md The README has some more details describing how to run the provider in a test environment, some information about code organization, and a few more tips to build a useful and robust provider. To implement your own provider for Vunnel, you will need to implement a class inheriting from vunnel.provider.Provider, and implement two functions: update() and name(): name() should return a unique and useful name for your provider. If you’re ingesting vulnerabilities from a Linux distribution, the name of the Linux distribution would be a good choice. update() is responsible for downloading the vulnerability data from an external source and processing it. This is where all of the work is done! Here is part of our Awesome Provider’s class that implements these two functions (slightly modified for readability): # this provider requires the previous state from former runs provider.disallow_existing_input_policy(config.runtime) @classmethod def name(cls) -> str: return PROVIDER_NAME def update(self, last_updated: datetime.datetime | None) -> tuple[list[str], int]: with self.results_writer() as writer: for vuln_id, record in self.parser.get(): vuln_id = vuln_id.lower() writer.write( identifier=vuln_id, schema=SCHEMA, payload=record, ) return self.parser.urls, len(writer) The Provider class has functions to save the processed data in Vunnel’s format, so you don’t need to worry about writing to files or managing storage underneath. The arguments passed into writer.write include identifier, a unique indicator for a particular vulnerability, schema, the Vunnel schema for the kind of vulnerability you’re parsing (see schema.py for details), and payload, the data associated with the vulnerability: def update(self, last_updated: datetime.datetime | None) -> tuple[list[str], int]: with self.results_writer() as writer: for vuln_id, record in self.parser.get(): vuln_id = vuln_id.lower() writer.write( identifier=vuln_id, schema=SCHEMA, payload=record, ) return self.parser.urls, len(writer) (from vunnel/blob/main/example/awesome/__init__.py) As you can see from the example, you may want to factor out the download and processing steps into separate classes or functions for code portability and readability. Our example has most of the parsing logic in parser.py. In the Awesome example you will find some sections of code labeled “CHANGE ME!”. This is where you will need to make modifications to suit your particular provider. Trying out the Awesome Provider To begin, install the basic requirements by following the bootstrapping instructions outlined in Vunnel’s DEVELOPING.md document. Once you have installed Poetry and bootstrapped the necessary project tooling, you can test the example provider by running: poetry run python run.py You should get an output that looks something like this: tgerla@Timothys-MacBook-Pro example % poetry run python run.py [DEBUG] config: Config(runtime=RuntimeConfig(on_error=OnErrorConfig(action=fail, retry_count=3, retry_delay=5, input=keep, results=keep), existing_input=keep, existing_results=delete-before-write, result_store=flat-file), request_timeout=125) [DEBUG] using './data/my-awesome-provider' as workspace [DEBUG] creating input workspace './data/my-awesome-provider/input' [DEBUG] creating results workspace './data/my-awesome-provider/results' [INFO] downloading vulnerability data from https://services.nvd.nist.gov/made-up-location [DEBUG] clearing existing results [INFO] wrote 2 entries [INFO] recording workspace state [DEBUG] wrote workspace state to ./data/my-awesome-provider/metadata.json You can inspect the resulting output in ./data/my-awesome-provider/metadata.json: { "schema": "https://raw.githubusercontent.com/anchore/vunnel/main/schema/vulnerability/os/schema-1.0.0.json", "identifier": "fake-sa-001", "item": { "Vulnerability": { "Name": "FAKE-SA-001", "NamespaceName": "GRYPEOSNAMESPACETHATYOUCHOOSE", "Link": "https://someplace.com/FAKE-SA-001", "Severity": "Critical", "Description": "Bad thing, really bad thing", "FixedIn": [ { "Name": "curl", "VersionFormat": "apk", "NamespaceName": "GRYPEOSNAMESPACETHATYOUCHOOSE", "Version": "2.0" } ] } } } Now you are ready to modify the example provider to suit your own needs. To contribute your provider to the Vunnel project and share it with the rest of the open source community, you will need to write some tests and create a GitHub pull request. For more information on Vunnel and writing new Providers, you can find a lot more information in Vunnel's README.md, DEVELOPING.md, and CONTRIBUTING.md documents. Please join us on Discourse if you have any questions or need any help. We will be glad to get you started! The next post in this series will help you connect your new provider to Grype itself. Stay tuned! ### Mitigating Three Popular Software Supply Chain Attacks with Anchore Software supply chain attacks are extremely prevalent and a great way for attackers to easily proliferate a single vulnerability across an entire organization to have maximum impact. Thankfully, mitigating these three types of threats is easy by utilizing Anchore’s automated policy enforcement throughout your software supply chain. In this article, I’m going to walk through three types of software supply chain attacks and how Anchore helps in each scenario. Penetrating Source Code Repositories: Exploiting a Known Vulnerability in the Software Supply Chain The first type of attack begins in a source code repository. Attackers aren’t dumb and they don’t like to waste time. This is why advanced persistent threats typically leverage a software package that is known to have an exploited vulnerability that is being actively exploited. Even today, over a year after the log4shell vulnerability there are still recent exploitations that entangled the security industry in a vice grip. Incidents like this can all be mitigated automatically with Anchore’s Known Exploited Vulnerabilities (KEV) policy.  Leveraging Anchore’s policy pack, I am able to scan against all of CISA’s Known Exploited Vulnerabilities. This will allow me to detect KEV’s across my SDLC whether it's in a GitHub repo, image registry, or runtime. What’s more is that Anchore provides a recommendation for remediation that can automatically notify team members  to remove that package from your development process. Registry Poisoning: An Image with Malware appears in a Trusted/Protected Registry This is a popular attack vector. In 2021, the Anchore team saw threat actors use this style of attack to proliferate cryptominers and malicious software across target environments with relative ease. Anchore can detect and prevent these attacks by keeping a watchful eye on customers’ registries, allowing us to continuously monitor that registry for unauthorized pushes of malicious images. Anchore Enterprise 4.4 continuously monitors repositories within a registry Anchore Enterprise 4.4 continuously monitors images and all tags within a registry I’m going to dig in on a very oddly worded PostGres Image that was scanned and automatically triggered a notification about malware in that image. In this example, this attacker combined registry poisoning with typosquatting. Anchore detects the malware in the image and triggers an alert based on that image analysis for my investigation. It’s important to note here that it’s a very unique feature that Anchore provides a malware scan as a part of every SBOM. In an ideal scenario, developers would be following a software supply chain security architecture that would utilize Anchore policy enforcement that scans for malware before it hits the registry. However, as we have seen in many supply chain attacks since, credentials tend to be left on CI servers, in pipelines in plain text, source code repositories, or on a post-it note left at a coffee shop. Hence, this is a good reminder why we should always be continuously monitoring the registry to prevent registry poisoning attacks. Cloud Credential Leak: Credential is Unintentionally Left Behind in a Build Artifact Not all software supply chain attacks are malicious in nature. Some are simple human errors. While the intent isn’t meant to cause havoc, the leaking of a credential (or secret) can still have a lasting impact. Even the most security minded organizations can be hit with an incident of credential leakage.  In March of ‘23 GitHub experienced a very public instance of this supply chain attack. An accidental commit to a public git repository revealed the private key for GitHub’s entire SSH service. This created the opening for an enterprising attacker to set up a fake GitHub service and masquerade as GitHub with full legitimacy. The ultimate deep fake. Fortunately, GitHub caught it quickly and rotated their key out of an abundance of caution. In order to prevent a potential catastrophic incident like that from happening to your organization it is important to scan your entire SDLC for credential and secret leaks. Catching the exposure before it is pushed to a publicly accessible location mitigates a potential sev 0 before it happens. Actively scanning for leaked secrets has the added benefit of helping prevent the previous attack we highlighted from occurring as well. It is difficult to poison a private container registry when the environment is protected with a secret (that hasn’t been leaked). Anchore Enterprise offers the ability to use policies to scan images and discover leaked credentials before they are deployed to production. The policies can be configured to enforce a preset action if the presence of a secret is detected, preventing a security incident from happening before it starts. I hope this article provided insight into the three most popular types of software supply chain attacks and how they happen. Anchore’s technology platform provides the confidence and tools needed for developers and security teams to stay ahead of malicious threats to your software supply chain. If you want to learn more click here to request a demo or watch one of our recent webinars. ### Five Insider Tips to Federal Compliance ### Navigating Continuous Authority To Operate (cATO): A Guide for Getting Started Continuous Authority to Operate (cATO), sometimes known as Rapid ATO, is becoming necessary as the DoD and civilian agencies put more applications and data in the cloud. Speed and agility are becoming increasingly critical to the mission as the government and federal system integrators seek new features and functionalities to support the warfighter and other critical U.S. government priorities. In this blog post, we'll break down the concept of cATO in understandable terms, explain its benefits, explore the myths and realities of cATO and show how Anchore can help your organization meet this standard. Save a Seat What is Continuous Authority To Operate (cATO)? Continuous ATO is the merging of traditional authority to operate (ATO) risk management practices with flexible and responsive DevSecOps practices to improve software security posture. Traditional Risk Management Framework (RMF) implementations focus on obtaining authorization to operate once every three years. The problem with this approach is that security threats aren’t static, they evolve. cATO is the evolution of this framework which requires the continual authorization of software components, such as containers, by building security into the entire development lifecycle using DevSecOps practices. All software development processes need to ensure that the application and its components meet security levels equal to or greater than what an ATO requires. You authorize once and use the software component many times. With a cATO, you gain complete visibility into all assets, software security, and infrastructure as code. By automating security, you are then able to obtain and maintain cATO. There’s no better statement about the current process for obtaining an ATO than this commentary from Mary Lazzeri with Federal Computer Week: “The muddled, bureaucratic process to obtain an ATO and launch an IT system inside government is widely maligned — but beyond that, it has become a pervasive threat to system security. The longer government takes to launch a new-and-improved system, the longer an old and potentially insecure system remains in operation.” The Three Pillars of cATO To achieve cATO, an Authorizing Official (AO) must demonstrate three main competencies: Ongoing visibility: A robust continuous monitoring strategy for RMF controls must be in place, providing insight into key cybersecurity activities within the system boundary. Active cyber defense: Software engineers and developers must be able to respond to cyber threats in real-time or near real-time, going beyond simple scanning and patching to deploy appropriate countermeasures that thwart adversaries. Adoption of an approved DevSecOps reference design: This involves integrating development, security, and operations to close gaps, streamline processes, and ensure a secure software supply chain. Looking to learn more about the DoD DevSecOps Reference Design? It's commonly referred to as 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. Intro to DoD Software Factory Outline for Getting Up to Speed on the DoD Software Factory How Anchore Secures Software Factories Continuous ATO vs. ATO The primary difference between traditional ATOs and continuous ATOs is the frequency at which a system seeks to prove the validity of its security claims. ATOs require that a system can prove its security once every three years whereas cATO systems prove their security every moment that the system is running. The Benefits of Continuous ATO Continuous ATO is essentially the process of applying DevSecOps principles to the compliance framework of Authority to Operate. Automating the individual compliance processes speeds up development work by avoiding repetitive tasks to obtain permission. Next, we’ll explore additional (and sometimes unexpected) benefits of cATO. Increase Velocity of System Deployment CI/CD systems and the DevSecOps design pattern were created to increase the velocity at which new software can be deployed from development to production. On top of that, Continuous ATOs can be more easily scaled to accommodate changes in the system or the addition of new systems, thanks to the automation and flexibility offered by DevSecOps environments. Reduce Time and Complexity to Achieve an ATO With the cATO approach, you can build a system to automate the process of generating the artifacts to achieve ATO rather than manually producing them every three years. This automation in DevSecOps pipelines helps in speeding up the ATO process, as it can generate the artifacts needed for the AO to make a risk determination. This reduces the time spent on manual reviews and approvals. Much of the same information will be requested for each ATO, and there will be many overlapping security controls. Designing the DevSecOps pipeline to produce the unique authorization package for each ATO from the corpus of data and information available can lead to increased efficiency via automation and re-use. No Need to Reinvent AND Maintain the Wheel When you inherit the security properties of the DevSecOps reference design or utilize an approved managed platform, then the provider will shoulder the burden. Someone else has already done the hard work of creating a framework of tools that integrate together to achieve cATO, re-use their effort to achieve cATO for your system.  Alternatively, you can utilize a platform provider, such as Platform One, Kessel Run, Black Pearl, or the Army Software Factory to outsource the infrastructure management. Learn how Anchore helped Platform One achieve cATO and become the preeminent DoD software factory: Download Now Myths & Realities Myth or Reality?: DevSecOps can be at Odds with cATO Myth! DevSecOps in the DoD and civilian government agencies are still the domain of early adopters. The strict security and compliance requirements — the ATO in particular — of the federal government make it a fertile ground for DevSecOps adoption. Government leaders such as Nicolas Chaillan, former chief software officer for the United States Air Force, are championing DevSecOps standards and best practices that the DoD, federal government agencies, and even the commercial sector can use to launch their own DevSecOps initiatives. One goal of DevSecOps is to develop and deploy applications as quickly as possible. An ATO is a bureaucratic morass if you’re not proactive. When you build a DevSecOps toolchain that automates container vulnerability scanning and other areas critical to ATO compliance controls, can you put in the tools, reporting, and processes to test against ATO controls while still in your development environment. DevSecOps, much like DevOps, suffers from a marketing problem as vendors seek to spin the definitions and use cases that best suit their products. The DoD and government agencies need more champions like Chaillan in government service who can speak to the benefits of DevSecOps in a language that government decision-makers can understand. Myth or Reality?: Agencies need to adopt DevSecOps to prepare for the cATO  Reality! One of the cATO requirements is to demonstrate that you are aligned with an Approved DevSecOps Reference Design. The “shift left” story that DevSecOps espouses in vendor marketing literature and sales decks isn’t necessarily one size fits all. Likewise, DoD and federal agency DevSecOps play at a different level.  Using DevSecOps to prepare for a cATO requires upfront analysis and planning with your development and operations teams’ participation. Government program managers need to collaborate closely with their contractor teams to put the processes and tools in place upfront, including container vulnerability scanning and reporting. Break down your Continuous Integration/Continuous Development (CI/CD) toolchain with an eye on how you can prepare your software components for continuous authorization. Myth or Reality?: You need to have SBOMs for everything in your environment Myth! However...you need to be able to show your Authorizing Official (AO) that you have "the ability to conduct active cyber defense in order to respond to cyber threats in real time." If a zero day (like log4j) comes along you need to demonstrate you are equipped to identify the impact on your environment and remediate the issue quickly. Showing your AO that you manage SBOMs and can quickly query them to respond to threats will have you in the clear for this requirement. Myth or Reality?: cATO is about technology and process only Myth! As more elements of the DoD and civilian federal agencies push toward the cATO to support their missions, and a DevSecOps culture takes hold, it’s reasonable to expect that such a culture will influence the cATO process. Central tenets of a DevSecOps culture include: Collaboration Infrastructure as Code (IaC) Automation Monitoring Each of these tenets contributes to the success of a cATO. Collaboration between the government program office, contractor’s project team leadership, third-party assessment organization (3PAO), and FedRAMP program office is at the foundation of a well-run authorization. IAC provides the tools to manage infrastructure such as virtual machines, load balancers, networks, and other infrastructure components using practices similar to how DevOps teams manage software code. Myth or Reality?: Reusable Components Make a Difference in cATO Reality! The growth of containers and other reusable components couldn’t come at a better time as the Department of Defense (DoD) and civilian government agencies push to the cloud driven by federal cloud initiatives and demands from their constituents. Reusable components save time and budget when it comes to authorization because you can authorize once and use the authorized components across multiple projects. Look for more news about reusable components coming out of Platform One and other large-scale government DevSecOps and cloud projects that can help push this development model forward to become part of future government cloud procurements. How Anchore Helps Organizations Implement the Continuous ATO Process Anchore's comprehensive suite of solutions is designed to help federal agencies and federal system integrators meet the three requirements of cATO. Ongoing Visibility Anchore Enterprise can be integrated into a build pipeline, image registry and runtime environment in order to provide a comprehensive view of the entire software development lifecycle (SDLC). On top of this, Anchore provides out-of-the-box policy packs mapped to NIST 800-53 controls for RMF, ensuring a robust continuous monitoring strategy. Real-time notifications alert users when images are out of compliance, helping agencies maintain ongoing visibility into their system's security posture. Active Cyber Defense While Anchore Enterprise is integrated into the decentralized components of the SDLC, it provides a centralized database to track and monitor every component of software in all environments. This centralized datastore enables agencies to quickly triage zero-day vulnerabilities with a single database query. Remediation plans for impacted application teams can be drawn up in hours rather than days or weeks. By setting rules that flag anomalous behavior, such as image drift or blacklisted packages, Anchore supports an active cyber defense strategy for federal systems. Adoption of an Approved DevSecOps Reference Design Anchore aligns with the DoD DevSecOps Reference Design by offering solutions for: Container hardening (Anchore DISA policy pack) Container policy enforcement (Anchore Enterprise policies) Container image selection (Iron Bank) Artifact storage (Anchore image registry integration) Release decision-making (Anchore Kubernetes Admission Controller) Runtime policy monitoring (Anchore Kubernetes Automated Inventory) Anchore is specifically mentioned in the DoD Container Hardening Process Guide, and the Iron Bank relies on Anchore technology to scan and enforce policy that ensures every image in Iron Bank is hardened and secure. Final Thoughts Continuous Authorization To Operate (cATO) is a vital framework for federal system integrators and agencies to maintain a strong security posture in the face of evolving cybersecurity threats. By ensuring ongoing visibility, active cyber defense, and the adoption of an approved DevSecOps reference design, software engineers and developers can effectively protect their systems in real-time. Anchore's comprehensive suite of solutions is specifically designed to help meet the three requirements of cATO, offering a robust, secure, and agile approach to stay ahead of cybersecurity threats.  By partnering with Anchore, federal system integrators and federal agencies can confidently navigate the complexities of cATO and ensure their systems remain secure and compliant in a rapidly changing cyber landscape. If you're interested to learn more about how Anchore can help your organization embed DevSecOps tooling and principles into your software development process, click below to read our white paper. Download Now ### SBOMs on the Road: Thrilling Tales of Software Supply Chain Security ### Open Source is Bigger Than You Can Imagine If we pay attention to the news lately we hear about supply chain security and how it’s the most important topic ever and we need to start doing something right now. But the term “supply chain security” isn’t well defined.  The real challenge we actually have is understanding open source. Open source is in everything now. There is no supply chain problem, there is an understanding open source problem. Log4Shell was our Keyser Söze moment There’s a scene in the movie “The Usual Suspects”, where the detective realizes everything he was just told has been a lie. His entire world changed in an instant. It was a plot twist, not even the audience saw coming. Humans love plot twists and surprises in our stories, but not in real life. Log4Shell was a plot twist but in real life. It was not a fun time. Open source didn’t take over the world overnight. It took decades. It was a silent takeover that only the developers knew about. Until Log4Shell. When Log4Shell happened everyone started looking for Log4j and they found it, everywhere they looked. But while finding Log4j, we also found a lot more open source. And I mean A LOT more. Open source was in everything, both the software acquired from other vendors and the software built in house. Everything from what’s running on our phones to what’s running the toaster. It’s all full of open source software. Now that we know open source is everywhere, we should start to ask what open source really is. It’s not what we’ve been told. There’s often talk of “the community”, but there is no community. Open source is a vast collection of independent projects. Some of these projects are worked on by Fortune 100 companies, some by scrappy startups, and some are just a person in their basement who only can work on their project from 9:15pm to 10:05pm every other Wednesday. And open source is big. We can steal a quote from Douglas Adams’ Hitchhiker’s Guide to the Galaxy to properly capture the magnitude of open source: “Space Open source … is big. Really big. You just won't believe how vastly hugely mind-bogglingly big it is. I mean, you may think it's a long way down the road to the chemist, but that's just peanuts to space open source.” The challenge for something like open source isn’t just claiming it’s big. We all know it’s big. The challenge is showing how mind-bogglingly big it is. Imagine the biggest thing we can, open source is bigger. Let’s do some homework. The size of NPM For the rest of this post we will focus on NPM, the Node Package Manager. NPM is how we would install dependencies for our Node.js applications. The reason this data was picked is it’s very easy to work with, it has good public data, and it’s the largest package ecosystem in the world today. It should be said, NPM isn’t special in the context of the below data, if we compare these graphs to Python’s PyPI for example, we see very similar shapes, just not as large. In the future we may explore other packaging ecosystems, but fundamentally it’s going to look a lot like this. All of this data was generated using the scripts stored in GitHub, the repo is aptly named npm-analysis. Let’s start with the sheer number of NPM package releases over time. It’s a very impressive and beautiful graph. This is an incredible number of packages. At the time of capturing data, there were 32,600,904 packages. There are of course far more now, just look at the growth. By packages, we mean every version of every package released. There are about 2.3 million unique packages, but when we take those packages times all the released versions, we end up with over 32 million. It’s hard to imagine how big this really is. There was a proposal recently that suggested we could try to conduct a security review on 10,000 open source projects per year. This is already a number that would need thousands of people to accomplish. But even at 10,000 projects per year, it would take more than 3,000 years to get through just npm at its current size. Ignoring the fact that we’ve been adding more than 1 million packages per year, so doing some math … we will be done … never, the answer is never. The people As humans, we love to start creating reasons for this sort of growth. Maybe it’s all malicious packages, or spammers using NPM to sell vitamins. “It’s probably big projects publishing lots of little packages”, or “have you ever seen the amount of stuff in the React framework”? It turns out almost all of NPM is single maintainer projects. The graph below shows the number of maintainers for a given project. We see there are more than 18 million releases that list a single maintainer in their package.json file. That’s over half of all NPM releases ever having just one person maintaining them. This graph shows a ridiculous amount of NPM is one person, or a small team. If we look at the graph on a logarithmic scale we can see what the larger projects look like, the linear graph is sort of useless because of the sheer number of one person projects. These graphs contain duplicate entries when it comes to maintainers. There are many maintainers who have more than one project, it’s quite common in fact. If we filter the graph by the number of unique maintainers, we see this chart. It’s a lot less maintainers, but we see the data is still dominated by single maintainer projects. In this data set we see 727,986 unique NPM maintainers. This is an amazing number of developers. This a true testament to the power and reach of open source. New packages Now that we see there are a lot of people doing an enormous amount of work. Let’s talk about how things are growing. We mentioned earlier that more than one million packages and versions are being added per year. If this continues we’re going to be adding more than one million new packages per month soon. Now, it should be noted this graph isn’t new packages, it’s new releases, so if an existing project releases five updates, it shows up in this graph all five times. If we only look at brand new packages being added, we get the below graph. A moving average was used here because this graph is a bit jumpy otherwise. New projects don’t get added very consistently. This shows us we’re adding less than 500,000 new projects per year, which is way better than one million! But still a lot more than 10,000. The downloads We unfortunately don’t have an impressive graph of downloads to show. The most npm data we can get is for one year of download statistics and it’s a single number, it’s not spread out by date. In the last year, there were 130,046,251,733,027 NPM downloads. That feels like a fake number, 15 digits. That’s 130 TRILLION downloads. Now, that’s not spread out very evenly. The median downloads of a package are only 217. The bottom 5% are 71 downloads, and the top 5% are more than 16,000 downloads. It’s pretty clear the number of downloads are very uneven. The most popular projects are getting most of the downloads. Here is a graph of the top 100 projects by downloads. It follows a very common power distribution curve. We probably can’t imagine what this download data over all time must look like. It’s almost certainly even more mind boggling than the current data set. Most of these don’t REALLY matter Nobody would argue if someone said that the vast majority of NPM packages will never see widespread use. Using the download data we can show 95% of NPM packages aren’t widely used. But the sheer scale is what’s important. 5% of NPM is still more than 100,000 unique packages. That’s a massive number, even at our 10,000 packages a year review, that’s more than ten years of work and this is just NPM. If we filter our number of maintainers graph to only include the top 5% of downloaded packages, it basically looks the same, just with smaller numbers Every way we look at this data, these trends seem to hold. Now that we know how incredibly huge this all really is, we can start to talk about this supposed supply chain and what comes next. What we can actually do about this First, don’t panic. Then the most important thing we can do is to understand the problem. Open source is already too big to manage and growing faster than we can keep up. It is important to have realistic expectations. Before now many of us didn’t know how huge NPM was. And that’s just one ecosystem. There is a lot more open source out there in the wild. There’s another quote from Douglas Adams’ Hitchhiker’s Guide to the Galaxy that seems appropriate right now: ‘“I thought,” he said, “that if the world was going to end we were meant to lie down or put a paper bag over our head or something.” “If you like, yes,” said Ford. “Will that help?” asked the barman. “No,” said Ford and gave him a friendly smile.”’ Open source isn’t a force we command, it is a resource for us to use. Open source also isn’t one thing, it’s a collection of individual projects. Open source is more like a natural resource. A recent report from the Atlantic Council titled Avoiding the success trap: Toward policy for open-source software as infrastructure compares open source to water. It’s an apt analogy on many levels, especially when we realize most of the surface of the planet is covered in water. The first step to fixing a problem is understanding it. It’s hard to wrap our heads around just how huge open source is, humans are bad at exponential growth. We can’t have an honest conversation about the challenges of using open source without first understanding how big and fast it really is. The intent of this article isn’t to suggest open source is broken, or bad, or should be avoided. It’s to set the stage to understand what our challenge looks like. The importance and overall size of open source will only grow as we move forward. Trying to use the ideas of the past can’t work at this scale. We need new tools, ideas, and processes to face our new software challenges. There are many people, companies, and organizations working on this but not always with a grasp of the true scale of open source. We can and should help existing projects, but the easiest first step is to understand how big our open source use is. Do we know what open source we’re using? Anchore is working on this problem every day. Come help with our open source projects Syft and Grype, or have a chat with us about our enterprise solution. Josh Bressers Josh Bressers is vice president of security at Anchore where he guides security feature development for the company’s commercial and open source solutions. He serves on the Open Source Security Foundation technical advisory council and is a co-founder of the Global Security Database project, which is a Cloud Security Alliance working group that is defining the future of security vulnerability identifiers. ### Build Your Own Grype Database When running vulnerability scans against your software dependencies it’s important to have the most up to date vulnerability information that’s been published. New vulnerabilities are found all the time, the data goes stale quickly. For current Grype users, we have a daily pipeline that builds and publishes a Grype database with the latest vulnerability data. Up until now the tooling that drives this pipeline has not been available as open source since it was originally designed as an embedded aspect of Anchore's commercial products. Today that’s changing!  How does this help the average Grype user? By making the framework and code that are used to prepare vulnerability data sources open, the entire open source community (even you!) can contribute improvements and new vulnerability data sources, enhancing both the breadth and quality of vulnerability scanning for all. We’re happy to announce two new open source projects: Vunnel and Grype-DB. Vunnel (short for “vulnerability data funnel”) understands how to pull and process vulnerability from various upstream data sources, such as NVD, Github Security Advisories, and multiple Linux distribution providers. This allows you to prepare a data directory with indexed and normalized vulnerability data. This sounds simple, but all of this vulnerability data is different and varies widely in its quality and composition. Vunnel gives us some control to normalize this data in a way that gives better consistency. Grype-DB builds an SQLite database that Grype can use based off of the data that Vunnel outputs. Even more, Grype-DB can invoke Vunnel in order to prepare a data directory for multiple providers, allowing you to orchestrate and tailor which providers you want to include in the database. This puts the entire Grype vulnerability data pipeline and surrounding tooling into the open source! This includes all of the providers that drive Grype today: Alpine, Amazon Linux, Centos, Debian, GitHub Security Advisories, NVD, Oracle Linux, RedHat Enterprise Linux, SUSE Linux Enterprise, Ubuntu, and Wolfi. Anyone can now fully participate in the data processing for the Grype ecosystem, expanding the vulnerability matching capabilities of Grype (for example, adding support for new Linux distributions in Grype).  We’re excited to see what community contributions arise from this effort! Stay tuned for a tutorial to show you how to implement a new Vunnel provider.  If you’d like to learn more feel free to reach out to us on our Discourse forum, drop into our community meetings for live Q&A (every other Thursday), or see the docs: https://github.com/anchore/vunnel https://github.com/anchore/vunnel/blob/main/DEVELOPING.md https://github.com/anchore/grype-db https://github.com/anchore/grype-db/blob/main/DEVELOPING.md ### Syft and Grype Community Momentum Hello open source supply chain security fans! A lot has happened with Syft and Grype in the last couple of months, so I want to share some of the new features and improvements we’ve been working on. If you’re not familiar with Syft and/or Grype, here are the details: both tools are open source, and maintained by Anchore. Syft is our Software Bill of Materials generator. It scans container images and filesystems and makes an inventory of contents including files and software packages. Grype, in turn, takes that information and analyzes it for vulnerabilities from a variety of sources including the GitHub Advisory Database, the National Vulnerability Database, and others. Syft and Grype development happen at a rapid pace and I want to share a couple of recent improvements.  Syft Performance Improvements In Syft 0.71, released early February 2023, we spent some time focusing on improving scanning performance. If you use Syft to scan large, multi-GB images or big directories, you will definitely see some improvement. These improvements are passed through to Grype as well, since Grype uses Syft under the hood to extract the list of packages needing to be analyzed for vulnerabilities. In one of our tests, we saw the time for a scan operation that took six minutes before optimizations only take 23 seconds after. If you scan large images or containers, make sure you are up to date on Syft because you will probably see big improvements. Syft Binary Detection Syft gained new capabilities in version v0.62.3 released in late 2022: this version introduced a way to scan and detect binary packages for common open source components, so we can detect things like embedded copies of Apache HTTP Server or PostgreSQL that might not have been installed using a package manager. Our development community quickly started adding new classifiers for a lot of different open source components, including Python, PHP, Perl, and Go runtimes, Redis, HAProxy, and others. It’s pretty easy to extend the binary detection mechanism for new things, so if you want to learn how to add a new classifier, let us know and we can point you in the right direction. Good First Issues Are you interested in contributing to Syft or Grype? We would be happy to have you. We’ve labeled some issues in GitHub with “Good First Issue” if you want to look for something to start with. If you want to talk about a possible implementation or ask questions to help you get started, you can find the developers on Discourse or join the community meeting once every two weeks on Thursday at noon Eastern Time. Good First Issues for Syft Good First Issues for Grype Developers: smaller binaries and improved build times Finally, we’ve made some changes to the dependencies we are using, which has resulted in significantly smaller binary sizes for both Syft and Grype, along with improvements to our build and release process. We now have the ability to get changes released much faster – from PR to release, the pipeline is less than 30 minutes instead of hours. Thank you to everyone who contributes to and helps our team advance Syft and Grype for the open source community. We're excited about the future of open source software security and hope that you are too. ### Breaking Down NIST SSDF: Spotlight on PW.6 Compilers and Interpreter Security In this part of the long-running series breaking down NIST Secure Software Development Framework (SSDF), also known as the standard NIST 800-218, we are going to discuss PW 6. This control is broken into two parts, PW.6.1 and PW.6.2. These two controls are related and defined as: PW.6.1: Use compiler, interpreter, and build tools that offer features to improve executable security. PW.6.2: Determine which compiler, interpreter, and build tool features should be used and how each should be configured, then implement and use the approved configurations. We’re going to lump both of these together for the purpose of this post. It doesn’t make sense to split these two controls apart when we are reviewing what this actually means, but there will be two posts for PW.6, this is part one. Let’s start by looking at the examples for some hints on what the standard is looking for: PW.6.1 Example 1: Use up-to-date versions of compiler, interpreter, and build tools. Example 2: Follow change management processes when deploying or updating compiler, interpreter, and build tools, and audit all unexpected changes to tools. Example 3: Regularly validate the authenticity and integrity of compiler, interpreter, and build tools. See PO.3. PW.6.2 Example 1: Enable compiler features that produce warnings for poorly secured code during the compilation process. Example 2: Implement the “clean build” concept, where all compiler warnings are treated as errors and eliminated except those determined to be false positives or irrelevant. Example 3: Perform all builds in a dedicated, highly controlled build environment. Example 4: Enable compiler features that randomize or obfuscate execution characteristics, such as memory location usage, that would otherwise be predictable and thus potentially exploitable. Example 5: Test to ensure that the features are working as expected and are not inadvertently causing any operational issues or other problems. Example 6: Continuously verify that the approved configurations are being used. Example 7: Make the approved tool configurations available as configuration-as-code so developers can readily use them. If we review the references, you will find there’s a massive swath of suggestions. Everything from code signing to obfuscating binaries, to handling compiler warnings, to threat modeling. The net was cast wide on this one. Every environment is different. Every project or product uses its own technology. There’s no way to “one size fits all” this control. This is one of the challenges that has made compliance for developers so very difficult in the past. We have to determine how this applies to our environment, and the way we apply this finding will be drastically different than the way someone else applies it. We’re going to split this topic along the lines of build environments and compiler/interpreter security. For this blog, we are going to focus on using modern protection technology, specifically in compiler security and runtimes. Of course, you will have to review the guidance and understand what makes sense for your environment, everything we discuss here is for example purposes only. Compiler security When we think about the security of applications, we tend to focus on the code itself. Security vulnerabilities are the result of attackers causing unexpected behavior in the code. Printing an unescaped string, adding or subtracting a very large integer. Maybe even getting the application to open a file it shouldn’t. We’ve all heard about memory safety problems and how hard they are to avoid in certain languages. C and C++ are legendary for their lack of memory protection. Our intent should be to write code that doesn’t have security vulnerabilities. The NSA and even Consumer Reports have recently come out against using memory unsafe languages. We can also lean on technology to help reduce the severity of memory safety bugs when we can’t abandon memory unsafe languages just yet, maybe never. There’s still a lot of COBOL out there, after all. While attackers can exploit some bugs in ways that cause unexpected behavior, there are technologies, especially in compilers, that can lower the severity or even eliminate the danger of certain bug classes. For example, stack buffer overflows in C used to be a huge problem, then we created stack canaries which has reduced the severity of these bugs substantially. Every compiler is different, every operating system is different, and every application is different, so all of this has to be decided for each individual application. For the purposes of simplicity, we will use gcc to show how some of these technologies work and how to enable them. The Debian Wiki Hardening page has a huge amount of detail, we’ll just cover some of the quick easy things. user@debian:~/test$ user@debian:~/test$ gcc -o overflow test-overflow.c root@debian:~/test$ ./overflow Segmentation fault user@debian:~/test$ gcc -fstack-protector -o overflow test-overflow.c user@debian:~/test$ ./overflow *** stack smashing detected ***: terminated Aborted user@debian:~/test$ In the above example, we can see how the compiler can issue a warning instead of crashing if we enable the gcc stack protector feature. Most of these protections will only reduce the severity of a very narrow group of bugs. These languages still have many other problems and moving away from a memory unsafe language is the best path forward. Not everyone can move to a memory safe language, so compiler flags can help. Compiler warnings are bugs There was once a time when compiler warnings were ignored because they were just warnings. It didn’t really matter, or so we thought. Compiler warnings were just suggestions from the compiler, if there’s time later those warnings can be fixed. Except there is never time later. It turns out that sometimes those warnings are really important. They can be hints that a serious bug is waiting to be exploited. It’s hard to know which warnings are harmless and which are serious, so the current best practice is to fix them all to minimize vulnerabilities in your code. If we use our example code, we can see: user@debian:~/test$ user@debian:~/test$ gcc -o overflow test-overflow.c test-overflow.c: In function 'function': test-overflow.c:6:2: warning: '__builtin_memcpy' writing 24 bytes into a region of size 9 overflows the destination [-Wstringop-overflow=] 6 | strcpy(s, "This string is too long"); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ user@debian:~/test$ We see a warning telling us our string is too long. The build doesn’t fail, but that’s not a warning you should ignore. Interpreted languages The suggestion in the SSDF is for interpreted languages is to use the latest interpreter. These languages are memory safe, but they are still vulnerable to logic bugs. Many of the interpreters are written in C or C++, so you could double check they are built with the various compiler hardening features enabled. There aren’t often protections built into the interpreter itself. This goes back to the wide swath of guidance for this control. Programming languages have an infinite number of possible use cases, the problem set is too large to accurately protect. Memory safety is a very narrow set of problems that we still can’t get right. General purpose programming is an infinitely wide set of problems. There were some attempts to secure interpreted languages in the past, but the hardening proved to be too easy to break to rely on as a security feature. PHP and Ruby used to have safe mode, but it turned out they weren’t actually safe. Compiler and interpreter protections are hard to make effective in meaningful ways. The best way to secure interpreted languages is to run code in sandboxes using things like virtualization and containers. Such guidance won’t be covered in this post. In fact SSDF doesn’t have guidance on how to run applications securely, SSDF focuses on development. There is plenty of other guidance on that, we’ll make sure to cover those once the SSDF series is complete. This complexity and difficulty are almost certainly why the SSDF guidance is to just run the latest interpreter. The latest interpreter version will ensure any bugs, security or otherwise are fixed. Wrapping up As we can see from this post, optimizing compiler and runtime security isn’t a simple task. It’s one of those things can can feel easy, but it’s really not. The devil is in the details. The only real guidance here is to figure out what works best in your environment and go with that. If you missed the first post in this series, you can view it here. Next time we will discuss build systems. Build systems have been a popular topic over the last few years as they have been targets for attackers. Luckily for us there is some solid guidance we can draw upon for securing a build system. Josh Bressers Josh Bressers is vice president of security at Anchore where he guides security feature development for the company’s commercial and open source solutions. He serves on the Open Source Security Foundation technical advisory council and is a co-founder of the Global Security Database project, which is a Cloud Security Alliance working group that is defining the future of security vulnerability identifiers. ### Practical Advice: How to Manage Federal Cybersecurity Requirements ### Anchore Adds Support for NIST 800-218 SSDF This blog post has been archived and replaced by the supporting pillar page that can be found here: https://anchore.com/wp-admin/post.php?post=987473414&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. ### Finding and Fixing the jsonwebtoken Vulnerabilities There’s a new vulnerability in the Node.js jsonwebtoken library getting attention. CVE-2022-23529, or GHSA-27h2-hvpr-p74q are the identifiers this vulnerability has been assigned. It’s not just one thing though, there were four fixes to jsonwebtoken version 9.0.0. For now we’re going to focus on CVE-2022-23529 which is getting the most attention due to a high CVSS score. There’s added complexity around the score as NVD scores it a 9.8 (critical), the researcher that found it scored it a 7.6 (high), and the GHSA advisory rates it medium.  Note: How you use the library actually determines your severity, it’s unlikely most users of this library will be vulnerable, the vulnerability only affects unique uses.  The jsonwebtoken library is a Node.js library for working with JSON Web Tokens, or JWT. JWT is used as a way to authenticate web services. This library is downloaded more than 9 million times per week, which is a pretty substantial number. It’s easy to say this is a well used library. Whenever there’s an issue like what we’re seeing in the jsonwebtoken library, there’s questions about how to actually find and fix it. A lot of articles and advisories will say “just upgrade the package”, but that’s meaningless advice. How do we know if we’re using jsonwebtoken? How do we know if we’re using a vulnerable version? And how do we actually upgrade it? Let’s go over all of these questions, and we will use a Software Bill of Materials (SBOM) as our vehicle for helping  First we have to find jsonwebtoken in our projects and products. We’re going to use Syft and a very simple example for this. We start out in a directory named “jwt”, then we will create a directory called “project”, install jsonwebtoken version 8.5.0 in it, and generate an SBOM with Syft. ➜  jwt$ mkdir project ➜  jwt$ cd project ➜  project$ npm install jsonwebtoken@8.5.0 added 15 packages, and audited 16 packages in 629ms ➜  project$ cd .. ➜  jwt$ syft dir:project -o json > sbom.json  ✔ Indexed project r] Cataloged packages [15 packages] ➜  jwt$ We can see jsonwebtoken version 8.5.0 is installed if we look at the SBOM file ➜ jwt$ cat sbom.json | jq '.artifacts[] | select(.name == "jsonwebtoken")' { "id": "94476b6a2fbdc8c5", "name": "jsonwebtoken", "version": "8.5.0", "type": "npm", "foundBy": "javascript-lock-cataloger", "locations": [ { "path": "/path/to/project/package-lock.json" } ], "licenses": [], "language": "javascript", "cpes": [ "cpe:2.3:a:jsonwebtoken:jsonwebtoken:8.5.0:*:*:*:*:*:*:*", "cpe:2.3:a:*:jsonwebtoken:8.5.0:*:*:*:*:*:*:*" ], "purl": "pkg:npm/jsonwebtoken@8.5.0" } ➜ jwt$ We could create an SBOM for all of our projects and look through them for versions of jswonwebtoken that are older than 9.0.0, but that can be a chore, especially if you have a lot of projects. It’s far easier to rely on a vulnerability scanner such as Grype to scan projects and report back the findings. Here’s what we get if we scan our project with Grype ➜  jwt$  ls project  sbom.json ➜  jwt$ grype sbom:sbom.json  ✔ Vulnerability DB    [no update available]  ✔ Scanned image       [4 vulnerabilities] NAME      INSTALLED  FIXED-IN  TYPE  VULNERABILITY    SEVERITY jsonwebtoken  8.5.0  9.0.0 npm   GHSA-27h2-hvpr-p74q  High jsonwebtoken  8.5.0  9.0.0 npm   GHSA-8cf7-32gw-wr33  Medium jsonwebtoken  8.5.0  9.0.0 npm   GHSA-hjrf-2m68-5959  Medium jsonwebtoken  8.5.0  9.0.0 npm   GHSA-qwph-4952-7xr6  Medium ➜  jwt$ Remember back when I said there are four vulnerabilities? Now we can see all four with a scan like this. Grype would also report other findings if they existed in our application. We use Grype to scan the SBOM in our above example. Grype can directly scan a directory, but we’re not using a directory scan. SBOMs scan faster and give us a nice point-in-time snapshot of what packages are installed. Now that we know we have jsonwebtoken, and we know we have a vulnerable version, how can we upgrade the package? We know we have to move to version 9.0.0 and we have version 8 installed. There have been some breaking changes. You can see those in the changelog document. For the purpose of simplicity we will ignore possible breaking changes. We can run `npm update` to upgrade our jsonwebtoken package ➜  project$ npm update changed 1 package, and audited 16 packages in 4s ➜  project$ cd .. ➜  jwt$ syft dir:project -o json > upgraded-sbom.json  ✔ Indexed project  ✔ Cataloged packages      [15 packages] ➜  jwt$ grype sbom:upgraded-sbom.json  ✔ Vulnerability DB        [no update available]  ✔ Scanned image           [4 vulnerabilities] NAME          INSTALLED  FIXED-IN  TYPE  VULNERABILITY        SEVERITY jsonwebtoken  8.5.1      9.0.0     npm   GHSA-27h2-hvpr-p74q  High jsonwebtoken  8.5.1      9.0.0     npm   GHSA-8cf7-32gw-wr33  Medium jsonwebtoken  8.5.1      9.0.0     npm   GHSA-hjrf-2m68-5959  Medium jsonwebtoken  8.5.1      9.0.0     npm   GHSA-qwph-4952-7xr6  Medium ➜  jwt$ Notice if we just run `npm update` we end up at version 8.5.1 instead of 9. This is because of those breaking changes. You have to run ‘npm install jsonwebtoken@9.0.0` to update to the version we want. ➜  project$ npm install jsonwebtoken@9.0.0 added 3 packages, removed 7 packages, changed 2 packages, and audited 12 packages in 5s ➜  project$ cd .. ➜  jwt$ syft dir:project -o json > 9.0-sbom.json  ✔ Indexed project  ✔ Cataloged packages      [11 packages] ➜  jwt$ grype sbom:9.0-sbom.json  ✔ Vulnerability DB        [no update available]  ✔ Scanned image           [0 vulnerabilities] No vulnerabilities found ➜  jwt$ Our package is updated and no vulnerabilities are found! In the real world it’s rarely this simple. Most modern applications are large and often have library versions that can’t be easily upgraded. For our oversimple example however, this is the output we expect. This may be a simple contrived example, but the fundamental concept applies to any package and vulnerability. We can use tools like Syft and Grype to know what we have, what vulnerabilities affect our project, then we can verify we upgraded everything correctly. I hope this deep dive into the example scenario provides the groundwork to help you confidently approach the jsonwebtoken vulnerability to keep your organization safe from susceptible libraries.  Josh Bressers Josh Bressers is vice president of security at Anchore where he guides security feature development for the company’s commercial and open source solutions. He serves on the Open Source Security Foundation technical advisory council and is a co-founder of the Global Security Database project, which is a Cloud Security Alliance working group that is defining the future of security vulnerability identifiers. ### Why is this massive supply chain attack being ignored? If you read security news, you may have heard about a recent attack that resulted in 144,000, that’s one hundred and forty four THOUSAND packages being uploaded to NuGet, PyPI, and NPM. That’s a mind boggling number, it seems like with all the supply chain news it would be all anyone is talking about. Except it seems to have flared up quickly then died right down. The discovery of this attack was made by Checkmarx. Essentially what happened was attackers created a number of accounts in the NuGet, PyPI, and NPM packaging ecosystems. Those fake accounts then uploaded a huge number of packages that linked to phishing sites in the package description. The intention seems to have been to improve search ranking of those sites as well as track users that enter sensitive details. Supply chain security is an overused term This concept called “supply chain security” is a term that  is very overused these days. What we tend to call software supply chain security is many other things that are sometimes hard to describe. Reproducible builds, attestation, source code control, slim containers are a few examples. An attack like this can’t be solved with the current toolset we have which is almost certainly why it’s not getting the attention it deserves. It’s easy to talk about something an exciting project or startup can help with. It’s much harder to understand and fix systemic problems. Why this one is different To understand why this is so different and hard, let’s break this problem down into its pieces. The first part of the attack is the packaging ecosystems. The accounts in question were valid, they weren’t hacked or trying to impersonate someone else. The various packaging ecosystems have low barriers to entry, this is why we all use them and why they are so incredible. In these packaging ecosystems we see new accounts and packages all the time. In fact there are thousands of new packages added every day. There’s nothing unexpected if an attacker creates many accounts, no alarm bells would be expected. Once an account exists, it can start adding packages. The second piece of this attack is someone has to download the package in question. It should be pointed out that in this particular instance the actual package content isn’t malicious, but it’s safe to say nobody wants any of these packages in their application. The volume of bad packages are important for this part of the attack. Developers will accidentally typo package names, or they might stumble on a package thinking it solves whatever their problem is. Or they might just have bad luck and install something by accident. Again, this is working within the constraints of the system. So far nothing happening is outside of everyday operations. Then the last part of this attack is how it gets cleaned up. The packaging ecosystems have stellar security teams working behind the scenes. As soon as they find a bad package it gets delisted. It’s rare for these malicious packages to last more than a few days once they are discovered. Quickly removing packages is the best course of action. But again, the existing supply chain security solutions won't pick up any of these happenings at this time. When a package is delisted, it just vanishes. How do you know if any of the packages you already installed are a problem? What if your artifact registry just cached a malicious package? It can be difficult to understand if you have a malicious package installed. How should this work? How we detect these problems is where things start to get really hard. There will be calls for the packaging ecosystems to lock down their environments, that’s probably a bad idea. The power of open source is how fast and easy it is to collaborate. Putting up walls won’t solve this, it just moves the problem somewhere else, often in a way that hides the real issues. We have existing databases that track vulnerabilities and bad packages, but they can’t handle this scale today. There are examples of malicious packages listed in OSV and GitHub’s vulnerability database. Other databases like CVE have explicitly stated they don’t want to track this sort of malware. Just knowing where to look and how to catalog these malicious packages isn’t simple, yet it’s an ongoing problem. There have been several instances of malicious packages just this year. To understand the scale of this data, the CVE project has existed since 1999 and there are about 200,000 IDs total at the end of 2022. Adding 144,000 new IDs would be significant. At the end of the day, the vulnerability databases are where this data needs to exist. Creating a new way to track malicious packages and expecting everyone to watch it just creates new problems. We are good at finding and fixing vulnerabilities in our software, this is fundamentally the same problem. Malicious packages are no different than vulnerabilities. We also need to keep in mind this will continue to happen. There are a huge number of tools that exist and parse vulnerability databases, then alert developers. Alerting developers is exactly what these datasets and tools were built for, but none of them are picking up this type of supply chain problem today. If we add this data to the existing data all the pieces can fall into place with minimal disruption. What can we do right now? A knee jerk reaction to an event like this is to create constraints on developers in an attempt to only use trusted packages. While that can work, it’s always important to remember that when you create constraints for a person, they become more creative. Using curated open source repositories will need ongoing maintenance. If you just make pulling new packages harder without the ability to quickly add new packages, the developers will find another way. At the moment there’s no good solution for detecting these packages. The best option is to generate a software bill of materials (SBOM) for all of your software, then look for the list of known bad packages against what’s in the SBOMs. In this particular case even if you have one of these packages in your environment, it will be harmless. But the purpose of this post is to explain the problem so the community can have informed conversations. This is about starting to work together to solve hard problems. In the future we need to see lists of these known malicious packages cataloged somewhere. It’s boring and difficult work though, so it’s unlikely to get much attention. This is the equivalent of buried utilities that let modern society function. Extremely important, but not something that turns many heads unless it goes terribly wrong. There’s no way any one group can solve this problem. We will need a community effort. Everyone from the packaging ecosystems, to the vulnerability databases, to the tool manufacturers, and even the security researchers all need to be on the same page. There are efforts underway to help with this. OSV and GitHub allow community contributions. The OpenSSF has a Securing Software Repos working group. The Cloud Security Alliance has the Global Security Database. These are some of the places to find or generate productive and collaborative conversations that can drive progress that hinders use of malicious packages in the software supply chain. Josh Bressers Josh Bressers is vice president of security at Anchore where he guides security feature development for the company’s commercial and open source solutions. He serves on the Open Source Security Foundation technical advisory council and is a co-founder of the Global Security Database project, which is a Cloud Security Alliance working group that is defining the future of security vulnerability identifiers. ### Breaking Down NIST SSDF: Spotlight on PS.3.2 This is the second post in a long running series to explain the details of the NIST Secure Software Development Framework (SSDF), also known as the standard NIST 800-218. You can find more details about the SSDF on the NIST website. Today we’re going to cover control PS.3.2 which is defined as PS.3.2: Collect, safeguard, maintain, and share provenance data for all components of each software release (e.g., in a software bill of materials [SBOM]). This one sounds really simple, we just need an SBOM, right? But nothing is ever that easy, especially in the world of cybersecurity compliance. Let’s break this down into multiple parts. Nearly every word in this framework is important for a different reason. The short explanation is we need data that describes our software release. Then we need to safely store that data. It sounds simple, but like many things in our modern world of technology, the devil is in the details. Start with the SBOM Let’s start with an SBOM. Yes, you need an SBOM. That’s the provenance data. There are many ways to store release data, but the current expectation across the industry is that SBOMs will be the primary document. The intent is we have the ability to receive and give out SBOMs. For the rest of this post we will put a focus on how to meet this control using an SBOM and SBOM management. It doesn’t matter how fast or slow the release process is, every time you ship or deploy software, you need an SBOM. For most of us the days of putting out a release every few years are long gone, almost everyone is releasing software at a breakneck pace. Humans cannot be a part of this process, because humans are slow and make mistakes. To solve the challenge of SBOM automation, we need, well, automation. SBOMs should be generated automatically during stages of the development process. There are many different ways to accomplish this, here at Anchore we’re pretty partial to the Syft SBOM generator. We will be using Syft in our examples,  but there are many ways to create this data. Breaking it Down Creating an SBOM is the easiest step of meeting this control. If we have a container we need an SBOM for, let’s use the Grype container for our example. It can be as easy as running syft -o spdx-json anchore/grype:latest and we have an SBOM of the Grype container image in the SPDX format. In this example we generated an SBOM from a container in the Docker registry, but there’s no reason to wait for a container to be pushed to the registry to generate an SBOM. You can add Syft into the build process. For  example, you can see a Syft GitHub action that does this step  automatically on every build. There are even ways to include the SBOM in the registry metadata now. Once we have our SBOMs generated, keep in mind the ‘s’ is important, you are going to have a lot of SBOMs. Some applications will have one, some will have multiple. For example if you ship three container images for the application you will end up with at least three SBOMs. This is why the word “collect” exists in the control. Collecting all the SBOMs for a release is important. Collecting really just means making sure you can find the SBOMs that were automatically generated. In our case, we would collect and store the SBOMs in Anchore Enterprise. It’s a tool that does a great job of keeping track of a lot of SBOMs. More details can be found on the Anchore Enterprise website. Protect the Data Integrity After the SBOMs are collected, we have to safeguard the SBOMs contents. The word safeguard isn’t very clear. One of the examples states “​​Example 3: Protect the integrity of provenance data, and provide a way for recipients to verify provenance data integrity.” This seems pretty straightforward. It would be dishonest to make the claim “just sign the SBOM and you’re done” because digital signatures are still hard. It’s probably best to use whatever mechanisms you use to safeguard your application artifacts to also safeguard the SBOM. This could be digital signatures. It could be a read only bucket storage over HTTPS. It could be checksum data available out of band. Maybe just a system that provides audit logs of when data changes. There’s no single way to do this and unfortunately there’s no good advice that can be handed out for this step. Be wary of anyone claiming this is a solved problem today. The smart folks working on Syft have some ideas on how to deal with this. We also are expected to maintain the SBOMs we are now collecting and safeguarding. This one seems easy as in theory an SBOM is a static document. I think one could interpret this in several ways. NIST has a glossary, it doesn’t define maintain, but does define maintenance as “Any act that either prevents the failure or malfunction of equipment or restores its operating capability.” It’s safe to say the intent of this is to make sure the SBOMs are available now and into perpetuity. In a fast moving industry it’s easy to forget that in two or more years from now the data in an SBOM could be needed by customers, auditors, or even forensic investigators. But on the other side of that coin, it’s just as possible that in a few years what passes as an SBOM today won’t be considered an SBOM. Maintaining SBOMs should not be disregarded as unimportant or simple. You should find an SBOM management system that can store and convert SBOM formats as a way to future proof the documents. There are new products coming to market that can help with this maintain stage. They are being touted as SBOM management platforms. Anchore Enterprise is a product that does this. There are also open source alternatives such as Dependency Track. There will no doubt be even more of these tools into the future as SBOM use increases and the market matures. Lastly, and possibly most importantly, we have to share the SBOMs. One aspect of SBOMs that keeps coming up is an idea that every SBOM needs to be available to the public. This is specifically covered by CISA in their SBOM FAQ. It comes up on a pretty regular basis and is a point of confusion. You get to decide who can access an SBOM. You can only distribute an SBOM to your customers, you can distribute them to the public, you can keep them internal only. Today there isn’t a well defined way to distribute SBOM data. Many ecosystems have their own ways of including SBOM data. For example in the world of containers, registries are putting them in metadata. Even GoReleaser lets you create SBOMs. Depending how your product or service is accessed, there may not be a simple answer to this question. One solution could be having customers email support asking for a specific SBOM. Maybe you have the SBOM available in the same place customers download your application or login to your service. You can even just package the SBOM up into the application, like a file in a zip archive. Once again, the guidance does not specifically tell us how to accomplish this. Pro Tip: Make sure you include instructions for anyone downloading the SBOM how to verify the integrity of your application and your SBOM. PS3.1 talks about how to secure the integrity of your application and we’ll cover that in a future blog post. Final Thoughts This is one control out of 42. It’s important to remember this is a journey, it’s not a one and done sort of event. We have many more blog posts to share on this topic, and a lot of SBOMs to  generate. Like any epic journey, there’s not one right way to get to the destination.  Everyone has to figure out how they want to meet each NIST SSDF control, ideally in a way that is valuable to the organization as well as customers. Processes that create unnecessary burden will always end up worked around, and processes integrated into existing workflows are far less cumbersome. Let’s aim high and produce verifiable components that not only meet NIST compliance, but also ease the process for downstream consumers. To sum it all up, you need to create SBOMs for every release, safeguard them the same way you safeguard your application, store them in a future proof manner, and be able to share the SBOMs. There’s no one way to do any of this, if you have any questions subscribe to our newsletter for monthly updates on software supply chain security insights and trends. Josh Bressers Josh Bressers is vice president of security at Anchore where he guides security feature development for the company’s commercial and open source solutions. He serves on the Open Source Security Foundation technical advisory council and is a co-founder of the Global Security Database project, which is a Cloud Security Alliance working group that is defining the future of security vulnerability identifiers. ### Ask Me Anything: SBOMs and the Executive Order The software supply chain is under intense pressure and scrutiny with the rise of malicious attacks that target open source software and components. Over the past year the industry has received guidance from the government with the Executive Order on Improving the Nation’s Cybersecurity and the most recent M-22-18 Enhancing the Security of the Software Supply Chain through Secure Software Development Practices. Now, perhaps more than ever before, it’s critical to have a firm understanding of the integrity of your software supply chain to ensure a strong security posture. This webinar will provide you with open access to a panel of Anchore experts who can discuss the role of a software bill of material (SBOM) and answer questions about how to understand and tackle government software supply chain requirements. ### Meet Quill: A cross platform code signing tool for macOS We generate a lot of tooling at Anchore. We chose to write most of these tools in Go for a few reasons: the development process is delightful, cross-platform builds are easy, and the distribution of artifacts is very simple (curl the binary).  Since we target releasing tools for macOS we are beholden to the requirements put forth by Apple, something we’ve written about at length in the past. Tools like gon have made the process of signing and notarizing our releases much easier by wrapping xcrun and codesign utilities and hiding some of the inherent complexities. However, since gon shells out to these tools you still must be on a mac to sign and notarize your binaries. This nullifies one of the reasons why we chose Go in the first place: having simple cross-platform builds from any platform.  We’ve reworked our release process a few times over to account for this, all with unpleasant tradeoffs. It seems to come down to a couple of points: Running macOS in CI is more expensive than running on linux. Using Docker on macOS in CI is annoying. Due to licensing restrictions Docker is not included on the default mac runners. This is problematic since we use goreleaser to perform the build and release steps in one shot, which means we need to be able to sign/notarize our binaries at the same time as we package and release them for all platforms. This has only very recently been alleviated with the addition of colima on the default mac runner, but before this it has caused us to slice-and-dice up our release pipeline in awkward ways. After a while we started to wonder to ourselves: Is it intrinsically necessary to require the signing and notarization steps to run on a mac? The more we looked the more we were certain the answer was “no”. What’s in a signed binary anyway? When you run codesign to sign your binary a new payload is added at the end of the binary with (usually) the following sections: A Code Directory: essentially a table of hashes. Each hash is a digest of each page in the binary before the new payload. The code directory is “what” gets signed. A PKCS7 (CMS) envelope: contains the cryptographic signature made against the Code Directory. A Set of Requirements (optional): expressions that are evaluated against the signature that should hold true. “Designated Requirements” are a special set of requirements that describe how to determine the identity of the code being signed. A Set of Entitlements (optional): a list of key-value pairs in XML that represent privileges an executable can request, e.g. com.apple.developer.avfoundation.multitasking-camera-access=true request for camera access while running alongside another foreground app. There is nothing inherent about any of these payload elements that require the signing process to run on a mac. What about notarization? What’s involved to get your binary notarized by Apple? This is an easier answer: Put your binary in a zip Upload the zip to Apple via their Notarization API Poll their Notarization API until there is a result It seems that the only reason why we are signing and notarizing our releases on macOS is because Apple does not yet provide cross-platform tooling to do so… Introducing Quill We created a new tool called Quill to sign and notarize your macOS binary from any platform.  This works quite well with goreleaser as a post-build step: In this way you can use a single goreleaser file for local builds and production builds: Signing and notarization are performed for production builds. Ad-hoc signing is done for snapshot builds (notarization is skipped). This means that no cryptographic material is needed as input, so the Code Directory is added to the binary but there is no signature attached. You can additionally use Quill to: View your previous notarization submissions with "quill submission list" Get the logs from Apple about the details of a submission result with "quill submission logs " Parse and describe a macOS binary (including all signing details) with "quill describe ./path/to/binary" We are now using quill for our production releases of Syft and Grype and have room to implement more features in the future to expand the capabilities of quill to match that of codesign. Quill is an open source project -- we would love feedback, bug reports, and pull requests! ### Measuring Vulnerability Scanner Quality with Grype and Yardstick Introducing Yardstick As we build Grype, our open source container vulnerability scanner, we are constantly thinking about the quality of our results and how to improve them. We have developed a number of methods to measure our results at development time, so that our scanner doesn’t regress as we change our scanning logic and how we parse sources of external data. We’ve incorporated some of these methods into a new tool: Yardstick, which inspects and compares the results of vulnerability scans between different scanner versions. The most important thing for any vulnerability scanning software is the quality of its results. How do you measure the quality of vulnerability scan data? How do you know if your scanner quality is improving or declining? What impact do code changes have on the quality of your results? How about new or updated sources of external data? Can we incorporate these and prove that the scanner results will get better? Yardstick aims to answer these questions by characterizing matching performance quantitatively. Vulnerability Scan Quality A basic approach to measuring the quality of a vulnerability scan over time might be to simply compare the results from one version to another, for the same container image. But this will only tell us if the results changed, not whether they got better or worse without manually looking at all of the results. There are a number of factors that could change the results of a scan: Code changes in the scanner itself New vulnerabilities added to upstream data sources Existing vulnerabilities might be changed or removed from upstream data sources The artifacts being scanned might have changed in some way, or our understanding of the contents of those artifacts might change because of changes to Syft (our SBOM generator, which Grype uses to analyze the contents of artifacts being scanned.) To move beyond simple result change detection we’ve hand-curated a set of ever-growing examples of labeled data from real container images. These “labels'' are used as ground truth to compare against vulnerability results. We use the F1 score (a combination of True Positive, False Positive, and False Negative counts) and a few simple rules to make up Grype’s quality gate. Get more technical information on our scoring. Positives and Negatives For the most accurate results, we want to maximize “True Positives” while minimizing “False Negatives” and “False Positives”: True Positive: A vulnerability that the scanner correctly identifies. (good!) False Positive: A vulnerability that was reported but should not have been. (bad, but not as bad as a false negative.) False Negative: A vulnerability that the scanner should have reported, but didn’t. (bad!) We have integrated Yardstick into our test and build infrastructure to compare the scan results from different versions of Grype, so that we can identify regressions in our vulnerability matching techniques. We also integrate a lot of external data from various sources, and our goal is to open the process by which the Grype vulnerability database is populated so that our community can add additional sources of data. All of this means that we need robust and comprehensive tools to ensure that our quality stays high. Right now, Yardstick only has a driver for Grype, but it is extensible, so it’s possible to add support for other vulnerability matchers. We would be happy to see pull requests from the community to improve Yardstick’s capabilities, and we’d be happy to hear if Yardstick is useful when you use a vulnerability scanning tool. What does it look like? Here are some screenshots and an animation to show you what Yardstick looks like in operation: Want to try it out? You can find instructions in our GitHub repository, and please feel free to visit our Discourse forum to ask questions and chat with our developers and security experts. Frequently Asked Questions: Q: Why didn’t you call it “Meterstick”? A: In 1793, a ship sailing from Paris to America carrying objects to be used as references for a standard kilogram and meter was thrown off course by a storm, washed up in the Caribbean, and raided by British pirates who stole the objects. By the time a second ship with new reference pieces set sail, the United States had already decided to use the Imperial system of measurement. So, we have Yardstick. (source) Q: If I just want to scan my containers for vulnerabilities, do I need to use Yardstick? A: No, Yardstick is intended more as a tool for developers of vulnerability scanners. If you just want to scan your own images, you should just use Grype. If you want to participate in the development of Grype, you might want to explore Yardstick. Q: Can Yardstick compare the quality of SBOMs (Software Bill of Materials)? A: Not yet, but we have designed the tool with this goal in mind. If you’re interested in working on it, chat with us! PR’s appreciated! Q: Can Yardstick process results from other vulnerabilities besides Grype? A: Not yet, but PRs accepted! ### Anchore Enterprise and the new OpenSSL vulnerabilities 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. ### Detecting binary artifacts with Syft Actions speak louder than words 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. ### An Introduction to the Secure Software Development Framework It’s very likely you’ve heard of a new software supply chain memo from the US White House that came out in September 2022. The content of the memo has been discussed at length by others. The actual memo is quite short and easy to read, you wouldn’t regret just reading it yourself. The very quick summary of this document is that everyone working with the US Government will need to start following NIST 800-218, also known as the NIST Secure Software Development Framework, or SSDF. This is a good opportunity to talk about how we can start to do something with SSDF today. For the rest of this post we’re going to review the actual SSDF standard and start creating a plan of tackling what’s in it. The memo isn’t the interesting part, SSDF is. This is going to be the first of many, many blog posts as there’s a lot to cover in the SSDF. Some of the controls are dealt with by policy. Some are configuration management, some are even software architecting. Depending on each control, there will be many different ways to meet the requirements. No one way is right, but there are solutions that are easier than others. This series will put extra emphasis on the portions of SSDF that deal with software bill of materials (SBOM) specifically, but we are not going to ignore the other parts. An Introduction to the Secure Software Development Framework (SSDF) If this is your first time trying to comply with a NIST standard, keep in mind this will be a marathon. Nobody starts following the entire compliance standard on day one. Make sure to set expectations with yourself and your organization appropriately. Complying with a standard will often take months. There’s also no end state, these standards need to be thought about as continuous projects, not one and done. If you’re looking to start this journey I would suggest you download a spreadsheet NIST has put together that details the controls and standards for SSDF. It looks a little scary the first time you load it up, but it's really not that bad. There are 42 controls. That’s actually a REALLY small number as far as NIST standards go. Usually you will see hundreds or even thousands. An Overview of the NIST SSDF Spreadsheet There are 4 columns: Practices, Tasks, Notional Implementation Examples, References If we break it down further we see there are 19 practices and 42 Tasks. While this all can be intimidating, we can work with 19 practices and 42 tasks. The practices are the logical groupings of tasks, and the tasks are the actual controls we have to meet. The SSDF document covers all this in greater detail, but the spreadsheet makes everything more approachable and easy to group together. The Examples Column The examples column is where the spreadsheet really shines. The examples are how we can better understand the intent of a given control. Every control has multiple examples and they are written in a way anyone can understand. The idea here isn’t to force a rigid policy on anyone, but to show there are many ways to accomplish these tasks. Most of us learn better from examples than we do from technical control text, so be sure to refer to the examples often. The References Section The references sections are scary looking. Those are a lot of references and anyone who tries to read them all will be stuck for weeks or months. It’s OK though, they aren’t something you have to actively read, it’s to help give us additional guidance if something isn’t clear. There’s already a lot of security guidance out there, it can be easier to cross reference work that already exists than it is to make up all new content. This is how you can get clarifying guidance on the tasks. It’s also possible you already are following one or more of these standards which means you’ve already started your SSDF journey. The Tasks Every task has a certain theme. There’s no product you can buy that will solve all of these requirements. Some themes can only be met with policy. Some are secure software development processes. Most will have multiple ways to meet them. Some can be met with commercial tools, some can be met with open source tools. Interpreting the Requirements Let’s cover a very brief example (we will cover this in far more detail in a future blog post). PO 1.3. 3rd party requirements. The text of this reads PO.1.3: Communicate requirements to all third parties who will provide commercial software components to the organization for reuse by the organization’s own software. [Formerly PW.3.1] This requirement revolves around communicating your own requirements to your suppliers. But today the definition of supplier isn’t always obvious. You could be working with a company. But what if you’re working with open source? What if the company you’re working with is using open source? The important part of this is better explained in the examples: Example 3: Require third parties to attest that their software complies with the organization’s security requirements. It’s easier to understand this in the context of having your supplier prove they are in compliance with your requirements. Proving compliance can be difficult in the best situations. Keep in mind you can’t just do this in one step. You probably first just need to know what you have (SBOM is a great way to do this.) Once you know what you have, you can start to define expectations for others. And once you have expectations and an SBOM you can hand out an attestation. One of the references for this one is NIST 800-160. If we look at section 3.1.1, there are multiple pages that explain the expectations. There isn't a simple solution as you will see if you read through NIST 800-160. This is an instance where a combination of policy, technology, and process will all come together to ensure the components used are held to a certain standard. This is a lot to try to take in all at once, so we should think about how to break this down. Many of us already have existing components. How we tackle this with existing components is not the same approach we would take with a brand new application security project. One way to think about this is you will first need an inventory of your components before you can even try to create expectations for your suppliers. We could go on explaining how to meet this control, but for now let’s just leave this discussion here. The intent was to show what this challenge looks like, not to try to solve it today. We will revisit this in another blog post when we can dive deep into the requirements and some ideas on how to meet the control requirements, and even define what those requirements are! Your Next Steps Make sure you check back for the next post in this series where we will take a deep dive into every control specified by the SSDF. New compliance requirements are a challenge, but they exist to help us improve what we are already doing in terms of secure software development practices. Securing the software supply chain is not just a popular topic, it’s a real challenge we all have to meet now. It’s easy to talk about securing the software supply chain, it’s a lot of hard work to actually secure it. But luckily for us there is more information and examples to build off of than ever before. Open source isn’t about code, it’s about sharing information and building communities. Anchore has several ways to help you on this journey. You can contact us, join our community Discourse forum, and check out our open source projects: Syft and Grype. Josh Bressers Josh Bressers is vice president of security at Anchore where he guides security feature development for the company’s commercial and open source solutions. He serves on the Open Source Security Foundation technical advisory council and is a co-founder of the Global Security Database project, which is a Cloud Security Alliance working group that is defining the future of security vulnerability identifiers. ### NSA Securing the supply chain for developers: the past, present, and future of supply chain security Last week the NSA, CISA, and ODNI released a guide that lays out supply chain security, but with a focus on developers. This was a welcome break from much of the existing guidance we have seen which mostly focuses on deployment and integration rather than the software developers. The software supply chain is a large space, and that space includes developers. The guide is very consumable. It’s short and written in a way anyone can understand. The audience on this one is not compliance professionals. They also provide fantastic references. Re-explaining the document isn’t needed, just go read it. However, even though the guide is very readable, it could be considered immature compared to much of the other guidance we have seen come from the government recently. This immaturity of a developer focused supply chain guide came through likely because this is in fact an immature space. Developer compliance has never been successful outside of some highly regulated industries and this guide reminds us why. Much of the guidance presented has themes of the old heavy handed way of trying to do security, while also attempting to incorporate some new and interesting concepts being pioneered by groups such as the Open Source Security Foundation (OpenSSF). For example, there is guidance being presented that suggests developer systems not be connected to the Internet. This was the sort of guidance that was common a decade ago, but no developers could imagine trying to operate a development environment without Internet access now. This is a non-starter in most organizations. The old way of security was to create heavy handed rules developers would find ways to work around. The new way is to empower developers while avoiding catastrophic mistakes. But next to outdated guidance, we see modern guidance such as using Supply chain Levels for Software Artifacts, or SLSA. SLSA is a series of levels that can be attained when creating software to help ensure integrity of the built artifacts. SLSA is an open source project that is part of the OpenSSF project that is working to create controls to help secure our software artifacts. If we look at SLSA Level 1 (there are 4 levels), it’s clearly the first step in a journey. All we need to do for SLSA level 1 is keep metadata about how an artifact was built and what is in it. Many of us are already doing that today! The levels then get increasingly more structured and strict until we have a build system that cannot connect to the internet, is version controlled, and signs artifacts. This gradual progress makes SLSA very approachable. There are also modern suggestions that are very bleeding edge and aren’t quite ready yet. Reproducible builds are mentioned, but there is lack of actionable guidance on how to accomplish this. Reproducible builds are an idea where you can build the source code for a project on two different systems and get the exact same output, bit for bit. Today everyone doing reproducible builds does so from enormous efforts, not because the build systems allow it. It’s not realistic guidance for the general public yet. The guide expands the current integrator guidance of SBOM and verifying components is an important point. It seems to be pretty accepted at this point that generating and consuming SBOMs are table stakes in the software world. The guide reflects this new reality. Overall, this guide has an enormous amount of advice contained in it. Nobody could do all of this even if they wanted to, don’t feel like this is an all or none effort. This is a great starting point for developer supply chain security. We need to better define the guidance we can give to developers to secure the supply chain. This guide is the first step, the first draft is never perfect, but the first draft is where the journey begins. Understand what you are doing today, figure out what you can easily do tomorrow, and plan for some of the big things well into the future. And most importantly, ignore the guidance that doesn’t fit into your environment. When guidance doesn’t match with what you’re doing it doesn’t mean you’re doing it wrong. Sometimes the guidance needs to be adjusted. The world often changes faster than compliance does. The most important takeaway isn’t to view this guide as an end state. This guide is the start of something much bigger. We have to start somewhere, and developer supply chain security starts here. Both how we protect the software supply chain and how we create guidance are part of this journey. As we grow and evolve our supply chain security, we will grow and evolve the guidance and best practices. ### Anchore Enterprise 4.1 Introduces Curated Vulnerability Feed, AnchoreCTL 1.0, and Source to Build SBOM Drift Management We are pleased to announce the release of Anchore Enterprise v4.1 which contains a major new service to help reduce false positives as well as improvements to our SBOM Drift capability, RHEL 9 support, and updates to the AnchoreCTL command line tool. Read on to learn more! Reducing False Positives with the new curated Anchore Vulnerability Feed For most security teams who are doing vulnerability management, handling false positives is the biggest source of frustration and wasted time. A large number of false positives affect every user, independent of their environment, for one of two major reasons: incorrectly identified software contents that appear to be vulnerable or incomplete data in the vulnerability feed itself. In 2021, to address the challenge of misidentified components, Anchore introduced two features, SBOM Hints and SBOM Corrections, that allow users to adjust the metadata to ensure more accurate generation of the SBOM. This, in turns, provides better mapping to the list of vulnerabilities. With Anchore Enterprise 4.1, we are excited to offer the Anchore Vulnerability Feed which addresses the second issue of incomplete data in public feeds, especially from the National Vulnerability Database (NVD). The Anchore Vulnerability Feed uses data gathered from Anchore’s user community, customer environments, and research done by the Anchore Security Team. This data is used to identify inaccurate metadata in public vulnerability feeds. Once problematic metadata is identified, the Anchore Vulnerability Feed prevents matches against a software component either through a managed exclusion list or by enhancing the metadata itself. All customers can request an assessment of a potential false positive through the Anchore support portal. As Anchore discovers and adds new data to the feed, customers will benefit from live updates which immediately reduce false positives on the customer site without any need for administration changes or software updates. This feature is available to all existing customers across all tiers. Detect Malicious Activity and Misconfiguration with SBOM Drift Enhancements Ever since the Solarwinds compromise, companies have become aware that malicious components can be added during development to create attack vectors. To help with detecting this type of attack, Anchore added a capability in Anchore Enterprise 4.0 called SBOM Drift which looked for when components were being added, changed, or removed during the software development life cycle. The initial feature enabled users to detect and alert on changes between builds of container images. Anchore Enterprise 4.1 further expands on this capability by adding the ability to detect drift between the SBOM generated from a source code repository and the SBOM generated from the resulting build. While some drift is normal as packages are added as dependencies or included from the base operating system, some drift is not. New policy rules can catch changes such as downgrades in version numbers which may be a result of either tampering or misconfigurations. Drift alerts are configurable and can be set to either warn or fail a build based on your requirements. The underlying API to the service allows users to query the changes for reporting and to track dependency usage. Unified and improved command line experience with AnchoreCTL 1.0 Part of the power of Anchore Enterprise is the extensive API coverage and the flexibility of integrating with 3rd party tools and platforms. Since the first launch of our product, the main tool for interacting with any of Anchore Enterprise’s functions via the command line has been anchore-cli. This tool was used to request operations, status, or pull data from the backend. At the beginning of the year, we introduced a next-generation tool called AnchoreCTL, written in GoLang and provided as a standalone client tool. AnchoreCTL allowed a user to interact with Anchore Enterprise application grouping and source code/image SBOM features. Along with Anchore Enterprise 4.1, we are releasing AnchoreCTL v1.0 which now has all of the capabilities previously provided by anchore-cli, but in a simple, unified experience. Provided as a Go binary, it reduces the environment requirements to run the tool on systems such as runners in a CI/CD environment and simplifies the administrative experience of working with Anchore Enterprise. Additionally, the user experience for interacting with operations like sbom management and application management has been massively simplified. Operations which took multiple command line invocations can now be performed with a single operation. RHEL9 and clone support Finally, Anchore Enterprise 4.1 can now scan and continuously monitor RHEL 9 and CentOS 9 Stream container images for any security issues present in installed packages for these operating systems. These packages are now included in generated SBOMs and customers can be applied to Anchore’s customizable policy enforcement. For more information about the product or to get started with a trial license, please contact Anchore. ### 3 Myths of Open Source Software Risk and the One Nobody Is Discussing Open source software is being vilified once again and, in some circles, even considered a national security threat. Open source software risk has been a recurring theme: First it was classified as dangerous because anyone could work on it and then it was called insecure because nobody was in charge. After that, the concern was that open source licenses were risky because they would require you to make your entire product open source. Let’s consider where open source stands today. It’s running at minimum 80% of the world. Probably more. Some of the most mission-critical applications and services on the planet (and on Mars) are open source. The reality is, open source software isn’t inherently more risky than anything else. It’s simply misunderstood, so it’s easy to pick on. Myth 1: Open source software is a risk because it isn’t secure Open source software may not be as risky as you have been led to believe, but that doesn’t mean it gets a free pass either. The most recent and top-of-mind example is the Log4Shell vulnerability in Log4j. It’s easy to put the blame on open source, but it’s lack of proper insight into our infrastructure that is the fundamental issue. The question, “Are we running Log4j?” took many of us weeks to answer when we needed that answer in a few minutes. The key to managing our software risk (and that’s all software, not just open source) is to have the ability to know what is running and where it’s running. This is the literal purpose for a software bill of materials (SBOM). The foundation for managing open source risk begins with knowing what we have in our software supply chain. Any software can be a potential risk if you don’t know you’re running it. You should be generating and receiving an SBOM for every piece of software used and have the capability to store and search the data. Not knowing what you’re running in your software supply chain is a far greater risk than actually running it. The reality is that open source software is just software. It’s when we do a poor job of incorporating it into our products, deploying it, and tracking it that creates this mythic “security risk” we often hear about. Myth 2: Open source software is a risk because it isn’t high quality It was easier a decade ago to claim that open source software was inferior because there wasn’t a lot of open source in use. Today too much of the world runs on top of open source software to make the claim that it is low quality — the idea is simply laughable. The real purpose behind the message that open source software is not suitable for enterprise use — and which you’ll often hear from legacy software vendors — is that open source software is inferior to commercially developed software. In actuality, we’re not in a place to measure the quality of any of our software. While work is ongoing to fill this need, your best option today is to find the open source software that solves your problem and then make sure that it is up to date and has no major bugs that can leave your software supply chain susceptible to vulnerabilities. Myth 3: Open source software is a risk because you can’t trust the people writing it Myth 3 is loosely tied to the first myth that open source software is not secure. There are efforts to measure open source quality, which is a noble cause. Not all open source is created equally. It’s a common misbelief that open source projects with only one maintainer are of lower quality (see myth 2) and you can’t trust the people who build them. There are plenty of projects in wide use where nobody really knows who is working on them. It’s a GitHub ID and that’s about it. So it’s possible the maintainer is an adversary. It’s also possible the intern that your endpoint vendor just hired is an adversary. The only difference is that in the open source world, we can at least figure it out. Although there are open source projects that are nefarious, there are also many people working to uncover the malicious activity. They include a wide range of individuals from end users pointing out strange behavior to researchers scanning repositories and endpoint teams looking for active threats. The global community is a mighty power when it turns its attention to finding malicious open source software. Again, open source software risk is less about trust than it is about having insight into what we are using and how we are using it. Trying to find malicious code is not realistic for many of us, but when it does get found, we need the ability to quickly pinpoint it in our software and remove it. The true risk of open source software In an era where the use of open source software is only increasing, the true risk in using open source — or any software for that matter — is failing to understand how it works. In the early days of open source, we could only understand our software by creating it. There wasn’t a difference between being an open source user and an open source contributor. Open source is very different today. The number of open source users is huge (the population of the world to be exact), while the number of open source contributors is much smaller. And this is OK because everyone shouldn’t be expected to be an open source contributor. There’s nothing wrong with taking in open source packages and using them to build something else. That's the whole point! If there’s one piece of advice I can give, it’s that consuming open source can help you create better software faster as long as you manage risk. There are many good tools that scan for vulnerabilities and there are SBOM-driven solutions to help you identify security issues in all your software components. Open source is an experience where we will all have a different journey. But like any journey, we have to pay attention along the way or we could find ourselves off course. Josh Bressers Josh Bressers is vice president of security at Anchore where he guides security feature development for the company’s commercial and open source solutions. He serves on the Open Source Security Foundation technical advisory council and is a co-founder of the Global Security Database project, which is a Cloud Security Alliance working group that is defining the future of security vulnerability identifiers. ### Docker Security Best Practices: A Complete Guide 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: Securing the Host OS Choosing an OS OS Vulnerabilities and Updates User Access Rights Host File System Audit Considerations for Docker Runtime Environments Securing the Container Images Continuous Approach Image Vulnerabilities Policy Enforcement Create a User for the Container Image Use Trusted Base Images for Container Images Do Not Install Unnecessary Packages in the Container Add the HEALTHCHECK Instruction to the Container Image Do Not Use Update Instructions Alone in the Dockerfile Use COPY Instead of ADD When Writing Dockerfiles Do Not Store Secrets in Dockerfiles Only Install Verified Packages in Containers Securing the Container Runtime Consider AppArmor and Docker Consider SELinux and Docker Seccomp and Docker Do Not Use Privileged Containers Do Not Expose Unused Ports Do Not Run SSH Within Containers Do Not Share the Host’s Network Namespace Manage Memory and CPU Usage of Containers Set On-Failure Container Restart Policy Mount Containers’ Root Filesystems as Read-Only Vulnerabilities in Running Containers Unbounded Network Access from Containers What Are Containers? 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. Watch Now Securing the Host Operating System 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. Download Now Docker Image Security Best Practices 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. For more info see Docker Content Trust and Notary. In the context of Kubernetes, see Connaisseur, which supports Notary/Docker Content Trust. 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: RUN apt-get update && apt-get install -y  bzr  cvs  git  mercurial  subversion 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. 6. Do Not Run SSH Within Containers SSH server should not be running within a container. Read this blog post for details. 7. Do Not Share the Host’s Network Namespace 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. ### Docker Image Security in 5 Minutes or Less Updated post as of May, 2022 Containerized software has become the de facto choice for new development with a recent survey showing that over 80% of organizations claim they will increase container adoption over the next 24 months. While container adoption can ease the development process and increase velocity, it also has the potential to increase an organization’s attack surface and make it susceptible to vulnerabilities. With developers now using both proprietary and open source components in their container environments, visibility into software containers and their dependencies is paramount to securing Docker images and ultimately avoid data breaches. An SBOM, or a Software Bill of Materials, is a vital tool for securing the software supply chain. Used by both security and development teams alike, SBOMs provide visibility into all the components in a container image, including both direct and transitive dependencies. They can be used to identify vulnerabilities and risks such as misconfigurations and embedded secrets so teams can quickly locate and remediate issues before they reach runtime and continue to monitor for new vulnerabilities post-deployment. In this blog post, we’ll show you how you can easily get started generating docker SBOMs and analyzing them for vulnerabilities using the open source projects Syft and Grype, maintained by Anchore. Shifting Docker Image Security Left Getting started with comprehensive Docker image security is easy to do with Syft and Grype. These projects are lightweight, flexible, and stateless command line tools for developers that make it possible to generate a Software Bill of Materials (SBOM) from container images and analyze that SBOM  for vulnerabilities. First, you start by running Syft to generate an SBOM to identify all of your components including dependencies, package details, and filesystem metadata plus malware and risks like secrets and misconfigurations. This level of granularity will make sure you are identifying and accurately matching any potential vulnerabilities. Once that SBOM is generated, it can be fed into Grype which will scan it for vulnerabilities. Re-analyzing images on a regular basis to identify newly discovered vulnerabilities is fast and easy because you only need to generate one SBOM for each version of an image. This is particularly useful in the event of a zero-day, when time is of the essence and you don’t have a minute to spare rescanning your environment from scratch. Using Syft and Grype for Docker Image Analysis Generating an SBOM Step 1: Download & Install Syft Go to the Syft releases page and download the latest version of Syft or follow installation instructions for your system here. Step 2: Generate SBOM Run Syft against your Docker image to output a comprehensive SBOM: syft You will see an output similar to this: $ syft debian:10  ✔ Pulled image  ✔ Loaded image  ✔ Parsed image  ✔ Cataloged packages      [91 packages] NAME                    VERSION                  TYPE adduser                 3.118                    deb apt                     1.8.2.3                  deb base-files              10.3+deb10u12            deb base-passwd             3.5.46                   deb bash                    5.0-4                    deb … Step 3: Save Your SBOM You can easily generate an SBOM and save it in multiple formats depending on your needs by following the steps outlined here. For this example we’ll use JSON using the -o json config. Finding Vulnerabilities Step 1: Download & Install Grype Go to the Grype releases page and download the latest version of Grype or follow installation instructions for your system here. Step 2: Generate a Vulnerability Report You can pipe an SBOM file directly from Syft into Grype: syft :tag -o json | grype Or scan an existing SBOM Grype sbom:path/to/sbom.json You will see an output similar to this:  $ grype sbom:./debian_10_SBOM.json  ✔ Vulnerability DB        [updated]  ✔ Loaded image  ✔ Parsed image  ✔ Cataloged packages      [91 packages]  ✔ Scanned image           [137 vulnerabilities]   NAME            INSTALLED            FIXED-IN      TYPE  VULNERABILITY     SEVERITY apt             1.8.2.3                            deb   CVE-2011-3374     Negligible bash            5.0-4                              deb   CVE-2019-18276    Negligible bsdutils        1:2.33.1-0.1                       deb   CVE-2022-0563     Negligible bsdutils        1:2.33.1-0.1        (won't fix)    deb   CVE-2021-37600    Low coreutils       8.30-3              (won't fix)    deb   CVE-2016-2781     Low … Note: To output the vulnerability report as a file, follow the config options here. Grype uses multiple vulnerability data sources to optimize vulnerability matching and reduce noise from false positives so that developers don’t waste as much time when fixing vulnerabilities in their Docker images. Docker Image Security at Scale While conducting scans of Docker images is quick and easy, automating such scans and implementing Docker image security best practices at scale across multiple teams and applications requires an enterprise-level solution that goes beyond what Syft and Grype provide. Anchore Enterprise adds powerful functionality to the intuitive features of Syft and Grype. With features such as SBOM Management, policy and compliance controls and global reporting and notifications, Anchore Enterprise helps organizations secure their entire software supply chain. Conclusion It is critically important for developers to know exactly what is inside a software container before using it and to enforce company-wide policy and compliance regulations throughout the build process. Using simple image analysis tools, like Syft and Grype are a great way to get up and running quickly and easily with Docker image security before graduating to an enterprise level, overall software supply chain management solution like Anchore Enterprise. By using Anchore, you can know more about the building blocks used in your applications and prepare for the ever growing industry best practices that are quickly becoming standards and mandates. ### Anchore Enterprise Now Supports SBOM Import From ‘docker sbom’ Recently, Docker and Anchore worked together to deliver a new operation within Docker Desktop for generating a container image software bill of materials (SBOM) using native Docker tools. The core functionality for generating an SBOM comes from Anchore’s open-source Syft project, which can be accessed as a command line tool or used as a library for other tools to integrate with (as is the case with our collaboration with Docker). Anchore provides a number of open-source and commercially available software tools for managing SBOMs and providing security/compliance insights and enforcement capabilities against those generated SBOMs. Our general approach to securing modern software development systems embraces the user’s automation and development flexibility objectives, handling large and dynamic software production flows. To facilitate this, the Anchore Enterprise platform effectively conforms to a pattern where: Existing software development infrastructure is instrumented with light-weight tooling that is pointed at a software element (source code checkout, container image, etc.) to generate an SBOM, and then The tooling imports that SBOM into a deployment of Anchore Enterprise which stores the SBOM for further processing, at which point the full capabilities of Anchore Enterprise can be applied to the software SBOM. The Anchore Enterprise client that implements the SBOM generation and import steps is named ‘anchorectl’, a lightweight CLI tool that is included with the Anchore Enterprise platform. As part of our ongoing commitment to support integration with Docker’s native tooling and approach to SBOM generation, we’ve recently released a new version of anchorectl, available to all Anchore Enterprise users, with added support for importing an SBOM directly from new ‘docker sbom’ command. With this capability, users who have access to an existing Anchore Enterprise deployment and prefer to use native ‘docker’ commands in their development environments can easily connect the two systems in a typically UNIX-like fashion. The following example shows an abstract ‘checkout, build container image, import image sbom to Anchore Enterprise’ using this new interface. # git clone # docker build -t -f /Dockerfile / # docker sbom --format syft-json | anchorectl sbom upload - With this simple process invoked either manually or scripted as part of an automated build, users can be assured that new container image SBOMs are being imported to their Anchore Enterprise deployment, so that the full capabilities of Anchore Enterprise - vulnerability scanning (on demand, historical), compliance checks using Anchore’s fully policy subsystem, SBOM drift detection, global reporting and notifications, and many others - can be applied. Learn more about generating SBOMs for Docker images with Syft.  Conclusion As we continue to explore new areas for building SBOM generation and consumption capabilities in collaboration with the Docker community, we remain committed to ensuring that all of Anchore’s products, open-source tools and partnership collaboration efforts are interoperable. As we move forward, we’re looking forward to moving SBOM generation capabilities even closer to the ‘build’ process, continuing support for open standards atop the existing native, SPDX, CycloneDX and other formats, and providing integrations with a wide variety of development environments. ### Gartner Innovation Insight for SBOMs 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. ### How to Generate an SBOM with Free Open Source Tools Generating a Software Bill of Materials (SBOM) as part of your DevOps process is an essential technique to help secure your software supply chain. SBOMs are becoming critical due to the growing prominence of supply chain attacks such as Solarwinds, maintainers intentionally adding malware like node-ipc, and severe vulnerabilities like Log4Shell. SBOMs can help identify the software components used within a system as well as licenses and vulnerabilities. SBOMs also can be used to comply with the Executive Order Improving the Nation's Cybersecurity. Fortunately, there are a number of tools that can help create SBOMs and generating your first one takes just a few easy steps: Choose your SBOM generation tool - we’ll use Syft here Download and install Syft Determine the SBOM output format you need Run Syft against the desired source: syft -o Hold on! Before you jump into using open source tools for SBOMs, note that you can get instant access to a free trial of the Anchore Enterprise platform here. Open Source Tools for Generating SBOMs There are many tools available for generating SBOMs, so the first thing you’ll need to do is pick one to use. SBOM generators are often specific to a particular ecosystem such as Python or Go. Some are capable of generating SBOMs for a number of different ecosystems and environments. Some of the more popular SBOM tools are: Syft by Anchore Tern Kubernetes BOM tool spdx-sbom-generator For this example we’ll focus on Syft, since it is easy to use in many different scenarios and supports a variety of ecosystems. Syft can run on your desktop, in CI systems, as a Docker container and scan a wide variety of ecosystems from Linux distributions to many types of build dependency specifications. Getting Syft The first thing to do is download Syft. There are a number of ways to do this: Using curl The recommended method to get Syft for macOS and Linux is by using curl: curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b For example: curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin   Homebrew For macOS, you can install Syft using Homebrew: brew tap anchore/syft brew install syft   Direct Download You can directly download Syft binaries for many platforms including Windows from the GitHub releases page. Docker There is also a Syft Docker image with every release: anchore/syft, which can be run like this: docker run -it --rm anchore/syft   Validate the Syft Installation To confirm Syft was installed correctly, simply run: syft version You should see output similar to: Application:        syft Version:            0.43.2 JsonSchemaVersion:  3.2.2 BuildDate:          2022-04-06T21:49:04Z GitCommit:          e415bb21e7a609c12dc37a2d6395796fb675e3fe GitDescription:     v0.43.2 Platform:           linux/amd64 GoVersion:          go1.18 Compiler:           gc Note: Syft was version 0.43.2 at the time of this writing Generating Your First SBOM Once you have Syft available, creating your first SBOM is simple. Syft supports multiple sources to scan when generating an SBOM using both the local filesystem and container images. Scanning Images To generate an SBOM for a Docker or OCI image - even without a Docker daemon, simply run: syft By default, output includes only software that is included in the final layer of the container. To include software from all image layers in the SBOM, regardless of its presence in the final image, use the --scope all-layers option: syft --scope all-layers   Scanning the Filesystem To generate an SBOM for the local filesystem, use the dir: and file: prefixes with either absolute or relative paths. For example to scan the current directory: syft dir:. Or a specific file: syft file:/my-go-binary Syft can generate SBOMs from a variety of other sources, such as Podman, tar archives, or directly from an OCI registry even when Docker is not available. Check out the full list of sources. Basic Example For example, to scan the latest Alpine image, simply run: syft alpine:latest You should see output similar to this:  ✔ Loaded image              ✔ Parsed image              ✔ Cataloged packages      [14 packages] NAME                    VERSION      TYPE  alpine-baselayout       3.2.0-r18    apk    alpine-keys             2.4-r1       apk    apk-tools               2.12.7-r3    apk    busybox                 1.34.1-r3    apk    ca-certificates-bundle  20191127-r7  apk    libc-utils              0.7.2-r3     apk    libcrypto1.1            1.1.1l-r7    apk    libretls                3.3.4-r2     apk    libssl1.1               1.1.1l-r7    apk    musl                    1.2.2-r7     apk    musl-utils              1.2.2-r7     apk    scanelf                 1.3.3-r0     apk    ssl_client              1.34.1-r3    apk    zlib                    1.2.11-r3    apk By default, the SBOM you’ll see will be a nicely formatted table rather than any standardized SBOM format, which leads us to… Choose Your SBOM Format Depending on your use cases, it may be important to use a particular SBOM format. The most common ones are Software Package Data Exchange (SPDX) and CycloneDX, both of which Syft supports. Syft also has a format which interoperates losslessly with the Grype vulnerability scanner. While Syft supports these different formats, they have slightly different goals and features. It may be important to pick SPDX or CycloneDX for interoperability with other tools or as a standardized format to distribute to downstream consumers. Generating an SBOM in SPDX format If your use case requires an SBOM in SPDX format, Syft has you covered. SPDX has been around the longest of all the formats mentioned here. There are multiple variants of SPDX. Syft supports SPDX Tag-value (spdx-tag-value) and SPDX JSON (spdx-json). For SPDX JSON, simply add the -o spdx-json argument. For example, running this against a docker image, again using the latest Alpine: syft alpine:latest -o spdx-json You’ll see there is a lot more data than the table view allows! You should see something resembling: {  "SPDXID": "SPDXRef-DOCUMENT",  "name": "alpine-latest",  "spdxVersion": "SPDX-2.2",  "creationInfo": {   "created": "2022-04-12T01:47:03.011148Z",   "creators": [    "Organization: Anchore, Inc",    "Tool: syft-0.42.4"   ],   "licenseListVersion": "3.16"  },  "dataLicense": "CC0-1.0",  "documentNamespace": "https://anchore.com/syft/image/alpine-latest-31e0e940-da83-4ea2-8a0c-fbba76371667",  "packages": [   {    "SPDXID": "SPDXRef-8039c8621bcc1383",    "name": "alpine-baselayout",    "licenseConcluded": "GPL-2.0-only",    "description": "Alpine base dir structure and init scripts",    "downloadLocation": "https://git.alpinelinux.org/cgit/aports/tree/main/alpine-baselayout",    "externalRefs": [     {      "referenceCategory": "SECURITY",      "referenceLocator": "cpe:2.3:a:alpine:alpine-baselayout:3.2.0-r18:*:*:*:*:*:*:*",      "referenceType": "cpe23Type"     },     {      "referenceCategory": "PACKAGE_MANAGER",      "referenceLocator": "pkg:alpine/alpine-baselayout@3.2.0-r18?arch=x86_64&upstream=alpine-baselayout&distro=alpine-3.15.0",      "referenceType": "purl"     }    ],    "filesAnalyzed": false,    "licenseDeclared": "GPL-2.0-only",    "originator": "Person: Natanael Copa ",    "sourceInfo": "acquired package info from APK DB: /lib/apk/db/installed",    "versionInfo": "3.2.0-r18"   }  ],  "files": [   {    "SPDXID": "SPDXRef-2eaa15c5fc625ebe",    "comment": "layerID: sha256:8d3ac3489996423f53d6087c81180006263b79f206d3fdec9e66f0e27ceb8759",    "licenseConcluded": "NOASSERTION",    "fileName": "/etc/crontabs/root"   }  ],  "relationships": [   {    "spdxElementId": "SPDXRef-8039c8621bcc1383",    "relationshipType": "CONTAINS",    "relatedSpdxElement": "SPDXRef-2eaa15c5fc625ebe"   }  ] } Not only does this format contain the package names, but also Package URLs, license information, and a host of other things such as files Syft identified associated with a package. Generating an SBOM in CycloneDX format Similarly, if you need to generate an SBOM in CycloneDX format use a CycloneDX format option. Syft supports CycloneDX XML (cyclonedx-xml) and JSON (cyclonedx-json). For CycloneDX XML: syft -o cyclonedx-xml To run this against the same latest Alpine image, run: syft alpine:latest -o cyclonedx-xml And you should see a result resembling this:        2022-04-11T22:01:51-04:00                     anchore         syft         0.42.4                        alpine:latest       sha256:a3f8ca28888378e4880b3f73504c78278a9038dccf906760a1afd4a08c81c1c1                       Natanael Copa <ncopa@alpinelinux.org>       alpine-baselayout       3.2.0-r18       Alpine base dir structure and init scripts                           GPL-2.0-only                       cpe:2.3:a:alpine-baselayout:alpine-baselayout:3.2.0-r18:*:*:*:*:*:*:*       pkg:alpine/alpine-baselayout@3.2.0-r18?arch=x86_64&upstream=alpine-baselayout&distro=alpine-3.15.0                           https://git.alpinelinux.org/cgit/aports/tree/main/alpine-baselayout                                apkdb-cataloger         ApkMetadata         apk         cpe:2.3:a:alpine:alpine-baselayout:3.2.0-r18:*:*:*:*:*:*:*         sha256:8d3ac3489996423f53d6087c81180006263b79f206d3fdec9e66f0e27ceb8759         /lib/apk/db/installed         dfa1379357a321e638feef1cd8d55ab03d020f45         413696         alpine-baselayout         Q1EymS6rAgmGs7XYhqdyEoiWgEZ6A=         /bin/sh so:libc.musl-x86_64.so.1         21101                        alpine       3.15.0       Alpine Linux v3.15                                  https://bugs.alpinelinux.org/                             https://alpinelinux.org/                                alpine         Alpine Linux v3.15         3.15.0                Again, there is a lot more data than the table allows, but a different set of data than the SPDX format because there simply is not a one-to-one mapping of properties between the two. Generating an SBOM in Syft Lossless format The last format we’ll talk about is Syft’s own JSON format. If there isn’t a need to provide an SBOM to other tools and you may be using Grype to scan the SBOM, the format with the highest fidelity is the Syft JSON format. Both SPDX and CycloneDX lose some amount of information from the initial Syft data model whereas the Syft format does not. Although Grype works great with SPDX and CycloneDX, there could be a situation where data was lost converting to one of these formats and Grype matching uses some of that extra data, so using the Syft JSON might make the most sense. To use the Syft JSON format, use the -o json argument. Additional Syft Features There’s a lot more that Syft can do, with quite a few configuration options. A few things to note include: Output the SBOM to a file using --file path/to/file Exclude paths from scanning using --exclude path/**/*.txt Specify configuration in a .syft.yaml file Connect to private OCI registries Cryptographically sign and attest SBOMs Next Steps Now that you’ve got an SBOM, what’s next? A logical next step would be to integrate with your build pipeline to have SBOMs generated automatically. In fact, there could be more than one location where it makes sense to generate SBOMs such as build time and after a container is built or during a release process. The SBOMs then could be scanned for license compliance and continuously for vulnerabilities. In fact, if you are using GitHub Actions, there are a couple actions to do just that: sbom-action to generate SBOMs using Syft and scan-action to perform vulnerability scanning. For a few repositories, it’s very simple to set these up but might be challenging when there are a lot of repositories to keep track of. Managing SBOMs at scale As we’ve talked about, using SBOMs as a central part of securing your software supply chain is increasingly important. Integrating automated SBOM generation into your DevOps process is vital. Storing, managing, and analyzing those SBOMs to inform security measures should be an important consideration for you and your organization. For more comprehensive SBOM management, an enterprise level solution like Anchore Enterprise will enable you to generate comprehensive SBOMs with every build, detect drift from one build to the next, share SBOMs internally or externally, and quickly identify risk such as vulnerabilities, secrets, malware, and misconfiguration. To learn more about Anchore Enterprise, schedule a demo with one of our specialists here. Conclusion Now that you understand the many reasons to generate SBOMs (whether for compliance or vulnerability analysis) using Syft to generate SBOMs is a flexible and simple process with many options to tailor SBOMs to your specific use cases. If you'd like to explore using Anchore Enterprise for its robust features like continuous visibility, SBOM monitoring, drift detection, and policy enforcement then access a free 15 day trial here. ### Anchore and Docker Release ‘docker sbom’ to Create Comprehensive SBOMs Based on Syft Today Anchore and Docker released the first feature in what we anticipate will be an ongoing initiative to bring the value of the software bill of materials (SBOM) to all container-oriented build and publication systems. Now included in the latest Docker Desktop version is an operation called ‘docker sbom’ that is available via the ‘docker’ command. This new operation, which is built on top of Anchore’s open source Syft project, enables Docker users to quickly generate detailed SBOM documents against container images using the native Docker CLI. SBOMs are quickly becoming foundational data sources for a variety of DevSecOps use cases ranging from basic software development hygiene all the way to unlocking more complex security and compliance capabilities such as tamper and drift detection, zero-day response support, and post-security-event forensic analysis. While security scanning tools need to identify software components, they often don’t make an SBOM accessible to users or include the level of detail needed to support a variety of use cases. With this open source collaboration between Anchore and Docker, we are giving users the ability to create and store an SBOM independently from running any higher-level function like vulnerability scanning or license detection. By enabling SBOM creation to be an independent operation, it can be decoupled from the multitude of individual use cases that rely on SBOM data. This approach gives users the ability to generate an SBOM once and then use it for a variety of use cases. We believe that the availability of SBOM data is foundational when developing processes and technologies to improve software supply chain security. With ‘docker sbom’, we’re excited to engage with the Docker and Anchore communities together on the topic of SBOM creation, usage, and future directions. How the ‘docker sbom’ command works The new ‘docker sbom’ command is simple to use and leverages the power of Syft to provide rich content and data formats. In the following quick example, we show how the ‘docker sbom’ command can be used to generate a comprehensive SBOM document in a user-chosen format and then used as input for other tools that are capable of consuming an SBOM to provide higher-level functions such as vulnerability scanning. As the discussion on the best way to create and consume SBOM data continues to evolve, we’re committed to supporting industry standard formats like SPDX, CycloneDX, Syft-JSON, and others in order to promote the idea of creating and storing SBOMs in forms that interoperate with evolving security and DevOps infrastructure tools. Here, we show using the ‘docker sbom’ command against a test image that combines regular distro-provided packages (Alpine in this case) with multiple vulnerable versions of Log4j that are packaged in a variety of different forms ranging from simple top-level jars to many-levels-deep jars within compressed Java archives: % docker sbom dnurmi/testrepo:jarjar Syft v0.42.2  ✔ Loaded image  ✔ Parsed image  ✔ Cataloged packages      [217 packages] NAME                         VERSION                        TYPE alpine-baselayout            3.2.0-r18                      apk alpine-keys                  2.4-r1                        apk … … log4j-core                   2.12.1                        java-archive log4j-core                   2.11.0                         java-archive log4j-core                   2.11.1                         java-archive log4j-core                   2.13.2                         java-archive log4j-core                   2.12.0                         java-archive … While the default output is in human-readable form for quick review, the command supports a growing set of output formats that can be used more directly for integration into other systems and tools that can analyze SBOMs: % docker sbom --help Usage:  docker sbom [OPTIONS] COMMAND …       --format string         report output format, options=[syft-json cyclonedx-xml cyclonedx-json github-json spdx-tag-value spdx-json table text]                               (default "table") … To demonstrate this flow, let’s look at a simple use case where ‘docker sbom’ is used to produce its data as SPDX JSON, which is then consumed by another tool. We’ll use Grype, Anchore’s open source vulnerability scanner, to produce a vulnerability report without needing to contact any remote scanning services: % docker sbom --format spdx-json docker.io/dnurmi/testrepo:jarjar | grype Syft v0.42.2  ✔ Loaded image  ✔ Parsed image  ✔ Cataloged packages      [217 packages] NAME                 INSTALLED     FIXED-IN      VULNERABILITY        SEVERITY … log4j-core           2.12.1                      CVE-2021-45046       Critical log4j-core           2.11.0                      CVE-2021-45105       Medium log4j-core           2.13.2        2.16.0        GHSA-7rjr-3q55-vv33  Critical log4j-core           2.12.1        2.12.4        GHSA-8489-44mv-ggj8  Medium log4j-core           2.13.0                      CVE-2020-9488        Low log4j-core           2.12.1        2.12.3        GHSA-p6xc-xr62-6r2g  High log4j-core           2.12.0        2.12.3        GHSA-p6xc-xr62-6r2g  High log4j-core           2.12.0                      CVE-2021-44832       Medium … What’s next for Anchore and Docker collaboration The process above demonstrates a vulnerability scan as just one example use case where SBOMs can prove valuable. At Anchore, we’ve built our open source projects and our commercial Anchore Enterprise solution using SBOMs as the foundation for enabling best practices for software development, security, and compliance. We’re committed to continuing this work by making available both open source projects and commercial Anchore Enterprise products that are built to create, ingest, store, analyze, and output SBOM data across all stages in the development cycle. With Docker, we’re looking forward to further collaboration to deliver deeper integration between Syft’s SBOM generating technology and the Docker build and store processes. We are working toward a near future where every container image stored in a registry has an associated SBOM that can be inspected and consumed for further processing. And beyond that, we’re looking to explore ideas that couple build directives with SBOM content to drive concepts like reproducible builds and build time security rule enforcement. We’re excited to continue the discussion and to have you join us in this effort! ### Grype now supports CycloneDX and SPDX In the world of software bills of materials (SBOM) there are currently two major standards: Software Package Data Exchange (SPDX) and CycloneDX. SPDX is a product of the Linux Foundation. It’s been a standard for over ten years now. CycloneDX is brought to us by the OWASP project. It’s a bit newer than SPDX, and just as capable. If you’re following the SBOM news, these two formats are often topics of discussion. It is expected that anyone who is creating or consuming SBOMs will probably use one of these two formats to ensure a certain amount of interoperability. If you expect the consumers of your software to keep track of your SBOM, you need a standard way of communicating. Likewise, if we are expecting an SBOM from our vendors, we want to make sure it’s in a format we can actually use. This is one of those cases where more isn’t better, two is plenty. If you’re familiar with Anchore’s open source projects Syft and Grype, there’s also another format you’ve probably seen known as the Syft lossless SBOM. This format has been tailored specifically to the needs of Syft and Grype when the projects were just starting out. It’s a great format and contains a huge amount of information, but there aren’t a lot of tools out there that can generate or consume this SBOM format today. When we think about vulnerability scanners, we tend to think about pointing a scanner at a container, or directory, or even a source repo, then scanning that location to find vulnerabilities in the dependencies. Grype has a neat trick though, it can scan an SBOM for vulnerabilities. This means instead of having to first scan the files to identify them, then figure out if any have vulnerabilities. Grype can skip over that identification  step by using an SBOM. Most of the time a vulnerability scanner spends is in this identification stage, scanning an SBOM for vulnerabilities is incredibly fast. Initially Grype was only able to use a Syft format SBOM to scan for vulnerabilities. This is awesome, but we come back to the problem of what happens when a vendor gives us an SBOM in SPDX or CycloneDX format? The easy answer is to support those formats too of course. The next obvious question is which format should Grype support next; SPDX or CycloneDX? Since making a decision is hard, and SBOM formats are like children, you can’t really pick a favorite, it was decided to support both! If you download the latest version of Grype you can now use it to scan your SPDX and CycloneDX SBOMs for vulnerabilities. If a vendor ships you an SBOM, it can be fed directly into Grype. We’re pretty sure Grype is the first open source vulnerability scanner that supports both SPDX and CycloneDX at the time of writing this. We think that’s a pretty big deal! Now, it should be noted that this functionality is very new. There are going to be bugs and difficulties scanning SPDX and CycloneDX SBOMs. We would be fools to pretend the features are perfect. However, Grype is also an open source project, you don’t have to sit on the sidelines and watch. Open source is a team sport. If you scan an SBOM with Grype and run into any problems, please file a bug here. You can even submit a patch if that’s more your style, we love pull requests from our community. Stay tuned for even more awesome features coming soon. We’re just getting started! ### Anchore Enterprise 4.0 Delivers SBOM-Powered Software Supply Chain Management 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. End-to-end SBOM management reduces risk and increases transparency in software supply chains 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. ### Trusting SBOMs in the Software Supply Chain: Syft Now Creates Attestations Using Sigstore This blog post has been archived and replaced by the supporting pillar page that can be found here: https://anchore.com/wp-admin/post.php?post=987473385&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. ### Helping Entrepreneurs Take Flight 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. ### Gartner’s 12 Things to Get Right for Successful DevSecOps: A Study in DevSecOps Best Practices This blog post has been archived. It was replaced by the supporting pillar page, found here: https://anchore.com/wp-admin/post.php?post=987473321&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. ### Container Security Best Practices: Zero-Days Jan 26th @ 2pm EST/11am PST ### FedRAMP Pre-Assessment Playbook for Containers ### 2022 Security Trends: Software Supply Chain Survey 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. What Are the 2022 Top Security Trends? The top 2022 security trends related to software supply chain security are: Supply chain attacks are impacting 62 percent of organizations Securing the software supply chain is a top priority The software bill of materials (SBOM) emerges as a best practice to secure the software supply chain Open source and internally developed code both pose security challenges Increased container adoption is driving the need for better container security Scanning containers for vulnerabilities and quickly remediating them is a top challenge The need to secure containers across diverse environments is growing as organizations adopt multiple CI/CD tools and container platforms Software Supply Chain Security Survey: Key Findings 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. We highlight several key findings from the survey in this blog post. For the complete survey results, download the Anchore 2022 Software Supply Chain Security Report. 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. For more insights to help you build and maintain a secure software supply chain, download the full Anchore 2022 Software Supply Chain Security Report. Attribution Requirements for Sharing Charts Anchore encourages the reuse of charts, data, and text published in this report under the terms of the Creative Commons Attribution 4.0 International License. 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. ### 7 Software Supply Chain Security Actions to Take in 2022 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. ### Key Things to Know about SBOMs and SBOM Standards 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. ### How to Find and Fix Log4j with Open Source and Enterprise Tools from Anchore Updated 01/07/22. As new information about the Log4j vulnerability becomes available, we will update this blog with the latest information. As the Log4j zero-day vulnerability continues to have widespread effects across nearly every industry and sector, it’s becoming increasingly evident that there is still a long remediation road ahead. With new vulnerabilities associated with Log4j continuing to emerge, it is imperative to find and remediate this Log4j vulnerability across all your applications to ensure the security of your software supply chains. This blog provides step-by-step instructions for finding and fixing the Log4Shell vulnerability found in Log4j using Anchore open source solutions (Syft and Grype) and commercial solution (Anchore Enterprise). Summary of the Known Log4j Vulnerabilities Log4Shell was originally published on Dec 10, 2021 as a zero-day vulnerability found in Apache Log4j 2, a widely used Java library. The vulnerability enables a remote attacker to take control of a device on the internet if the device is running certain versions of Log4j 2. After the original vulnerability was reported and fixed, there have been subsequent vulnerabilities identified which have resulted in new patched versions. We will update this table for any further Log4j vulnerabilities or versions Vulnerability IDs Affected Package and Version  Patched Version  Date Published References CVE-2021-44228, GHSA-jfh8-c2jp-5v3q log4j-core 2.14 and earlier 2.15.0 (Java 8) 10 Dec 2021 NVD, GHSA CVE-2021-45046, GHSA-7rjr-3q55-vv33 log4j-core 2.15 and earlier 2.16.0 (Java 8) 2.12.2 (Java 7) 14 Dec 2021 NVD, GHSA CVE-2021-45105, GHSA-p6xc-xr62-6r2g log4j-core 2.16 and earlier 2.17.0 (Java 8) 2.12.3 (Java 7) 2.3.1 (Java 6) 18 Dec 2021 NVD, GHSA CVE-2021-44832, GHSA-8489-44mv-ggj8 Log4j-core 2.17.0 and earlier 2.17.1 (Java 8) 2.12.4 (Java 7) 2.3.2 (Java 6) 28 Dec 2021 NVD, GHSA Steps to Find Log4j Using Anchore Open Source Tools Anchore provides two lightweight, command-line open source tools. Syft scans filesystems or container images to produce a comprehensive software bill of materials (SBOM). Grype identifies known vulnerabilities by scanning an SBOM generated by Syft or by scanning filesystems or container images directly. In the context of Log4j, Syft-generated SBOMs enable you to find out if Log4j is present in a source code repository, a filesystem, or a container image. Grype can then be used to perform a vulnerability scan on that SBOM to determine if the detected versions of any given software package match any of the known Log4j vulnerabilities. As the Log4j incident continues to evolve, both Syft and Grype are useful in identifying which Log4j versions you are running and determining the presence of any new Log4j vulnerabilities as they are announced. The following examples provide step-by-step instructions for using Syft and Grype to locate and remediate Log4j. Syft Watch a video demonstration Download Syft. Example 1: Run syft to generate an SBOM and filter the results to identify any vulnerable versions of Log4j. Command Example: # syft dir://tmp/jarsinjars/ | grep log4j Command Example: # syft docker.io/dnurmi/testrepo:jarjar | grep log4j Example 2: Run syft with the JSON output option to get more detailed information on the locations of the Log4j dependencies in your source code repositories and/or container images. The example below shows the top-level ‘fireline.hpi’ package which contains a Log4j jar deeply embedded as shown by the ‘VirtualPath’ element of the JSON record. Command Example: # syft -o json docker.io/dnurmi/testrepo:jarjar Example 3: Run syft and create a JSON file so you can save it as an SBOM artifact. Command Example: # syft -o json docker.io/dnurmi/testrepo:jarjar > log4j-sbom.json Grype Download Grype. Example 4: Run grype on an SBOM produced by Syft and filter to find components that contain Log4j vulnerability IDs. The example below filters for the ID GHSA-jfh8-c2jp-5v3q but you can also filter for any of the new CVEs affecting Log4j (see above for a list of vulnerability identifiers). Command Example: # grype docker.io/dnurmi/testrepo:jarjar | grep GHSA-jfh8-c2jp-5v3q Steps to Find and Fix Log4j Using Anchore Enterprise Watch a video demonstration. Anchore Enterprise scans and performs a deep inspection of container images to identify the presence of Log4j and related vulnerabilities. However Anchore Enterprise also maintains a repository of SBOMs across applications and teams, so that users can query their entire SBOM catalog to search for any scanned images that include Log4j. Anchore Enterprise users can leverage policy-based reporting and alert services to create automatic notifications when existing or new scans identify vulnerable versions of Log4j. The customizable policy engine can provide a “stop” signal your build systems and Anchore’s out-of-the-box policies also contain a rule blocking critical vulnerabilities such as those registered against Log4j from being deployed into production. Using the Anchore Enterprise Runtime Inventory system, users can also quickly search for and detect instances of vulnerable Log4j software that is present in containers running in your Kubernetes deployments. All Anchore Enterprise vulnerability detection features continuously update using the latest vulnerability data from a variety of public sources, and send notifications as the Log4j incident evolves, to keep teams abreast of newly discovered vulnerabilities and fix versions pertaining to Log4j software. Instructions below are provided for the Anchore Enterprise command-line interface (CLI) and the user interface. Scanning with Anchore CLI to Find Log4j Watch a video demonstration.  The Anchore CLI provides a command-line interface on top of the Anchore Enterprise REST API. The Anchore CLI is published as a Python package that can be installed from the Python PyPI package repository on any platform supporting PyPI. Anchore CLI users can manage and inspect images, policies, subscriptions, and registries. Example 1: Run anchore-cli to scan container images, produce an SBOM, and use it to identify any vulnerable versions of Log4j, along with the location of any detected, installed Log4j packages. Command Example: # anchore-cli image content docker.io/dnurmi/testrep:jarjar java | grep log4j Example 2: Run anchore-cli to search a specific container image for vulnerabilities matching vulnerability IDs. The example below filters for CVE-2021-44228 but you can also filter for any of the new CVEs affecting Log4j (see above for a list of CVE identifiers). Command Example: # anchore-cli image vuln docker.io/dnurmi/testrepo:jarjar all | grep CVE-2021-44228 Example 3: Run anchore-cli to query all of the analyzed image SBOMs in your catalog for instances of vulnerable software matching particular vulnerability IDs. The example below filters for ID GHSA-jfh8-c2jp-5v3q but you can also filter for any of the new CVEs affecting Log4j (see above for a list of CVE identifiers). Command Example: # anchore-cli query images-by-vulnerability --vulnerability-id GHSA-jfh8-c2jp-5v3q Policy Enforcement and Reporting Using Anchore Enterprise Example 1: In the Anchore Enterprise user interface navigate to View Reports -> Quick Report -> Images By Vulnerability to perform a query to retrieve all images with vulnerable software matching particular vulnerability IDs, such as CVE-2021-44228. Example 2:  In Anchore Enterprise, navigate to Image Analysis > Select Image > Vulnerabilities Tab. Select View Images Affected on the left hand side of the screen. This will generate a report of all other images that share the specified CVE. Example 3:  Ensure that the active policy has a rule that specifies a STOP action on any vulnerability marked with a severity level of Critical. Finding Log4j in Running Containers Using Anchore Enterprise Example 4: Use Anchore Enterprise’s Runtime Inventory to detect any container that is running in your Kubernetes cluster and includes a vulnerable version of Log4j. You will first need to install KAI (an agent that runs in your Kubernetes cluster) which can be downloaded here. Once KAI is installed, select the Kubernetes tab in Anchore Enterprise and select Vulnerabilities. Next query for the known vulnerability identifiers for Log4j such as CVE-2021-44228 or others listed above. Any currently running images with the Log4j vulnerability will populate in the table below when you execute the query. From there, you can drill down on any impacted image, by selecting the Vulnerabilities tab within the impacted runtime image, and View Images Affected to identify other images that share the Log4j vulnerability. Remediation Workflows Using Anchore Enterprise Example: If Log4j is detected in any of your applications, you must begin the fix process. Anchore Enterprise users can trigger notifications and remediation workflows based on rules set through the policy engine. Tickets can be automatically created in Jira or GitHub, sent as emails, or posted to Slack or Microsoft Teams channels. These notifications provide not only the details of the Log4j version discovered or the policy rules that were violated but also include explicit instructions on what versions should be used to resolve the issue. Contact Us Anchore is continuing to monitor the Log4j incident as it evolves. If you need assistance or want to learn more about how Anchore can help, please contact us. ### Find the Log4j Vulnerability with Anchore Enterprise 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. ### Identify Log4j Using Anchore Enterprise with Anchore CTL 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 ### Find the Log4j Vulnerability Using Syft and Grype 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. ### How to Detect and Remediate Log4J at Scale with Anchore Enterprise Responding to Log4Shell, the Log4j zero-day that disrupted the lives of security teams around the globe, is not a one weekend or one week event. While organizations may have put in place immediate responses to try to prevent exploits, the problem won’t be resolved until all of the applications that use Log4j have been remediated. This will require a long term response that remediates the impacted applications while preventing any more vulnerable components from making it through to production or being delivered to customers. Since the Log4shell vulnerability disclosure, we’ve seen a huge interest in our open source projects, Syft and Grype. These tools are simple yet powerful CLI utilities which help you generate a Software Bill of Materials (SBOM) for your software artifacts (Syft) so you can see if you are using Log4j and notify you if they are vulnerable (Grype). Our VP of Security, Josh Bressers, wrote an Infoworld article explaining how you can get going with them quickly. Syft and Grype are very convenient for ephemeral, one time scans but with a fast moving situation and new versions of Log4j coming out quickly to address the vulnerability (we’ve already seen two), tracking, enforcing and managing the SBOMs and vulnerability data they generate can quickly become challenging. Anchore Enterprise provides users with a number of features that both help to reduce the pain of the current response frenzy and help you over the long haul get to a place where the vulnerability has been fully remediated. Detecting Log4Shell at Scale Applications containing Log4j may be going through your development pipeline, sitting in your registry, or actively running in Kubernetes. Anchore Enterprise customers already have all of this information about the possible locations of the vulnerable package in a single repository so they can easily search across their entire environments to assess the impact. Anchore Enterprise customers already get a fully supported version of the functionality in Syft and Grype combined into a single tool called AnchoreCTL. Whether used on the command line on a desktop or integrated into your CI/CD pipelines, AnchoreCTL pushes all of the SBOM data to Anchore Enterprise centralized data store. Combined with data that Anchore Enterprise gathers from artifact registries or Kubernetes environments, all SBOM data is managed and accessible in a single place. Not only does this allow security teams to detect whether vulnerable versions of Log4j are being used anywhere across their environments but also allows them to check when new versions of Log4j are being deployed and put into production by developers. Many CEOs and Boards of Directors are demanding daily updates from the CISO and security teams on the business impact of the Log4j vulnerability and Anchore Enterprise’s reporting system is allowing security and response teams to accurately report on how vulnerable they are to the ongoing issue. Using Policies for Enforcement at Scale While identifying if and where you are vulnerable is the essential first step to triage the problem, customers quickly need to reduce risk. Anchore Enterprise contains a sophisticated policy engine that can provide a “stop” signal to the platforms in your development environment. By default, the out-of-the-box policies in Anchore Enterprise contain a rule disallowing critical CVEs so all customers already received necessary protections as soon as the issue was flagged in public databases on December 9, even if they had not yet crafted a specific response. For users who are using AnchoreCTL to scan builds in their CI/CD systems, as soon as the policy rule about critical CVEs was triggered, build and deployment jobs would have been halted for affected software. Going further along the deployment process, users who had Anchore Enterprise connected to Anchore’s Kubernetes Admission Controller, would have also been unable to deploy vulnerable applications as a result of the policy rule. Beyond the default policies provided by Anchore Enterprise, customizing more granular policy rules can help your organization to further pinpoint your efforts. For example, users may run very old versions of Log4j that are not vulnerable to the Log4Shell exploit. Users can easily add an access list rule in Anchore Enterprise to disallow the impacted versions (2.0 to 2.15) but allow others (versions lower than 2.0) to ensure the dragnet doesn’t catch more than it needs. As we have recently seen, an updated version of Log4j (2.15) was itself a concern. Some more advanced users create their own hot fix packages to avoid waiting for upstream security responses. Temporary policy rules can be created to enforce the presence of a specific hash for a custom-built package to ensure developers have used the internally created hot fix until the organization is comfortable using the upstream public package. Beyond just looking at the version string, a number of mitigation strategies have emerged such as using environment variables to modify the behavior of the Log4j code. A policy rule can be added that ensures these variables are in place. Combined with a temporary allow-list entry for the version of Log4j you are using, this can be a more practical solution while you work on your upgrade strategy. Using the Anchore Enterprise policy engine for multiple pipeline stages enables a defense-in-depth approach to ensure you are catching all entry points for vulnerable content. The single point of command and control for your security rules across any component found in an SBOM allows customers to adjust as new information comes to light. Remediating Log4Shell At Scale Finally, chances are you are detecting Log4j in multiple applications maintained by multiple development teams. To start the fix process, Anchore Enterprise users can trigger notifications and remediation workflows based on rules that are triggered from the policy engine. Tickets can be automatically created in Jira or GitHub, sent as emails, or posted to Slack or Microsoft Teams channels. These notifications provide not only the details of the Log4j version discovered or the policy rules that were violated but also include explicit instructions on what versions should be used to resolve the issue. From Sprint to Marathon The extensive use of Log4j and the severity of the exploit 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 critical issue that surfaces. Perhaps you’ve already found some as you’ve addressed Log4j. 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. ### Anchore Enterprise 3.3 Increases Vulnerability Visibility and Adds UI Enhancements 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. ### Viewpoint: The Future of Software Supply Chain Security Hello friends. My name is Josh and I’ve just started at Anchore as the Vice President of Security. I’ll talk more about what the role means in future posts, but for the moment I want to answer a few questions that are top of mind right now. Namely, what do I think the future of software supply chain security looks like and why did I choose to work with Anchore to help organizations better protect their software supply chains. Back in 2004 I started working on the Red Hat Product Security Team. My focus has always been on securing the open source we all use  every day. Back then we were securing the open source supply chain, but there wasn’t really a name for this practice yet. I have always felt very strongly about the integrity and security of software products as well as the security of open source. It’s a happy coincidence that these two topics have merged in the last few years! Today open source software makes up a majority of the code in almost every software application we use. Combining open source with cloud platforms and modern development technologies has completely changed the way we build and deliver software applications. These changes have helped us to fundamentally transform how we interact with technology in our jobs and our lives. But now, this dependence on software, and the supply chain that produces it, has created a new set of attack points for bad actors. I believe this industry-wide and economy-wide realization will change the foundations of how we build, deliver, and use technology. What’s different now? There was once a time the security team would end every conversation with “if you don’t listen to us someday you’ll be sorry.” Nobody was ever sorry. But the world has changed a lot and that  “someday” may be now. There are many new threats and attacks that create significant and measurable losses. Breaches are expensive, ransomware is expensive, personal data has monetary value now. Anchore’s 2021 Software Supply Chain Security Report found that 64% of organizations had been impacted by a software supply chain attack in the past year. We exist at a nexus point that has made the risk very real. Every company has gone digital with almost everything online now, DevOps has made the number of services uncountable and the pace of change almost unmeasurable. Meanwhile, the adversaries are organized and highly motivated. Separately any one of these factors might be manageable, but when you put it all together we need to completely rethink the approach to software supply chain security. Big problems need bold new ideas. We are also in a period of disruptive change that allows for new ideas and real change to happen much faster than normal. The explosion of ransomware and increasing supply chain attacks against the backdrop of a global pandemic that have changed the very foundations of society, are creating the imperative to act. As we witness the growing attention software supply chain security is getting, it’s important to notice that we are no longer just talking about software supply chain security, we’re actually taking concrete steps to solve the problems. What will the future look like? Now we are starting to understand what the future will look like as we move toward solutions that will help better protect the software supply chain against these growing risks. In the past it was very common to conduct a security review once a product was “done”. This often resulted in a lot of missed security vulnerabilities being run in production or delivered to customers. Modern day development has changed such that security is expected to be tightly integrated into every step of the development process. This is where the term “shift left” originated. We are already seeing the beginning of this change with the growing attention paid to the software bill of materials (SBOM) and vulnerability scanning as critical components of software supply chain security. Neither of these ideas are new, but we are seeing convergence around SBOM standards. There are groups like The Linux Foundation’s OpenSSF and the Cloud Native Computing Foundation (CNCF) that are working in the open source ecosystem to create a common understanding of the problems and define potential solutions. The United States Cybersecurity and Infrastructure Agency (CISA) has a supply chain task force. Conferences have entire supply chain tracks to share emerging best practices. The time to address software supply chain security is here. There are new practices, processes, and tools that will need to be put into place to protect the software supply chain. While the importance of SBOM and vulnerability scanning is well understood, the critical challenge is in using the data to improve security. I think what we do with this data is the biggest area for improvement. Having an SBOM by itself isn’t useful. You need the ability to store it, track it over time, to aggregate the data, search the data, and get back actionable answers to questions. The same holds true for vulnerability scanning. Just scanning software after it has been built isn’t enough. What happens after the scan runs? How do you use the data to identify and remediate problems to reduce risk? I want to use the Heartbleed vulnerability as a great example of where we started, where we are today, and where I want to see us go next. If you were around for Heartbleed, it was an eye opening experience. Just determining which systems you had running a vulnerable version of OpenSSL was a herculean task. Most of us had to manually go looking for files on a disk. Today with our ability to generate and distribute SBOMs, it’s not hard to figure out what systems are using OpenSSL. We can even construct policies now that could prevent a new build or deployment that contains an old version of OpenSSL. The future I want to see is having insight into your end-to-end software supply chain and the security of the software you create and use. Being able to craft policies that can be enforced about what your software should look like. Not just having the ability to ask what a vulnerability or bug means for your application, but having tools that tell you before you even ask the question. Why Anchore? This all brings us to Anchore. I’ve known about Anchore for quite some time. In my previous role in Product Security, I worked with a large number of organizations focused on software supply chain issues. This included open source projects, software vendors, consultants, and even supply chain working groups. It became very obvious that while there was increasing focus on software supply chain security, there wasn’t always a consensus on the best practices or tooling needed. The current state of tools is very uneven. Few tools provide comprehensive SBOMs with all of the relevant metadata needed to make accurate security assessments and decisions. Some scanning tools want to report zero false positives, resulting in lots of false negatives. Other tools simplistically report every possible vulnerability which results in lots of irrelevant false positives. I’m not looking to point any fingers here, this is all very new and everyone is continuing to learn. In my experience the sweet spot is somewhere in the middle—some false positives should be expected, but too many or too few are both bad. The purpose of tooling is to help provide data to make decisions. Bad data results in bad decisions. Every time I interacted with any organization in the software supply chain space, I kept seeing Anchore as occupying the sweet spot in the middle over and over again. Anchore starts from a foundation of open source tools that are easy for developers to integrate and use. Syft, an open source SBOM generator, is incredibly useful and accurate. Grype, an open source vulnerability scanner, is one of the best vulnerability scanners I’ve ever used. Anchore’s commercial product, Anchore Enterprise, builds on that open source foundation and adds some powerful features for cataloging SBOMs, remediating vulnerabilities, and enforcing policies. Everywhere I looked it seemed that Anchore was the one company that “got it.” Anchore was doing all the things that were important to me in a way that made sense. Relevant scanning results, easy SBOM creation and use, and the ability to leverage existing policies (like CIS) instead of trying to build new ones. And lastly, open source. Open source isn’t something I think is a good idea, it’s part of who I am. My entire life has been shaped and built within the open source community. I know anywhere I work has to be extremely open, very open source friendly, and have a culture that mirrors the ways open source thinks and works. Anchore has the open source culture and open source focus that I know is so very important. They have a whole blog dedicated to their culture, give it a read, it’s fantastic! What’s next? The easiest way to see what’s next is to give the Anchore open source tools a spin. Generate an SBOM with Syft. Then scan the SBOM file for vulnerabilities with Grype. It’s all open, try them out, file some bugs, submit pull requests. Open source works best when everyone works together. If you want to pull it all together for an end-to-end solution for securing your software supply chain, check out Anchore Enterprise. It’s a nice way to tie the tools together in one place to meet the needs of a larger organization or multiple teams. I love to talk about these topics. If you’re interested in having a chat or even just saying hi feel free to reach out. Watch this space, there’s a lot to talk about, and even more work to do. It’s going to be a truly epic adventure! ### How to Check for CISA Catalog of Exploited Vulnerabilities Last week the United States Cybersecurity and Infrastructure Security Agency (CISA) published a binding operational directive describing a list of security vulnerabilities that all federal agencies are required to fix. Read the directive here: https://cyber.dhs.gov/bod/22-01/  The directive establishes a CISA-managed catalog of known exploited vulnerabilities that carry significant risk to federal agencies. The list can be found here: https://www.cisa.gov/known-exploited-vulnerabilities-catalog While CISA’s directive is binding only on U.S. federal agencies, companies can also leverage this catalog to prioritize vulnerabilities that may put their organization at risk. There has been a lot of discussion about this directive and what it will mean. Rather than add commentary about the directive itself, let’s discuss what’s actually inside this list of vulnerabilities and what actions you can take to check if you are using any of the software in question. It’s important to understand that the list of vulnerabilities in this catalog will not be static. CISA has stated in their directive that the list will be modified in the future, meaning that we can expect more vulnerabilities to be added. Even if a federal agency is not currently running any of the vulnerable software versions, as the list grows and evolves and the software that is running evolves, it will be important to have a plan for the future. Think about handling vulnerabilities like delivering the mail. Even if you finish all your work by the end of the day, there will be more tomorrow. If you work with lists of vulnerabilities you will be used to vulnerabilities having a severity assigned by the National Vulnerability Database (NVD). The NVD is a U.S. government repository of vulnerability data that is managed by the National Institute of Standards and Technology (NIST). The data in NVD enriches the CVE data set with additional product information as well as a severity rating for the vulnerability based on the CVSS scoring system. It is very common for policy decisions to be made based on the NVD CVSS severity rating. Any vulnerability with a CVSS score of critical or important is expected to be fixed very quickly, while more time is allowed to fix medium and low severity vulnerabilities. The idea is that these severity ratings can help us decide which vulnerabilities are the most dangerous, and those should be fixed right away. However, this new list of must-fix vulnerabilities from CISA goes beyond just considering the CVSS score. At the time of writing this the CISA list contains 291 vulnerabilities that require special attention. But why these 291 when there are an almost immeasurable number of vulnerabilities in the wild? The directive indicates that these vulnerabilities are being actively exploited, which means there are attackers using these vulnerabilities to break into systems right now. Not all vulnerabilities are created equally Examining the catalog of vulnerabilities from CISA, many of the IDs have received a rating of critical or important from NVD, but not all. For example CVE-2019-9978 is a Wordpress plugin with a severity of medium. Why would a medium severity rating make this list? Attackers don’t pay attention to severity. Remember this list isn’t based on the NVD CVSS severity rating, it’s based on which vulnerabilities are being actively exploited. CISA has information that organizations do not and is aware of attackers using these particular vulnerabilities to attack systems. The CVSS rating does not indicate if a vulnerability is being actively attacked, it only scores on potential risk. Just because a vulnerability is rated as medium doesn’t mean it can’t be attacked. The severity only describes the potential risk; low risk does not mean zero risk. How Anchore can help There are a few options Anchore provides that can help you handle this list. Anchore has an open source tool called Grype which is capable of scanning containers, archives, and directories for security vulnerabilities. For example, you can use Grype to scan the latest Ubuntu image by running docker run anchore/grype ubuntu:latest You will have to manually compare the output of Grype to the list from CISA to determine if you are vulnerable to any of the issues, luckily CISA has provided a CSV of all the CVE IDs here: https://www.cisa.gov/sites/defaultkn/files/csv/known_exploited_vulnerabilities.csv Here’s a simplified example you can use right now to check if a container is vulnerable to any of the items on the CISA list. First, use Grype to scan a container image. You can also scan a directory or archive; this example just uses containers because it’s simple. Extract just the CVE IDs, sort them, then store the sorted list in a file called scan_ids.txt in /tmp. docker run anchore/grype | sed -r 's/.*(CVE-[0-9]{4}-[0-9]{4,}).*/\1/g' | sort > /tmp/scan_ids.txt Next download the CISA csv file, extract the CVE IDs, sort it, and store the results in a file called “cisa_ids.txt” in /tmp/ curl https://www.cisa.gov/sites/default/files/csv/known_exploited_vulnerabilities.csv | sed -r 's/.*(CVE-[0-9]{4}-[0-9]{4,}).*/\1/g' | sort > /tmp/cisa_ids.txt Then compare the two lists, looking for any IDs that are on both lists comm -1 -2 /tmp/cisa_ids.txt /tmp/scan_ids.txt The “comm” utility when run with the “-1 -2” flags only returns things it finds in both lists. This command will return the overlap between the vulnerabilities found by Grype and those on the CISA list. If the container doesn’t contain any CVE IDs on the CISA list, then nothing is returned. Users of Anchore Enterprise can take advantage of a pre-built, curated CISA policy pack that will scan container images and identify any vulnerabilities found that are on the CISA list. Download the CISA policy pack for Anchore Enterprise here. Once downloaded, Anchore customers can upload the policy pack to Anchore Enterprise by selecting the Policy Bundles tab as seen below: Next, upload the policy pack by selecting the Paste Bundle button. If done correctly, you should see something very similar to what is depicted below, where you can see the raw json file loaded into the policy editor: Lastly, activate by clicking the radio button for the bundle, so that it can be used in your CI/CD pipelines and/or runtime scans to detect the relevant CVEs from the CISA catalog that are specified within the policy. You can now see the results generated by the CISA policy pack against any of your images, as demonstrated below against an image that contains Apache Struts vulnerabilities that are included within the CISA vulnerability list. From here, you can easily generate automated reports listing which CVEs from the CISA policy exist within your environments. Looking ahead Organizations should expect new vulnerabilities to be added to the CISA catalog in the future. Attackers are always changing tactics, finding new ways to exploit existing vulnerabilities, and finding new vulnerabilities. Security is a moving target and security teams must remain vigilant. Anchore will continue to follow the guidance coming out of organizations such as CISA and enable customers and users to take action to secure their environments based on that guidance. ### Creating a FedRAMP Compliance Checklist 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. Learn how Anchore brings DevSecOps to DoD software factories. 6. Express Security Policy as Code 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.  Download our FedRAMP containers checklist to help jump start your organization’s FedRAMP compliance checklist. ### 7 Tips to Create a DevSecOps Open Source Strategy 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. Open Source in the Thick of DevSecOps DevOps and DevSecOps can find their roots in the open source culture. DevOps principles have a lot in common with open source principles. 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. ### SBOM Tools: Drop an SBOM GitHub Action into your Workflow This blog post has been archived and replaced by the supporting pillar page that can be found here: https://anchore.com/wp-admin/post.php?post=987473412&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. ### Anchore Enterprise 3.2 Provides Increased Visibility to Identify More Risks in the Software Supply Chain Modern cloud-native software applications include software components and code from both internal developers and external sources such as open source communities or commercial software providers. Visibility into these components to identify vulnerabilities, security risks, misconfigurations, and bad practices is an integral part of securing the software supply chain. Anchore Enterprise 3.2 provides richer visibility into your software components so risks can be identified and quickly resolved. Discover and Mitigate Vulnerabilities and Security Risks Found in SUSE Enterprise Linux Containers SUSE container image scan results Anchore Enterprise 3.2 can now scan and continuously monitor SUSE container images for any security issues present in installed SUSE packages to improve their security posture and reduce threats. SUSE packages are now included in SBOMs as well as a comprehensive list of files. Additionally, customers can apply Anchore’s customizable policy enforcement to SUSE packages and vulnerabilities. Identify Vulnerabilities More Accurately with Our Next-Generation Scanning Engine Anchore Enterprise 3.2 now uses our next-generation scanning engine that builds upon capabilities in our open source tool Grype and also delivers more accurate results. Users will benefit from the fast pace of innovation while gaining all of the additional features that are available in Anchore Enterprise such as false-positive management. In addition, Grype users switching to Anchore Enterprise will benefit from consistent results between the two solutions, simplifying the transition. The 3.2 version of Anchore Enterprise provides richer visibility into your software components so risks can be identified and quickly resolved. Note: Existing customers will need to select the next-generation engine in order to take advantage of these benefits. All new installations will default to the new scanning engine. For more information on how to switch, please see the release notes. More Metadata Exposed in the UI for Policy Rules New metadata tabs Customers using Anchore Enterprise now have the ability to see additional SBOM file details in the UI that were previously available only through the API. This new UI visibility enables users to quickly and easily view data that can be instrumental in creating and tuning policy rules. The UI data additions include secrets for identifying credential information inadvertently included in container builds and file content checks which can be used for best practices such as making sure configurations are set correctly. The UI also now allows you to access retrieved files (files that you have designated to be saved during the scan) for further review and additional policy checks.  More Allowlist Customization Options in the UI Allowlist customized by Trigger ID Users now have additional Allowlist customization options in the UI. Allowlists enable development teams to continue working while issues are being investigated. Now in addition to vulnerabilities, users can add other policy checks to Allowlists through the UI which permits them to override specific policy violations for a more accurate final pass or fail recommendations on image scans. ### Expanding Container Security: Announcing Anchore Engine 1.0 and the Role of Syft and Grype It’s been an amazing five years working with you, our users, with more than 74,000 deployments across more than 40 releases since we initially shipped Anchore Engine. Today, we are pleased to announce that the project has now reached its 1.0 milestone. Much has changed in the world of container security since our first release, but the need for scanning container images for vulnerabilities and other security risks has been a constant.  Anchore Engine 1.0 includes a focused feature set that is the result of working directly with many organizations toward securing cloud-native development environments and also represents an update to Anchore’s overall approach to delivering DevSecOps-focused open source tools. New code, New Speed Over and over again, we’ve heard that the three most important criteria for a container scanning tool is that it needs to be quick, it needs to be accurate, and it needs to be easy to integrate into existing development toolchains. To support those needs, last year we took the lessons learned over years of developing Anchore Engine and created two new command line tools: Syft and Grype. Syft generates a high-fidelity software bill of materials (SBOM) for containers and directories, and Grype performs a vulnerability analysis on the SBOMs created by Syft or against containers directly.  With the release of 1.0, we’ve now refactored Anchore Engine to embed these stateless tools for core scanning functions, improving the speed of container image scans and ensuring parity between stand-alone stateless Syft/Grype scans and those produced in the stateful Anchore Engine service. We’ve also cut the time for the initial sync of the vulnerability DB from hours to seconds, getting new users up-and-running even faster than before. Feed Service Deprecation Prior to the 1.0 release, deployments of Anchore Engine periodically connect up to our public feed service, hosted in the cloud. The vulnerability data would then be pulled down and merged into your local Anchore Engine database. This merge process often took a while due to the per-record insert-or-update process.  With the new Grype-based scanner, the vulnerability data is now managed using Grype itself using a single file transfer that updates the entire vulnerability database atomically. The vulnerability data itself is generated from the same sources as the public feed service ensuring that you’ll see no drop in distro or package ecosystem coverage. Since Anchore Engine 1.0 will no longer use the public feed service, we plan to sunset the non-Grype feed service on April 4, 2022, which we’ve chosen in order to give all users of Anchore Engine the time to plan and execute upgrades to Anchore Engine 1.0+. After April 4, 2022, any existing deployments of Anchore Engine prior to 1.0 will continue to operate, but will no longer be receiving new vulnerability data updates. New Tools for CI/CD When Anchore Engine was created, scanning was centered around the container registry. Now, with GitHub Actions, GitLab Runners, Azure Pipelines, and the ever present Jenkins, scanning in the CI/CD pipeline is fast becoming the norm. We originally created our inline scanner script (inline_scan) to wrap around Anchore Engine and facilitate this workflow, and it did its job well. With Syft and Grype now delivering the same capabilities as inline_scan (and much more), in a faster and more efficient fashion, we are also retiring the project.  As of 1.0, we will no longer be updating inline_scan with new releases of Anchore Engine, and we will stop updating the existing inline_scan images after January 10, 2022. Similarly, our existing native CI/CD integrations based on inline_scan will be or have already been, updated to use Grype internally.  The Road Ahead Going forward, Syft and Grype will be the best choice for developers and DevOps engineers that need to integrate scanning into their CI/CD pipelines. Anchore Engine 1.0 will continue to play the role of providing persistent storage for the results of CI/CD scans as well as automated registry scanning. Because Anchore Engine 1.0 is built on the common core of Syft and Grype, you will get a consistent result regardless of where you need scans performed and which tools you use. With the foundational role that SBOMs will play in software supply chain security and the fast moving changes to the various CI/CD platforms, we have an ambitious roadmap for Syft and Grype. Our goal is to make Syft the best open source tool for generating an SBOM and Grype the best tool for reporting discovered vulnerabilities. Anchore Engine will continue to receive updates and improvements, but with registry scanning requirements being relatively static we are not planning any major new capabilities at this time. Our commercial solution, Anchore Enterprise, will continue to be focused on helping security teams to manage the whole security lifecycle with centralized policy control, audits, and integrations with enterprise platforms. We are committed to ensuring that users who chose to use Syft, Grype and Anchore Engine have a quick and easy path if and when they are ready to make the transition.  Anchore is committed to open source, recognizing that it is the best way to give DevOps teams the tools they need to move fast. Whether you use Syft, Grype, or Anchore Engine, we look forward to working together with you on your DevSecOps journey. You can connect with us on Discourse or GitHub. We’ll also be hosting a webinar on October 20, 2021 to walk you through our open source and enterprise solutions and explain the role and capabilities of each. Register here. Important Resources Anchore Engine 1.0 Installation Instructions  Syft Github Getting Started Video Demo of Syft Grype  GitHub Getting Started Video Demo of Grype Anchore Enterprise Getting Started Video Demo of Anchore Enterprise Compare Anchore open source and enterprise solutions Register for October 20 webinar Important Dates October 1, 2021 - Anchore Engine 1.0 Available October 20, 2021 - Webinar on Anchore open source and enterprise solutions. Register here. January 10, 2022 - the inline_scan project will be retired.  Users can switch to using syft/grype for stateless security scans.  Executions of inline_scan will continue to function but will no longer receive vulnerability data updates. inline_scan will not be updated with Engine 1.0. It will remain on 0.10.x until retirement. April 4, 2022 - The public feed service, ancho.re, will no longer be available.  Anchore Engine users need version 1.0+ using the v2 scanner to receive new vulnerability data updates.  Existing users will continue to function but will no longer receive vulnerability data updates. ### The 3 Shades of SecDevOps We live and work in a time of Peak Ops. DevOps. DevSecOps. GitOps. And SecDevOps, to name a few. It can be confusing to discern the reality through the marketing spin. However, SecDevOps is one new form of Ops that’s worth keeping in mind as you face new and emerging security and compliance challenges as your organization pulls out of the pandemic. Here’s what I call the three shades of SecDevOps definitions: SecDevOps: The Ops Definition SecDevOps -- also called rugged DevOps -- places security first in the development process. SecDevOps and DevSecOps differ in the order of security considerations during the software development life cycle (SDLC). It’s a nascent school of thought which goes as far as comparing SecDevOps vs. DevOps. SecDevOps requires a thorough understanding of how the application works to identify how it can be vulnerable. Such an understanding gives you a clearer idea of how you can protect your application from security threats. Threat modeling during the SDLC is an industry best practice for gaining such an understanding. There are two distinct parts in SecDevOps: Security as Code Security as Code (SaC) is when you build security into the tools and practices in your DevOps pipeline. Static application security testing (SAST) and dynamic application security testing (DAST) solutions automatically scan applications coming through the pipeline. SaC places priority on automation over manual processes. Manual processes do remain in place for security-critical components of the application. Implementing SaC is an essential element of DevOps toolchains and workflows. Infrastructure as Code Infrastructure as Code (IaC) refers to a set of DevOps tools for setting up and updating infrastructure components to ensure a hardened and controlled deployment environment. The same code development rules are used to manage operations infrastructure instead of manual changes or one-off scripts that often take place these days. With IaC, mitigating a system problem takes deploying a configuration-controlled server versus the old way of patching and updating servers already in production. SecDevOps uses continuous and automated security testing starting before the application goes into production. It implements issue tracking to ensure the early identification of any defects. It also leverages automation and testing to provide effective security tests throughout the software development lifecycle. SecDevOps: The DevSecOps Synonym  Then again, some organizations use the term SecDevOps synonymously with DevSecOps. There’s nothing wrong here. For example, a government agency focusing on security may use the term to mean DevSecOps. It’s semantics because they want to emphasize the importance of security in their software development. SecDevOps: The Marketing Spin Definition The Ops market is full of competition. It’s natural for marketers to want to spin the definition of SecDevOps so that it best suits the products and solutions that their company is selling to prospective customers. The best way to digest a marketing spin definition is to define what SecDevOps means for your organization. Don’t let salespeople define SecDevOps for you. Final thoughts Regardless of your school of thought about the three shades of SecDevOps, it’s about the people, culture, processes, and technology. A positive outcome of our current age of Peak Ops is that we all have a lot to learn from other schools of Ops thought, so soak in the SecDevOps definition and see what you can learn from it to apply to your organization’s DevSecOps practices. ### Drop an SBOM: How to Secure your Software Supply Chain Using Open Source Tools In the past few years, the number of software supply chain attacks against companies has skyrocketed. The incessant threat is pushing organizations to start figuring out their own solutions to supply chain security. The recent Executive Order on Improving the Nation’s Cybersecurity also raises new requirements for software used by the United States government. Securing the software supply chain is no easy task! Software supply chains continue to grow in complexity. Software may come from open source projects, commercial software vendors, and your internally-developed code. And with today’s cloud-native, container-centric practices, development teams are consuming, building, and deploying more software today than they ever have before. So this begs the question: “Is your team deploying software that might lead to the next headline-grabbing supply chain hack?” Some supply chain hacks happen when software consumers don’t realize they are using vulnerable software, while other hacks can occur when the origin or contents of the software has been spoofed by malicious actors. If you’d like to avoid falling victim to these types of attacks, keep reading. To start off, let’s step backward from the worst-case scenario… I don’t want my company to make headlines by having a massive security breach, so… I don’t want to deploy any software artifacts that are known to have vulnerabilities, so… I need to know which of my installed software packages are vulnerable, so… I need to know what my installed software packages are, so… I need to analyze my artifacts to determine what software they contain. The Ingredients of Supply Chain Security Any effective solution to securing your supply chain must include two ingredients: transparency and trust. What does that mean? Transparency: Discovering What is There Inevitably, it all starts with knowing what software is being used. You need an accurate list of “ingredients” (such as libraries, packages, or files) that are included in a piece of software. This list of “ingredients” is known as a software bill of materials (SBOM). Once we have an SBOM for any piece of software we create or use, we can begin to answer critical questions about the security of our software supply chain. It’s important to note that SBOMs themselves also serve as input to other types of analyses. A noteworthy example of this is vulnerability scanning — discovering known security problems with a piece of software based on previously published vulnerability reports. Detecting and mitigating vulnerabilities goes a long way toward preventing security incidents. In the case of software deployed in containers, developers can use SBOMs and vulnerability scans together to provide better transparency into container images. When performing these two types of analyses within a CI/CD pipeline, we need to realize two things: Each time we create a new container image (i.e. an image with a unique digest), we only need to generate an SBOM once. And that SBOM can be forever associated with that unique image. Nice! Even though that unique image never changes, it’s vital to continually scan for vulnerabilities. Many people scan for vulnerabilities once an image is built, and then move on. But new vulnerabilities are discovered and published every day (literally) — so it’s vital to periodically scan any existing images we’re already consuming or distributing to identify if they are impacted by new vulnerabilities. Trust: Relying on What is There While artifacts such as an SBOM or vulnerability report provide critical information about software at various points in the supply chain, software consumers need to ensure that they can rely on the origin and integrity of these artifacts. Keep in mind that software consumers can be customers or users outside your organization or they can be other teams within your organization. In either case, you need to establish “trust”. One of the foundational approaches to implementing “trust” is for software producers to generate artifacts (including SBOMs and vulnerability reports) that attest to the contents of the software (including SBOMs and vulnerability reports), and then sign those artifacts. Software consumers can then verify the software, SBOM and vulnerability report for an accurate picture of both the contents and security status of the software they are using. To implement signing and attestation, development teams have to figure out how to create the SBOM and vulnerability reports, which crypto technology to use for signing, how to manage the keys used for signing, and how to jam these new tools into their existing pipelines. It’s not uncommon to see a “trust” solution get misimplemented, or even neglected altogether. Ideally, solving for trust would be easy and automated. If it was, development teams would be much more likely to implement it. What might that look like? Let’s take a look at how we can build transparency and trust into an automated workflow. Building the Workflow To accomplish this, we’re going to use three open source CLI tools that are gaining traction in the trust and transparency spaces: Cosign:  container signing, verification and storage in an OCI registry (one of the tools in the Sigstore project) Syft:  software bill of materials generator for container images and filesystems Grype: vulnerability scanner for container images and filesystems If you learn best by seeing a working example, we have one! Check out https://github.com/luhring/example-container-image-supply-chain-security. We’re using GitHub Actions and GitHub’s container registry, but these practices apply just as well to any CI system and container registry. In our example, we’ve created a container image that’s been intentionally designed to have vulnerabilities, using this Dockerfile. But you should apply the steps below to your own container images that your team already builds. Signing the Image Since we’re adding trust and analysis for a container image, the first step is to provide a way to trust the origin and integrity of the container image itself. This means we need to ensure that the container image is signed. For this, we’ll use Cosign. Cosign is a fantastic tool for signing and verifying container images and related artifacts. It can generate a public/private key pair for us, or it can hook into an existing key management system. For the simplicity of this demonstration, we’ll use “cosign.key” and “cosign.pub” files that Cosign generates for us. Outside of our CI workflow, we’ll run this command, set a password for our private key, and store these files in GitHub as secrets. cosign generate-key-pair Then in our workflow, we can use these keys in our Cosign commands, such as here to sign our image: cosign sign -key ./cosign.key "$IMAGE" Conveniently, this command also pushes the new signature to the registry for us. Analyzing the Image Now that we have an image we can trust, we can begin asking critical questions about what’s inside this image. Creating an SBOM Let’s start by generating an SBOM for the image. For this, we’ll use Syft. Syft is a great tool for discovering what’s inside an image and creating SBOMs that can be leveraged downstream. syft "registry:$IMAGE" -o json > ./sbom.syft.json Having an SBOM on file for a container image is important because it lets others observe and further analyze the software packages found in the image. But we can’t forget: other people need to be able to trust our SBOM! Cosign lets us create attestations for container images. Attestations allow us to make a claim about an image (such as what software is present) in such a way that can be cryptographically verified by others that depend on this information. cosign attest -predicate ./sbom.syft.json -key ./cosign.key "$IMAGE" Like with the “sign” command, Cosign takes care of pushing our attestation to the registry for us. Scanning for Vulnerabilities Okay, now that we have an SBOM that we can trust, it’s critical to our security that we understand what vulnerabilities have been reported for the software packages in our image. For this, we’ll use Grype, a powerful, CLI-based vulnerability scanner. We’ll use Grype to scan for vulnerabilities using the SBOM from Syft as the target. grype sbom:./sbom.syft.json -o json > ./vulnerability-report.grype.json Just as we did with our SBOM, we’re going to “attest” this vulnerability report for our image, which allows others to trust the results of our scan. cosign attest -predicate ./vulnerability-report.grype.json -key ./cosign.key "$IMAGE" Remember that it’s crucial that we continuously scan for vulnerabilities since new vulnerabilities are reported every day. In our example repo, we’ve set up a nightly pipeline that looks for the latest SBOM, verifies the attestation using Cosign, and if valid, uses the SBOM to perform a new vulnerability scan. Why Did We Do All of That? Armed with an attested SBOM and vulnerability report, consumers of our image can depend on both the contents of the software and our scan results to understand what software vulnerabilities are present in the container image we’ve shipped. Here’s how someone could leverage the trust and transparency we’ve created by verifying the attestations in their own workflow: cosign verify-attestation -key ./cosign.pub “$IMAGE” If the attestation can be verified, cosign retrieves all of the attestation data available for the container image. Depending on the scenario, there can be a large amount of attestation data. But this opens up a lot of options for downstream users that are depending on the ability to trust the container images they’re consuming. Here’s an example of how to use an attestation to find all of the reported vulnerabilities for a container image. (This command assumes you’ve downloaded the cosign.pub public key file from our example). cosign verify-attestation -key ./cosign.pub ghcr.io/luhring/ example@sha256:1f2d8339eda7df7945ece6d3f72a3198bf9a0e92f3f937d4cf37adcbd21a006a | jq --slurp 'map(.payload | @base64d | fromjson | .predicate.Data | fromjson | select(.descriptor.name == "grype")) | first | .matches | map(.vulnerability.id) | unique' Yes, it’s a long command! But that’s only because we’re using the console. This gets much easier with tooling designed to verify signatures and attestations on our behalf. Final Thoughts Now is the time to invest in the security of your software supply chain. Equipped with the knowledge above, you can start to bake trust and transparency into your own pipelines right now. This mission can be daunting — it’s difficult or impossible without great tooling. We’ve now built a workflow that uses Cosign, Syft, and Grype to: provide transparency into the contents and the security of our container image, and create trust that the output from any given step is valid to use as the input to the next step. With Cosign, Syft, and Grype, you’re much closer to securing your supply chain than you were before. Here’s how to get started with each: Cosign: https://github.com/SigStore/cosign#installation Syft: https://github.com/anchore/syft#installation Grype: https://github.com/anchore/grype#installation And most importantly, remember that these tools are entirely open source. Please consider giving back to these communities! Add issues, open PRs, and talk to us in the Sigstore and Anchore community Discourse forum. The biggest challenges are overcome when great minds come together to create solutions. ### 7 Principles of DevSecOps Automation This blog post has been archived and replaced by the supporting pillar page that can be found here: https://anchore.com/wp-admin/post.php?post=987473388&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. ### 5 DevSecOps Best Practices for Hybrid Teams 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.  ### DevOps Supply Chain Security: A Case for DevSecOps 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: Visibility into dependencies through the use of automated container scanning and SBOM generation 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. Want to learn more about supply chain security? Download our Expert Guide to Software Supply Chain Security White Paper! ### 4 Kubernetes Security Best Practices Kubernetes security best practices are a necessity now as Kubernetes is becoming a defacto standard for container orchestration. Many of the best practices focus on securing Kubernetes workloads. Managers, developers, and sysadmins need to make it a habit to institute early in their move to Kubernetes orchestration. Earlier this year, respondents to the Anchore 2021 Software Supply Chain Security Report replied that they use a median of 5 container platforms. That’s testimony to the growing importance of Kubernetes in the market. ”Standalone” Kubernetes (that are not part of a PaaS service) are used most often by 71 percent of respondents. These instances may be run on-premise, through a hosting provider, or on a cloud provider’s infrastructure. The second most used container platform is Amazon ECS (56%), a platform-as-a-service (PaaS) offering. Tied for third place (53%) are Amazon EKS, Azure Kubernetes Services, and Red Hat OpenShift. A common industry definition for a workload is the amount of activity performed or capable of being performed within a specified period by a  program or application running on a computer. The definition is often loosely applied and can describe a simple “hello world” program or a complex monolithic application. Today, the terms workload, application, software, and program are used interchangeably. Best Practices Here are some Kubernetes security best practices to keep in mind 1. Enable Role-Based Access Control Implementing and configuring Role-Based Access Control (RBAC) is necessary when securing your Kubernetes environment and workloads. Kubernetes 1.6 and later enable RBAC by default (later for HAProxy); however, if you’ve upgraded since then and haven't changed your configuration since then, you should double-check it. Due to how Kubernetes authorization controllers are combined, you will have to enable RBAC and disable legacy Attribute-Based Access Control (ABAC). Once you start enforcing RBAC, you still need to use it effectively. You should avoid cluster-wide permissions in favor of namespace-specific permissions. Don't give just anyone cluster admin privileges, even for debugging - it is much more secure to grant access only as needed. 2. Perform Vulnerability Scanning of Containers in the Pipeline Setting up automated Kubernetes vulnerability scanning of containers in your DevSecOps pipelines and registries is essential to workload security. When you automate visibility, monitoring, and scanning across the container lifecycle, can you remediate more issues in development before your containers reach your production environment. Another element of this best practice is to have the tools and processes in place to enable the scanning of Kubernetes secrets and private registries. This is another essential step as software supply chain security continues to gain a foothold across industries.  3. Keep a Secret A secret in Kubernetes contains sensitive information, such as a password or token. Even though a pod cannot access the secrets of another pod, it’s vital to keep a secret separate from an image or pod. A person with access to the image would also have access to the secret. This is especially true for complex applications that handle numerous processes and have public access. 4. Follow your CSP’s Security Guidelines If you’re running Kubernetes in the cloud, then you want to consult your cloud service provider’s guidelines for container workload security. Here are links to documentation from the major CSPs: Amazon Web Services Google Cloud Platform Microsoft Azure Along with these security guidelines, you may want to consider cloud security certifications for your cloud and security teams members. CSPs are constantly evolving their security offerings. Just consulting the documentation when you need it may not be enough for your organization’s security and compliance posture.        Final thought Kubernetes security best practices need to become second nature to operations teams as their Kubernetes adoption grows. IT management needs to work with their teams to ensure the best practices in this post and others make it into standard operating procedures if they aren’t already. Want to learn more about container security practices? Check out our Container Security Best Practices That Scale webinar, now on-demand! ### Cloud Migration Security Challenges: 5 Ways DevSecOps Can Help DevSecOps is playing a growing role in cloud migrations, especially in the public sector. Even before the Executive Order on Improving the Nation’s Cybersecurity Executive Order, agencies had to face cloud migrations with an eye on security to ensure their cloud projects met FedRAMP compliance. Here are some ways that DevSecOps can help your agency or organization meet cloud migration challenges: 1. Improves Information Processing When a DoD or other government program moves to the cloud and a DevSecOps model, it fundamentally transforms how they interact with data. DevSecOps gives government agency and DoD programs the tools, processes, and frameworks to develop applications quickly and capitalize on data to help them respond to data-intensive mission challenges such as big data data analysis, fraud detection, and trends data. To say information is power now considering government responses to natural disasters, COVID-19, and other threats on the world stage. For example, DevSecOps gives development teams in the public sector a new ability to migrate legacy applications to the cloud securely to enable access so they can open them up a new hybrid workforce. 2. Provides Security by Design for New Cloud Projects “Shift security left” is a common refrain about DevSecOps. More importantly, DevSecOps brings security by design to public sector cloud projects. When you consider DevSecOps as part of your program’s cloud migration strategy, DevOps and security teams can collaborate on workload protection, secure landing zones, operating models, network segmentation, and the implementation of zero trust architecture (ZTA) because both teams get input and buy-in during the design phase in regards to functional requirements, data flows, and workstreams.  DevSecOps, by its nature, also provides the feedback loops and collaboration channels that you don’t find in the public sector’s legacy model of long-term contracts, multiple vendors, and silos between developers, cybersecurity, stakeholders, and constituents. 3. Automation of Builds and Testing Automation is becoming one of the keys to security and overall success with public sector cloud projects. Implementing a DevSecOps toolchain or upgrading your existing DevOps toolchain for DevSecOps provides the tools for automation of container security scanning and compliance checks. With some government contracting pundits saying up to 80% of agency IT staff’s daily work is just keeping the lights on, moving technical staff to more mission-critical and strategic work will benefit the program. A cloud migration -- by its very nature -- requires some time for your teams to learn and harness the latest cloud services. Being able to retask team members from fairly rote tasks such as running software builds to critical tasks such as implementing new cloud services benefits government programs small and large and, in turn, the taxpayer. 4. Supports Secure Iteration of Cloud Applications Following a DevSecOps methodology gives you a secure method for iterating on application features. For example, let’s say your agency is moving a legacy application to the cloud. Moving legacy agency applications to the cloud requires a process that secures the application and its data from inside the agency data into the cloud. If the choice is made to refactor your application, your users can use new cloud services that improve security and user experience (UX).  DevSecOps adds a new layer of security over these everyday development tasks: Adding new features using DevSecOps can help the project gain the delivery velocity of a consumer app store versus the quarterly or yearly feature releases common to public sector software development Allowing applications to take advantage of containers and microservices architectures Enabling application optimization using the cloud service provider’s infrastructure that wasn’t previously available in agency data centers Another option is to rebuild a legacy application for the cloud. Moving to DevSecOps and containers brings with it significant code changes. Still, such an investment could be worth it depending on the purpose of the application, and the changing user and constituent landscape as remote and hybrid work grow in dominance. 5. Sets a Foundation for a Security Culture DevSecOps and moving to the cloud require a cultural transformation for today’s public sector agencies to meet cloud migration security challenges. Bringing DevSecOps into your program’s cloud migration process is another step in making security part of everybody’s job.  When your cloud migration and development teams adopt DevSecOps, it opens up new opportunities for reporting that enable you to best communicate the progress and security status of your cloud migrations to your internal stakeholders.  DevSecOps and Cloud Benefits in Full View The DoD and the public sector are gradually realizing the benefits of DevSecOps and the cloud. Bringing DevSecOps into your cloud migration framework gives you new tools to maintain security and compliance of your legacy applications and data as they leave your agency data centers and make their journey to the cloud. Download our Expert Guide to DevOps to DevSecOps Transformation to learn more about DevSecOps to help prepare for your next cloud migration security challenges! ### Advancing Software Security with Technical Innovation 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. ### The Power of Policy-as-Code for the Public Sector 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: Intro to DoD Software Factory Outline for Getting Up to Speed on the DoD Software Factory How Anchore Secures Software Factories Policy-as-Code: Current and Future States 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. Policy-as-code can also serve as another automation tool for FedRAMP and Security Technical Implementation Guide (STIG) testing as more agencies move their systems to the cloud. Look for the backend tools that can make this happen gradually to improve over the next few years. Managing Cultural and Procurement Barriers 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. Interested to see how the preeminent DoD Software Factory Platform used a policy-based approach to software supply chain security in order to achieve a cATO and allow any DoD programs that built on their platform to do the same? Read our case study or watch our on-demand webinar with Major Camdon Cady. ### The Broad Impact of Software Supply Chain Attacks 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. Do you want more insights into container and software supply chain security? Download the Anchore 2021 Software Supply Chain Security Report! ### 5 Tips for Improving your DevOps Methodology Post-COVID The time is now to review your current DevOps methodology and look for areas of improvement. The fog is lifting off our pandemic-enforced lockdowns and your teams have most definitely learned a lot during the past year-plus of remote work. Most of all, your teams have had to stretch and pivot because your in-place development methodologies weren’t ideal for remote or hybrid team working models. 1. Conduct a Post Mortem of your DevOps Methodology During the Pandemic DevOps is about continuous learning and feedback. Take the time as your organization opens up to a hybrid work model or doubles down on remote work to take stock of how your method fared during the pandemic. Talk to your development and operations teams about what technology worked during the pandemic for them. Ask about your toolchains, automation, and security. Did your teams have to do any workarounds in the remote world? If so, make sure you capture and document them for future reference and for the benefit of your organization. Also, reflect on the temperature of your DevOps culture. Did your teams not miss a beat once you moved to a remote working model? Did working remotely adversely affect your collaboration and communication between team members? Are there concerns about how a hybrid work model affects team collaboration and communications? Such a post-mortem doesn’t mean calling yet another meeting. You can push out questions through your Slack channels plus meetings and standups that are already on your calendars.   2. Review your Definition of DevOps Success It’s important to have a definition of DevOps success for your organization. Some common measurements of DevOps success include: Availability and uptime Work in progress Repository speed Deployment frequency Deployment stability The first step here is to evaluate whether your pre-pandemic measurements of DevOps success still apply today. Review your current measurements against your operations and performance during the past year-plus of remote working. Be sure to document any changes to your measurements and communicate that to your DevOps teams. 3. Update Developer Onboarding Training with your DevOps Methodology While you shift your operations to a post-pandemic working model, whether remote or hybrid, take the time to review and update your developer onboarding training. Here are some examples of onboarding training items to capture or update and communicate: Communications and collaboration channels for escalation of issues and problem solving Accounts and access to cloud services Documentation of your DevOps Methodology in written and graphical form Training on your toolchain in written and graphical form (Bonus points for a video) Standard practices and create reference materials to ensure that your teams are following the DevOps methodology you set for your organization, not the developer’s interpretation of DevOps. Some developers may also carry forth DevOps practices from their previous employer. 4. Automate your Workflows According to the 2021 Anchore Software Supply Chain Security Report, only 47% of the respondents have automated remediation workflows to help developers fix issues that are identified in scanning. Now is the time to review the automation (or lack thereof) of your remediation workflows. While you’re at it, take stock of other automation opportunities across your DevOps pipelines to help improve the productivity of your development organization. 5. Conduct a DevOps to DevSecOps Transformation Cybersecurity lessons are all around us now. There comes a time when even a finely tuned and maintained DevOps methodology needs to support additional security requirements. As new breaches make headlines, new government executive orders (EOs) hit the street, and attack vectors now could be time for your organization to make a full-blown DevOps to DevSecOps transformation. Making such a transformation is the best way to lock down the security of your DevOps toolchains and software supply chain. Final Thoughts A DevOps methodology should represent the current state of a development organization complete with lessons learned. Taking a continuous improvement approach especially after such a life-changing event as the pandemic makes good business sense. Work to maintain your development team’s agility and prepare to face challenges in the new world of work together. Do you want to learn more about DevOps pipelines? Check out our on-demand webinar, How To Secure Your DevOps Pipeline In a Post-SolarWinds World! ### What’s Critical Software? NIST Responds Part of President Biden’s May 12, 2021 Cybersecurity Executive Order (EO) is for the National Institute of Standards and Technology (NIST) to define critical software as part of the goal for strengthening the security of government purchased software. NIST recently delivered on that aim and the definition of critical software has the potential to influence government IT as a whole. Plus the companies that sell IT services and software into the federal government could feel the impact in unexpected ways. Let’s take a closer look... The Meaning of Critical Software Software runs the United States federal government. It powers the processing of government benefits. Government researchers on the front lines of the pandemic rely on cloud computing power. America’s warfighters rely on software to run logistics, process real-time intelligence, and for R&D. Here’s the official NIST definition of critical software: EO-critical software is defined as any software that has, or has direct software dependencies upon, one or more components with at least one of these attributes: is designed to run with elevated privilege or manage privileges; has direct or privileged access to networking or computing resources; is designed to control access to data or operational technology; performs a function critical to trust; or, operates outside of normal trust boundaries with privileged access. This definition strikes at the heart of software in government and DoD infrastructure. Critical software manages access to mission-critical systems that play key roles in government programs including support of the warfighter, intelligence community (IC), and other government programs that support the health and vitality of United States citizens and the economy. The preliminary list of software categories includes software at every level of the technology stack: Identity, credential, and access management (ICAM) Operating systems, hypervisors, container environments Web browsers Endpoint security Network control Network protection Network monitoring and configuration Operational monitoring and analysis Remote scanning Remote access and configuration management Backup/recovery and remote storage NTIA defines “Critical to trust,” as “categories of software used for security functions such as network control, endpoint security, and network protection.” Critical Software: Definition + Dependencies As required by the order, NIST’s definition of critical software focuses heavily on software that has elevated privileges or controls access to an organization’s computing resources along with related direct software dependencies. Here’s the definition from NIST: “Direct software dependencies,” means, for a given component or product, “other software components (e.g., libraries, packages, modules) that are directly integrated into, and necessary for operation of, the software instance in question. This is not a systems definition of dependencies and does not include the interfaces and services of what are otherwise independent products.” The direct software dependencies mentioned are where the definition of critical software gets interesting. Agency and DoD software development bring together the work of multiple vendors and open source projects. Government programs are going to need a level of software transparency now that maybe wasn’t in their previous request for proposals (RFPs).  It’s the NIST definition of dependencies that gives new meaning to critical software. Dependencies mean software libraries, packages, and modules that are necessary for software operations. NTIA has quite a task deciding how deep a software bill of materials (SBOM) detail should go into when capturing software composition. Industry Feedback  & SBOM Visibility Industry feedback has been sent to the NTIA asking for flexibility, especially on how deep an SBOM should be required to go in describing its transitive dependencies, according to NextGov.  Granted there’s still an industry need for a definitive software bill of materials (SBOM) standard, the comments focus on SBOM limitations due to software versioning and identification issues. They also cite the importance of context when it comes to vulnerability information. Lastly, they mention the level of effort and resources required to prepare SBOMs. While the SBOM isn’t a new thing in software development, yet it’s not in as wide of use as you’d expect. President Biden’s cybersecurity executive order has the potential to finally give the SBOM some teeth.  SBOM generation to be effective requires automation and just as importantly, a definitive industry standard. Automated generation of SBOMs is a natural step in a DevOps or DevSecOps toolchain. Platform-centric toolchains can make this a new feature or API-based integration. Traditional DevOps/DevSecOps toolchains are open for integration as well. Government acquisitions and procurement officials have yet to enter the critical software discussion. The definition that NTIA is championing is going to have an impact on how request for proposals (RFPs), statement of works (SOWs), and even the other transaction authority (OTA) procurement vehicles. Post-cybersecurity EO RFPs must now account for: SBOM generation SBOM management and security SBOM reporting requirements Such additional considerations may expand the scope of RFPs. Expect a learning curve from agency contracting officers and respondents alike during the first round of IT proposals. 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. ### Settling into a Culture of Kindness 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.    ### Developing Passionate and Supportive Leaders 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. ### Anchore Enterprise 3.1 Streamlines End-to-End Container Security Container security is a team sport.  Development teams need to avoid delays by finding and fixing security issues early in development, while DevOps teams must check compliance before they deploy. Security teams must continuously monitor for new vulnerabilities that impact production environments. Collaboration among these teams is required for efficient and effective security processes. Anchore Enterprise 3.1 adds new capabilities to expand automation of container security across these stages from development to production. This will advance the team’s collective goals and ultimately, speed to market. Runtime Image Monitoring for Continuous Security Anchore Enterprise 3.1 makes it easy to monitor your running containers and quickly evaluate images for security and compliance risks. Security teams can now watch entire Kubernetes clusters, gain visibility into overall risk in production, and be alerted of new vulnerabilities. Our new UI makes it easy to layer in our extensive policy language and start using Anchore’s admission controller to enforce security across your critical Kubernetes clusters. Watch a video of Runtime Image Monitoring in action. New AnchoreCTL Client Automates Pipeline Scanning  Designed for use with Anchore Enterprise, AnchoreCTL is a new command-line client that makes it easier to automate container scanning within the CI/CD pipeline. With AnchoreCTL, customers can distribute scanning tasks across their CI/CD platforms and pipelines, increasing throughput and reducing time-to-analyze for Anchore Enterprise.  AnchoreCTL incorporates the capabilities of Anchore open source tools Syft (SBOM generator) and Grype (vulnerability scanner) while adding support for the reporting and compliance APIs in Anchore Enterprise. AnchoreCTL is also fully supported under the Anchore Enterprise support agreement and SLAs. Those who are ready to move from open source to Anchore Enterprise will benefit from an easy migration path from Syft and Grype to AnchoreCTL.  AnchoreCTL can be installed through a binary, container, or a growing number of package managers. Watch a video of AnchoreCTL here. Simplified STIG Compliance for US Federal Agencies The Federal Edition of Anchore Enterprise 3.1 greatly simplifies the process of DISA Security Technical Information Guide (STIG) checks for containers running in a Kubernetes cluster. With Anchore’s new cloud-native tool  STIG tool REM, federal agencies can fully automate what was once a time-consuming manual process. The results of STIG checks are aggregated and correlated within Anchore Enterprise, providing security teams with a single pane of glass to report on STIG compliance issues along with vulnerabilities and other compliance checks. Watch a video of STIG Compliance Checks. ### Kubernetes Adoption by the Numbers Our recent 2021 Anchore Supply Chain Security Survey sheds some light on Kubernetes adoption and growth in the enterprise as it pertains to running container workloads.  For this blog post, container platforms based on Kubernetes run containerized applications, whether during development and testing, staging, or production. These platforms run in house, through a hosting provider, or from a cloud provider or another vendor. K8s Stands Alone Perhaps the most interesting Kubernetes stat in the survey is that 71% of respondents are using a “standalone” version of Kubernetes that’s not part of a platform as a service (PaaS) rather it’s run on-premise or even on cloud infrastructure as a service (IaaS). The second most used container platform is Amazon Amazon Elastic Container Service (ECS) with 56%.  53% of the respondents are using Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Services, and Red Hat OpenShift for their container management and orchestration. We’re at an interesting point for Kubernetes adoption as these numbers show. While there’s a well-known Kubernetes skills gap, organizations are still relying on their own teams, most likely augmented with outside contractors to deploy and operate Kubernetes. While the major cloud service providers (CSPs) are the logical platform for outsourcing Kubernetes infrastructure and the related backend management tasks the numbers point to the fact they are still gaining mindshare in the Kubernetes market. K8s and Large Workloads Cloud-native software development is now delivering at an enterprise-scale on major development projects that include 1000+ containers. Here’s the spread of Kubernetes adoption in use on these business and mission-critical projects: Standalone Kubernetes (7%) Amazon ECS (7%) Amazon EKS (7%) Azure Kubernetes Service (7%) SUSE-Rancher Labs (6%) This tight spread of K8s platforms paints an interesting picture of the scale where these large enterprise projects play. Standalone Kubernetes, Amazon ECS, Amazon EKS, and Azure AKS are all at a tie. The continued presence of standalone Kubernetes is a testimony to early adopters and the growing reliance on open source software in large enterprises. It’ll be interesting to revisit this question next year after large enterprises have gone through more than a year of COVID-19 driven cloud migrations which could give CSP offerings a decided advantage in the new world of work. Looking Forward Kubernetes is still experiencing exponential growth. The Kubernetes responses in our survey speak to a future that’s being written as we speak.  The complexities around deploying and operating Kubernetes still remain and aren’t going to disappear anytime soon. That means that the open source projects and CSPs offering Kubernetes solutions are going to have to focus more on simplicity and usability in future releases. Along with that comes a renewed commitment for outreach, documentation, and training for their Kubernetes offerings. Do you want more insights into container and software supply chain security? Download the Anchore 2021 Software Supply Chain Security Report! ### A Custom Approach to Software Security Solutions 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. ### Secure the Software Supply Chain: 5 Insights from the 2021 Anchore Software Supply Chain Security Report The challenge of building and maintaining a secure software supply chain continues to vex enterprise IT leaders. We recently surveyed IT, security, and development leaders in the Anchore 2021 Software Supply Chain Security Report to get some insights into these challenges they and their teams face daily. Here’s a preview of our survey results: Highlights from the Survey Container usage is on the rise as these highlights from the survey show: 65% of the respondents replied they are at intermediate or advanced levels of container maturity 84% plan to increase container use and 29% will increase container use significantly. Respondents use containers for both internal applications and software products they sell. 38% of advanced container users see containerized apps as a higher supply chain risk versus 16% of beginner container users 1. Open Source is the Top Container Security Challenge  Developers incorporate a significant amount of open source software (OSS) in the containerized applications they build. As a result, 23% of respondents rank securing OSS containers as the number one challenge. In a tie for second place (19%) is understanding the security of code that an organization writes themselves and understanding the full software bill-of-materials (SBOM).  SBOMs are a critical part of President Biden's Executive Order because they are the foundation for many security and compliance practices. 2. Software Supply Chain Attacks Cut Deep With over 18,000 organizations affected just by the SolarWinds attack, a software supply chain attack has affected a significant majority (64%) of respondents within the last twelve months. Over a third of the respondents report that the impact of a software supply chain on their organizations was moderate or significant. 3. Containers and Software Supply Chain Risk We saw an interesting statistic in the survey with 38% of advanced container users seeing containerized apps as a higher supply chain risk versus just 16% of beginner container users.  These stats paint an intriguing picture of container adoption that’s entering middle age. When you look at the rise of Docker containers since 2013 leading into the current generation of cloud-native development. Long-time container users recognize the security risks of containers inside the supply chain. A new generation of developers adopting containers is starting on their own learning journey. 4. OSS, SBOM, and Container Security Rank as Challenges Open source software (OSS) ranks as a top container security challenge according to 23% of the survey respondents. Meanwhile, the software bill of materials (SBOM) is a top challenge for 19% of the respondents. Another interesting insight from the survey is that some enterprises still underestimate OSS as 26% of components and code where some industry benchmarks such as the Synopsys 2020 Open Source Security and Risk Analysis Report point to OSS comprising 70% or more of components and code in today’s applications. 5. The Truth about False Positives We hear a lot about container vulnerability scanning challenges and the damage that false positives can do to a security team’s credibility. Survey respondents laid out their top three challenges: Identifying vulnerabilities (86%)  Receiving too many false positives (77%) Getting developers to remediate issues (77%) On average, survey respondents estimate that 44% of vulnerabilities they find are false positives.   Do you want more insights to help build and maintain a secure software supply chain? Download the Anchore 2021 Software Supply Chain Security Report! ### Carving a Career Path That Fits 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. ### 3 Tips for getting Stakeholder Buy-in for DevSecOps Gaining stakeholder buy-in for DevSecOps comes with some upfront work. You don’t want to present to your department’s leadership, much less your C-Suite, to talk about DevSecOps unless you have an accurate picture of where your development teams are currently and where they need to go in the future. Here are three tips for preparing to get stakeholder buy-in for DevSecOps: 1. Analyze your Development Process Maturity Whether DevSecOps is just the next step in your DevOps journey or you’re making your initial foray into DevSecOps straight from a waterfall SDLC, a critical step in the first phase is to analyze the maturity of your software development process. Your analysis should include: Document any current state processes Gather any reporting data about your current development processes Interview key developers about what’s working and not currently working in your development processes Interview key security team members about what’s working well and what’s not working in their processes and procedures that support your applications in development and production Before presenting this information to your stakeholders, distill it down into the key points in a format that’ll resonate with your stakeholders. For example, if you work in a data-driven organization, then let the numbers tell your story. Non-technical stakeholders may also need a quick DevOps to DevSecOps education that hones in on how DevSecOps benefits their piece of the business.  2. Define DevSecOps for your Organization Software vendor marketing and the OSS community each put their spin on the definition of DevSecOps. Therefore, as part of your outreach, it’s important to define DevSecOps for your organization, including: What DevSecOps means to your organization The expected outcomes after moving to DevSecOps The tools and processes your organization is putting into place to ensure employee success Spare your teams from any misunderstandings and document your DevSecOps definition. Post that definition in a place that’s accessible to all your team members and stakeholders. It’s not about creating a project charter for your DevOps to DevSecOps transformation, but defining your true north. 3. Plan for a DevSecOps Culture Like DevOps, you can’t buy DevSecOps. Your managers and key technology team members need to work together to foster DevSecOps cultural philosophies that take your DevOps foundation to DevSecOps transformation. Culture can be a squishy word to some stakeholders. It’s important to couch DevSecOps culture in business terms with an eye for how it benefits the organization. A simple way to do this is to create a DevSecOps roadmap with milestones for each major transformation point, including: Continuous Feedback and Interaction Cross-functional DevSecOps teams may collaborate remotely, which can create challenges with continuous feedback. It’s not about a manager delivering feedback on the DevSecOps team performance. Instead, it’s about enabling teams to collaborate more effectively. ChatOps tools such as Slack, Microsoft Teams, and MatterMost can now replace email for DevSecOps teams. As technology such as artificial intelligence (AI) improves, you can expect to see more automation through chatbots. Container-Based Architectures The shift to cloud-native applications is driving the adoption of container-based delivery models.  DevSecOps plays a critical role in the move to container-based architectures, which can be a cultural change in and unto itself for DevOps teams. A proper and robust implementation of containers changes developer and operations cultures because it changes the development model of how architects design solutions, programmers create code, and how operations teams maintain production applications. Team Autonomy Like DevOps, DevSecOps is no place for micromanagers at any level of your organization. A standard part of DevSecOps culture is enabling your teams to choose their own tools and create their processes based on the way they work. DevSecOps also promotes distributed decision models to support greater innovation and delivery velocity. Automation DevSecOps extensively embeds automation for security checks and remediation workflows directly into DevOps processes and toolchains. An automation strategy that extends to security is a sign of a healthy DevSecOps culture.  DevSecOps Training for Developers Another step to security becoming part of everyone’s job is to provide security training for your developers. Training could take the form of in-house developer training in casual formats such as Lunch and Learns or more formal training classes conducted by your organization’s training department. Another option is to send your developers to a third-party training provider to get the requisite security training. Depending on your security ambitions (and budget), there is always the option to send your DevOps team members to get a vendor certification such as the DevSecOps Foundation certification from the DevOps Institute the Certified DevSecOps Professional (CDP) from practical-devsecops.com. Final Thought Preparing your case to advance your DevOps journey with data, a current state picture of your development processes, and a plan to transform your development team culture enables you to meet your stakeholders with the facts and strategy they require to make a decision to grant budget and staffing to the effort. ### Container Security Best Practices That Scale 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. ### Behind the Scenes of Startup Team Strategies Building products in an emerging tech space requires a highly collaborative and creative Engineering team. We sat down with Chief Architect & Director of Engineering Zach Hill (he/him) to understand more about creating an environment of psychological safety and operating with a growth mindset. “At a high level, psychological safety is about fostering an environment where people feel comfortable saying ‘I don’t know’ - because it’s safe to do so and we’ll figure it out together. We’re a fast-paced startup with high-tech products in a fairly emerging industry, and that means much of what we are working on is developing as we go and we are all learning and growing together.” Anchore’s values of kindness, openness, and ownership play an integral role in the Engineering team culture.  “You can see it in our Slack channels. You can see it in the way people on the team interact with one another and with their managers. We have a highly collaborative team that’s open to asking for help and being mentors to one another.  It’s an exciting time to be an Engineer at Anchore.”  If you are interested in joining Zach’s team and working at a company that values kindness, ownership and openness, we’re hiring across our Engineering organization. ### The Current State of the Container Registry A container registry is becoming a necessity for organizations using containers in cloud-native development projects because it enables them to reuse software components that have already been through a vulnerability scan and other compliance checks.  Here’s a look at the current state of container registries: What’s a Container Registry? A container registry, sometimes called a container hub, is a centralized repository of container images that an organization develops, vets, and secures to support the reuse of containers. When your organization establishes a container registry, they gain the technical foundation to create a reuse strategy that can help increase development velocity through the strategic reuse of software. For example, when a team reuses containers that have already gone through vulnerability scans and other security checks there’s no need to repeat those checks on the container at points during the DevOps lifecycle. Container Registry Use Cases Here are some examples of container hub use cases that are bubbling up right now: Healthcare As more healthcare applications migrate to the public cloud and to mobile apps because of COVID-driven telehealth initiatives, a container hub offers healthcare institutions such as a regional hospital system a secure and centralized repository of containers that are in compliance and now available for reuse. For example, telehealth is changing user expectations for user experience (UX) and security.  It’s incumbent on healthcare institutions to implement a container hub that can help their developers meet the changing market expectation for slick and consumer-like experiences they would expect with any app they download from Google Play or the iTunes Store. Financial Services Another industry ripe for container registries is the financial services industry. The financial services industry had been embracing the cloud even pre-pandemic to feed consumer demand for online and consumer banking services. In turn, this strategic move fuels the need for DevOps to DevSecOps and containers to support the necessary security and compliance that the industry requires to protect the personal and financial information of their customers. A container registry inside a financial institution offers its developers and outside partners secure and vetted reusable containers that they can reuse across projects. Public Sector & DoD Public sector agencies and Department of Defense (DoD) programs are prime candidates for container hubs because they have security and compliance requirements they must maintain to protect government data and applications from attacks. An example of a DoD container registry is Iron Bank (more on that later) which serves as a repository of standard container images for Platform One, an innovative cloud, and DevSecOps initiative. Iron Bank offers DoD developers hardened containers they can use across cloud projects they’re building to run on Platform One infrastructure. Other container registries are certain to come online as other DoD elements move forward with their own large-scale cloud initiatives. Learn how Anchore brings DevSecOps to DoD software factories. Container Registry Examples Here are examples of industry-standard  container registries: Docker Hub Docker Hub is perhaps the best-known example of a container registry. It’s a cloud-based repository open to the public in which Docker users and partners create, test, store, and distribute container images. All Docker tools go to the Docker Hub by default. GitLab GitLab offers a secure and private registry for Docker images that integrates directly with their industry-standard version control platform. The Future is the Industry Specific Container Registry As Platform One and the NVIDIA NGC show, there are some benefits of industry-specific container hubs including: A platform for cross-industry collaboration amongst developers and even market competitors to help some industry and even society level challenges such as COVID-19 A central repository showing best practices in container creation and security for everybody to learn from A “container ethos” much in line with the open source ethos that can help support organizations early in their container adoption journey with secure and vetted containers they can download and use in their own projects More corporate and government program-level container registries are a natural launchpad for more of an industry-level container registry as alliances and partnerships find the need to connect with developers outside their normal sphere of influence. Do you want to learn more about container security best practices? Check out our Container Security Best Practices that Scale On-Demand Webinar. ### Riding the Wave of Container Security Robert Prince (he/him) joined Anchore in May 2020 as a Senior Automation/Release Engineer, going back to his roots as an individual contributor after several years in leadership roles. In this Humans of Anchore profile, we sat down with Robert to talk about his transition back to development, having a safe work environment to explore and learn, and riding the wave of container security. Leadership roles come with a host of responsibilities like budgeting, managing people and their professional development, building and maintaining relationships with strategic partners, and reporting to the board. Though he enjoyed those responsibilities while he held them, Robert wanted to connect with hands-on development again. Thankfully Anchore presented him with the perfect opportunity to do so. “I feel comfortable putting my head down, doing tactical work, and not having to worry about people managing or strategic decision making. One reason for that is Anchore’s leadership team: it’s obvious that they’re at the top of their game, and to me that is very comforting. A lot of companies talk about being kind to each other, but it’s more than talk here; kindness is non-negotiable, and that’s one of the things that pulled me in and keeps me here. Coming from environments where that hasn’t always been the case, it’s taken me some time to internalize it. Once I understood that this company provides a kindness-based, trust first culture - I found it freeing. It lets me focus with less distraction.” Robert is part of the DevOps group, focusing on automation of tools and the release process. “The container orchestration and security space is hot right now. Software development supply chain is a concept that few outside of infrastructure tech talked much about before. Now people are starting to pay attention. Anchore is at the center of what people actually need right now - it’s really fun to be involved in a company that is riding that wave. You can almost see the change in infrastructure and tooling happening in real time. It reminds me of the massive change that happened when cloud computing was commoditized: some things got much simpler but when you go beyond “Hello, World” - there’s new layers of complexity. It means that you’re constantly learning while applying what you already know. I don’t have all the answers but I’m with a well rounded team. Sometimes I mentor folks, and sometimes they mentor me. I feel lucky to be part of Anchore.” ### Latest Cybersecurity Executive Order Requires an SBOM This blog post has been archived and replaced by the supporting pillar page that can be found here: https://anchore.com/wp-admin/post.php?post=987473366&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. ### GitOps vs. DevOps: How GitOps plays in a DevOps and DevSecOps World Operations models are coming at us fast and furious these days. DevOps and DevSecOps adoption and maturity have only increasing during the pandemic. It’s now incumbent for DevOps and DevSecOps teams to get all their system configurations under the same level of control and governance as they do with their application source code and containers. That's right, it’s time for a new operations model. Say hello to GitOps! What is GitOps? GitOps practices empower development teams to perform traditional IT operations team tasks. As more organizations move to continuous integration (CI), continuous delivery (CD), and apply automation to their testing, delivery, deployment, and governance the more opportunities they have to implement GitOps to streamline infrastructure tasks that DevOps doesn’t necessarily automate and factor into its workflows. It also lets your teams take advantage of backend data through the application of analytics to give your stakeholders actionable insights on what’s happening up and down your pipelines and in your cloud infrastructure. One of the many strengths of GitOps when compared to DevOps, is that it enables DevOps teams to loosen restrictions between development and operations sequences. GitOps is also repository centric with the project’s configuration files and deployment parameters residing in the same repository as the application source code. These strengths mean GitOps supports rapid development and complex changes, all the while minimizing reliance on the complex scripts that traditionally dominate such tasks. GitOps also emphasizes the use of Git, a single and often already familiar tool for developers. GitOps is gaining attention because of the complexities around configuring Kubernetes (K8s). When a Kubernetes shop moves to GitOps, they can manage their K8s configuration right along with their application source code. If they make a configuration mistake, they can roll back to their last known good configuration. Critics of GitOps cite its lack of visibility into environments despite proponents seeing visibility as one of its strong suits. The criticism is because the data that teams see resides in a plain text format in Git which they see working for only simple configurations and setups. Comparing GitOps vs. DevOps We’re reaching a peak level of ops in the IT industry right now. It’s easy to get them all confused without the help of corporate marketing departments. The easiest way to distinguish between DevOps vs. GitOps is to think of DevOps as a pipeline mechanism that enhances software delivery. GitOps is a software development mechanism that improves developer productivity. These ops models bleed together because of continuous integration/continuous delivery (CI/CD) and the componentization of software through containers.  GitOps complements an overall DevOps strategy and your toolchains. By introducing GitOps into their workflows, a DevOps team can experiment with new infrastructure configurations. If the team finds that the changes don’t behave as expected, they can roll back the changes using Git history. GitOps and Secure Development Many of the same contrasts between DevOps and GitOps remain in GitOps vs. DevSecOps. GitOps is developer-centric. DevSecOps is security-focused with software containers playing a growing role in how DevSecOps teams secure software during development, testing, and in production. As DevSecOps add more security and analytics to the toolchain, teams can easily extend their security measures to secure their Git repositories. The merging of DevSecOps and GitOps should be interesting to watch. DevOps, DevSecOps, and GitOps in the Future Evolution is constant in the IT operations world. While some foresee that DevOps and DevSecOps will merge, GitOps will certainly continue to augment DevOps and DevSecOps toolchains and processes offer teams better tools to manage configurations, thus lifting some pressure off the Ops team so they can focus on more strategic work. ### How Core Values Can Foster Open Performance Discussions Kindness, Openness, and Ownership.  These are the core values that Anchore was built on and our team members exhibit every day.  At the core of these values are the underlying themes of trust, empathy, and communication, which are paramount to our continuous performance model.  We designed this model to create manager and employee relationships that enable and empower every employee to feel safe to raise their hand with new ideas and ask for help, creating open two-way communication. Every other month, employees sit down with their managers for a Top 2 conversation, where they discuss two things that went well and two things that can be focused on in the coming months.  Most importantly, this feedback goes both ways.  Employees have a regular opportunity to share feedback with their manager (wanting more frequent check-ins, interest in stretch projects, etc.) and managers have regular opportunities to coach employees, providing the tools and resources they need to be successful.  Additionally, every six months managers sit down with their direct reports for a Stay Interview, providing a dedicated time to discuss motivators, communication styles, and long-term career goals. With this understanding, the feedback and opportunities presented can be deliberately aligned with each person’s individual goals and objectives.  To learn more about how our continuous performance model has given our team members the tools to build a trusting and open relationship, we sat down with Brandon Lee (he/him), Senior Accountant, and his manager Alaina Frye (she/her), Sr. Director, Finance, Accounting and RevOps.  Brandon has worked at various sized companies, from large financial services firms to small startups, all of which had infrequent and unclear performance models (or none at all). When he joined Anchore, Brandon welcomed the opportunity to participate in a robust and regular performance development program.  “I think what we have with the Anchore Top 2 discussions and Stay Interviews is pretty awesome and has enabled Alaina and I to have a very open and honest relationship,” said Brandon.  “Because the Top 2 meetings occur so often, it’s easy for us to reflect on what went well in the previous months, as well as help identify some of the processes that we can continue to enhance and refine. The transparency and open dialogue we have in our Stay Interviews is really helpful for my career growth and happiness at Anchore. I enjoy the opportunity to share my short-term and long-term career goals in a very candid way and really appreciate the continuous support in accomplishing my goals.” Alaina, whose experience also ranges from large financial services firms to small startups, has become a champion of Anchore’s Top 2’s and Stay Interviews.  As a manager, they give her the ability to have constant communication with her direct reports. This ensures that expectations and goals are clear on both sides - ensuring strong communication all around.  “Top 2’s help everyone digest feedback because we have this set framework and recurring time to discuss performance regularly. It facilitates the opportunity to receive feedback and then work together on action plans,” said Alaina. “Some months there is specific feedback about how I can better support Brandon, but other months we sit down and talk at a higher level about process improvements we want to make.” Even ad-hoc feedback conversations outside of Top 2’s have become more natural because Brandon and Alaina have built a foundation in their sessions, understanding how each other thinks, communicates, and what motivates them.  This sense of trust and psychological safety with one another has opened the door to real time feedback opportunities.  Through Alaina and Brandon’s embodiment of Anchore’s values they have cultivated a strong relationship where they can learn and grow - together.  If you are interested in working on a team that fosters kindness, trust and open communication, head to our careers page.  ### 5 Open Source Procurement Best Practices 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. ### Blending Passion and Performance to Advance Innovation As we explore the various roles and responsibilities at Anchore, one critical area is maintaining our interactions with the open source community. Anchore’s roots are deep in open source, and this area remains vital to our organization today. As a company we may expand our offerings, but the technology feedback and engagement we receive from our users in the community drives and inspires our team. As we continually innovate and cultivate the newest technologies for secure and compliant software development, Anchore is thrilled to be hiring a Developer Advocate for our open source tools.   Our Vice President of Product, Neil Levine, weighed in on what he sees as the key elements to this role: “Hiring a developer advocate is critical for Anchore as we look to grow adoption of our open source tools and evangelize the benefits of DevSecOps practices. We make our tools open source to reduce friction and encourage conversation with the developer community. This role is the essential glue between those users and the Anchore engineering team, so we can ensure that we are advancing state-of-the-art concepts when it comes to developing secure software. This role will help not just Anchore, but the broader software community.” Are you passionate about DevSecOps and open source projects? Then apply for this role on our job board. #NowHiring ### 5 Reasons AI and ML are the Future of DevSecOps 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. ### Celebrating Anchore’s Fifth Birthday This is a special guest post from our CEO, Saïd Ziouani to celebrate and reflect on five years of the Anchore journey. As we celebrate Anchore’s fifth birthday this month, and reflect on our journey thus far, I am truly humbled at what our talented team of professionals has accomplished in such a short period of time. Anchore was founded on three core values: Kindness, Openness, and Ownership. Our employees (affectionately called Anchorenauts) exemplify each of those values every day, and are the backbone of the company. When Dan Nurmi, Co-founder, and I got together back in 2016 to start Anchore, container technology was still in the early stages, but adoption was starting to take shape at a pace that was like nothing we’d seen in the past. We could see how security and compliance would need to be re-imagined to a “continuous” approach that would allow developers to deliver innovation quickly and securely. We then realized that coupling the container adoption movement with developer-led security (or “shift left”) was going to be the foundational play for our next adventure. Today, after five wonderful years of innovation, building a team, raising capital and instilling a strong operational foundation, I’m pleased to see how far we have come as a company. At 75 people strong, we are excited to be helping Fortune 100 companies such as eBay, NVIDIA and Cisco and government agencies such as the U.S. Air Force and Navy to develop secure cloud-native applications. And we’ve been honored to work alongside DevOps leaders such as GitLab, GitHub and Cloudbees to advance DevSecOps practices. As we look forward, the next five years at Anchore will be full of new innovations as we help organizations secure their software supply chains in a world of increasing threats. We also seek to develop and inspire the next generation of engineers, technologists and leaders, both within Anchore and in the larger open source and technology community. I’m even more excited now than I was the day Dan and I founded the company. The thrill of being at the forefront of such amazing and dynamic technology is more than we expected. As Anchorenauts have heard me say many times in the past, “it’s really all about the journey.” At Anchore, we surround ourselves with hardworking, kind individuals, all driving toward a common goal of building a technology that contributes to ensuring a safer and more secure world. I’m grateful to our industry partners, valued customers and all Anchorenauts — from those who’ve been with us since the early days to those who have embraced the journey with us more recently. We look forward to continuing to build this amazing company together! ### 2 SBOM & Supply Chain Security News Items to Watch We aren’t about to stop hearing about the need for a software bill of materials (SBOM) and software supply chains security anytime soon. You can expect more news about a Presidential executive order about SBOMs and a new software supply chain breach at Codecov that we’re all still learning more about. Impending Executive Order about SBOMs The fallout from the SolarWinds supply chain attack is behind the U.S. federal government considering issuing an executive order that would require vendors to provide a software bill of materials (SBOM) with the software they sell to or create for a customer. One of the potential benefits of this EO is that we might finally see a boost to some of the excellent industry and cross-industry work being done out there to better track software dependencies and related metadata. Hopefully, we’ll see SPDX, CycloneDX, SWID, and the National Telecommunications and Information Administration (NTIA) play new and collaborative roles within government and industry once this EO hits the street.  An EO of this magnitude also sends a powerful message to government and industry about the risks of vulnerabilities that come from software dependencies. There’s also the potential of a knowledge gap that both government and industry will need to bridge. Look for security vendors to pivot their messaging and thought leadership to fill this gap. Codecov Supply Chain Breach Codecov — makers of a tool that lets development teams measure the testing coverage of their codebase — could be the latest high-profile software supply chain breach adding new fuel to the impending federal government EO. Reports point to attackers exploiting a bug in Codecov’s Docker image creation process to gain access to a Bash Uploader script that maps out development environments and reports back to the development team. The modification called out for user credentials that would enable the attackers to access and exfiltrate data right from the continuous integration environment. CEO  Jerrod Engelberg published an update on their corporate site that warned that any credentials, authentication tokens, or keys run through an affected customer’s CI process were exposed giving attackers access to application code, data stores, and git repositories. The Codecov breach brings up the harsh realities of the need to secure the DevSecOps toolchain for government and commercial enterprises. Nowadays, any focus on application security must also include the toolchain. Be Proactive about SBOMs and Supply Chain Security News of the impending executive order and recent news about Codecov mean the time is now to become more proactive about your organization’s SBOM adoption. Here are some actions you can take to be proactive about SBOMs and supply chain security: Review your current DevOps or DevSecOps process with your development and operations teams and look for natural points to introduce the requirement for an SBOM as an entry gate. Become conversant in the major SBOM standards: SPDX, SWID, and CycloneDX because we’ve yet to see a full-court push for an industry standard. It’s also a good time to monitor the SBOM work the NTIA is doing. Implement a tool to generate SBOMs from container images and file systems if you haven’t already done so. Download and take Syft for a spin. It’s our open source CLI tool and library for generating a Software Bill of Materials from container images and filesystems. ### A Family Approach to Startup Life When Chad Olds (he/him) joined Anchore in February 2020 as VP of Sales-Americas, his goal was to build a collaborative, high-performing sales organization.  The first year was filled with many unexpected challenges, most notably a global pandemic. This led him through an action-packed year beginning as a “team of one” and ending with an incredibly talented team of Account Executives, Solution Engineers, and Sales Development Representatives.   When the pandemic hit, Chad learned quickly how much work is involved with raising three children and being present as a parent while balancing a demanding career. It completely changed the expectations and needs in his household.   “What I learned, even before the pandemic, is that taking care of the kids is a lot of work, and it is absolutely unfair for me to think that my wife, Brittany, who owns a small business, should be expected to take on full parent duties 24/7.”   Chad knew how important it was to participate and share in the demands required in caretaking, and finding a way to balance the ownership and responsibility was a priority. With a career in sales spanning 15 years, Chad’s focus was aligning himself with a company that understood the importance of finding an effective balance between work and life. At Anchore he found a sense of trust in managing personal schedules that flex with an individual's needs.  It’s not always possible to predict needs or delegate work to others at a start-up, but he knew that with proper planning and prioritization, he had the support to make it happen.    “I changed my work schedule to help take on more of the morning responsibilities for our family. Things like help make breakfast, get the kids dressed and hair brushed. Essentially help them get ready to start the school day, which, for any parents out there, can attest that this alone can be a day’s work!” Chad realized that even with the adjustment of helping with the morning routine, it wasn’t enough.  He wanted to support his wife in having more time to herself.  “I started blocking time during the week to spend time with my kids while Brittany was able to take the time she needed to stay balanced and healthy. It was fantastic for both of us! One of the things I appreciate about Anchore is that I don’t feel the need to hide spending time with my family. It’s something that our leadership team fully supports.”   Being able to show up at work and contribute at the highest level involves having a life outside of work - whatever that may look like to each person.  Chad believes that burnout can happen quickly, especially at a start-up where the workload is vast, and the pressure is high.  “I want my team to really know their friends and family.  I want them to enjoy what they do every day.  It’s about working smart, and prioritizing early and often to ensure you’re able to get done what you need to get done, while also being able to show up in other areas of your life fully, without distraction.  It is incredibly meaningful for me to not only give that support to my team in achieving what is most important to them, but to receive that level of support from my leadership as well.” You can keep up with Chad and his series Colds Unfair Advantage on LinkedIn. ### Taking A Healthy Viewpoint Since Anchore’s inception, healthcare has been a central tenet for CEO Saïd Ziouani. “We want everyone at Anchore to focus on creating and being a part of something really special here. Employees should not have to worry that their physical and mental health is not being taken care of. It is, and will always be, a priority for us.” In this Mission: Impact health profile, we sat down with Shannon Goulding to hear about her wellness journey with Anchore’s benefits program. “Last year I joined Anchore and upon enrolling in benefits, was blown away at the number of plans that were fully covered by the employer - my experience of the industry standard is that the lowest HDHP-type plans were the only ones covered at 100%. While I consider myself a generally healthy person, I enrolled in a low-deductible PPO at ZERO extra cost to me, so I buckled down and got serious about using my insurance. I saw all the specialists that I had been putting off for years due to cost, and for lack of a better phrase, got my act together! Thanks to having comprehensive insurance from my employer, I now can afford the things that I have realized are a necessity as I advance in a challenging career in talent acquisition at a startup, during a totally unprecedented season of life. As a result I now wear glasses, resulting in fewer headaches. Plus I have easy and affordable access to tools that are helping me keep my mental health in check. It's a win-win for me AND for Anchore because when I'm happier and healthier, I'm a much better recruiter!”   ### Software Supply Chain Security: Now is the Time to Act It’s time to make evaluating and mitigating software supply chain security attacks top of mind as government agencies, corporations, industry analysts, and security firms try to chart a course forward for supply chain security after the SolarWinds hack. Security Challenges  Here are some software supply chain security challenges you should keep at top of mind now and in the future: Software updates are a well-known best practice but can also introduce risk. However, with SolarWinds, customers received software that was signed but compromised. In following this best practice, they did just what the attacker wanted by installing the compromised software on your systems.  Software behavior monitoring — another best practice — met its match in the stealthy and patient attackers who created so much damage inside SolarWinds before their discovery. Source code reviews are inefficient, as the SolarWinds hack shows. Some reports point out that attackers had control of the SolarWinds build environment, making it possible for them to insert malicious code without knowing the SolarWinds Orion development team.  When traditional security practices and solutions such as these fail on such a grand scale, it becomes time to reevaluate how software supply chain security works in organizations of all types.  The SolarWinds hack exposes many of the significant drawbacks of today’s supply chains to the light of new and changing cybersecurity realities.  Changing supply chain security means galvanizing your teams and counterpart teams in all the commercial partners and vendors that touch your supply chain to become true partners with open communication lines, collaboration, and knowledge sharing. While large corporations may vet software vendors’ security through questionnaires or independent assessments, more still needs to be done to reduce risks across the software supply chain. Work beyond that initial questionnaire and subsequent onboarding means focusing on automated vulnerability scans and other methods to shore up your process for bringing in software components or applications. Security, development, and IT teams must collaborate to ensure sufficient security checks and remediation of issues at each software supply chain stage. Those compliance processes must apply to software from all sources, whether open source, commercial vendors, or internal developers.  Best Practices There isn’t a single security solution that can secure your software supply chain from attacks. The gravity of the SolarWinds attack is an invitation for you and your software supply chain partners to collaborate and reassess the security, governance, communications, and collaboration needs across your supply chain. Here are some best practices you are bound to see and experience in the post-SolarWinds world: Improve relationships and collaboration Improve governance of software onboarding  Harden your build environment Require an SBOM for all partners and vendors Implement Defense in Depth Apply "Zero Trust" to software supply chain security  Create a “kill chain” for your software supply chain Read our White Paper Today, software supply chain security requires continuous awareness, collaboration, and new strategies. We no longer live in a time to sit still when it comes to software supply chain security. Software Supply Chain Security, Best Practices for Cloud-Native Application Development ### The SBOM + Threat Intelligence are the Future of Software Supply Chain Security As organizations open up the software bill of materials (SBOM) to their security teams, there is a future of the SBOM as source data for threat intelligence is becoming abundantly clear. Applying intelligence to SBOM data is a natural step in a world where DevOps and DevSecOps teams use a range of tools and technologies such as AIOps and analytics to gain actionable intelligence from their backend data. Here’s a look at how the SBOM and threat intelligence spells the future of software supply chain security: SBOMs Today We’re reaching a critical point with the role of the SBOM in today’s enterprise. After the SolarWinds hack, it’s incumbent for government agencies and businesses to open up the SBOM to their security teams. Options to make this work include: Offer training to your internal teams about SBOM basics with an accompanying briefing about what your organization expects to get  Give your security team the tools and support to make the SBOM the first “gate” before third-party software code and components enter your software supply chain. Put in the tools and processes to generate SBOMs as part of your DevSecOps toolchain and processes Threat Intelligence Today Threat intelligence, also known as cyber threat intelligence (CTI), is organized, analyzed, and refined information about current or potential attacks according to Whatis.com. An entire industry has arisen around threat intelligence that includes platforms, open source, and fee-based data feeds. Choosing a threat intelligence platform means knowing your goals and requirements for data collection, and how the platform presents its threat analysis and reports to your security team. If you already have a threat intelligence platform in place that your security team manages, it’s time to work with your team and, if necessary, the vendor, to explore potential integration options for pulling in SBOM data into your threat intelligence reporting. There’s not a single hard and fast answer here (at least not yet) but the platform application programming interface (API) is the logical starting point. The SBOM and Threat Intelligence in the Future The SBOM is an under-realized threat intelligence option. For example, let’s say that you want to integrate an open source software (OSS) project into an enterprise software project you have underway for an important customer. The project is highly functional and shows excellent potential to serve as a key feature in your solution. Then the OSS project suffers a security incident. There are also vulnerabilities appearing in the same OSS project weekly. A commercial or open source vulnerability scanner can only tell you whether some piece of that OSS project is vulnerable. It doesn’t give you any sort of status or analysis that alerts to the project’s history in the “vulnerability of the week club.” While that OSS project with the vulnerability a week remains appealing, that there’s an OSS project with vulnerabilities is lost on the vulnerability scanner. You have a commercial option that fills most of the requirements but has only suffered two vulnerabilities over its entire lifetime. That’s probably the safer bet. We need to reach a point where we couple SBOMs with intelligence to help raise the role and importance of SBOM as a key security data source. Even if you have the staffing budget to hire 100 people and their whole role in life is to determine the threat status of your open source dependencies, they still need a technology solution that enables them to narrow down what they examine as third-party software enters your pipelines.  Final Thoughts As businesses and governments continue to tackle the rise of software supply chain attacks, they and the vendors that serve them need to look at coupling SBOMs with some form of intelligence. Threat intelligence is a logical bet. It’s time for threat intelligence platform vendors and their customers to work collaboratively on solutions to add SBOMs to their feeds by default. 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. ### It All Started With a Fish Tank It all started with a fish tank...  You don’t hear that often, but for Anchore employees Touré Dunnon and Amy Oxley, this hobby was just the thing to start their Anchorenaut friendship.   Touré’s 250 gallon saltwater aquarium is the real deal. It has an impressive mechanical and biological filtration system that holds 400 gallons total (2500 lbs). Touré grows seaweed and keeps the water extra clean for his nine fish from Fiji and the Caribbean.   This advanced level of aquatic life didn’t happen overnight.  Touré learned his love of fish through his Dad, who started him out with a 10 gallon saltwater tank when he was 13.  After college, Touré got back into aquariums with his two daughters who help manage the water changes, clean the tank, and feed the fish.  Since he was interested in becoming a marine biologist as a kid, Touré is hoping his daughters will be inspired to pursue that path when they get older. Outside of his fish tank fatherhood, Touré is a Senior Software Engineer on the Anchore platform team, primarily working on policy engine with a key focus on keeping active containers within compliance.   Meanwhile in Texas, Amy’s three-year-old daughter Fynn’s obsession with the Finding Nemo movie piqued her interest in starting a fish tank hobby. It wasn’t until seeing Toure’s aquarium during an Anchore All-Hands virtual meeting that she was inspired to commit.  Amy’s 40 gallon freshwater tank has 11 fish, complete with schools of tetra, catfish, and shrimp.   While still aspiring to make her tank more automated (and eventually upgrade to a saltwater tank as “saltwater fish are way cooler”), Amy and Fynn love to count the fish and learn their names.  Amy is the Senior Manager of the IT and Information Security team, filling her days with managing Anchore’s internal systems for both ease of use and compliance while maintaining and managing the company's security initiatives. Toure and Amy’s friendship has continued to grow - with Touré being a fountain (dare we say, an aquarium) of knowledge for Amy as she has embarked on her fish tank journey, being her go-to person for questions on everything from water changes to the ideal plants and fish to purchase next.  They even connected on their hobby of woodworking, and strategize on how to build stands and support systems for their fish tanks.   In a distributed company during an unprecedented time, Touré and Amy’s friendship is an example of the unconventional ways people can make a connection through something as simple as a video conference background. You can keep up with Touré and Amy (and their aquatic hobbies) on LinkedIn. ### Plugging an SBOM into your DevSecOps Process The software bill of materials (SBOM) is gaining renewed attention and notoriety post-SolarWinds. More companies and government agencies seek deeper transparency into the software components entering their software supply chain. While there are critics out there that believe that the SBOM is a misguided concept for DevSecOps, the continuing evolution of DevSecOps, much less the automation it brings to development teams today, now makes SBOMs a foundational aspect of the DevSecOps process. SBOMs: The New Gate to the DevSecOps Pipeline It’s time to treat the software BOM as a barrier to entry for software components entering your DevSecOps, not just your container repository. Requiring an SBOM for all software entering your pipeline has become a common-sense best practice in this day and age. You have three options for obtaining SBOMs: Gain full cooperation from the software vendor, despite whether they’re a partner of your organization, with the SBOM as part of their delivery  Implement software composition analysis tools that require particular expertise  Implement a container vulnerability scanning tool that enables you to generate SBOMs for the containers entering your pipeline  Moving software bill of materials generation to the left is just another step in moving security left. Depending on your particular business processes, compliance requirements, and pipeline gateway requirements, it’s essential to add a documented or automated process (or better yet, a combination of the two) that ensures that each software component has an accompanying SBOM before it enters your development environment As an example, let’s say your developers are taking advantage of an open source software (OSS) component in a cloud-native application built for one of your most important customers. OSS projects don’t have the resources or staff to generate an SBOM. It’s not something they do. Nothing stops your teams, however, from creating an OSS onboarding process and putting in the right tool to generate the SBOM for the OSS themselves before the software even hits your development environment and software repositories. SBOM, Say What? There are some details from industry surveys and various industry mutterings that project that less than half of the companies out there are creating SBOMs for their software. It’s not about the SBOM being a misguided concept for DevSecOps either. Currently, organizations just do not build SBOM creation into their DevSecOps processes. You control the gates at all phases of your DevSecOps toolchain. It’s up to you to put in the tools and processes upfront (“to the left”) to ensure that all software from your in-house teams, contractors, partners, vendors, and OSS enter your DevSecOps toolchain, much less your enterprise software supply chain. Accountability for the SBOM is a New Priority Accountability for SBOMs seems to get lost in the rush to deliver new software. It’s time for that to change. Beyond putting in the tools and processes to capture an SBOM at contract time or have your team generate an SBOM for OSS, here are some examples of how you can build in SBOM accountability inside your organization: Include SBOM as a requirement for contractual deliverables from your vendors and partners, making it part of new software development, updates, and patches they deliver as part of a project. Establish the SBOM as a method for cross-functional team collaboration early in the project lifecycle because your contracts, finance, development, and cybersecurity teams all benefit from a well-formed SBOM to help them accomplish critical project-related tasks. Deputize a developer or development team to “own” or shepherd OSS components through your DevSecOps toolchain, giving them the responsibility of generating an SBOM for each component. Elevate the role of your cybersecurity team in the SBOM discussion by mandating that the SBOM serves as the basis for vulnerability scans. Final Thoughts Your development, security, and operations teams have probably already put a lot of work into creating the culture, processes, and frameworks to enable your organization to leverage DevSecOps. Factoring in the role of the SBOM into your DevSecOps processes is yet another iteration of your DevSecOps processes.  Do you want to generate SBOMs on the OSS in your development projects? Download Syft, our open source command-line interface (CLI) tool, and Go library for developing a Software Bill of Materials (SBOM) from container images and filesystems. ### The Software Bill of Materials (SBOM) through an Open Source Lens This blog post has been archived and replaced by the supporting pillar page that can be found here: https://anchore.com/wp-admin/post.php?post=987473384&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. ### Bringing Gratitude into the Workplace: Meet Emily Long   Emily Long (she/her) joined Anchore one week after the pandemic shut down the U.S. in March 2020, she was employee number 25. In her Chief People Officer role, Emily led the build out of the G&A (General and Administrative - self titled ‘Great and Awesome’) functions made up of Finance/Accounting, IT, Information Security, Recruiting, HR, Legal/Compliance, L&D (Learning and Development), and DEI (Diversity, Equity and Inclusion). Though she’d be the first to tell you, the best part was hiring “the incredibly talented team that really does the work.” Through her value system and leadership approach focused on empowerment, team dynamics, and trust, Emily’s impact has extended to her recent move into the Chief Operating Officer role where the Customer Success organization has joined forces with the G&A team. In this Humans of Anchore profile, we (virtually) sat with Emily to hear about her journey over the past year, what the organization has accomplished, and what inspires her: “I feel a deep sense of gratitude that I’ve been part of Anchore during the growth we have experienced over the last year. That gratitude is attached to what makes our growth special - that it’s always been about us accomplishing this together, as a collective company and team. Everyone here believes in what we’re doing, and every single person that works here is part of that success. Being able to partner with a team that is low ego, and high in humility and kindness, makes those wins as a company that much more fulfilling. Everything that we accomplish at Anchore - whether that be product features, financials, training materials, or metrics - has people behind it. Teams of people collaborating together to solve problems. If we don't understand the person that is developing code or supporting our customers, we aren’t telling the whole story. We can’t fully understand the quantitative outputs we get without deeply understanding the qualitative inputs that create it. Notably, the people behind the data. What makes us different is not putting more or less focus on the technical or non-technical side of our business, rather putting an equal focus on both. We believe that everything is connected and we can get increased technical innovation through empowerment of our team members. And not just by saying it is important - but doing something about it. I can honestly say I’ve never worked somewhere that has focused on this more - a true example of this was hiring me originally as Chief People Officer at employee number 25. We have worked hard to ensure the way we operate gives every team member a sense of belonging - that we take the time to understand how each unique person works, exploring their ideas, and hearing their concerns. This community of empowerment exists in a crew of almost 70 Anchorenauts. We have this infrastructure built to enable us to continue this as we scale because we have invested the time, energy, and resources through internal education, individual ownership, and structural support. We believe this is key to our success, for every employee. Anyone who has worked closely with me hears me say all the time that I genuinely believe that people are fundamentally good. Most of the time when I’ve seen people become defensive, shut down, or act out in some way at work it has been a result of insecurity or a lack of trust that they’ve learned through past experiences - and I’ve been there before. There is honestly nothing better and more inspiring than watching someone shed away those walls they’ve built by experiencing what trust really looks like and truly stepping into their power. I get to witness this at Anchore all of the time - and each time I’m filled with a deep sense of pride and gratitude. My ultimate goal is to have everyone at every level here at Anchore believe in, and have a path to achieve, that limitless potential that lives in each of us. Working somewhere with people that believe in each other, want to be part of a greater good, and are willing to hand the mic to someone that needs it more than they do... now there’s something really beautiful about that.” ### We're debuting our Anchorenaut logo As we continue our culture-first series, this Friday we're debuting our Anchorenaut logo (pronouns they/them). By definition, an Anchorenaut is someone that embodies our company values and what being an Anchore employee encompasses: kindness, openness and ownership. We have a strong-knit team here, even though we're dispersed geographically across the globe. This character serves as a symbol of how together, we're real people uniting every day to advance software security. Does this resonate with you? See our open roles here: https://lnkd.in/edDC7bf   ### At Anchore we're passionate about our products and our industry 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. https://hubs.li/H0G636d0 ### Curious what it’s like in a startup? 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. ### From Olympic Athlete to DevOps Engineer When Alfredo Deza came to work here at Anchore it was early in the startup phase, he was employee #16. His path to Anchore began after a storied upbringing in his native country of Peru, where Alfredo competed as a high jump athlete in the Athens 2004 Summer Olympics. He then shifted his determination and perseverance to study how to become a developer.  “My goal is to translate the stamina and work ethics from athletics to my work as an engineer. Having discipline, not letting my guard down, and doing things the right way has enabled me to propel forward in my career,” said Deza. After building a strong skill set in software coding and engineering, he pursued a career as a software engineer and still fuels his passion for computer programming in his free time.  Alfredo has co-authored a book “Python for DevOps” and is currently writing another book on machine learning. He teaches courses on Python and CI/CD, and recently was an expert panelist at GitHub Universe 2020.  When he’s not mentoring the next generation of developers and engineers, Alfredo spends time with his wife and three children. He consciously tries to expose his kids to new experiences and let them guide their own interests, in fact, his oldest recently taught himself to play the piano. “When you carve your path to success with effort, you can apply the principles of ownership and see great results. If you do what you say and live with objectives, amazing things will happen.” ### Charting your DevSecOps Stakeholder Spectrum The adoption of DevSecOps touches more than just your technology and security stakeholders within your organization. There’s a full spectrum of DevSecOps stakeholders spanning technology, security, and even your business units. The full DevSecOps Stakeholder spectrum includes: Technology Stakeholders The obvious stakeholders to feel some positive effects and challenges of moving to DevSecOps are your technology leaders, such as your chief technology officer (CTO), chief information officer (CIO), and engineering VP. Their motivations typically include developer productivity. Security teams also can become more productive because of a DevSecOps transformation through automation and adjustments to job roles and processes. DevSecOps is a mighty robust preventative measure to keep these stakeholders and their teams from getting caught up in expensive security remediation efforts that draw attention away from their regular duties. An essential role for the technology stakeholder is to be the internal champion for DevSecOps or be the one to empower somebody on their senior staff to be that champion. The DevSecOps champion at the stakeholder level needs prompting to represent your organization’s current and future needs at high-level strategy and budget discussions. Security Stakeholders If your organization has a chief information security officer (CISO) or chief security officer (CSO), they are a significant element in your DevSecOps stakeholder spectrum. Duties of a security stakeholder focus on managing and maintaining the security posture of build environments, software supply chain, and end products. The CISO, often with the CIO, may represent the organization about security matters such as a recent attack on or breach within your organization. Business Stakeholders You can’t dismiss the role of business stakeholders in DevSecOps either. These are the business unit leaders that may feel the most impact from DevSecOps. The good news is that such effects are positive if the units work with the technology team to put the right processes, frameworks, and content to tell the story of how DevSecOps benefits your organization. Here are some typical DevSecOps stakeholders on the business or back-office side of your organization: Sales  Your sales leaders and representatives gain many benefits from DevSecOps that you can’t gloss over. Positioning the benefits of DevSecOps with sales leaders and their teams who can benefit from it can help them land prospective customers. Suppose your company has clients in the public sector or the financial services and healthcare industries. In that case, DevSecOps can help your applications achieve compliance more quickly since your organization has shifted security and compliance left. DevSecOps is becoming an emerging requirement on DoD and civilian government agency procurement vehicles. If your business works with these entities, then you want to arm your sales stakeholders with the correct talking points about your company’s DevSecOps efforts. Marketing DevOps culture transformation shouldn’t just be about your development, operations, and security teams. Marketing stakeholders such as your chief marketing officer (CMO), VP of marketing, or marketing director need visibility into your DevSecOps efforts just like other parts of your organization. Your marketing stakeholders need a share in the collective responsibility to ensure that the software your organization delivers meets expectations and is a market fit for the business customer you’re pursuing. Marketing teams supporting the launch of new products and services need constant visibility into the DevSecOps project progress. Likewise, developers earn a view of marketing activities. The days of surprises in marketing collateral should be no more in a DevOps culture. DevOps also offers sales organizations a conduit to communicate customer feedback and requirements into the development cycle, so incremental releases can include customer-requested features. Automation is a priority in DevSecOps. It’s up to you to educate your marketing team on how automation changes how your organization delivers software internally and externally.  Finance The chief financial officer (CFO) role is seen as a more strategic role considering the pandemic’s effects on business. Similar positions in federal government agencies also see a similar change as agencies juggle budgets to support their mission, constituents, and employees. Even the finance department has a potential role in your DevSecOps process. While an accountant may not be billing their time to your DevOps projects, there’s work for them with facets of software license management, plus your cloud spending. Cloud economics and cloud cost optimization are integral elements of digital transformation projects these days, just like DevOps. Don’t forget to add the finance team to meetings when building out reporting requirements for the DevOps toolchain, cloud migration, and cloud management solutions that’ll power your software development efforts. Legal Your organization’s chief legal officer (CLO) or outside counsel is another link in the DevSecOps stakeholder spectrum.  Legal counsel is helpful as software licensing becomes more complex due to open source and commercial software components come together in product development. There are also potential legal issues as you establish software supply chains with licensing and contracts where having a legal stakeholder comes in handy. When you make legal counsel part of your DevSecOps stakeholder spectrum, you can count on the right software licensing questions and concerns before making a costly intellectual property (IP) or licensing mistake. Final Thoughts DevSecOps not only transform how you develop and secure software, but it also transforms your business or agency business units as well. Like it or not, DevSecOps makes software development truly a cross-functional effort. It’s up to you to bring the DevSecOps stakeholders together to ensure the success of your DevSecOps initiatives. ### Your DevSecOps Toolchain: 6 Steps to Integrate Security Into DevOps This blog post has been archived and replaced by the supporting pillar page that can be found here: https://anchore.com/wp-admin/post.php?post=987473366&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. ### Creating a DevOps to DevSecOps Framework for your Organization A DevOps to DevSecOps transformation works best with a structured framework acting as governance. When you approach such a transformation, putting structure around it allows you and your teams to stop, ask questions, and iterate on potential changes to your existing DevOps processes. Here’s a simple framework to help ensure an orderly DevOps to DevSecOps transformation: 1. Outreach and Education A move from DevOps to DevSecOps is far from strictly a technological affair. Such a transformation will significantly impact your developers, sysadmins, project management, and stakeholders.  DevOps to DevSecOps transformation touches other business units when it enables them to deliver on projects to their customers at a higher velocity and more securely. There may also be changes in how your other business groups interact with your development teams for new feature requirements and related matters. Outreach and education with developers can take a couple of forms. First, you want to seek developer participation in your transformation. It’s time to create internal advocates and champions for DevSecOps. That’s a little easier to do if your organization is already a DevOps shop. However, you’re going to need to extend your outreach efforts to your security team as well. When you build advocates and champions for DevOps to DevSecOps, your development teams become self-policing towards fear, uncertainty, and doubt amongst your developers who aren’t ready about making a move to DevSecOps. You can only do so much to change developer attitudes if you’re not working with them daily and understand their pain points. Sysadmin outreach plays out much the same way as developer outreach. Build allies. Work with them through any potential changes to their job duties, especially for bringing security checks and scans into their daily work. There are also outreach and education considerations that may take you out of your IT department to educate the business about DevSecOps. A move to DevSecOps is going to affect the executive management team over the DevOps teams. You want to set expectations about the benefits of DevSecOps and automation.  Exiting the outreach and education phase means you’ve met with your developers, sysadmins, stakeholders, and management. You’ve also delivered DevSecOps training, whether in-house or through an outside provider, to help upskill your developers and sysadmins and teach them about the benefits of DevSecOps. During this phase, security training may also extend to secure coding and vendor training on the DevSecOps security tools you plan to implement. This phase is also a good time to survey the market and seek potential vendors to help you integrate security. Visit their websites. Watch their online demos. Ask thoughtful questions about their products and services in such online DevSecOps communities such as DevOps Chat and The DevOps Institute. You should also seek solutions and insights from the open source community that may help you secure your DevSecOps delivery cycle. If you work inside a large corporation or government agency, establishing a DevSecOps Center of Excellence (CoE) brings together the DevSecOps expertise from across your organization. It can channel them into helping solve some technology and cultural challenges your organization might face in your move to DevSecOps.  2. Implement Security across your Toolchains Just like you’re giving your DevOps teams a choice in deciding upon their DevOps tools, the same should apply to the DevSecOps security. Whether you have teams choose open source or vendor-based DevSecOps solutions, the only caveat is that your organization’s requirements are met. This phase may overlap with the Education and Outreach phase depending on your organization’s schedule and related factors. While you’re building out your DevOps toolchains with additional security tools and features, it’s also a good time to audit the security of your DevSecOps toolchain itself. Remote DevOps teams and the growing prevalence of cloud-based DevOps tools comprising today’s toolchains making for attractive targets. Attackers are targeting toolchains with man-in-the-middle (MitM) attacks to compromise the development environment. Exiting this phase means your new security measures are in place and generating your required reports. Depending on your organization’s maturity and situation, it may also mean improving the security of your access controls and endpoints against future attacks. 3. Pilot Project There’s no better way to confirm that the tools and processes you’re putting in place for your DevOps teams to move to DevOps are working than a real-life pilot project. Pick a small internal project with an owner who’s keen to move to DevSecOps. Put your best people on the project and use it as a learning opportunity for your developers and sysadmins. It’s also an opportunity to educate your business stakeholders about the benefits and virtues of DevSecOps because you can show business value. Exiting the pilot project stage can happen once the project is live and you’ve captured the lessons learned and rolled them back into your DevSecOps processes. 4. Full DevSecOps Once you hit full DevSecOps, your job still isn’t done. When your organization hits this point, it’s time to take a continuous learning and collaborative approach to development and operations to speed up and secure your software delivery. Don’t forget an ongoing feedback mechanism once your DevOps teams move into full-on DevSecOps. You want to take in developer and sysadmin feedback to apply lessons learned through a DevSecOps Center of Excellence (CoE) or another forum where your organization can intake the information without filtering through management, bureaucracy, or corporate politics. DevSecOps isn’t meant to be a static state of being. You need to put your lessons learned into practice. You also need to offer ongoing training to your teams moving to DevSecOps. Final Thoughts Taking a systematic approach — such as an adoption framework — moving from DevOps to DevSecOps provides your teams and stakeholders with enough structure to transition their projects and job roles into this new way of developing software securely. This approach allows you to discuss your progress with your DevOps teams and their stakeholders at mutually agreed times during your transformation.  ### 5 Ways a DevOps to DevSecOps Transformation Changes Teams for the Better Whether your organization is moving from DevOps to DevSecOps or making the initial step from a traditional waterfall software development life cycle (SDLC) to DevSecOps, you need to account for how DevSecOps is going to change your teams. Here are five changes your teams can expect when your organization moves to DevSecOps: 1. Security becomes part of everyone’s job. Perhaps the most significant change that comes to DevOps teams when they take the next step in their DevOps journey to move to a DevSecOps model is that security becomes part of everyone’s job. It starts with incorporating security from day one of the project, whether it’s a new cloud application your organization is launching or an update to an existing application. When you take this first step, security is the “Department of No” or “It’s us versus them” when seeking approvals or collaborating on resolving security issues. Another step to security becoming part of everyone’s job is to provide security training for your developers. Training could take the form of in-house developer training in casual formats such as Lunch and Learns or more formal training classes conducted by your organization’s training department. Another option is to send your developers to a third-party training provider to get the requisite security training. Depending on your security ambitions (and budget), there is always the option to send your DevOps team members to get a DevSecOps vendor certification such as the DevSecOps Foundation certification from the DevOps Institute or the Certified DevSecOps Professional (CDP) from practical-devsecops.com. Finally, it’s also critical to document secure coding standards for developer onboarding and their later reference to ensure security becomes a part of the developer’s job. 2. Priorities may change Trust between your security and DevOps teams will not improve overnight. The key to building trust between these teams — traditionally at odds in some organizational environments — is about prioritizing results. Both teams need to set priorities that are best for the project delivery and the overall business. For example, some software bugs that the team may encounter during development may not be enough to halt a product release. The development and security teams 3. Instills a Fail Fast culture Unfortunately, in some corporate cultures, even the thought of failure can paralyze software development projects or keep the teams working in an endless loop redoing work to avoid releasing a product. When “Fail Fast” becomes part of team culture, developers identify bugs as they build. That’s a big contrast to the days when developers or QA would work on bugs during the last few days (or hours!) before product launch. DevSecOps culture enables developers to take the time to fix issues in development versus spending hours or days fixing the issue once your application is in production. Elements of a “Fail Fast” culture include: Failure becomes a learning experience for the team rather than a career-ending incident. Teams document lessons learned from the failure and put in the tools and processes to ensure the failure doesn’t happen again. Testing. QA and remediation are recurring aspects of the DevSecOps lifecycle enabling developers to find bugs and issues during the development lifecycle before your application hits production. Ask for help becomes a rule rather than an exception, with team members not worrying about losing face to their fellow team members and management. “Fail Fast” cultures aren’t born overnight. Creating such a culture requires management support, accompanied by building trust across the teams who work together to deliver software. Most of all, management needs to lead by example and show their teams that failure is a learning opportunity, so take the extra time to put actions behind words if you’re a manager or stakeholder. 4. Increases Transparency DevSecOps is no place for job security through obscurity. The DevSecOps culture warrants transparency between developers, security, and operations teams during their work. Increasing transparency requires the work of everybody to open collaboration between groups. Here are some examples of how DevSecOps increases transparency: Security teams enter the DevOps lifecycle, ensuring developers, security, and operations teams see everything through the same lens while working together. Teams begin to use the “same language” since they are now working together during the development lifecycle. As engagement between development, security, and operations teams grows, it can finally be possible for these groups to see they are all aligned to a single goal and start dropping the “us versus them” attitude that can sometimes affect how these teams collaborate with each other. Another element of transparency that you should monitor on your teams is engagement. Be prepared to work with teams and staff who might have been working in silos either deliberately or through no fault of their own. 5. Treat Metrics as your Missing DevOps Team Member Tools across the DevSecOps toolchain are chock full of data for teams and their stakeholders to track. DevSecOps culture enables teams to tell their data-driven story to internal stakeholders such as executives and project sponsors. Some metrics to consider capturing during your delivery lifecycle include: Reduced Total Security Tickets Opened Discovery of Preproduction Vulnerabilities Reduced Time-to-Remediate Reducing Failed Security Tests Percentage of Security Audits Passed When choosing DevSecOps tools, make sure that analytics and reporting tools are prominent in your requirements.  Also, be prepared to iterate on metrics and reporting as you and your stakeholders learn more about your organization’s reporting capabilities and needs. DevSecOps and Other Business Units Also, keep in mind that many of the changes that DevSecOps demands of development and operations teams also trickle out to the business units that sit around the periphery of software development projects. For example, business stakeholders will have to factor more security requirements into their project requirements. Your executives have the opportunity to tap into more backend data from your DevSecOps toolchain and view actionable data through dashboards that your teams can set up and configure. DevSecOps also provides your compliance auditors with new options for tapping into security and application data that would have required extra efforts in the days of waterfall software development. Final thoughts: Building the Better DevSecOps Team Setting up a DevSecOps team for success isn’t about just throwing some security tools into your existing DevOps toolchain and considering it done. It’s about cultural transformation and transparency. The first employees to feel that change will be in your development, operations, and security groups. These are also the team members you need to buy in on your DevSecOps vision. ### Anchore Enterprise 3.0 introduces New Features to Secure the Software Supply Chain Hopefully, heralding the start of what is a happier new year for everyone, today we are pleased to announce the availability of Anchore Enterprise 3.0. Over the past 18 months since our last major release, much has happened in the world of software security (and beyond!). From the software supply chain becoming a national security issue to the major developer platforms prioritizing DevSecOps in their roadmaps, the practice of hardening the entire software-delivery lifecycle is now front and center of all organizations.  We’ve taken a hard look at the fundamental challenges of taking a true “shift left” approach to cloud-native security. Finding vulnerabilities or flagging issues in software is not difficult. Every piece of software has something that could be of concern. The critical challenge is doing it to reduce developer friction by avoiding noise, providing relevant context, and clear remediation steps. Let’s drill into the major features of the 3.0 release, which help our customers achieve these goals. Check out our launch video: Bringing the Kubernetes Context to Container Alerts  Anchore Enterprise has integrated with Kubernetes for a while, blocking images being deployed that fail to meet security standards. With 3.0, we’ve taken that a step further and now connect into the operational Kubernetes environment to catalog the running instances with our Kubernetes Inventory feature. We can flag any containers which have active vulnerabilities or are now failing policy or compliance checks that have run or are running Kubernetes. By marking the relevant image digest in your registry as being currently run in production and its being a security concern, developers can more easily prioritize their response to alerts. A Distributed Model for CI/CD Scanning Many security tools in the container space wait for an image to be published to a registry by the CI/CD system before scanning it, adding performance overhead and placing the burden of scanning on a central security platform.  To distribute the processing effort and improve pipeline speed by reducing network traffic, we’ve completely refactored how we integrate with GitLab, GitHub, and other popular CI/CD tools. Our new Go-based Pipeline Scanner tool creates the Software Bill of Materials (SBOM) from the container image locally in the CI/CD platform itself and sends the results to the central Anchore system. Anchore then sends back the policy result to pass or fail the CI job. This new deployment model improves the operational cost of running the Anchore system while also simplifying the security scan’s operational overhead in the pipeline. Helping Security Teams help Developers You have security information from the pipeline scan and situational awareness from the Kubernetes inventory. What should a developer do next? Our Remediation Action Plans are a brand new addition to our user interface, allowing security teams to generate clear instructions for developers on how to resolve security alerts. Pre-populated suggestions created by Anchore Enterprise can be combined with contextual information and then sent out to popular messaging or ticketing systems.  This powerful combination can help developers, who are probably not security experts, understand the options available to them, resolve issues faster, and allow additional research to be passed along by the security team.  Reducing False Positives  False positives are the bane of all security teams, wasting time and effort on wild goose chases. On the container input side, we added a “Hints'' capability in 2.4 which allowed developers to explicitly describe software content to help improve vulnerability matching and reduce false positives. In 3.0, we’ve added a new False Positive Management feature so security teams can modify artifact metadata after it has been extracted by Anchore’s system. This allows for gaps or inaccuracies in the data generated during a scan to be fixed thereby ensuring better fidelity with associated fields in the vulnerability database. This is particularly useful for particular language artifacts such as Java which either have inaccurate metadata or don’t have any data at all. Finally, DevSecOps teams deal with false positives are often dealt with by allowlisting specific packages. This provides a quick and instant way to unblock a pipeline. However, allowlists tend to linger, making what is often intended to be a temporary reprieve to an image a permanent exception. This in itself can become a security concern as fixes are not followed up. With our new Allowlist Expiration feature, security teams can ensure that exceptions to deployments can be time-limited on a customizable value. Looking Forward Anchore Enterprise 3.0 is going to continue to receive regular updates throughout the year. We plan to continue adding more runtime features and deeper integrations with the CI/CD platforms while improving the fidelity of security information. As ever, we look forward to hearing from customers and do sign up for our upcoming Anchore 3.0 webinar entitled How to Secure Containers Across The SDLC.  ### DevSecOps and Defense in Depth for Software Supply Chain Security One challenge that needs addressing in the software supply chain security fight is the balance between agility and redundancy in enterprise security strategies. There’s no better example of that than the recommendations about moving to DevSecOps and implementing Defense in Depth to improve your software supply chain security. DevSecOps and Software Supply Chain Security The shift left movement that DevSecOps offers can be vital to securing software build environments. DevSecOps is the next step beyond DevOps, a cultural change that brings security into DevOps rapid release cycles. DevSecOps is built for agility and velocity. It relies on a range of open source tools to automate the software build cycle. It’s also not uncommon for organizations to put their own spin on DevOps and DevSecOps to meet their security and compliance requirements. There’s plenty of room for enterprises adopting DevSecOps to “build to suit,” which can make it challenging to maintain DevSecOps standards across vendors serving a software supply chain. The cultural changes that DevSecOps brings to software development can almost be more important than the tooling because it brings security concerns into the development lifecycle versus making security the last stop (and the last night) before applications hit production. The DevSecOps culture stresses: Transparency yields trust with sharing between the DevOps and security teams inside enterprises Shared goals and metrics with DevOps and security teams cooperating on shared goals to achieve the desired metrics to achieve compliance and security While often an ideal, these cultural norms have a lot of applicability to securing the software supply chain. Transparency along the software supply chain builds trust. That can play a couple of different ways. When you build trust with your vendor teams along your supply chain, it becomes easier to share information and collaborate on security and operational challenges. Many of us are also working under challenging personal and professional circumstances during this pandemic. It only helps that you have clear lines of communication open to set expectations. You also want to create an environment where your team, not to mention vendors, can feel safe asking questions and bringing up technology and business issues. Defense in Depth and Software Supply Chain Security Another security technique bound to gain attention in the fight against software supply chain hacks is Defense in Depth. Typically, a security strategy of large enterprises with big budgets, Defense in Depth employs multiple layers of security controls so that if one layer fails, other layers remain operating. No enterprise can say that its systems are 100% secure. That goes for any organization working on your software supply chain. Otherwise, there’d be no need for such drastic security measures as Defense in Depth. Nor would you need system redundancies because attackers wouldn’t be able to exploit your systems. In reality, the state of software supply chain security isn’t going to change much in the next year or even five years. Thus, it behooves security teams across the supply chain to look to security measures such as Defense in Depth to put in “sea walls” with the attitude that eventually, a wave may crash over the wall. Defense in Depth includes three layers of controls: Physical layer, which controls the physical access to IT systems, including fences and human guards. Technical controls such as fingerprint readers, authentication, and data encryption that prevent access.  Administrative controls are an organization’s policies and procedures to ensure security and compliance requirements are met. Policies include hiring, onboarding, and other processes that govern how technology teams do their work. There’s no real cultural shift that Defense in Depth brings with it. Yet, it’s essential to consider the introduction of system redundancies to developers and sysadmins’ routine day-to-day work. Specific job roles and metrics would undoubtedly have to adjust to running, managing, and securing redundant systems. DevSecOps and Defense in Depth There are many questions about how a coopetion between DevSecOps and Defense in Depth could work for the average enterprise. Both security strategies have their purposes. The cultural aspects of DevSecOps, especially when it comes to transparency, still relate very well to Defense in Depth. Sooner or later, large enterprises scrutinizing their software supply chain security need to start paying attention to the people aspect of software supply chain security — transparency, insider threat, security training, and communications.  The people aspects of software supply chain security are bound to come under additional scrutiny in some large enterprises. There are some lessons for everybody to learn from how DevSecOps handles culture and metrics that can transfer over to Defense in Depth. System redundancies are where DevSecOps and Defense in Depth are at odds. The reference architecture of the typical DevSecOps toolchain is lean and mean, without redundancies. Some organizations even allow their development teams to choose their tools to build out their toolchains. Somehow, the smart enterprises will cherry-pick from DevSecOps and Defense in Depth to create a solution within budget that can improve their software supply chain security. Final Thoughts Risk mitigation around software supply chains is going through an awakening post-SolarWinds. DevSecOps and Defense in Depth both help mitigate a range of significant security risks. The gravity of a software supply chain attack brings home the reality that despite your best preparations, it’s essential to acknowledge that you’ll be hacked. It may not be your enterprise directly but could be one of the vendors along your supply chain. So, you must do the best you can as a security organization. Put in the right tools. Institute best practices. Train your developers and security teams in best practices. Incentivize your vendors to follow suit.  But most of all, you should have a response plan in place to augment your security tools and strategy.   ### 5 Critical Job Skills for Software Supply Chain Security Professionals When auditing your software supply chain security, it’s important not to forget building and maintaining the job skills of your software supply chain security team. Building skills amongst your software supply chain security team and setting expectations for skills and experience amongst your supply chain vendors is a prudent investment as you prepare for a potential attack in your future. Here are some job skills to build and refresh amongst your technology teams and vendors who make up your software supply chain: 1. DevSecOps The agile nature of the software supply chain combined with the operational complexities necessitates people with DevSecOps skills and experience.DevSecOps brings your security team and tools into the DevOps life cycle. Designating DevSecOps as a desired job skill for your software supply chain internal and vendor teams also gives your teams a common framework, operational expectations, and terminology that can help improve operations across your supply chain. Building upon and validating DevSecOps skills is still a nascent activity. There are few industry certifications right now for DevSecOps. The DevSecOps Foundation certification from The DevOps Institute is one certification you can have your software supply chain team members pursue to level set DevSecOps skills across your teams and vendors. If DevSecOps certifications aren’t workable because of timing and availability, then consider the DevSecOps courses on learning sites such as LinkedIn Learning, Cloud Academy, or A Cloud Guru.  Another option for DevSecOps skills training is to create your own internal training program for all engineers and architects involved in your software supply chain. Your team members who are in charge of software supply chain security need to partner with every vendor team that touches any part of your product during the DevSecOps life cycle to validate that security is an integral element of the vendor’s software delivery organization’s tools, processes, and culture.  2. Oral and Written Communication (Soft Skills) Securing the software supply chain of today requires that all the participants have soft skills. Relationship building is critical behind the scenes of software supply chain security as you often have to interact with executive decision-makers, management stakeholders, and counterparts on their vendor teams. Extending the need for soft skills outside your own enterprise, dealing with vendors and suppliers across your supply chain in times of regular business and crisis situations requires strong oral and written communications skills and even empathy. Building up soft skills takes practice. While there are various online platforms that offer soft skills training, sometimes the best training is having your managers and team leads set the example so you establish a culture where soft skills are seen as a benefit and not a weakness. 3. Analytical Skills Software supply chains add additional levels of complexity to software delivery. With more complexity comes more opportunities for things to break down at points across your software supply chain. Building up analytics skills on your teams can take a couple of forms. Most commonly, it’s thought of as a personal learning pursuit. However, DevOps teams have the advantage of using retrospectives and post-mortems to showcase the analytical thinking skills of their senior team members. These meetings also give you the opportunity to put a structure or framework around troubleshooting and analysis. 4. Cloud Architecture As the cloud is playing a predominant role in the software supply chain, it’s time to make wise staffing investments in cloud architects. Yes, cloud architects are an in-demand role, as Google shows in their use of trusted cloud computing to secure their own software supply chains. While Google is an extreme example of how cloud architecture skills play into a software security supply chain security, cloud infrastructure is a growing attack vector. You want to have that skill set in your organization. It’s also a skill set you want across your vendors. Cloud architecture is an in-demand job skill. Fortunately, cloud architect training options abound. Each of the major cloud services providers has solution architect certifications. Your employees and partners can take the training and even their certification tests online. 5. Documentation You can’t run a software supply chain with its needs for processes, frameworks, and policies on oral history, email inbox, or Slack channel alone. You need to create a documentation culture with the job skills to go with it. Outside of the security requirements, you place in your vendor contracts and RFPs, written documentation is necessary to help educate your vendors about the standard security practices they must follow to remain a vendor in good standing for your software supply chain. For example, a best practice is for vendors to document their software and hardware design and build processes to ensure the processes are repeatable and measurable. Such documentation should already be part of the cost of doing business if your product must meet compliance standards such as FedRAMP, Sarbanes Oxley (SOX), or the Health Insurance Portability and Accountability Act. Building documentation skills isn’t about throwing contract technical writers to write some documentation for your supply chain as part of a rapid-fire one and done project. Rather, documentation needs to become part of team member jobs and vendor requirements. Options for building documentation skills: Embed technical writers or editors amongst your teams to act as writing coaches for technical staff tasked to document the systems and processes they support Create documentation templates for the major document types you require from vendors and provide job aids and documentation kickoff meetings and follow up support Showcase examples of well-done documentation in team and vendor meetings Final thoughts As your teams work to improve their support of software supply chain security you’re going to encounter many judgment calls. The job skills in this blog post, all have one thing in common. They all require continuous learning in order for your internal teams and vendors to be successful. As the software supply chain becomes the latest attack vector for nation-state and other attackers, it’s in your best interests to give your teams and vendors the tools they need to succeed. ### 7 Trends Lining Up to Fight Software Supply Chain Attacks Software supply chain attacks are going to be forever on the minds of CISOs and DevSecOps teams as commercial and public sector enterprises look for ways to avoid the headlines as the next SolarWinds. Now’s the time for technology, collaboration, and compliance processes to come together to help protect software supply chains. Here are seven trends that paint a future picture of how it may all work: 1. Compliance Strengthens in the Face of Supply Chain Security We’ve yet to see a full response from the compliance world — HIPAA, Sarbanes Oxley (SOX), and PCI-DSS —  in the aftermath of the SolarWinds compromise. Responses from the compliance community are certain to come out as healthcare, financial services, and other compliance-governed industries seek advice and counsel about what makes for a compliant software supply chain to their auditors. One compliance standard built for multi-vendor environments is the United States Government’s Federal Risk and Authorization Management Program (FedRAMP). When you peel away the bureaucracy and the politics, the federal government is just one big compliance play. They have the experience of integrating multiple vendors from large systems integrators, taking small to midsize companies into their software supply chain while maintaining security and compliance. However, despite all the goodness of FedRAMP, there’s little adoption outside of businesses that do government work. 2. Defense in Depth Protects the Software Supply Chain Defense in Depth is a strategy where you treat every piece of software that you bring into your software supply chain as malicious actors regardless of whether the source where it’s your own developers, external suppliers, or open source. You run and monitor the software accordingly.   However, Defense-in-Depth is extremely expensive to do for real. 3. The Rise of Code as an Attack Vector A software supply chain attack, such as we saw with SolarWinds, will put a renewed focus on code as an attack vector. DevSecOps, with the “shift left” culture it brings, will increasingly become a necessity for development teams up and down the software supply chain. Part of the shift-left culture is to equip your developers with lightweight tools to use locally to scan their code. You can expect to see other mitigation strategies on the rise such as developing a robust code composition strategy with a detailed software bill of materials (SBOMs). Such strategies with a fully documented and verified change of custody for all software code entering the supply chain. Your developers can also run a secrets calling tool on all code repositories and include active monitoring. You should also have your developers or in-house cybersecurity team search for your code in public Git repositories, especially GitHub and GitLab. Finding your code once means there’s bound to be more of it out there. Another strategy is to invest in tools to monitor code integrity and git misconfiguration. Deploy these tools in your DevSecOps pipelines and ensure that your supply partners are using the same or similar tools in their DevSecOps toolchains. 4. OSS and the Future of Supply Chain Security There are bound to be more questions than ever about open source software (OSS) in enterprise software supply chains across industries and governments. While OSS is a foundation to leading DevOps, DevSecOps, and cloud-first initiatives, it will not stop technical and business leaders from asking even more questions about sourcing this critical software. There are still more questions than answers about what the post-SolarWinds world may look like for major OSS projects prevalent in the enterprise. It may lend even more credence to the Red Hat business model and perhaps breed more companies taking ownership over some more facets of OSS. Some in the OSS community are calling for more corporate open source citizenship. For-profit companies and even government agencies donate money, time, and expertise back to the OSS projects they use most to improve the project’s code security. On the security front, it could mean that enterprises depending on OSS enlist mandatory code scanning tools to vet all the open source code entering the toolchain. It could lead to an onboarding process for open source code. 5. DevSecOps for Everybody! DevSecOps could become one cost of entry for partners in a software supply chain soon. While criticisms about the validity of DevSecOps abound in some technology industry circles, the current situation offers the DevSecOps movement a time to prove itself.  The benefits of well-executed DevSecOps across software supply chain providers include: A common language for developers, security, and operations teams Improved access to actionable data from backend development, build, and QA systems for reporting to stakeholders and auditors A development model that relates well to iterative software development and automated security testing at each phase of the development cycle In the future, larger enterprises may demand contractually that all their suppliers follow a DevOps/DevSecOps model of development. However, such standardization of practices could be difficult, if not impossible, to enforce in all reality. However, startups already standardized on agile and DevOps gain a leg up if they have salespeople who can bring home large enterprise accounts. 6. Transparency Grows in the Software Supply Chain DevOps and DevSecOps have driven home the need for transparency in the development lifecycle. Transparency needs to grow throughout the software supply chain during 2021 and beyond. One solution to make that happen is in-toto -- a software supply chain security framework-- that includes current integrations with Git, Docker, Datadog, and some other open source build tools. 7. Zero Trust across the Supply Chain As concerns over software supply chain security grow in 2021 and beyond, zero trust security solutions may come to bear in the next generation of software supply chain security. However, there are some caveats to this approach. Zero trust security is still an emerging category (albeit with great potential). My colleague, Andre Neufville, wrote about how zero trust security can protect containers. It’s a technology bound to find itself in the software supply chain of the future because it treats all code as equally malicious while giving developers and security teams the tools and processes to help mitigate the associated risks. Final Thoughts There’s no denying that software supply chain security will forever remain a challenge. Given that,  it doesn’t mean that your organization can’t be forward-thinking in the technologies and strategies that you put in place to mitigate risks across your software supply chain ### Preparing for Future Software Supply Chain Attacks Questions around software supply chain attacks aren’t leaving the industry conversation anytime because of the SolarWinds attack. It’s time to review your software supply chain security fundamentals. Now that we’re in 2021, we can all expect newfound attention on securing the supply chain inside business and government.  Let’s first define the role of the software supply chain in modern software development. Software Supply Chain Explained To prepare themselves for software supply chain attacks, teams need to understand the software supply chain’s operational role in their product development and services activities.  Much of the traditional security focus inside commercial and public sector enterprises is about compliance with end-user security. DevSecOps — still in its infancy — is starting early adopters on a journey to bring security into the start of the DevOps life cycle. It’s also breaking down the traditional silos that exist between developers and security. Now enter the software supply chain, which follows a similar model as a manufacturing supply chain. One of the software supply chain’s primary jobs is to ensure that the right code is being developed for the program’s most essential features. When you consider the scale of enterprise applications, the correct code encompasses multiple applications, a potentially exhausting list of application features, plus internal and sometimes third-party development teams to maintain existing applications and create new code. Such a scale and complexity make it a growing attack vector. So much has changed about large-scale software development over the last decade. A significant change is that today’s software supply chain includes a sourcing step. It works similar to the sourcing to the sourcing step in the traditional supply chain where your organization manages relationships with suppliers. The sourcing step is also where an organization buys parts or materials that are more efficient or cost-effective to outsource. For example, in enterprise software development, stakeholders use the sourcing step to purchase security software for integration into the products they’re developing if security isn’t part of their strengths. It’s also the step where organizations determine using open source software based on their products or as an integration option for features. Whether the source is an open source project, a fledgling startup, or an offshore firm, organizations must put in the tools and processes to analyze the components’ quality and security entering their software supply chain. Such an analysis should include  the following factors: Developer documentation, especially for the product’s application programming interface (API) Software support through community forums or fee-based arrangements with the developer Commercial and open source software licensing agreements Security features in the software It’s also raising questions in the halls of Congress about whether the U.S. government has an adequate framework to assess the security of products upon which the government relies, according to CyberScoop. We’ll be discussing the intricacies of open source software in the corporate software supply chain in a future blog post. Software Supply Chain Security Fundamentals Here are some fundamentals of software supply chain security to brush up on as you look to improve your supply chain security in 2021: Practice Basic Cyber Hygiene Like so much of cybersecurity as a discipline, start with security basics at the top of the list to maintain supply chain security.  Basic cyber hygiene starts with installing industry standards antivirus and malware software on any machine or mobile device that accesses the supply chain.  Another step is to set strong passwords, multifactor authentication, device encryption, and regular software updates for any machine or mobile device with access to the supply chain. You can enforce these policies from your enterprise mobility management (EMM) platform. Other hygiene practices include using network firewalls to protect your software supply chain. You also need to back your systems up regularly and clean their hard drives on a regularly scheduled basis. Include Software Supply Chain Attacks in your Threat Models When creating or just updating your threat models, be sure to include supply chain attacks. While many analysts, pundits, say that SolarWinds did nothing wrong, that’s no excuse for you not to factor software supply chain attacks in your threat models. Institute Proper Risk Management for your Supply Chain The technology risk management discussion has mostly been devoid of the software supply chain, unfortunately. My colleague Andre Neufville, an Anchore solution architect, speaks to the wisdom of instituting proper risk management in the DevSecOps pipeline and some other advice that you can also apply to your supply chain best practices. Work with your Partners to improve Security Accountability It’s one thing to manage your technology stack and supporting infrastructure; it’s another thing to secure and enforce your development partners that you have in your supply chain. While challenging to do, you can look at contractual measures to ensure security with enforceable penalties if broken. Unfortunately, such contractual agreements can be challenging to enforce. There’s also seeking out third-party vendors who’re already adhering to your industry’s necessary compliance standards.  Implement Defense in Depth Another option to explore if you have the budget is to implement defense in depth, where you treat every piece of software you bring into your supply chain as a malicious actor. It doesn’t matter if you source the software from your internal DevSecOps teams, a third-party supplier, an open source software project, or a combination of sources. Defense in Depth requires your organization to put in the tools and processes to monitor everything that enters your supply chain. It’s an expensive measure to implement and out of reach for all but the largest of enterprises. Key Takeaways Remember that as software supply chain attacks continue to mount in the future, tactics will change, but the basic cybersecurity fundamentals will remain in place. Your DevSecOps team needs to work with your auditors and cybersecurity team to ensure that your supply chain security adheres to your required standards. Here are some key takeaways: Software supply chain security is the new hot button security concern for 2021. Start with the cybersecurity basics when securing your software supply chain, including strong passwords, multifactor authentication, and regular software updates. Include software supply chain attacks in your organization’s threat models if you aren’t doing that already. Institute proper risk management for your supply chain using the same practices you’re already applying to your organization’s software and business risk. Implement Defense in Depth treating everything that enters your supply chain as malicious (an expensive option!). ### 5 DevSecOps Myths to Dispel in 2021 DevSecOps seems to attract its share of myths. As we go into 2021, it’s time that we as an industry work to dispel those myths for our prospective customers, customers, and internal stakeholders across our organizations. Here are some common DevSecOps myths we can all work on dispelling in 2021: 1. Organizations lose control when they move to DevSecOps. Software development has a legacy of long development timelines in both business and the public sector. There are long quality assurance cycles with a final assessment by a security team at the end of the process. A move to DevSecOps may seem like a loss of control to project managers, developers, QA, and security teams who are used to working on development projects following traditional waterfall software development methodologies. Dispelling the myth that your organization will lose control once you move to DevSecOps takes a multi-faceted approach. Internal training for your technology and business teams can be a powerful force to quell this misconception for starters. Then, when you tell the story of a DevSecOps pilot project, be sure to include facts around how the DevSecOps toolchain improved security and compliance coverage. Another exciting way to dispel stories about loss of control is to focus on the new reporting options for developers, security analysts, and business stakeholders that can now be made available because of the tools and processes you’ve put in place for DevSecOps. 2. You can buy DevSecOps. Marketing departments, PR agencies, and vendors are all trying to ride the DevSecOps trend to increase sales. The message that you can buy DevSecOps from a vendor — after all, it’s just a tool or a suite of tools — is a myth that DevSecOps has inherited from DevOps. Sales and marketing reps perpetuate this myth on sales calls all the time. Part of any DevSecOps pilot should be education and outreach to stakeholders and influencers inside and outside your IT groups. Your non-developers are still going to feel some cultural changes that DevSecOps adoption brings to organizations. 3. DevSecOps is about Speed and Speed Only. There’s the ongoing myth that DevSecOps is about speed and speed only. Improving software delivery velocity is but one aspect. Automation help speed deployments while improving software quality and compliance. 4. DevSecOps requires an elite senior-level Development Team. There’s a wrong sentiment out there that DevSecOps is only for an elite team of senior-level developers working as a tight group with specialized training, certifications, and tools. There’s no secret society of DevSecOps either. You shoot down this myth by keeping open lines of communications open between your DevSecOps delivery teams and the rest of your organization. Provide a DevSecOps overview to your business stakeholders to teach them the benefits of DevSecOps in business terms they can understand. Ask what support your business and technology teams to best communicate with each other because on of the tenants of DevSecOps is transparency, after all. 5. DevSecOps isn’t for Remote Teams. A program manager once told me that remote teams couldn’t do DevOps. Well, COVID-19 has proven him wrong. Enough said. The same myth follows DevSecOps around as well. Let’s say you may have a team that’s finding success with DevSecOps during the pandemic. You still need to capture and communicate the success stories and the lessons learned from working on DevSecOps as a remote team. At some point (maybe), your organization will return to everyday life back in the office. Anecdotes of DevSecOps success during COVID-19 will not be enough for some critics. Take the extra steps to capture data, metrics, and positive feedback from your internal and external customers. Final Thoughts  DevSecOps is another technology change that employees have to keep tracking. Some employees will embrace the changes with passion. Others will see DevSecOps as a disruption to their daily routines. DevSecOps myths take root in between these groups. Start of your 2021 with a campaign to improve your communication and education about DevSecOps to dispel such myths. ### 2021 DevSecOps Predictions: A Year of Growth and “Shift-Left” As a company, Anchore has been tracking the growth of DevSecOps we’re seeing in the market and with our commercial and public sector customers during the past year. DevSecOps keep progressing despite everything that was going on with the pandemic.  Our team recently got together and made some predictions about how DevSecOps will fare in 2021: Shift Left Grows from Objective to Best Practice Shift-left will become more of a practice than an objective.  In 2021, I predict that more dev teams will embrace shift-left concepts in a more pragmatic way, predicts Dan Nurmi, CTO of Anchore.  While early on, much of the messaging around shift-left security was taken as 'moving' responsibility from so-called 'right' (production, run-time, with responsibilities being on operators) to 'left' (closer to the source code with responsibilities being on software developers), the more realistic perspective is to embrace shift-left as 'spreading' the responsibilities rather than wholesale 'moving' them.  In practical terms, I predict that as more quality security/compliance tools exist that integrate into a DevSecOps automation design, the reality and value of being able to detect, report and remediate security, compliance and best-practice violations at *every* stage of an SDLC will become the norm. Shift Compliance Left Becomes Reality Compliance is ready for shift-left treatment, Nurmi also predicted.  There is significant overlap between many aspects of an organization's compliance requirements and the practices that exist for ensuring secure software development and delivery.  In the same way that shift-left has become a rallying cry for more efficiently handling secure software delivery, we predict that in 2021 the industry will begin looking at how a similar approach (if not identical) can apply to solving organizational compliance requirements, particularly as they pertain to the organization's own internal use of software and software services. DevSecOps grows outside of Compliance-based Industries “Given the increasing number of digital assets and the average cost of a cyberattack, it is critical for organizations to constantly be looking for weaknesses in their attack surfaces. In 2021, we will see more organizations than ever adopt DevSecOps into their cybersecurity strategies, or risk having their integrity and reputations destroyed,” Blake Hearn, DevSecOps engineer for Anchore, predicts. 2020 has been a year of change for many aspects of people’s lives, especially technology. Up to this point, DevSecOps has mostly operated in industries with heavy security mandates: defense, healthcare, and finance, adds Michael Simmons, DevSecOps engineer at Anchore. “I see DevSecOps spreading to other sectors as cybercrime rises due to the importance of software in function of people’s lives in the pandemic world.” “Additionally, California consumer data protection laws came into effect in 2020. Any businesses that operate in California need to abide by these rules,” Simmonds added. “Because of this, I see DevSecOps spreading into more mainstream industries and technology companies as they move towards maintaining compliance.” DevSecOps continues to Grow into a Data Play “Opinions on the growth of artificial intelligence (AI) in DevOps and DevSecOps vary. I see the release of AWS DevOps Guru more than a sign that DevOps and DevSecOps will grow into even more data-driven activities well into 2021 and beyond,” predicted Will Kelly, technical marketing manager for Anchore.  “With so many DevSecOps teams moving to remote work, it only makes sense to maximize the use of backend data to maximize the effectiveness and efficiency of those teams. AI and machine learning tools are where we’re going to see that happen for real.” DevSecOps in 2021 2021 is bound to be an exciting year of growth and maturing for DevSecOps as enterprises continue to lean into DevSecOps tools and strategies to apply lessons they learned during COVID-19. ### 2021 Container Predictions: The Year of Containers Walking Fast So many of us will be glad when 2020 is over and one for the history books. On the bright side, it has been an excellent year for container technologies, though. Recently, some Anchore employees made their predictions for the container market in 2021: 2021: The Year of Containers “Walking Fast” “If we look at container adoption as a matter of crawl, walk, run, 2021 is looking like many in the industry will be walking fast,” predicts Dan Nurmi, CTO of Anchore. “We've seen many mid to large organizations choose containers to realize their ultimate objective of delivering fast, stable, highly-automated, secure SDLC processes. Up until now, the greatest success we've seen has been in smaller R&D and greenfield projects.  Moving forward, organizations will be building on the tools and techniques delivered by these successful projects to drive container adoption further into critical production application environments."  He adds that many of these container projects have shown real value without sacrificing design characteristics. Containers drop their Bad Reputation He predicts that in 2021, now that many successful container-based designs have been proven out, organizations and designers will begin seeing characteristics of containers as beneficial rather than as problems.  He explains the flexibility of software choice to developers, clear and trackable content, quick update and deployment are aspects that containers can quickly provide and can be leveraged rather than resisted, now that tech exists to overcome those early concerns such as stability, security, monitoring, and provenance tracking. Containers aren’t the enemy, advises Nurmi.  “Whenever there is an innovation/evolution in the developer infrastructure space, there is an immediate and legitimate outpouring of concerns about the challenges and problems that appear when shifting to something new.  Container technology supports a compelling enough set of values to make the change worthwhile. However, with the availability of new and ever-improved tooling, we're now seeing organizations overcoming many of these initial concerns, ranging from software provenance to security and monitoring.” Growing Container usage Demands  Better Tooling More and more technology corners that haven't adopted containerization (or have, but not entirely) will continue the path towards better and more usage predicts Alfredo Deza, a senior software engineer at Anchore. He adds, “With that usage, the demand for better tooling will follow through. The need for integrations everywhere and anywhere for containers will continue, and more tools will default to a containerized installation only. “In areas like Machine Learning, containerization is becoming more prominent, and more cloud support dedicated to containers and machine learning will follow up," Deza further predicts. Multi-cloud goes Mainstream Multi-cloud will become mainstream in 2021, according to Paul Novarese, a senior sales engineer at Anchore. Unlike multi-region techniques that are mostly availability tactics, multi-cloud is a strategic way to avoid vendor lock-in. Serverless Container Platform Adoption Expands Infrastructure becomes more of a hindrance, and the adoption of serverless container platforms (such as Fargate) expands, Novarese predicts.  In a serverless universe, security solutions that rely on sidecar containers, agents, or kernel modules become obsolete - deep image awareness and continuous compliance become more and more important. Rise of Docker Build Alternatives There are already a lot of options for building containers without Docker. In 2021, these options will continue to gain momentum, and alternatives to Dockerfile may be just as popular as docker build, according to Adam Hevenor, principal product manager at Anchore. “I am keeping my eye on Cloud Native Buildpacks, which was recently brought into the Incubation stage by the CNCF.”  Rise of the Rest of the Registries With changes to the Dockerhub usage caps, we can expect to see more and more projects use alternative registries, predicts Hevenor. It remains to be seen whether open source projects will move out of Docker Hub. Still, offerings from Github, Amazon Web Services, and Google are going to become increasingly common places to keep your container images.  Beyond Kubernetes (towards Serverless) While Kubernetes has captured most enterprises’ mindshare, managing and upgrading Kubernetes is still a big challenge for operators, stated Hevenor. He predicts with the announcement of Lambda’s support of containers and the growth of Google Cloud Run and Azure Functions you can expect to see more and more enterprises consider serverless alternatives to Kubernetes.  Container Adoption on Microsoft Windows will Double in 2021 Mike Suding, a  sales engineer for Anchore, predicts that container usage/adoption on Microsoft Windows will double compared to 2020. Because of the law of small numbers and Microsoft’s history of excelling when their executive team gets behind a product or service. Containers in 2021 The Anchore team has high expectations for container acceptance and adoption in the market next year even when enterprises begin to enter post-COVID-19 recovery and many digital transformation projects mark their completion. ### Securing the DevSecOps Pipeline We live in an unprecedented era of remote work due to COVID-19.  Now is the time to review the security of your DevSecOps pipeline to ensure that the tools and workflow powering your software development is secure from attacks. Here are some tips to consider as you evaluate your approach to integrating security at each stage of the development lifecycle. Implement Threat Modeling Threat Modeling not only helps security teams define security requirements and assess underlying risks associated with new and existing applications; it fosters ongoing communication between security and development teams. Integrating threat modeling tools in the development lifecycle promotes collaboration between each team on the system architecture and provides a consistent method for tracking key information. Microsoft’s Threat Modeling Tool and OWASP’s Threat Dragon are popular open source tools used in DevSecOps pipelines to conduct threat modeling. Utilize IDE Extensions Utilizing IDE extensions to identify vulnerabilities and security flaws as developers are writing code is an easy way to catch security issues early on. It also serves as a way to educate developers on good coding practices.  Run Peer Code Reviews Implementing peer code reviews is another method to ensure developers are using secure coding practices. Code reviews practices can improve the quality of your organization’s code base as it fosters collaboration between reviewers and those writing the code, facilitating knowledge sharing, consistency, and legibility of code. Implement Pre-Commit Hooks Exposing secrets such as application programming interface (API) keys, database credentials, service tokens, and private keys to source code repositories occur more frequently than you might think and can be costly for organizations. In 2019, security researchers discovered over 200,000 unique secrets on GitHub. Integrating pre-commit tools in code repositories can prevent your secrets from being pushed inadvertently. Bolster your DevSecOps workflow with Automated Security Scanning and Testing  As development teams focus on ways to push faster release cadences, automated security scanning and testing is critical to identify vulnerabilities and other issues early in the development lifecycle.  For containerized applications, container security scanning tools evaluate container applications and their underlying file system for vulnerabilities, secrets, exposed ports, elevated privileges, and other misconfigurations that may be introduced either from public base images or developer mistakes.  With the proliferation of open source software in recent years, modern applications often consist of third-party dependencies. There are advantages to utilizing OSS; however, if not carefully inspected, it can introduce vulnerabilities and other issues. Implementing dependency checking tools can analyze dependencies in your code to identify issues such as vulnerabilities and the use of non-compliant licenses. Static application security testing (SAST) should be integrated into the pipeline to automatically scan every code change as it is committed. Initiating workflows from scan results can facilitate immediate feedback leading to quicker remediation. Dynamic application security testing (DAST) is a good way to evaluate your running applications for vulnerabilities that may be missed by SAST tools.  Build Secure Immutable Infrastructure in the Cloud The adoption of DevOps and cloud-hosted services facilitated the practice of Infrastructure-as-Code (IaC) in which enterprise services could be architected, committed as code, and deployed in an automated fashion. While this has allowed IT teams to quickly deploy enterprise applications and services, this has introduced challenges for security teams to identify issues in IaC before these applications and services are deployed to production. Static security scanning tools can analyze infrastructure tools such as Terraform and Cloudformation for any misconfigurations and other security issues early in the development lifecycle and provide feedback in an automated fashion.  Implementing practices such as configuration management and baseline configurations can help facilitate immutable infrastructure that is deployed in a consistent manner based on a defined set of requirements and continuously monitor infrastructure for inadvertent or unauthorized changes. Utilize Secrets Management As we discussed earlier in this post, exposed secrets can be an organizational nightmare. However, ensuring that sensitive information is protected is no small task either. This is where secrets management comes into play. Every organization should have a set of tools and processes to protect passwords, API keys, SSH keys, and other secrets. Besides providing a secure method for storing secrets, secrets management can also facilitate other best practices such as auditing, role-based access control, and lifecycle management. Final Thoughts Communications and collaboration amongst your team members should be part of all the tips in this post. Your new or renewed focus on DevSecOps pipeline security should also become part of any internal processes that you have in place to govern tool security and maintenance. ### DevOps to DevSecOps Cultural Transformation: The Next Step Part of any DevOps to DevSecOps transformation is cultural transformation. While you’ve probably made steps to strengthen your development and operations cultures to embrace the concepts and tools that power DevOps, there’s going to be some more work to do to transform your burgeoning corporate DevOps culture to embrace DevSecOps fully. DevSecOps is a growing movement in the commercial and public sectors to incorporate security into the software delivery process further.  Monitoring and analytics in the continuous integration/continuous delivery (CI/CD) pipeline expose software risks and vulnerabilities to DevSecOps teams for their follow-up actions and remediation. Here are some next steps to grow your DevOps culture to DevSecOps: 1. Position DevSecOps as the Next Step DevOps is a journey for many in the IT industry. It takes time and investments in staffing, tools, processes, and security to move from a traditional waterfall-driven software development life cycle (SDLC) to DevOps. There are two scenarios for organizations who want to move to DevSecOps: Moving straight from a waterfall SDLC, skipping traditional DevOps, and moving right to DevSecOps Moving from DevOps to DevSecOps through upgrading the CI/CD toolchain with a range of security automation tools, shifting security left, and bringing security team members into the development cycle Either DevSecOps adoption scenario needs outreach and training support to communicate expectations, next steps, and changes to your developers, sysadmins, and security team. Work closely with your teams during your move to DevSecOps to answer their questions, take their feedback on progress and changes, while giving the transformation project a chance to pivot based on lessons learned along the way. 2. Move from Gated Processes to Shared Responsibility DevOps depends on gates between each stage. Managers, stakeholders, and even entire development organizations can justify these gates because they provide a sense of security for troubleshooting, halting delivery, or stakeholder inquiries into the project.  DevSecOps substitutes mutual accountability for those gates. Mutual accountability comes about through process changes and improving collaboration between your development, security, and operations teams through cross-functional teams supported by the proper technology tools and executive sponsorship. 3. Communicate about Security outside your IT Department Such a new and enduring focus on security during the application delivery life cycle means you have to keep communications and outreach channels open with your stakeholders and user community. You need to create strong internal communications about how DevSecOps is changing how your teams deliver software, and its benefits they can expect from this transformation. You need to extend your security education to other departments, such as your sales and marketing teams. For example, moving to a DevSecOps model gives your marketing team the reason to create security-focused messaging and collateral that your sales team can use to reach prospective and existing customers who’re security conscious. 4. Make Security no longer “Us vs. Them” Gone are the days the cybersecurity team was the “Team of No,” and security testing took place right before product launch. Today consumers and enterprise customers want rapid updates and app stores. It’s time to dismantle the vestiges of “us vs. them” and make security a priority in your application development from project kickoff. Do everything you can process and tool-wise to move away from the stress of incident and issue-driven security responses, leading to fixing security issues at the end of your development life cycle. Building collaboration between your DevOps and security teams starts with: Building security into each stage of your CI/CD workflow Integrating mandatory security checks into your code reviews Integrating automated container security scanning into your container supply chain Beyond these incremental steps to build collaboration between your teams, it helps managers and team leads to set the example for collaboration. Organizational culture and internal politics can breed rivalries that can interfere with collaboration, if not the entire DevOps cycle. 5. Target Developers’ Baggage Developers bring the best practices and bad habits of every previous employer and past contract with them. There are plenty of developers who can sort this out from their work, but some find challenges in sorting such things out for themselves.  DevOps and DevSecOps definitions and implementations vary. Not to mention, COVID-19 is also raising stress levels at home and work for people causing work to slip. Some common ways to target developer baggage include: Focusing on developer experience (DX) throughout your development tool and CI/CD toolchain selection Communicate about your processes in terms of frameworks that capture approved tools, processes, and expectations for your developers, QA, and system administrators during employee onboarding Final Thoughts Culture can be the most essential but often misunderstood portion of DevOps transformation. I’m fond of the old saying that goes, “you can’t buy DevOps.” The same goes for DevSecOps. The security and compliance implications of DevSecOps make it, so you need to go further with your security outreach and communications to help push cultural transformation forward. ### Package Blocklists Are Not Foolproof As organizations progress in their software container adoption journeys, they realize that they need image scanning beyond simple vulnerability checks.  As security teams develop more sophisticated image policies, many implement package blocklists to keep unnecessary code such as curl and sshd out of their images. Curl can be a handy tool in development and debugging, but attackers can also use it to download malicious code into an otherwise trusted container.  There are two primary scenarios security teams want to protect against: An attacker compromises a container that has curl in it and then uses curl to bring compromised code into the environment A developer uses curl to download unapproved code, configurations, or binaries from unvetted sources (e.g. random GitHub repositories) during the build process (this could be malicious or inadvertent) For the first scenario, a simple blocklisting of the curl package will cover most cases.  If we can produce an image that we know curl is not installed on, we’ve effectively mitigated an entire class of potential attacks. Note: The policy rules, Dockerfiles, and other files used in this article are available from GitHub. Blocklisting curl Blocklisting packages is a pretty straightforward process.  We just need a simple policy rule: We’ll build an example image with this Dockerfile to test the rule: # example dockerfile that will use curl to download source, anchore # will stop this with a simple package blocklist on curl FROM alpine:latest   WORKDIR / RUN apk update && apk add --no-cache build-base curl # download source and build RUN curl -o - https://codeload.github.com/kevinboone/solunar_cmdline/zip/master | unzip -d / - RUN cd /solunar_cmdline-master && make clean && make && cp solunar /bin/solunar HEALTHCHECK --timeout=10s CMD /bin/date || exit 1 USER 65534:65534 CMD ["-c", "London"] ENTRYPOINT ["/bin/solunar"] OK, let’s build, push, and scan the image. pvn@gyarados ~/curl_example# export ANCHORE_CLI_USER=admin pvn@gyarados ~/curl_example# export ANCHORE_CLI_PASS=foobar pvn@gyarados ~/curl_example# export ANCHORE_CLI_URL=http://anchore.example.com:8228/v1 pvn@gyarados ~/curl_example# docker build -t pvnovarese/curl_example:simple . Sending build context to Docker daemon  112.1kB Step 1/12 : FROM alpine:latest  ---> a24bb4013296 [...] Successfully built 799a36c3cb2d Successfully tagged pvnovarese/curl_example:simple pvn@gyarados ~/curl_example# docker push pvnovarese/curl_example:simple The push refers to repository [docker.io/pvnovarese/curl_example] [...] pvn@gyarados ~/curl_example# anchore-cli image add --dockerfile ./Dockerfile pvnovarese/curl_example:simple [...] As expected, the package blocklist caught the installed curl package and the image fails the policy evaluation. Multi-stage Builds Add Complexity We’ve increased our protection against developers using curl to bring unknown code from random places on the internet into our environment. But what if the developer uses a multi-stage build?  If you’re not familiar with multi-stage builds, they are frequently used to create more compact docker images.  The most common pattern is that a first stage is used to build the software, then the binaries and other artifacts produced are transferred to the final stage, leaving behind the source code, build tools, and other bits that are vital to building the code but aren’t needed to run the code.  The build-stage container then is discarded and only the final lean container with the bare necessities moves on. Since those intermediate-stage containers are ephemeral, Anchore Enterprise doesn't have access to them and can only scan the final image.  Because of this, many things that happen during the actual build process can avoid detection.  A developer can install curl in the intermediate build-stage container, pull down unvetted code, and then copy a compromised binary to a final stage image without installing curl in that final image. ### example multistage build - in this case, a simple package blocklist ### will NOT stop this, since curl only is installed in the intermediate ### "builder" image and doesn't exist in the final image.  To stop this, ### we can look for curl in the RUN commands in the Dockerfile. ### Stage 1 FROM alpine:latest as builder WORKDIR /solunar_cmdline-master RUN apk update && apk add --no-cache build-base curl ### Clone private repository RUN curl -o - https://codeload.github.com/kevinboone/solunar_cmdline/zip/master | unzip -d / - RUN make clean && make ### Stage 2 FROM alpine:latest HEALTHCHECK NONE WORKDIR /usr/local/bin COPY --from=builder /solunar_cmdline-master/solunar /usr/local/bin/solunar # if you want to use a particular localtime, # uncomment this and set zoneinfo appropriately # RUN apk add --no-cache tzdata bash && cp /usr/share/zoneinfo/America/Chicago /etc/localtime USER 65534:65534 CMD ["-c", "London"] ENTRYPOINT ["/usr/local/bin/solunar"] The final image output from this example is a completely standard alpine:latest image with a single binary copied in. Our simple package blocklist won’t catch this: the multistage image passes the policy evaluation even though curl was installed and used as part of the build process. Only the final image is checked against the package blocklist. To increase our protection, we should check for RUN instructions in the Dockerfile that call curl in addition to our package blocklist rule. We’ve added two rules.  The first will fail the image on any RUN instruction in the Dockerfile that includes “curl”, and the second will fail the image if no Dockerfile is submitted with the image.  We then re-evaluate with this new policy bundle (note that we don’t need to re-scan, we’re just applying the new policy to the same image) and get the desired failure: Note: No changes were made to the Dockerfile from the previous run, and we did not rebuild the image - we only changed the policy rules. This time, our policy evaluation caught both the installation of curl into the intermediate container and the actual execution of curl to download the unauthorized code.  Either of these alone is enough to cause the policy evaluation to fail as desired. Also, in this case, our package blocklist was not triggered, since the final image still doesn’t contain the curl package. Conclusion Package blocklists can be quite useful. In most cases, whether or not particular packages are present in an image is much less of a concern than how those images are constructed and used, so looking just at the final image isn’t enough.  Anchore Enterprise’s deep image introspection includes analysis of the Dockerfile used to create the image, which allows the policy engine to enforce more best practices than simple image inspection alone. Policies, Dockerfiles, and Jenkinsfiles used for this article can be found in my GitHub. ### The Journey from DevOps to DevSecOps Digital transformation, improved security, and compliance are the key drivers pushing corporations and government agencies to adopt DevSecOps. Some organizations will experience a journey from DevOps to DevSecOps, depending on their DevOps maturity.  Defining DevOps and DevSecOps for your Organization There’s a growing list of definitions for DevOps and DevSecOps out there. Some come from vendor marketing, and a few of the definitions come from new perspectives about bringing together development, security, and operations teams. For the purposes of this blog post, DevOps combines cultural philosophies, practices, and tools that increase an organization's ability to deliver software and services at high velocity. DevOps enables teams to develop and improve products faster than organizations using traditional software development and infrastructure management processes. DevSecOps — by definition — brings cybersecurity and security operations tools and strategies such as container vulnerability scanning automation into your organization’s existing or new DevOps toolchain. In the next few years, it’s a safe bet that the definition of DevSecOps will subsume the DevOps definition as corporations and public sector agencies continue to increase their security focus across the software delivery life cycle. Moving from DevOps to DevSecOps: Step by Step When you move from DevOps to DevSecOps, it’s another step in your DevOps journey for many reasons. Your development and operations teams are taking another step left and bringing along their colleagues in security for the trip. Start with a Small Proof of Concept Project Starting with a small proof-of-concept project is always the best way to help your teams prepare for any technology or process changes. Choosing a small pilot project for DevSecOps lets you test adjustments and additions to your tools and processes. Your small pilot project could take one of the following forms: A solution architect or small project team building out your current or creating a new DevOps pipeline with additional security tools such as Anchore Toolbox or, even better, Anchore Enterprise at each stage to support automated scanning of your containers. This pilot project is ideal if you must show additional security features to your management and project stakeholders, such as your customers. A small project team is running an application development project through your sparkling new DevSecOps toolchain. An example of such a small project is an update to a small not-business critical project that your organization uses internally. Pilot projects such as these require little startup investment if you use open source tools. However, suppose your organization has to build and maintain applications that must meet compliance. In that case, you’ll probably have to consider using open source security tools that provide you with the reporting capabilities that your auditors require. Go Agile to Deliver Code in Iterative Releases Delivering your software code using agile methodologies in small scope iterative releases helps your DevSecOps teams check for code and container vulnerabilities through quality assurance gates embedded across your development life cycle. Implement Automated Testing across your Toolchain Automation is integral across a DevSecOps delivery process, especially with testing. Test automation shouldn’t replace human testers. Running automated testing and dependency checks enable your testers to focus on the most critical issues preventing you from achieving compliance. Invest in Upskilling your Developers and Testers Part of shifting security left with DevSecOps is training your developers and testers in security principles. These days that means online training from a vendor or other training providers. It also means letting your developers attend industry conferences. With national and regional technology and security conferences online, this is easy to do. Another way to invest in upskilling is to support your developers pursuing DevSecOps, DevOps, and cloud-focused certifications. For example, there’s a Certified DevSecOps Professional Certification from Practical DevSecOps and a DevSecOps Foundation Certification from the DevOps Institute. Involve your Developers in Security Discussions Just as you bring your development and operations teams out of their silos, you need to get your developers into the security discussion. A move to DevSecOps shifts security left, so it sits throughout your software development life cycle versus being the last step before product release. Everybody on the project team is accountable for security in a DevSecOps environment. Your organization can only reach this accountability level when you empower your teams with expertise and resources to respond to and mitigate security threats within the toolchain and before the threats hit production. Treat Compliance like another Team Member Failing compliance audits means an expensive, time-consuming, and sometimes litigious process to return systems to compliance. DevSecOps gives you the methodologies, framework, and tools to help your organization’s systems achieve continuous compliance at every stage of your delivery life cycle. Adopt Regular Security Practices across your Teams DevSecOps practices mean using regular scans, code reviews, and penetration tests to ensure your applications and cloud infrastructure are secure against insider and external threats. Final Thoughts Taking the journey from DevOps to DevSecOps is the ultimate story of shifting security left for commercial and public sector enterprises. Some organizations will seek DevSecOps first, leaping a traditional waterfall software development life cycle. Others will mature and strengthen their DevOps processes to become more security-focused during their delivery life cycle. ### Using Grype to Identify GitHub Action Vulnerabilities About a month ago, GitHub announced the presence of a moderate security vulnerability in the GitHub Actions runner that can allow environment variables and path injection in workflows that log untrusted data to STDOUT. You can read the disclosure here for more details. Given at Anchore, we build and maintain a GitHub Action of our own; this particular announcement was one we were made aware of. While I’m sure many folks have taken the time to update their GitHub Actions accordingly, I thought this would be a good opportunity to take a closer look at setting up a CI workflow as if I were developing my own GitHub Action, and step through the options in Anchore for identifying this particular vulnerability. To start with, I created an example repository in GitHub, demonstrating a very basic hello-world GitHub Action and workflow configuration. The configuration below scans the current directory of the project I am working on with the Anchore Container Scan Action. Under the hood, the tool scanning this directory is called Grype, an open-source project we built here at Anchore. name: Scan current directory CI on: [push] jobs:  anchore_job:    runs-on: ubuntu-latest    name: Anchore scan directory    steps:    - name: Checkout      uses: actions/checkout@v2    - name: Scan current project      id: scan      uses: anchore/scan-action@v2      with:        path: "./"        fail-build: true        acs-report-enable: true    - name: upload Anchore scan SARIF report      uses: github/codeql-action/upload-sarif@v1      with:         sarif_file: ${{ steps.scan.outputs.sarif }} On push, I can navigate to the Actions tab and find the latest build.  The build output above shows a build failure due to vulnerabilities identified in the project of severity level medium or higher. To find out more information about these specific issues, I can jump over to the Security tab. Once here, we can click on the vulnerability linked to the disclosure discussed above.  We can see the GHSA, and make the necessary updates to the @actions/core dependency we are using. While this is just a basic example, it paints a clear picture that adding security scans to CI workflows doesn’t have to be complicated. With the proper tools, it becomes quite simple to obtain actionable information about the software you’re building.  If we wanted to take this a step further “left” in the software development lifecycle (SDLC), I could install Grype for Visual Studio Code, an extension for discovering project vulnerabilities while working locally in VS Code.  Here we can see for the same hello-world GitHub Action, I can get visibility into vulnerabilities as I’m working locally on my workstation and can resolve these issues before I end up pushing to my source code repository. I’ve also just added two places for security checks in the development lifecycle in just a few minutes, which means I am spreading out my checks, providing more places to catch myself should I create issues.  Just for good measure, once I update my dependencies and push to GitHub, my CI job is now successfully passing the Anchore scan, and the security issues that were opened have now been closed and resolved.  While this was just a simple demonstration of what is possible, at Anchore, we generally just think of these types of checks as good hygiene, and the more spots in the development workflow we can provide developers with security information about the code they’re writing, the better positioned they’ll be to promote shared security principles across their organization and build high-quality, secure software. ### Free Download: Inside the Anchore Technology Suite: Open Source to Enterprise Open source is foundational to much of what we do here at Anchore. It’s at the core of Anchore Enterprise, our complete container security workflow solution for enterprise DevSecOps. Anchore Toolbox is our collection of lightweight, single-purpose open source tools for the analysis and scanning of software projects. Each tool has its place in the DevSecOps journey, depending on your organization’s requirements and eventual goals. Our free guide explains the following: The role of containers in DevSecOps transformation Features of Anchore Enterprise and Anchore Toolbox Ideal use cases for Anchore Enterprise Ideal use cases for Anchore Toolbox Choosing the right Anchore tool for your requirements To learn more about how Anchore Toolbox and Anchore Enterprise can fit into your DevSecOps journey, please download our free guide. ### Configuring Anchore Enterprise on AWS Elastic Kubernetes Services (EKS) In previous posts, we’ve demonstrated how to create a Kubernetes cluster on AWS Elastic Kubernetes Service (EKS) and how to deploy Anchore Enterprise in your EKS cluster. The focus of this post is to demonstrate how to configure a more production-like deployment of Anchore with integrations such as SSL support, RDS database backend and S3 archival. Prerequisites: A running EKS cluster (check out our blog post on how to deploy an EKS cluster in AWS) ALB Ingress Controller (see Kubernetes Ingress with AWS ALB Ingress Controller for instructions on configuring the necessary resources required to deploy the ALB Ingress Controller) Configuring the Ingress/Application Load Balancer Anchore’s Helm Chart provides a deployment template for configuring an ingress resource for your Kubernetes deployment. EKS supports the use of an AWS Elastic Load Balancing Application Load Balancer (ALB) ingress controller, an NGINX ingress controller or a combination of both. For the purposes of this demonstration, we will focus on deploying the ALB ingress controller using the Helm chart. To enable ingress deployment in your EKS cluster, simply add the following ingress configuration to your anchore_values.yaml: Note: If you haven’t already, make sure to create the necessary RBAC roles, role bindings and service deployment required by the AWS ALB Ingress controller. See ALB Ingress Controller for more details. ingress:  enabled: true  labels: {}  apiPath: /v1/*   uiPath: /*  annotations:    kubernetes.io/ingress.class: alb     alb.ingress.kubernetes.io/scheme: internet-facing Specify Custom Security Groups/Subnets By default, the ingress controller will deploy a public-facing application load balancer and create a new security group allowing access to your deployment from anywhere over the internet. To prevent this, we can update the ingress annotations to include additional information such as a custom security group resource. This will enable you to use an existing security group within the cluster VPC with your defined set of rules to access the attached resources. To specify a security group, simply add the following to your ingress annotations and update the value with your custom security group id: alb.ingress.kubernetes.io/security-groups: "sg-012345abcdef" We can also specify the subnets we want the load balancer to be associated with upon deployment. This may be useful if we want to attach our load balancer to the cluster’s public subnets and have it route traffic to nodes attached to the cluster’s private subnets. To manually specify which subnets the load balancer should be associated with upon deployment, update your annotations with the following value: alb.ingress.kubernetes.io/subnets: "subnet-1234567890abcde, subnet-0987654321edcba" To test the configuration, apply the Helm chart: helm install anchore/anchore-engine -f anchore_values.yaml Next, describe your ingress controller configuration by running kubectl describe ingress You should see the DNS name of your load balancer next to the address field and under the ingress rules, a list of annotations including the specified security groups and subnets. Note: If the load balancer did not deploy successfully, review the following AWS documentation to ensure the ingress controller is properly configured. Configure SSL/TLS for the Ingress You can also configure an HTTPS listener for your ingress to secure connections to your deployment. First, create an SSL certificate using AWS Certificate Manager and specify a domain name to associate with your certificate. Note the ARN of your new certificate and save it for the next step. Next, update the ingress annotations in your anchore_values.yaml with the following parameter and provide the certificate ARN as the value. alb.ingress.kubernetes.io/certificate-arn: "arn:aws:acm::" Additionally, we can configure the Enterprise UI to listen on HTTPS or a different port by including the following annotations to the ingress with the desired port configuration. See the following example: alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS": 443}, {"HTTP": 80}]' alb.ingress.kubernetes.io/actions.ssl-redirect: '{"Type": "redirect", "RedirectConfig": { "Protocol": "HTTPS", "Port": "443", "StatusCode": "HTTP_301"}}' Next, install the deployment if this is a new deployment: helm install anchore/anchore-engine -f anchore_values.yaml Or upgrade your existing deployment helm upgrade anchore/anchore-engine -f anchore_values.yaml To confirm the updates were applied, run kubectl describe ingress and verify your certificate ARN, as well as the updated port configurations, appear in your annotations. Analyze Archive Storage Using AWS S3 AWS’s S3 Object Storage allows users to store and retrieve data from anywhere in the world. It can be particularly useful as an archive system. For more information on S3, please see the documentation from Amazon. Both Anchore Engine and Anchore Enterprise can be configured to use S3 as an archiving solution. Some form of archiving is highly recommended for a production-ready environment. In order to set this up on your EKS, you must first ensure that your use case is in line with Anchore’s archiving rules. Anchore stores image analysis results in two locations. The first is the working set which is where an image is stored initially after its analysis is completed. In the working state, images are available for queries and policy evaluation. The second location is the archive set. Analysis data stored in this location is not actively ready for policy evaluation or queries but is less resource-intensive and information here can always be loaded into the working set for evaluation and queries. More information about Anchore and archiving can be found here. To enable S3 archival, copy the following to the catalog section of your anchore_values.yaml: anchoreCatalog:   replicaCount: 1  archive:    compression:      enabled: true      min_size_kbytes: 100    storage_driver:      name: s3      config:         bucket: ""        # A prefix for keys in the bucket if desired (optional)        prefix: ""        # Create the bucket if it doesn't already exist        create_bucket: false        # AWS region to connect to if 'url' not specified, if both are set, then 'url' has precedent         region: us-west-2 By default, Anchore will attempt to access an existing bucket specified under the config > bucket value. If you do not have an S3 bucket created, then you can set create_bucket to false and allow the Helm chart to create the bucket for you. If you already created one, put its name in the bucket parameter. Since S3 isn’t region-specific, you need to specify the region that your EKS cluster resides in with the region parameter. Note: Whether you specify an existing bucket resource or set create_bucket to true, the cluster nodes require permissions to perform the necessary API calls to the S3 service. There are two ways to configure authentication: Specify AWS Access and Secret Keys To specify the access and secret keys tied to a role with permissions to your bucket resource, update the storage driver configuration in your anchore_values.yaml with the following parameters and appropriate values: # For Auth can provide access/secret keys or use 'iamauto' which will use an instance profile or any credentials found in normal aws search paths/metadata service        access_key: XXXX         secret_key: YYYY Use Permissions Attached to the Node Instance Profile The second method for configuring access to the bucket is to leverage the instance profile of your cluster nodes. This eliminates the need to create an IAM role to access the bucket and manage the access and secret keys for the role separately. To configure the catalog service to leverage the IAM role attached to the underlying instance, update the storage driver configuration in your anchore_values.yaml with the following and ensure iamauto is set true: # For Auth can provide access/secret keys or use 'iamauto' which will use an instance profile or any credentials found in normal aws search paths/metadata service         iamauto: true You must also ensure that the role associated with your cluster nodes has GetObject, PutObject and DeleteObject permissions to your S3 bucket (see a sample policy below). {  "Version": "2012-10-17",  "Statement": [    {      "Effect": "Allow",       "Action": ["s3:ListBucket"],      "Resource": ["arn:aws:s3:::test"]    },    {      "Effect": "Allow",      "Action": [        "s3:PutObject",        "s3:GetObject",        "s3:DeleteObject"      ],      "Resource": ["arn:aws:s3:::test/*"]    }  ] } Once all of these steps are completed, deploy the Helm chart by running: helm install stable/anchore-engine -f anchore_values.yaml Or the following, if upgrading an existing deployment: helm upgrade stable/anchore-engine -f anchore_values.yaml Note: If your cluster nodes reside in private subnets, they must have outbound connectivity in order to access your S3 bucket. For cluster deployments where nodes are hosted in private subnets, a NAT gateway can be used to route traffic from your cluster nodes outbound through the public subnets. More information about creating and configuring NAT gateways can be found here. Another option is to configure a VPC gateway allowing your nodes to access the S3 service without having to route traffic over the internet. More information regarding VPC endpoints and VPC gateways can be found here. Using Amazon RDS as an External Database By default, Anchore will deploy a database service within the cluster for persistent storage using a standard PostgreSQL Helm chart. For production deployments, it is recommended to use an external database service that provides more resiliency and supports features such as automated backups. For EKS deployments, we can offload Anchore’s database tier to PostgreSQL on Amazon RDS. Note: Your RDS instance must be accessible to the nodes in your cluster in order for Anchore to access the database. To enable connectivity, the RDS instance should be deployed in the same VPC/subnets as your cluster and at least one of the security groups attached to your cluster nodes must allow connections to the database instance. For more information, read about configuring access to a database instance in a VPC. To configure the use of an external database, update your anchore_values.yaml with the following section and ensure enabled is set to “false”. postgresql:   enabled: false Under the postgres section, add the following parameters and update them with the appropriate values from your RDS instance. postgresUser:   postgresPassword:   postgresDatabase:    externalEndpoint: With the section configured, your database values should now look something like this: postgresql:  enabled: false  postgresUser: anchoreengine  postgresPassword: anchore-postgres,123  postgresDatabase: postgres   externalEndpoint: abcdef12345.jihgfedcba.us-east-1.rds.amazonaws.com To bring up your deployment run: helm install  stable/anchore-engine -f anchore_values.yaml Finally, run kubectl get pods to confirm the services are healthy and the local postgresql pod isn’t deployed in your cluster. Note: The above steps can also be applied to deploy the feeds postgresql database on Amazon RDS by updating the anchore-feeds-db section instead of the postgresql section of the chart. Encrypting Database Connections Using SSL Certificates with Amazon RDS Encrypting RDS connections is a best practice to ensure the security and integrity of your Anchore deployment that uses external database connections. Enabling SSL on RDS AWS provides the necessary certificates to enable SSL with your rds deployment. Download rds-ca-2019-root.pem from here. In order to require SSL connections on an RDS PostgreSQL instance, the rds.force_ssl parameter needs to be set to 1 (on). By setting this to 1, the PostgreSQL instance will set the SSL parameter to 1 (on) as well as modify the database’s pg_hba.conf file to support SSL. See more information about RDS PostgreSQL ssl configuration. Configuring Anchore to take advantage of SSL is done through the Helm chart. Under the anchoreGlobal section in the chart, enter the certificate filename next to certStoreSecretName that we downloaded from AWS in the previous section. (see example below) anchoreGlobal:    certStoreSecretName: rds-ca-2019-root.pem Under the dbConfig section, set SSL to true. Set sslRootCertName to the same value as certStoreSecretName. Make sure to update the postgresql and anchore-feeds-db sections to disable the local container deployment of the services and specify the RDS database values (see the previous section on configuring RDS to work with Anchore for further details). (If running Enterprise, the dbConfig section under anchoreEnterpriseFeeds should also be updated to include the cert name under sslRootCertName) dbConfig:    timeout: 120    ssl: true    sslMode: verify-full    sslRootCertName: rds-ca-2019-root.pem    connectionPoolSize: 30     connectionPoolMaxOverflow: 100 Once these settings have been configured, run a Helm upgrade to apply the changes to your cluster. Conclusion The Anchore Helm chart provided on GitHub allows users to quickly get a deployment running on their cluster, but it is not necessarily a production-ready environment. The sections above showed how to configure the ingress/application load balancer, configuring HTTPS, archiving image analysis data to an AWS S3 bucket, and setting up an external RDS instance and requiring SSL connections to it. All of these steps will ensure that your Anchore deployment is production-ready and prepared for anything you throw at it.   ### Enforcing the DoD Container Image and Deployment Guide with Anchore Federal The latest version of the DoD Container Image and Deployment Guide details technical and security requirements for container image creation and deployment within a DoD production environment. Sections 2 and 3 of the guide include security practices that teams must follow to limit the footprint of security flaws during the container image build process. These sections also discuss best security practices and correlate them to the corresponding security control family with Risk Management Framework (RMF) commonly used by cybersecurity teams across DoD. Anchore Federal is a container scanning solution used to validate the DoD compliance and security standards, such as continuous authorization to operate (cATO), across images, as explained in the DoD Container Hardening Process Guide. Anchore’s policy first approach places policy where it belongs-- at the forefront of the development lifecycle to assess compliance and security issues in a shift left approach. Scanning policies within Anchore are fully customizable based on specific mission needs, providing more in-depth insight into compliance irregularities that may exist within a container image. This level of granularity is achieved through specific security gates and triggers that generate automated alerts. This allows teams to validate that the best practices discussed in Section 2 of the Container Image Deployment Guide enable best practices to be enforced as your developers build.   Anchore Federal uses a specific DoD Scanning Policy that enforces a wide array of gates and triggers that provide insight into the DoD Container Image and Deployment Guide’s security practices. For example, you can configure the Dockerfile gate and its corresponding triggers to monitor for security issues such as privileged access. You can also configure the Dockerfile gate to expose unauthorized ports and validate images built from approved base images and check for the unauthorized disclosure of secrets/sensitive files, amongst others. Anchor Federal’s DoD scanning policy is already enabled to validate the detailed list of best practices in Section 2 of the Container Image and Deployment Guide.  Looking to learn more about how to achieve container hardening at DoD levels of security? 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. Intro to DoD Software Factory Outline for Getting Up to Speed on the DoD Software Factory How Anchore Secures Software Factories Next Steps Anchore Federal is a battle-tested solution that has been deployed to secure DoD’s most critical workloads. Anchore Federal exists to provide cleared professional services and software to DoD mission partners and the US Intelligence Community in building their DevSecOps environments. Learn more about how Anchore Federal supports DoD missions. ### Anchore Federal Now Part of the DoD Container Hardening Process The latest version of the Department of Defense (DoD) Container Hardening Process Guide includes Anchore Federal as an approved container scanning tool. This hardening process is critical because it allows for a measurement of risk that an Authorizing Official (AO) assesses while rendering their decision to authorize the container. DoD programs can use this guide as a source of truth to know they are following DISA container security best practices. Currently, the DoD is in the early stages of container adoption and security. As containers become more integral for secure software applications, the focus shifts to making sure, DoD systems are being built using DoD compliant container images and mitigating risks associated with using container images. For example, the United States Air Force Platform One initiative includes Iron Bank, a repository of DoD compliant container images available for reuse across authorized DoD program offices and weapon systems. Here are some more details about how Anchore factors into the DoD Container Hardening Process: Container Scanning Guidelines The DISA container hardening SRG relies heavily on best practices already utilized at Platform One. Anchore Federal services work alongside the US Air Force at Platform One to build, harden, and scan container images from vendors in Repo1 as the Platform One team adds secure images to Iron Bank. Automation of container scanning of each build within a DevSecOps pipeline is the primary benefit of the advised approach discussed in Section 2.3 of the SRG. Anchore encourages our customers to read the Scanning Process section of the DoD Container Hardening Process Guide to learn more about the container scanning process. Serving as a mandatory check as part of a container scanning process is an ideal use case for Anchore Federal in the DoD and public sector agencies. Our application programming interface (API) makes it very easy to integrate with DevSecOps environments and validate your builds for security and DoD compliance by automating Anchore scanning inside your pipeline. Anchore scanning against the DoD compliance standards involves assessing the image by checking for Common Vulnerabilities and Exposures (CVEs), embedded malware, and other security requirements found in Appendix B: DoD hardened Containers Cybersecurity Requirements.  An Anchore scan report containing the output is fed back to the developer and forwarded to the project’s security stakeholders to enable a Continuous Authority to Operate (c-ATO) workflow, which satisfies the requirements for the Findings Mitigation Reporting step of the process recommended by the Container Hardening Guide. The report output also serves as a source of truth for approvers accepting the risks associated with each image. Scanning Reports & Image Approval  After personnel review the Anchore compliance reports and complete the mitigation reporting, they report these findings to the DevSecOps approver, who determines if the results warrant approving the container based on the level of risk presented within each image.  Upon approval, the images move to the approved registry in Iron Bank accessible to developers across DoD programs. Next Step Anchore Federal is a battle-tested solution that has been deployed to secure DoD’s most critical workloads. Anchore Federal exists to provide cleared professional services and software to DoD mission partners and the US Intelligence Community in building their DevSecOps environments. Learn more about how Anchore Federal supports DoD missions. ### AI and the Future of DevSecOps Many companies have been investing heavily in Artificial Intelligence (AI) over the past few years. It has enabled cars to drive themselves, doctors to pick up on various diseases earlier, and even create works of art. Such a powerful technology can impact nearly every aspect of human life. We want to explore what that looks like in the realm of application security and DevSecOps. Addressing DevSecOps Challenges With AI The importance of maintaining compliance within any organization is crucial. Health care providers have to remain within the Health Insurance Portability and Accountability Act (HIPAA) requirements. Financial companies have similar requirements. Other companies have other requirements regarding protecting user data. Many times these regulations change. For example, HIPAA has had hundreds of minor updates and six major updates since its creation in 1996. Many times these requirements come in faster than humans can keep up with. AI can make sure that these requirements aren’t missed and implemented properly in any delivered code. Additionally, AI is taking the feasibility of application security from many companies from a “sometimes” thing to an “always” thing. It speeds up that testing process from a laborious manual process to something that can be run in a pipeline. AI functions like a human brain. With neural networks and backpropagation, It mimics how the brain changes to adapt to new situations. In this way, it can be leveraged to adjust to changes in code and infrastructure automatically.   The Future of “DevSecAIOps” Another critical aspect of DevSecOps that is sometimes difficult to maintain is the speed of code delivery. Securing pipelines will always add more time due to added complexity and the need for human interaction within that pipeline. An example of this is a developer needed to change code to remove specific vulnerabilities found during a security scan. This is an aspect of DevSecOps that can benefit from the introduction of Artificial Intelligence. AI can change its own code through neural networks and backpropagation, so, logically, it could be used to make these changes to vulnerable code to get that code through the pipeline rapidly.  Additionally, AI can bring the expertise of the few cybersecurity experts to many companies and organizations. Though artificial intelligence has the ability to accomplish tasks that humans usually do, it is a data and labor-intensive process to train the models to function to the standard that humans do. But once they are functioning to that level, they can be utilized by many people and, in the case of DevSecOps, can be used to assist companies who cannot have DevSecOps engineers working on their pipelines. Conclusion The usefulness of artificial intelligence far outweighs the buzz of it in society. It has allowed many companies to iterate their technologies at speeds that simply weren’t possible before. With these rapid advancements, however, the importance of maintaining that same cadence in the realms of application security and DevSecOps cannot be overstated. By taking advantage of AI like other technologies are, DevSecOps can make sure that these rapidly developed technologies are powered by secure and stable code when they reach the user. ### Understanding your Software Supply Chain Risk Many organizations have seen increased value from in house software development by adopting open source technology and containers to quickly build and package software for the cloud. Usually branded as Digital Transformation, this shift comes with trade-offs not often highlighted by vendors and boutique consulting firms selling the solutions. The reality is moving fast, can break things and without proper constraints, you can expose your organization to significant security, legal and reputational risks. These are not entirely new revelations. Security experts have long known that supply chains are an incredibly valuable attack surface to hackers. Software supply chain attacks have been used to exfiltrate credit card data, (alleged) nation-state surveillance, and to cash out ATMs. The widespread adoption of open source projects and the use of containers and registries have given hackers new opportunities for harm. Supply Chain Exposure Goes Beyond Security These risks are not limited 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 Trump’s support of ICE and pulled his package from NPM. Or unbeknownst to your legal team, you could be distributing software without proper license, as is the case with any container that uses Alpine Linux as the base image. Fortunately, understanding these risks is not unknowable. A number of open source tools exist for scanning for CVEs, and recent projects are helping to standardize Software Bill of Materials to help make it easy to check your containers for license and security risks. Knowing is of course only half the battle - securing your supply chain is the end goal. This is where the unique capabilities of Anchore Enterprise can be applied. Creating, managing, and enforcing policy allows you to enforce the constraints that are most applicable to your organization, and allow teams to still move quickly by building on top of open source and container tooling. Smart Contracts for your Supply Chain Most sizable organizations have already established best practices around their software supply chain. Network security, tool mandates, and release practices all help to decrease your organization’s risk - but they all are fallible. Where humans are involved, they are sure to choose convenience over security, especially when urgency is involved. This is the idea behind the Open Policy Agent (OPA) Kubernetes project which can prevent certain containers images from being scheduled, and even integrate with service mesh to route network traffic away from suspicious containers. At Anchore, we believe that catching security issues at runtime is costly and focus on controlling your path to production through an independent policy engine. By defining policy, and leveraging our toolbox in your pipelines you can enforce the appropriate policy for your organization, team, and environment. This powerful capability gives you the ability to allow development teams to use tools that are convenient to them during the creative process but enforce a more strict packaging process. For example, you might want to ensure that all production containers are pulled from a privately managed registry. This gives you greater control and less exposure, but how can you enforce this? Below is an example policy rule you can apply using Anchore Enterprise to prevent container images from being pulled from Docker Hub. "denylisted_images": [   {     "id": "9b6e8f3b-3f59-44cb-83c7-378b9ba750f7",     "image": {       "type": "tag",       "value": "*"      },     "name": "Deny use of Dockerhub Images",     "registry": "dockerhub.io",     "repository": "*"   }  ], By adding this to a policy you can warn teams they are pulling a publicly accessible image, and allow your central IT team to be aware of the violation. This simple contract severs a building block to developing “compliance-as-code” within your Organization. This is just one example of course, you could also search for secrets, personally identifiable information (PII data), or any variety of combinations. Supply Chain Driven Design For CIOs and CSOs, focusing on the role of compliance when designing your software supply chain is crucial for not only managing risk, but also to improve the efficiency and productivity of your organization. Technology leaders that do this quickly will maintain distinct agility when a crisis hits, and stand out from their peers in the industry by innovating faster and more consistently. Anchore Enterprise gives you the building blocks to design your supply chain based on the trade-offs that make the most sense for your organization. More Links & References How one programmer broke the internet NPM Typo Squatting attack How a supply chain attack lead to millions of stolen credit cards Kubecon Supply Chain Talk ### DevSecOps and the Next Generation of Digital Transformation COVID-19 is accelerating the digital transformation of commercial and public sector enterprises around the world. However, digital transformation brings along new digital assets (such as applications, websites, and databases), increasing an enterprise’s attack surface. To prevent costly breaches, protect reputation, and maintain customer relationships, enterprises undergoing digital transformation have begun implementing a built-in and bottom-up security approach: DevSecOps. Ways Enterprises Can Start Implementing DevSecOps DevSecOps requires sharing the responsibility of security across development and operations teams. It involves empowering development, DevOps, and IT personnel with security information and tools to identify and eliminate threats as early as possible. Here are a few ways enterprises that are undergoing digital transformation can start implementing DevSecOps: Analyze Front End Code. Cybercriminals love to target front end code due to its high number of reported vulnerabilities and security issues. Use CI/CD pipelines to detect security flaws early and share that information with developers so they can fix the issue. It’s also a good idea to make sure that attackers haven’t injected any malicious code - containers can be a great way to ensure immutability. Sanitize Sensitive Data. Today, several open source tools can detect personally identifiable information (PII), secrets, access keys, etc. Running a simple check for sensitive data can be exponentially beneficial - a leaked credential in a GitHub repository could mean game over for your data and infrastructure. Utilize IDE Extensions. Developers use integrated development environments and text editors to create and modify code. Why not take advantage of open source extensions that can scan local directories and containers for vulnerabilities? You can’t detect security issues much earlier in the SDLC than that! Integrate Security into CI/CD. There are many open source Continuous Integration/Continuous Delivery tools available such as Jenkins, GitLab CI, Argo, etc. Enterprises should integrate one or more security solutions into their current and future CI/CD pipelines. A good solution would include alerts and events that allow developers to resolve the security issue prior to pushing anything into production. Go Cloud Native. As mentioned earlier, containers can be a great way to ensure immutability. Paired with a powerful orchestration tool, such as Kubernetes, containers can completely transform the way we run distributed applications. There are many great benefits to “going cloud-native,” and several ways enterprises can protect their data and infrastructure by securing their cloud-native applications. Successful Digital Transformation with DevSecOps From government agencies to fast food chains, DevSecOps has enabled enterprises to quickly and securely transform their services and assets, even during a pandemic. For example, the US Department of Defense Enterprise DevSecOps Services Team has changed the average amount of time it takes for software to become approved for military use to days instead of years. For the first time ever, that same team managed to update the software on a spy plane that was in-flight! On the commercial side of things, we’ve seen the pandemic force many businesses and enterprises to adopt new ways of doing things, especially in the food industry. For example, with restaurant seating shut down, Chick-fil-A has to rely heavily on its drive-thru, curbside, and delivery services. Where do those services begin? Software applications! Chick-fil-A obviously uses GitOps, Kubernetes, and AWS and controls large amounts of sensitive data for all of its customers, making it critical that Chick-fil-A implements DevSecOps instead of just DevOps. Imagine if your favorite fast food chain was hacked and your data was stolen - that would be extremely detrimental to business. With the suspiciously personalized ads that I receive on the Chick-fil-A app, there’s also reason to believe that Chick-fil-A has implemented DevSecMLOps, but that’s a topic for another discussion. ### A Beginner's Guide to Anchore Enterprise [Updated post as of October 22, 2020] While many Anchore Enterprise users are familiar with our open source Anchore Engine tool and have a good understanding of the way Anchore works, getting started with the additional features provided by the full product may at first seem overwhelming. In this blog, we will walk through some of the major capabilities of Anchore Enterprise in order to help you get the most value from our product. From basic user interface (UI) usage to enabling third-party notifications, the following sections describe some common things to first explore when adopting Anchore Enterprise. The Enterprise User Interface Perhaps the most notable feature of Anchore Enterprise is the addition of a UI to help you navigate various features of Anchore, such as adding images and repositories, configuring policy bundle and whitelists, and scheduling or viewing reports. The UI helps simplify the usability of Anchore by allowing you to perform normal Anchore actions without requiring a strong understanding of command-line tooling. This means that instead of editing a policy bundle as a JSON file, you can instead use a simple-to-use GUI to directly add or edit policy bundles, rule definitions, and other policy-based features. Check out our documentation for more information on getting started with the Anchore Enterprise UI. Advanced Vulnerability Feeds With the move to Anchore Enterprise, you have the ability to include third-party entitlements that grant access to enhanced vulnerability feed data from Risk Based Security’s VulnDB. You can also analyze Windows-based containers using vulnerability data provided by Microsoft Security Research Center (MSRC). Additionally, feed sync statuses can be viewed directly in the UI’s System Dashboard, giving you insight into the status of the data feeds along with the health of the underlying Anchore services. You can read more about enabling and configuring Anchore to use a localized feed service. Note: Enabling the on-premise (localized) feeds service is required to enable VulnDB and Windows feeds, as these feed providers are not included in the data provided by our feed service. Enterprise Authentication In addition to Role-Based Access Controls (RBAC) to enhance user and account management, Anchore Enterprise includes the ability to configure an external authentication provider using LDAP, or OAuth / SAML. Single Sign-On can be configured via OAuth / SAML support, allowing you to configure Anchore Enterprise to use an external Identity Provider such as Keycloak, Okta, or Google-SSO (among others) in order to fit into your greater organizational identity management workflow. You can use the system dashboard provided by the UI to configure these features, making integration straightforward and easy to view. Take a look at our RBAC, LDAP, or our SSO documentation for more information on authentication/authorization options in Anchore Enterprise. Third-Party Notifications By using our Notifications service, you can configure your Anchore Enterprise deployment to send alerts to external endpoints (Email, GitHub, Slack, and more) about system events such as policy evaluation results, vulnerability updates, and system errors. Notification endpoints can be configured and managed through the UI, along with the specific events that fit your organizational needs. The currently supported endpoints are: Email—Send notifications to a specific SMTP mail service GitHub—Version control for software development using Git JIRA—Issue tracking and agile product management software by Atlassian Slack—Team collaboration software tools and online services by Slack Technologies Teams—Team collaboration software tools and online services by Microsoft Webhook—Send notifications to a specific API endpoint For more information on managing notifications in Anchore Enterprise, take a look at our documentation on notifications. Conclusion In this blog, we provided a high-level overview of several features to explore when first starting out with Anchore Enterprise. There are multiple other features that we didn’t touch on, so check out our product comparison page for a list of other features included in Anchore Enterprise vs. our open-source Engine offering. Take a look at our FAQs for more information. ### Our Top 5 Strategies for Modern Container Security [Updated post as of October 15, 2020] At Anchore, we’re fortunate to be part of the journey of many technology teams as they become cloud-native. We would like to share what we know. Over the past several years, we’ve observed many teams perform microservice application modernization using containers as the basic building blocks. Using Kubernetes, they dynamically orchestrate these software units and optimize their resource utilization. Aside from the adoption of new technologies, we’ve seen cultural transformations as well. For example, the breaking of organizational silos to provide an environment for “shifting left” with the shared goal of incorporating as much validation as possible before a software release. One specific area of transformation which is fascinating to us here is how cloud-native is modernizing both development and security practices, along with CI/CD and operations workflows. Below, we discuss how foundational elements of modern container image security, combined with improved development practices, enhance software delivery overall. For the purposes of this blog, we’ll focus mainly on the image build and the surrounding process within the CI stages of the software development lifecycle. Here is some high-level guidance all technology teams using containers can implement to increase their container image security posture. Use minimal base images: Use minimal base images only containing necessary software packages from trusted sources. This will reduce the attack surface of your images, meaning there is less to exploit, and it will make you more confident in your deployment artifacts. To address this, Red Hat introduced Universal Base Images designed for applications that contain their own dependencies. UBIs also undergo regular vulnerability checking and are continuously maintained. Other examples of minimal base images are Distroless images, maintained by Google, and Alpine Linux images. Go daemonless: Moving away from the Docker CLI and daemon client/server model and into a “daemonless” fork/exec model provides advantages. Traditionally, with the Docker container platform, image build, registry, and container operations happen through what is known as the daemon. Not only does this create a single point of failure, but Docker operations are conducted by a user with full root authority. More recently, tools such as Podman, Buildah, and Skopeo (we use Skopeo inside of Anchore Engine) were created to address the challenges of building images, working with registries, and running containers. For a bit more information the security benefits of using Podman vs Docker read this article by Dan Walsh. Require image signing: Require container images to be signed to verify their authenticity. By doing so you can verify that your images were pushed by the correct party. Image authenticity can be verified with tools such as Notary, and both Podman and Skopeo (discussed above) also provide image signing capabilities. Taking this a step further, you can require that CI tools, repositories, and all other steps in the CI pipeline cryptographically sign every image they process with a software supply chain security framework such as in-toto. Inspect deployment artifacts: Inspect container images for vulnerabilities, misconfigurations, credentials, secrets, and bespoke policy rule violations prior to being promoted to a production registry and certainly before deployment. Container analysis tools such as Anchore can perform deep inspection of container images, and provide codified policy enforcement checks which can be customized to fit a variety of compliance standards. Perhaps the largest benefit of adding security testing with gated policy checks earlier in the container lifecycle is that you will spend less time and money fixing issues post-deployment. Create and enforce policies: For each of the above, tools selected should have the ability to generate codified rules to enable a policy-driven build and release practice. Once chosen they can be integrated and enforced as checkpoints/quality control gates during the software development process in CI/CD pipelines. How Improved Development Practices Help The above can be quite challenging to implement without modernizing development in parallel. One development practice we’ve seen change the way organizations are able to adopt supply chain security in a cloud-native world is GitOps. The declarative constructs of containers and Kubernetes configurations, coupled with infrastructure-as-code tools such as Terraform provide the elements for teams to fully embrace the GitOps methodology. Git now becomes the single source of truth for infrastructure and application configuration, along with policy-as-code documents. This practice allows for improved knowledge sharing, code reviews, and self-service, while at the same time providing a full audit trail to meet compliance requirements. Final Thought The key benefit of adopting modern development practices is the ability to deliver secure software faster and more reliably. By shifting as many checks as possible into an automated testing suite as part of CI/CD, issues are caught early, before they ever make their way into a production environment. Here at Anchore, we’re always interested in finding out more about your cloud-native journey, and how we may be able to help you weave security into your modern workflow. ### Adopt Zero Trust to Safeguard Containers In a time where remote access has shifted from the exception to the new normal, users require access to enterprise applications and services from outside the traditional boundaries of an enterprise network. The rising adoption of microservices and containerized applications have further complicated things. Containers and their underlying infrastructure don’t play well within the boundaries of traditional network security practices, which typically emphasize security at the perimeter. As organizations look for ways to address these challenges, strategies such as the Zero Trust model have gained traction in securing containerized workloads. What is the Zero Trust Model? Forrester Research introduced the Zero Trust model in 2010, emphasizing a new approach to security: “never trust, always verify.” The belief was that traditional security methodologies focused on securing the internal perimeter were no longer sufficient and that any entity accessing enterprise applications and services needed to be authenticated, authorized, and continuously validated, whether inside or outside of the network perimeter, before being granted or keeping access to applications and their data.  Since then, cloud adoption and the rise in a distributed enterprise model has seen organizations looking to adopt these principles in a time where security threats and breaches have become commonplace. Google, a regular early adopter in new technological trends, released a series of whitepapers and other publications in 2014 detailing its implementation of the Zero Trust model in a project known as BeyondCorp.  Zero Trust and Containerized Workloads So how can organizations apply Zero Trust principles on their containerized workloads? Use Approved Images A containerized environment gives you the ability to bring up new applications and services quickly using free and openly distributed software rather than building them yourself. There are advantages to using open source software but this also presents the inherent risk of introducing vulnerabilities and other issues into your environment. Restricting the use of images to those that have been vetted and approved can greatly reduce their attack surface and ensure only trusted applications and services are being deployed into production. Implement Network Policies Container networking introduces complexities such as nodes, pods, containers, and service endpoints assigned IP addresses typically on different network ranges requiring interconnectivity to function properly. As a result, each of these endpoints is generally configured to communicate freely by default. Implementing network policies and micro-segmentation enforces explicit controls around traffic and data flowing between these entities to ensure that only permitted communications are established.  Secure Endpoints In traditional enterprise networks, workloads are often assigned static IP addresses as an identifier and controls are placed around which entities can access certain IP addresses. Containerized applications are typically short-lived, resulting in a dynamic environment with large IP ranges, making it harder to track and audit network connections. To secure these endpoints and the communications between them, organizations should focus on continuously validating and authorizing identities. An emphasis should also be placed on encrypting any communications between endpoints. Implement Identity-Based Policies One of the most important aspects of Zero Trust is ensuring that no entity, inside or outside the perimeter, is authorized to access privileged data and systems without first validating and confirming their identity. As previously mentioned, IP-based validation is no longer sufficient in a containerized environment. Instead, enterprises should enforce policies based on the identities of the actual workloads running in their environments. Role-based access control can facilitate the implementation of fine-grained access policies based on an entity’s characteristics while employing a least-privilege approach further narrows the scope of access by ensuring that any entity requiring privileged access is granted only the minimum level of permissions required to perform a set of actions.  Final Thoughts Container adoption has become a point of emphasis for many organizations in their digital transformation strategies. While there are many benefits to containers and microservices, organizations must be careful not to combine new technologies with archaic enterprise security methodologies. As organizations devise new strategies for securing containerized workloads in a modernized infrastructure, the Zero Trust model can serve as a framework for success.  ### The Story Behind Anchore Toolbox As tool builders, we interact daily with teams of developers, operators, and security professionals working to achieve efficient and highly automated software development processes.  Our goal with this initiative is to provide a technology-focused space for ourselves and the community to build and share a variety of open-source tools to provide data gathering, security, and other capabilities in a form specifically designed for inclusion in developer and developer infrastructure workflows. This post will share the reasoning, objectives, future vision, and methods for joining and contributing to this new project from Anchore. Why Anchore Toolbox? Over the last few years, we’ve witnessed a significant effort in the industry to adopt highly automated, modern software delivery lifecycle (SDLC) management processes.  As container security and compliance technology providers, we often find ourselves deeply involved in security/compliance discussions with practitioners and the general design of new, automation-oriented developer infrastructure systems.  Development teams are looking to add or start with automated security and compliance data collection and controls directly into their SDLC processes. We believe there is an opportunity to translate many of the lessons learned along the way into small, granular tools specifically (and importantly!) designed to be used within a modern developer/CI/CD environment.  Toward this objective, we’ve adopted a UNIX-like philosophy for projects in the Toolbox.  Each specific tool is a stand-alone element with a particular purpose your team can combine with other tools to construct more comprehensive flows. This model lends itself to useful manual invocation. We also find it works well when integrating these types of operations into existing CI/CD platforms such as GitHub, GitLab, Atlassian BitBucket, Azure Pipelines, and CloudBees as they continue to add native security and compliance interfaces. What’s Available Today? We include two tools in Anchore Toolbox to start - Syft,  a software bill of materials generator, and Grype, a container image/code repository vulnerability scanner.  Syft and Grype are fast and efficient software analysis tools that come from our experience building technologies that provide deep container image analysis and security data. To illustrate how we envision DevSecOps teams using these tools in practice, we’ve included a VS Code extension for Grype and a new version of the Anchore Scan GitHub action, based on Grype, that supplies container image security findings to GitHub’s recently launched code scanning feature set.  Both Syft and Grype are light-weight command-line tools by design. We wrote them in Go, making them very straightforward additions to any developer/developer infrastructure workflow. There’s no need to install any language-specific environments or struggle with configurations to pass information in and out of a container instance.  To support interoperability with many SBOM, security, and compliance data stores, you can choose to generate results in human-readable, JSON, and CycloneDX format. Future of Anchore Toolbox We’re launching the Anchore Toolbox with what we believe are important and fundamental building block elements that by themselves fill in essential aspects of the modern SDLC story, but we’re just getting started.  We would love nothing more than to hear from anyone in the community who shares our enthusiasm for bringing the goals of security, compliance, and insight automation ever closer.  We look forward to continuing the discussion and working with you to improve our existing projects and to bring new tools into the Toolbox! For more information - check out the following resources to start using Anchore Toolbox today. Toolbox.Anchore.io Anchore Scan GitHub Action on GitHub Marketplace The Anchore Community on Slack ### Introducing Anchore Toolbox: A New Collection of Open Source DevSecOps Tools Anchore Toolbox is a collection of lightweight, single-purpose, easy to use, open source DevSecOps tools that Anchore has developed for developers and DevOps teams who want to build their continuous integration/continuous development (CI/CD) pipeline. We’re building Toolbox to support the open source DevSecOps community by providing easy-to-use just in time tools available at the command line interface (CLI). Our goal is for Toolbox to serve a fundamentally different need than Anchore Enterprise by offering DevSecOps teams single-purpose tools optimized for speed and ease of use. The first tools to debut as part of Anchore Toolbox are Syft and Grype: Syft We built Syft from the ground up to be an open source analyzer that serves developers who want to “shift left” and scan their projects still in development. You can use Syft to scan a container image, but also a directory inside your development project. Syft tells you what’s inside your super complicated project or container and builds you a detailed software bill of materials (SBOM). You can output an SBOM from Syft as a text file, table, or JavaScript Object Notation (JSON) file and includes native output support for the CycloneDX format.  Installing Syft We provide everything you need, including full documentation for installing Syft over on GitHub. Grype Grype is an open source project to scan your project or container for known vulnerabilities. Grype uses the latest information from the same Anchore feed services as Anchore Engine. You can use Grype to identify vulnerabilities in most Linux operating system packages and language artifacts, including NPM, Python, Ruby, and Java. Grype provides output similar to Syft, including table, text, and JSON. You can use Grype on container images or just directories.  Installing Grype We provide everything you need, including full documentation for installing Grype over on GitHub. Anchore’s Open Source Portfolio and DevSecOps Open source is a building block of today’s DevSecOps toolchain and integral to the growth of the DevSecOps community’s growth at large. Anchore Toolbox is part of our strategy to contribute to both the open source and DevSecOps communities and do our part to advance container security practices. The Anchore Open Source Portfolio also includes two other elements: Out-of-the-box integrations that connect Anchore open source technologies with common CI/CD platforms and developer tools with current integrations including GitHub Actions, Azure Pipelines, BitBucket Pipes, and Visual Studio Code Anchore Engine, a persistent service that stores SBOMs and scan results for historical analysis and API-based interaction Learn more about Anchore Toolbox The best way to learn about Syft and Grype is to use them! Also, stay tuned this week for a blog on Thursday, October 8, 2020, from Dan Nurmi, Anchore CTO, who tells the story behind Anchore Toolbox and offers a look forward at what we plan to do with open source as a company. Join the Anchore Community on Slack to learn more about Toolbox developments and interact with our online community, file issues, and give feedback about your experience with these new tools. ### Deploying Anchore Enterprise 2.4 on AWS Elastic Kubernetes Services (EKS) with Helm [Updated post as of October 1, 2020] In this post, I will walk through the steps for deploying Anchore Enterprise v2.4 on Amazon EKS with Helm. Anchore currently maintains a Helm Chart which we will use to install the necessary Anchore services. Prerequisites A running Amazon EKS cluster with worker nodes launched. See EKS Documentation for more information. Helm (v3) client installed and configured. Before we proceed, let’s confirm our cluster is up and running and we can access the kube-api server of our cluster: Note: Since we will be deploying all services including the database as pods in the cluster, I have deployed a three-node cluster with (2) m5.xlarge and (1) t3.large instances for a basic deployment. I’ve also given the root volume of each node 65GB (195GB total) since we will be using the cluster for persistent storage of the database service. $ kubectl get nodes NAME                                     STATUS ROLES AGE VERSION ip-10-0-1-66.us-east-2.compute.internal  Ready 1d  v1.16.12-eks ip-10-0-3-15.us-east-2.compute.internal  Ready 1d  v1.16.12-eks ip-10-0-3-157.us-east-2.compute.internal Ready 1d  v1.16.12-eks Configuring the Ingress Controller The ALB Ingress Controller triggers the creation of an Application Load Balancer (ALB) and the necessary supporting AWS resources whenever an Ingress resource is created on the cluster with the kubernetes.io/ingress.class: alb annotation. To support external access to the Enterprise UI and Anchore API, we will need the cluster to create an ALB for our deployment. To enable the ALB Ingress Controller pod to create the load balancer and required resources, we need to update the IAM role of the worker nodes and tag the cluster subnets the ingress controller should associate the load balancer with. Download the sample IAM Policy from AWS and attach it to your worker node role either via console or aws-cli. Add the following tags to your cluster’s public subnets: Key Value kubernetes.io/cluster/<> shared Key Value kubernetes.io/role/elb 1 Next, we need to create a Kubernetes service account in the kube-system namespace, a cluster role, and a cluster role binding for the ALB Ingress Controller to use: $ kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.8/docs/examples/rbac-role.yaml With the service account and cluster role resources deployed, download the AWS ALB Ingress Controller deployment manifest to your working directory: $ wget https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.8/docs/examples/alb-ingress-controller.yaml Under the container specifications of the manifest, uncomment  --cluster-name=  and enter the name of your cluster: # REQUIRED # Name of your cluster. Used when naming resources created # by the ALB Ingress Controller, providing distinction between # clusters. - --cluster-name= Save and close the deployment manifest, then deploy it to the cluster: $ kubectl apply -f alb-ingress-controller.yaml Installing the Anchore Engine Helm Chart To install the chart repository, run the following command: $ helm repo add anchore https://charts.anchore.io "anchore" has been added to your repositories Confirm the chart was installed successfully: $ helm repo list NAME   URL anchore https://charts.anchore.io Deploying Anchore Enterprise For the purposes of this post, we will focus on getting a basic deployment of Anchore Enterprise running. For a complete set of configuration options you may include in your installation, refer to the values.yaml file in our charts repository. Note: Refer to our blog post Configuring Anchore Enterprise on EKS for a walkthrough of common production configuration options including securing the Application Load Balancer/Ingress Controller deployment, using S3 archival and configuring a hosted database service such as Amazon RDS. Configure Namespace and Credentials First, let’s create a new namespace for the deployment: $ kubectl create namespace anchore namespace/anchore created Enterprise services require an active Anchore Enterprise subscription (which is supplied via license file), as well as Docker credentials with permission to the private docker repositories that contain the enterprise images. Create a Kubernetes secret in the anchore namespace with your license file: Note: You will need to reference the exact path to your license file on your localhost. In the example below, I have copied my license to my working directory. $ kubectl -n anchore create secret generic anchore-enterprise-license --from-file=license.yaml=./license.yaml secret/anchore-enterprise-license created Next, create a secret containing the Docker Hub credentials with access to the private anchore enterprise repositories: $ kubectl -n anchore create secret docker-registry anchore-enterprise-pullcreds --docker-server=docker.io --docker-username= --docker-password= --docker-email= secret/anchore-enterprise-pullcreds created Ingress Create a new file named anchore_values.yaml in your working directory and create an ingress section with the following contents: ingress:    enabled: true    # Use the following paths for GCE/ALB ingress controller   apiPath: /v1/*    uiPath: /*   annotations: kubernetes.io/ingress.class: alb alb.ingress.kubernetes.io/scheme: internet-facing Engine API Below the ingress section add the following block to configure the Enterprise API: Note: To expose the API service, we set the service type to NodePort instead of the default ClusterIP anchoreApi:   replicaCount: 1   # kubernetes service configuration for anchore external API   service:     type: NodePort     port: 8228     annotations: {} Enable Enterprise Deployment Next, add the following to your anchore_values.yaml file below the anchoreApi section: anchoreEnterpriseGlobal:     enabled: true Enterprise UI Like the API service, we’ll need to expose the UI service to ensure it is accessible outside the cluster. Copy the following section at the end of your anchore_values.yaml file: anchoreEnterpriseUi:   enabled: true   image: docker.io/anchore/enterprise-ui:latest   imagePullPolicy: IfNotPresent   # kubernetes service configuration for anchore UI   service:     type: NodePort     port: 443     annotations: {}     labels: {}     sessionAffinity: ClientIP Deploying the Helm Chart To install the chart, run the following command from the working directory: $ helm install --namespace anchore -f anchore_values.yaml anchore/anchore-engine It will take the system several minutes to bootstrap. You can checks on the status of the pods by running kubectl get pods: $ kubectl -n anchore get pods  NAME READY STATUS RESTARTS AGE  anchore-cli-5f4d697985-rdm9f 1/1 Running 0 14m anchore-enterprise-anchore-engine-analyzer-55f6dd766f-qxp9m 1/1 Running 0 9m  anchore-enterprise-anchore-engine-api-bcd54c574-bx8sq 4/4 Running 0 9m anchore-enterprise-anchore-engine-catalog-ddd45985b-l5nfn 1/1 Running 0 9m  anchore-enterprise-anchore-engine-enterprise-feeds-786b6cd9mw9l 1/1 Running 0 9m anchore-enterprise-anchore-engine-enterprise-ui-758f85c859t2kqt 1/1 Running 0 9m  anchore-enterprise-anchore-engine-policy-846647f56b-5qk7f 1/1 Running 0 9m  anchore-enterprise-anchore-engine-simplequeue-85fbd57559-c6lqq 1/1 Running 0 9m  anchore-enterprise-anchore-feeds-db-668969c784-6f556 1/1 Running 0 9m anchore-enterprise-anchore-ui-redis-master-0 1/1 Running 0 9m anchore-enterprise-postgresql-86d56f7bf8-nx6mw 1/1 Running 0 9m Run the following command to get details on the deployed ingress: $ kubectl -n anchore get ingress NAME    HOSTS   ADDRESS  PORTS   AGE support-anchore-engine   *       1a2b3c4-anchoreenterprise-f9e8-123456789.us-east-2.elb.amazonaws.com   80      4h You should see the address for the created and can use it to navigate to the Enterprise UI: Conclusion You now have an installation of Anchore Enterprise up and running on Amazon EKS. The complete contents for the walkthrough are available by navigating to the GitHub repo here. For more info on Anchore Engine or Enterprise, you can join our community Slack channel, or request a technical demo. ### Compliance’s Role in Container Image Security and Vulnerability Scanning Compliance is the practice of observing a set of standards for recommended security controls laid out by a particular agency or industry that an application must adhere to or face stiff penalties. Today, most enterprises have regulations to protect information and assets from the Center for Internet Security (CIS) to the Health Insurance Portability and Accountability Act (HIPAA). As with most things in compliance, it’s how an agency or company configures applications and services that counts. While vulnerability scanning and image analysis are crucial parts of container security, ensuring that images are compliant with organizational and industry regulations extends beyond merely looking for vulnerabilities. NIST SP 800-190 An example of such an agency is the National Institute of Standards and Technology (NIST). NIST is a non-regulatory government agency that develops technology, metrics, and standards to drive innovation and economic competitiveness at U.S. based organizations in the science and technology industry. Companies that are providing products and services to the federal government are often required to meet the NIST security mandates. NIST provides guidance with Special Publication (SP) 800-190, which addresses the security concerns associated with application container technologies. CIS Docker Benchmark The Center for Internet Security (CIS), with its CIS 1.13.0 Docker compliance guide, provides a  more general recommended compliance guideline. A CIS 1.13.0 policy bundle that addresses compliance regulations outlined by CIS is available in Anchore’s Policy Hub, making it simple to enforce these checks with Anchore out of the box. Many common CIS compliance checks have been implemented with the CIS policy bundle or have examples for end-users to customize. Still, all Anchore policy bundles can be extended or even have new bundles created that are tailored directly to application and industry recommendations. Enforcing Compliance with Anchore As outlined in this previous blog post written by our very own Jeremy Valance, enforcing compliance with Anchore is a straightforward and flexible way to adhere to varying industry regulations. Given the variance of compliance needs across different enterprises, having a flexible and robust policy engine becomes necessary for organizations needing to stick to one or many sets of standards. With Anchore, development and security teams can harden their container security posture by adding an image scanning step to their CI, reporting back on CVEs, and fine-tuning policies to meet compliance requirements. Putting compliance checks in place ensures that only container images that meet the standards outlined by a particular agency or industry will be allowed to make their way into production-ready environments.  You can find more information on working with Anchore policies here. ### The Importance of Building Trust in Cloud Security, A Shared Responsibility With DevOps Teams Overall the world is moving towards the cloud. Companies all across the globe are recognizing the merit of overcoming infrastructure challenges by using cloud services. While moving to cloud infrastructure solves many complex problems faced by companies, it introduces new challenges. One of the main challenges is the security of business-critical information that companies are now storing inside cloud infrastructure. Storing data inside cloud infrastructure is easy and convenient, but it comes with a whole new set of technical challenges for DevOps engineers. Cloud services provide a highly configurable environment that can be adapted to any application. However, it is a new environment, and engineers must learn how to configure the system properly. The infrastructure must be configured appropriately; user accounts must be tracked and have the appropriate permissions, applications must be secure, the infrastructure running those applications must also be secured. Misconfigured cloud systems are a significant risk for data breaches where a company can lose important data. These data losses can cause incredible damage to a company, not only causing a loss in revenue and trust, but also a loss of reputation. These costly mistakes, more often than not, stem from a misconfigured system. Misconfigurations can include user accounts that have higher privileges than they should, web servers that are exposed to the public when they shouldn't be. Multi-factor authentication is not made a requirement when it should be. Overall the cloud has a lot to offer, the upsides are highly performant and scalable infrastructure, along with toolsets that give DevOps Engineers control over their system from top to bottom. However, this improved way of deploying and controlling production software is accompanied by a new set of security challenges. These security challenges come from the requirement to learn a whole new cutting edge system. In order to secure business-critical systems, tooling must be developed so that DevOps engineers can use the toolsets to ensure only secure software is running in production handling business-critical information. The landscape for production software is changing so quickly, and there is such a minuscule margin of error that there must be a focus on not only automated deployment but automated security as well. The infrastructure must be audited to ensure security. Applications must be audited for security before deployment, during deployment, and while running. It is the responsibility of DevOps Engineers to ensure that the software running business-critical systems is secure. With such an extensive and highly configurable system offered by cloud providers, many small misconfigurations can fall through the cracks. The best way to overcome the challenges of ensuring software security is to develop automation using security tooling to ensure your system conforms to the requirements. Once automation has been put in place, it will ensure that any system goes through the same rigorous process and security checks before it makes it into production. This helps reduce the number of misconfigurations due to human error, and it will help increase the overall trustworthiness of production software. Cloud infrastructure has so much to offer to improve the overall performance and data handling for companies today. However, it also comes with a whole new set of challenges that DevOps Engineers must face. As companies put more and more of their information into the cloud, it falls on DevOps Engineers to ensure that data is safely managed. The cloud, by its nature, is highly configurable, and thus, the security of the workloads running on it are subject to the configuration of the system. This configuration ultimately falls on the shoulders of DevOps Engineers, who must learn how to configure the system properly. To configure complex cloud systems, tooling and automation must be used to provide engineers a way to deploy software so that it is secure and trustworthy. Deploying software in this manner helps alleviate the complexity introduced by cloud systems and allows the engineers some peace of mind when their production software handles business-critical information. ### Container Security & Automation, How To Implement And Keep Up With CI/CD A major issue in modern software development is the fact that most organizations are quick to adopt containers and automation, but remain behind the curve in adopting DevSecOps processes that ensure container security. By sharing the responsibility of security across all software teams, organizations can begin to identify vulnerabilities earlier in their SDLC (software development lifecycle) and engrain security and compliance into their current and future CI/CD (Continuous Integration/Continuous Delivery) workflows. Empowering Developers Before CI/CD One of the first steps an organization should take towards sharing the responsibility of security across all teams is to empower their developers with visibility and knowledge into security threats. As the ones who initially create and improve code, developers need to be aware of the weaknesses in the packages and libraries they are using. Since developers are typically working on local machines, Anchore has created open source CLI tools that enable developers to generate SBOMs (software bill of materials) and identify vulnerabilities not only in container images but also in code and filesystems. Currently in pre-release, Syft and Grype are ideal for projects in development and will soon include automated vulnerability scanning with IDE (integrated development environment) plugins. This allows for development and security teams to communicate and remediate security threats prior to wasting time or money on operational resources. Automating Security During CI Once the development and security teams have acknowledged and accepted the threat level in a software project or feature, they may decide to run the code through a CI pipeline. These pipelines are usually owned by DevOps (development operations) Engineers and may include stages like building a container image, running tests, and pushing the image to a registry.  In order to share the responsibility of security across teams, an organization should ensure there is a vulnerability scanning and compliance stage in every pipeline. With easy integration with CI tools such as GitLab CI, Jenkins, and AWS CodeBuild, Anchore Enterprise 2.4.0 makes it simple for operations teams to incorporate things like malware scanning, base image comparisons, and enhanced vulnerability feeds to discover vulnerable points in the attack surface that the development team would have missed. When Anchore finds vulnerable points in the attack surface, future pipeline stages can be configured to fail and the operations team can be alerted so that development and security teams can work to resolve the security issue. Ensuring Compliance During CD When a feature is ready and it comes time to deploy into production through an orchestration tool such as Kubernetes, it is important that organizations remain vigilant in their “final evaluation” of a container image before runtime. The security team may have requirements like blocking containers from using specific packages, ports, or user permissions. The organization may have a mandated level of compliance to achieve such as DISA, NIST, or PCI DSS compliance. Anchore makes it simple for the security team to enforce security and compliance checks with policy as code. Additionally, the Anchore Admission Controller can ensure non-compliant containers are blocked from being deployed. Regardless of whether someone is attempting to deploy containers with a CD tool like Argo or by creating a pod, deployment, or stateful set, the Anchore Admission Controller will evaluate each container against the security team’s policy before deciding to deploy or not deploy. Conclusion As attackers are constantly looking to take advantage of vulnerable points, organizations should be looking for their own vulnerable points. By sharing the responsibility of security across all software teams, modern organizations can begin identifying threats earlier and automating container security processes in their CI/CD workflows. ### Container Registry Audits, 3 Reasons to Implement for Container Security & Compliance The ease of access a container registry provides users is a clear advantage over legacy code storage methods. However, just like almost any other type of technology, it has the potential to house and propagate malicious code. Docker Hub was a prime example of this, as is detailed in this post about malicious cryptocurrency mining code being buried in popular images. Any container registry is susceptible to this. Therefore, scanning images for vulnerabilities and malicious code is critical for organizational security and the security of the development community as a whole. Reason 1 - Internal Company Security To deliver a quality software product, companies need to ensure that the tools they use internally are secure and can be relied on. Auditing self-managed company registries is an important part of that process, especially if the code contained in those registries is written by external sources. It is easy for an engineer to accidentally introduce malicious code to the registry without knowing. By ensuring that tools are secure, the end product that is delivered to customers, as well as important, proprietary company information, can be kept secure.  Reason 2 - Product Security Securing a product is an important consideration that all software companies must keep in mind when contemplating the methods they use to deliver code to their customers. Auditing registries that hold code available to customers is a way companies can ensure that any code delivered lives up to their security standards and that no vulnerabilities whether intentional or unintentional slip through the cracks. Additionally, certain industries have stringent guidelines that any software product must adhere to. An example is the healthcare industry. The importance of securing HIPAA protected data cannot be overstated, so checks to ensure that data leaks are not possible are important to maintaining compliance under government and company guidelines and requirements. This helps maintain trust with regulatory authorities and with customers. Reason 3 - Open Source Security Open source security is the third and perhaps most important reason to implement registry audits. Large open source registries have code flooding into them from anyone, anywhere, with any intention. It is all too easy for a person to create an image and push it to Docker Hub. A nefarious image disguised as a common open source project such as MySQL has the potential to wreak havoc on those who unwittingly deploy that image. By maintaining the integrity of the code that is available to the open source community, public registry maintainers can ensure that those who use the containers to build other products or learn are protected from attacks or attempts to steal their data. The importance of container registry audits cannot be overstated. Containerization is an important development in the software delivery process. It has allowed for the quick and flexible deployment of countless applications, but it has taken the transparency to the user all but away making it difficult for a developer or user to know exactly what the code they are using is doing. With this loss of transparency, users, developers and anyone else who access these containers, needs to know that they are safe from malicious code and data security violations. By auditing the registries that secure that code, users can rest assured that the containers they use are safe and that the data they feed those containers is equally safe. ### Sharing Compliance & Security, How DevOps Benefits From Shifting Left to DevSecOps At Anchore, we work across the spectrum of many organizations' transformation journeys to DevSecOps. One of the most notable and exciting transformations we’ve been involved with over the past couple of years is the U.S. Department of Defense (DoD) Enterprise DevSecOps Initiative. This initiative is perhaps best described by U.S. Air Force Chief Software Officer Nicolas Chaillan, in this video from Kubecon 2019. While we are fans of buzzwords and IT trends, we also are mindful of the different DevOps and DevSecOps stages of maturity each IT organization is at. In this post, we will share three key benefits of moving to DevSecOps at any maturity stage. Before we dive into specifics, let's start with a definition from Wikipedia for DevOps: DevOps is a set of practices that combines software development (Dev) and IT operations (Ops). It aims to shorten the systems development lifecycle and provide continuous delivery with high software quality.  From this, we can describe DevSecOps. DevSecOps is an augmentation of DevOps. It means thinking about application and infrastructure security from the start. It also means automating security gates to keep the DevOps workflow from slowing down. It builds on the cultural changes and philosophies of DevOps to integrate the work of security teams sooner rather than later. DevSecOps also underscore the importance of helping developers write their software with security in mind, a process that typically involves sharing visibility, and insights on known threats or malicious activity. In addition, it requires security teams to build security into the software lifecycle end to end, with a set plan for automation.  Benefit 1: Saving Cost and Time Perhaps the most obvious benefit of incorporating automated security gates into existing software development workflows is saving cost and time. Shifting security left allows for vulnerabilities, misconfigurations, and other security risks to be caught closer to the developers, which means issues are caught early and triaged quickly. It is far cheaper and simpler to resolve a known security problem directly in the build pipeline or at the IDE step than post-deployment.  Benefit 2: Better Collaboration and Communication Among Teams Perhaps an obvious one, but by bringing security into the conversation as early as possible, and promoting collaboration with development and operations teams, developers now see security as an enabler, not an impediment. This adds to a culture of openness, accountability, and transparency across applications, infrastructure, security and compliance requirements, and runtime environments.  Benefit 3: Faster Response to Changing Customer Needs Somewhat related to the first benefit, however important to highlight the importance of rapid response to changes in the marketplace. For any organization developing and shipping software products or services to end-users, there are often compliance requirements for handling sensitive customer data, or security standards and audits SaaS or PaaS providers must meet. These requirements often struggle to keep up with the pace of technology innovation, however, the more automation and collaboration IT organizations can put around compliance requirements, the better they can adapt when new changes are published. Conclusion The above three benefits certainly aren’t meant to be exhaustive, however, based on our experience being embedded in one of the largest transformations to DevSecOps, these are the three we’ve seen as most impactful across the DoD organization. ### Part 2, A Container Security Terminology Guide For Better Communication In part 1 of our container security terminology guide, we introduced everyone to our shift left lexicon to help you gain a clear understanding of the key phrases and common phrases used in DevSecOps. Today, we're sharing part 2 of our guide where we’ll broaden our focus to include additional key security language is routinely used across DevSecOps teams and organizations.   We know not everyone in an organization is a security expert; this lexicon is intended to help organizations clearly understand DevSecOps terminology. Container Security Terminology Guide Audit An audit is a periodic exercise to review and judge the state of a software project. Audits can be performed against internal policies or external standards and may be conducted by internal security teams or by outside specialists. Center for International Security (CIS) The CIS is a nonprofit organization with a mission is to "identify, develop, validate, promote, and sustain best practice solutions for cyber defense.” CIS publishes a collection of benchmarks and controls that form the basis for many industry-standard security policies. Common Vulnerabilities and Exposures (CVE) The CVE is a system for standardizing documentation and reference to security issues. Many devs might gather feedback from a security tool that finds CVE’s attached to packages or libraries related to their application(s). Not every CVE needs to be remediated. In fact, there will always be some false positives that slip through the cracks. Track the false positives, remediate applicable high/critical vulnerabilities, and try to burn down vulnerabilities that are older.  Common Vulnerability Scoring System (CVSS) The CVSS is an industry-standard method for evaluating vulnerabilities and assigning severity scores to them. These scores are often included in vulnerability feeds and can be used by security teams to control thresholds for approving software. For example, organizations could create a benchmark where they only approve containers that contain no vulnerabilities that violate a CVSS impact and exploitability score of a 7.5. CVSS scoring is also a good compass to guide which CVE’s are more critical than others and can be used by teams to prioritize what needs fixing first within their builds. License Open-source software projects use a variety of different software licenses with different conditions for use and distribution of derivative software. Some licenses may be incompatible with each other or may have conditions that are incompatible with corporate policies.   NIST (National Institute of Standards and Technology)   NIST publishes widely-regarded security standards such as NIST 800-180 and maintains the National Vulnerability Database. NVD (National Vulnerability Database) NVD is a database of known vulnerabilities, mitigations, and vendor comments, maintained by NIST and freely distributed via a collection of feeds. Policy Policy is a set of rules that are used to perform an evaluation of a container image. Rules can, in theory, examine any aspect of the examined images. Commonly rules look at known CVEs contained in the image, ports exposed by the image, packages installed in the image, or even metadata such as the on-disk size of the image. Scanning Scanning is the process of examining container images, inventorying the contents, and applying policy/rules. The output of the scanning process is a judgment on whether the image complies with the selected policies or not, and that judgment can be used to provide feedback to developers, make decisions about the promotion of an image from a lower environment to a higher one, or even to prevent deployment of an image into a cluster. Shift Left A central practice in DevSecOps, shift left is essentially the complete integration of security and development. The result is a more robust testing, more efficient use of manpower and computing resources, faster delivery and fewer unplanned delays. It's important to use a competent security tool that provides developers with fidelity and granularity of security issues related to their builds so that they can fix and ultimately deploy much faster.   Vulnerability Feeds Vulnerability feeds deliver information about vulnerabilities via machine-readable format (often JSON, RSS, or other industry-standard formats) suitable for automatic consumption by security tools. Feeds serve as the backbone when identifying vulnerabilities. This allows scanning tools like Anchore to decompose images, analyze the packages that compose an image, and perform matching against packages to the CVE’s published against said packages. Being able to loop this into a Gitlab or Jenkins job is critical for teams focusing on building quickly. Integrate vulnerability scanning with your SCM so scanning is done regularly against code in your source repository. Combined with the topics discussed in part 1 of our container security lexicon, you now have a clear understanding of core security terminology and you’re ready to begin your DevSecOps journey. ### A Container Security Terminology Guide For Better Communication Many enterprises often find themselves sifting through guidance, compliance regulations, and requirements as organizations set out on their DevSecOps journey. Sifting through all of the key terminology and understanding how each key item intricately interacts with other key components can be overwhelming for developers who may be in the beginning stages of their journey. To help, Anchore has created a shift left lexicon to help you gain a clear understanding of the key phrases and terminology used in DevSecOps. Container Security Terminology Guide Containers Let’s start with a container. A container is a collection of processes along with constraints on what resources the container can access and isolate from other activities on the system. Multiple containers can then be run on top of the same host so that they can all share the host OS kernel with one another. The best way to understand containers is to look at container images and see how container images are consumed by a registry and deployed on Kubernetes. Container Images Container images are templates for the creation of containers and contain all of the source code, dependencies, licenses, metadata, libraries and supporting files needed for an application to run. Images are (usually) defined by a Dockerfile, which allows for them to be reproducibly built from defined base images, source code, and build instructions. Registry A registry is a storage system for images. Different images are stored in individual repositories in the registry, and in the repository, different versions of the image can be denoted with tags. Some registries are public and anyone can anonymously pull images, while others are private and require authentication. Many public registries also offer the ability to mark individual repositories as private: docker.io/alpine:latest Registry: docker.io  Repository: alpine Tag: latest Registries are useful in DevOps workflows because in general the container images will be built in one environment but will run in production in a different environment. The registry is a centralized hub: automation can direct worker nodes in the build farm to push completed images into the registry, and worker nodes in the production environment can pull the latest vetted version of an image when it’s time to execute. Kubernetes Kubernetes is an industry-standard container orchestration platform. This simply means that it keeps track of containers across a cluster of worker nodes, which can be as small as a single system on a developer's desk or scale up to hundreds or thousands of nodes, across multiple datacenters and cloud providers.  There are other container orchestrators but all major vendors have standardized on Kubernetes and many practitioners use “orchestration” and “Kubernetes” interchangeably. Continuous Integration (CI) Continuous Integration (CI) refers to the automated building of software on a continual basis as changes are checked in by developers. This generally means that developers are making a steady stream of small changes rather than the more traditional method of committing changes in huge but infrequent batches. As the changes come in, the CI tooling will automatically integrate the changes into the codebase, coordinating the efforts of multiple developers on the team. Continuous Delivery (CD) Continuous Delivery (CD) is a complimentary automation technique, which takes the software artifacts produced by the CI tooling and delivers them to the next location. In some cases, this may mean submitting recently checked-in code to automated testing processes, or it could move finished and tested code from a QA environment to a production environment. A fully automated set of tooling to integrate changes, apply testing (including security checks), and move code to production is often referred to as a CI/CD Pipeline. These are only a few key terms that are very important in gaining a foundational understanding of core concepts embedded within DevSecOps methodology. Stay tuned for part two of our shift left lexicon where we'll dive deeper into container security terminology. ### Introducing Anchore Enterprise 2.4 Today, we are pleased to announce the GA of Anchore Enterprise 2.4. In keeping with previous releases in the 2.x series, version 2.4 has been heavily driven by customer requests both in terms of features and operational improvements. Without further ado, let’s go into the main enhancements. Base Image Comparison It is common for teams to standardize around a base OS image upon which application teams then layer their specific content. With our new base image comparison feature, application teams can see which security issues or vulnerabilities have been introduced by their code or dependencies and are therefore their responsibility versus the owner of the base image. More importantly, it also allows the base image owner to see what issues they can resolve across multiple applications by addressing issues in the base image. Given that a few judicious upgrades of libraries in a base image can resolve a huge swathe of vulnerabilities, this feature ensures that it is easy to find steps that have the most impact with the fewest number of steps.  Malware Detection Despite the rise of more modern malware like cryptomining trojans, traditional viruses still continue to affect software via the software supply chain. Anchore will now scan for viruses in binaries against a database of known signatures as part of our deep image inspection. A rule can be created in our policy engine that generates a “warn” or “stop” if a virus is detected. This allows you to do your virus scans as part of CI/CD as well for scanning existing content in a registry.  Hint File When Anchore analyzes an image, it looks at package indexes, names of files and other metadata to generate matches with vulnerability information. Sometimes this information is not discoverable, either because it is missing or not discoverable. A good example is with Go, the popular programming language, where libraries are compiled in. Using a hint file, which is detected within the image itself, developers can explicitly enumerate dependencies they have used which Anchore will use to generate vulnerabilities. This feature is best used where the creation of the hint file is formalized as part of the development process. In addition, we have added Go as a type (in both the API and UI) in the Anchore system so vulnerabilities can be explicitly related to the language.  Fair Queuing As long term admins of Anchore will be aware, every now and then a user will add a repository that contains 1000s of tags, each containing hundreds of images. Previously, our queuing system worked on a first-in-first-out (FIFO) basis which meant that when a large repo was added, it could block other users with more urgent requests. With the new fair queueing algorithm in 2.4, the system will ensure that each account or tenant in the system gets equal processing time, with one image being processed for each account at a time in a round-robin fashion.  Bulk Image Deletion API It is common for the size of the Anchore database to grow over time as users add more and more repos. Many of the images that get scanned, do not need to be retained by the system as they are test or scratch images. Previously, it required an API call per image to delete them from the database with users writing scripts to iteratively call the API to delete multiple images. With the new bulk API, a user can submit a list of repos/images that should be deleted in bulk, asynchronous to the API call.  And Finally Many additional features and improvements have gone into the graphical user interface, most notably, users will now see a “What’s New” popup after their administrators have upgraded the system. This will introduce them to the new features listed above and other areas of change.  Many thanks to the customers who provided feedback and testing on our new features. We’re keen to hear feedback from prospective or existing customers on our Discourse forum about this release and to receive feedback for the next one. And finally, a huge thanks to the engineering team for keeping the momentum on our product releases even during the pandemic.  Watch the Anchore Enterprise 2.4 Video Please bookmark our product release page to see videos on all Anchore Enterprise releases, past, current and future as we announce them.  ### Container Security in Helm Charts for DevOps Teams What is Helm? In very basic terms, Helm is a package manager for Kubernetes that makes it easy to take applications and services that are highly repeatable and scalable and deploy them to a Kubernetes cluster. Helm deploys applications using charts, which are essentially the final packaged artifact; a complete collection of files describing the set of Kubernetes resources required to deploy the application successfully. By far the most popular way to manage Kubernetes applications and releases, Helm is a graduated member of the Cloud Native Computing Foundation (CNCF), and the Helm charts repository on GitHub has more than 14,000 stars.  Out of the box, there are major benefits to using Helm. To name a few, deployments become simpler and streamlined. Software vendors can provide a set of base defaults for an application, then developers can override or extend these settings during installation to suit the requirements for their deployments. These default configurations are often hardcoded in the deployment templates and made configurable by a values.yaml file which developers can choose to pass the chart during installation. This ease of use helps with the steep learning curve of Kubernetes. Developers don’t necessarily need to obtain a deep understanding of each Kubernetes object in order to deploy an application quickly. Finally, having a chart built and maintained by software vendors allows it to be used over and over again by a large audience, reducing duplication and complexity of customer and user releases across multiple environments.  While the benefits described above are great, it is important to understand the risks associated with using these new artifacts. Below are two major components to consider when beginning to work with Helm charts.   Container Images & Helm Deployments Since Helm charts deploy Kubernetes applications, they include references to container images in the YAML manifests which then run as containers on the cluster. For many charts, there are often several images (optional or required) for the application to start. Due to this, visibility into the images that will be used with your Helm deployment via image inspection should be a mandatory step in your deployment process. For example, the MariaDB Helm chart includes a reference to the image: docker.io/bitnami/mariadb:10.3.22-debian-10-r27 in the values.yaml file. Ordinarily, it is a good idea to check to see if this container image has any known vulnerabilities or misconfigurations that could be exploited by an attacker. This is also a good example of configuration flexibility with Helm. If I wanted to use a different image with this Helm chart, I could swap out the registry, repository, tag combination in the values.yaml, and deploy with another image. Important to be careful here though, as the deployment configuration for the applications are often software specific, so there are no guarantees that a newer version of MariaDB will work with the deployment.  Managing the sets of images that exist across various deployments in a Kubernetes environment often involves continuous monitoring of the image workload to manage the sprawl effectively. While there is no silver bullet, integrating image inspection, enforcement, and triage into your development and delivery workflow will greatly improve your security posture and reduce the time to resolution should containerized applications become vulnerable. Configuration Awareness For Secure Deployments As discussed above, Helm charts contain Kubernetes YAML manifest files, which describe the properties and characteristics of the Kubernetes objects that will then be deployed on the cluster. There are many defaults within these files which can be overridden upon deployment of the Helm chart via the values.yaml file or inline. It is very easy to deploy an application without CPU or memory limits set, without security contexts, or a container running with SYS_ADMIN capabilities, or in privileged mode.  Quite often, there are optional configurations documented in Helm charts which can greatly enhance the security of the deployment. It is not uncharacteristic for the basic Helm deployment to focus on “getting the software up and running” and not necessarily a default secure deployment. Without getting too involved in the intricacies of Kubernetes and runtime security, it is important to understand exactly what Helm is doing behind the scenes with regards to the application you are deploying, and what tweaks you can provide the configuration for the Kubernetes objects to secure your deployment.  In a similar vein, there are oftentimes application-specific configurations that are not always obvious or available for modification via the values.yaml file. I highly recommend taking a look at the deployment templates, configmaps, etc. just to ensure you are deploying the application the right way for your security needs. Last, but certainly not least, once you’ve deployed your applications in a Kubernetes environment, appropriate measures need to be taken to enforce and monitor for malicious activity, network anomalies, container escapes, etc. These are separate sets of challenges than managing deployment and configuration artifacts in a build workflow and often require tools designed specifically for forensics and monitoring of a runtime environment.   Conclusion The benefits of using Helm are easy to see, and many developers can get started quickly by deploying containerized applications to Kubernetes with just a simple "helm install." However, with any tool that includes a significant amount of abstraction to reduce deployment complexity, taking a methodical approach to understanding the nuts and bolts of what is going on behind the scenes is a recommended security practice to undertake. With the basic tips above, hopefully, you can be well on your way to understanding a bit more able Helm, so you can deploy Kubernetes applications securely. ### 3 Best Practices for Detecting Attack Vectors on Kubernetes Containers In recent years, the adoption of microservices and containerized architectures has continually been on the rise, with everyone from small startups to major corporations joining the push into the container world. According to VMWare, 59 percent of large organizations surveyed use Kubernetes to deploy their applications into production. As organizations move towards deploying containers in production, keeping security at the forefront of development becomes more critical because while containers ideally are immutable, they are just another application exposed to security vulnerabilities. The potential impact of a compromise of the underlying container orchestrator can be massive, making securing your applications one of the most important aspects of deployment.  Securing Infrastructure Securing the underlying infrastructure that Kubernetes runs on is just as important as securing the servers that run traditional applications. There are many security guides available, but keeping the following three points in mind is a great place to start. Secure and configure the underlying host. Checking your configuration against CIS Benchmarks is recommended as CIS Benchmarks provide clear sets of standards for configuring everything from operating systems to cloud infrastructure. Minimize administrative access to Kubernetes nodes. Restricting access to the nodes in your cluster is the basis of preventing insider threats and reducing the ability to elevate commands for malicious users. Most debugging and other tasks can typically be handled without directly accessing the node. Control network access to sensitive ports. Ensuring that your network limits access to commonly known ports, such as port 22 for SSH access or ports 10250 and 10255 used by Kubelet, restricts access to your network and limits the attack surface for malicious users. Using Security Groups (AWS), Firewall Rules (GCP), and Azure Firewall (Azure) are simple, straightforward ways to control access to your network resources. Rotate infrastructure access credentials frequently. Setting shorter lifetimes on secrets, keys, or access credentials makes it more difficult for an attacker to make use of that credential. Following recommended credential rotation schedules greatly reduces the ability of an attacker to gain access. Securing Kubernetes Ensuring the configuration of Kubernetes and any secrets is another critical component to securing your organization’s operational infrastructure. Here are some helpful tips to focus on when deploying to Kubernetes. Encrypt secrets at rest. Kubernetes uses an etcd database to store any information accessible via the Kubernetes API such as secrets and ConfigMaps; essentially the actual and desired state of the entire system. Encrypting this area helps protect the entire system. Enable audit logging. Kubernetes clusters have the option to enable audit logging, keeping a chronological record of calls made to the API. They can be useful for investigating suspicious API requests, for collecting statistics, or for creating monitoring alerts for unwanted API calls. Control the privileges containers are allowed. Limiting access to a container is crucial to prevent privilege escalation. Kubernetes includes pod security policies that can be used to enforce privileges. Container applications should be written to run as a non-root user, and administrators should use a restrictive pod security policy to prevent applications from escaping their container. Control access to the Kubelet. A Kubelet's HTTPS endpoint exposes APIs which give access to data of varying sensitivity, and allow you to perform operations with varying levels of power on the node and within containers. By default, Kubelet allows unauthorized access to the API, so securing it is recommended for production environments. Enable TLS for all API traffic. Kubernetes expects all API communication within the cluster to be encrypted by TLS, and while the Kubernetes APIs and most installation methods encrypt this by default, API communication in deployed applications may not be encrypted. Administrators should pay close attention to any applications that communicate over unencrypted API calls as they are exposed to potential attacks. Control which nodes pods can access. Kubernetes does not restrict pod scheduling on nodes by default, but it is a best practice to leverage Kubernetes’ in-depth pod placement policies, including labels, nodeSelector, and affinity/anti-affinity rules. Securing Containerized Applications Aside from how it is deployed, an application that runs in a container is subject to the same vulnerabilities as running it outside a container. At Anchore, we focus on helping identify which vulnerabilities apply to your containerized applications, and the following are some of many key takeaways that we’ve learned. Scan early, scan often. Shifting security left in the DevSecOps pipeline helps organizations identify potential vulnerabilities early in the process. Shift Left with a Real World Guide to DevSecOps walks you through the benefits of moving security earlier in the DevSecOps workflow. Incorporate vulnerability analysis into CI/CD. Several of our blog posts cover integrating Anchore with CI/CD build pipelines. We also have documentation on integrating with some of the more widely used CI/CD build tools. Multi-staged builds to keep software compilation out of runtime. Take a look at our blog post on Cryptocurrency Mining Attacks for some information on how Anchore can help prevent vulnerabilities and how multi-stage builds come into play. With the shift towards containerized production deployments, it is important to understand how security plays a role in each level of the infrastructure; from the underlying hosts to the container orchestration platform, and finally to the container itself. By keeping these guidelines in mind, the focus on security shifts from being an afterthought to being included in every step of the DevSecOps workflow. Need a better solution for managing container vulnerabilities? Anchore's Kubernetes vulnerability scanning can help. ### Cybersecurity & Container Security, Forecasting Organization Adoption to Minimize Threats The use of containers is growing rapidly and for good reason. Compared to traditional, monolithic applications, containers offer many great benefits: faster delivery, elasticity, portability—the list goes on. In a recent press release, Gartner predicted by 2022, more than 75 percent of global organizations will be running containerized applications in production and by 2024, container management revenue will reach $944 million. Despite this exciting growth, containers are still vulnerable to cyberattacks. According to a Tripwire survey, 60 percent of enterprises running containers suffered a container security incident in 2018. Additionally, a recent StackRox survey involving IT and security professionals found that 94 percent of respondents encountered a security incident in the past year related to containers or Kubernetes. Without proper security measures in place, your container management environment could suffer from container security incidents too.  To minimize your attack surface, you should know the exact contents and vulnerabilities of your containerized applications before running them in production. By first identifying threats and vulnerabilities, you can begin to enforce policies and achieve the desired level of security and compliance.  Application & Insider Threat Checks For example, a developer has been tasked with creating a custom-built container that utilizes a popular database server. The security team has required that this database server be configured using a specific version with TLS and authentication enabled. What can be done to ensure these requirements are fulfilled? Anchore provides users with the ability to create policy-as-code. A user can create a simple JSON policy that checks for application-level configuration such as a specific package version or a required configuration option. A policy can then be enforced by user-defined actions that could fail a pipeline stage or prevent the container from being deployed. Implementing both accidental and malicious insider threat checks is one of the first things your organization can do to mitigate container security risks. Ports, Permissions & Private Data Checks In addition to checking for files, packages, and software artifacts, a container security solution should also check for ports, permissions, and private data. Similar to how AWS Macie checks for personal identifiable information (PII) in an S3 bucket, container security software should provide users with automatic checks for exposed ports, insecure permissions, secrets, passwords, licenses, keys, and other metadata. Whether the information was mistakenly added or left behind during testing, checks of this nature are essential in achieving levels of compliance and preventing bad actors from acquiring privileged access or sensitive data. Vulnerability Checks There are many container scanning tools on the market that check for common vulnerabilities and exposures (CVE). However, scanning the same container image with two separate tools will always yield different results. With the variety of public security advisories available today, it is important your organization chooses a container scanning solution that utilizes a comprehensive set of feed sources and is able to identify every software package installed in the container.  As a developer myself, I know that we will install any packages necessary to get a job done. Nonetheless, your security team may want to block a risky package from being used or discover that there is an upstream patch available for a package. Knowing which CVE corresponds to which package and ensuring that the minimum required packages are installed in a container is critical while your security team researches, evaluates and minimizes risk.  In this blog, we acknowledged that the increased use of containers among global organizations requires an increased focus on cybersecurity. We’ve also seen a few reasons why Fortune 100 companies and government agencies around the world trust Anchore for their cloud-native environments. By implementing the right tools and policies, your organization can prevent threats and vulnerabilities as well as achieve desired levels of security and compliance, saving time and money prior to runtime. ### DevSecOps & Department of Defense, Separating Agile Hype From Legitimate Practice Agile software development has become a tried and true practice for delivering high quality and effective software in the modern age. Due to its effectiveness, agile development is not only being used by tech companies; it has also been picked up by the Department of Defense (DoD). With the advancement of technology to the forefront of the battlefield, the DoD has embraced the need to get effective software tools into the hands of the warfighters quickly and efficiently. With all the excitement surrounding agile, there are bound to be groups who claim to be agile while not actually following the agile methodology. In order to counteract this, the DoD has invested time and effort in identifying the indicators of who is faking agile practices. This effort ensures that software developed in the DoD is cutting edge and truly useful to the warfighter. The Defense Innovation Board has created a document that highlights some of their findings for those wanting more detail. Even though emphasis has been placed on moving quickly while developing software, the Department of Defense cannot compromise the security of their products. This is where DevSecOps comes in. The U.S. government has adopted a DevSecOps approach to its software development, putting an emphasis on speed and automation while also not compromising security. Groups like Platform 1 have been pioneering what it means to implement agile and DevSecOps in the government space, providing hardened environments to software developers that allow them to quickly develop software that serves a mission without compromising security. The benefits of modernizing development practices are usually described in concrete terms; increased productivity (faster delivery, decreased maintenance), increased resilience (fewer and shorter outages with a lower cost of issue resolution). Going to the next step and integrating security teams by using a DevSecOps approach provides even further benefits. Security issues that would require an entire cycle to resolve in a traditional workflow can be resolved earlier (and hence, faster) and the resulting software in production becomes more robust. The crucial concept here is that integrating security into the development and deployment of your apps at every stage, rather than treating security as an outside process that is imposed upon your production environment at the end of the pipeline, will pay massive dividends. Good security practices evolve over time, and DevSecOps approaches are quickly becoming understood as the new standard for not only modern enterprise applications but the Department of Defense as well. With the ever-changing software landscape that faces us today, it is crucial that software is delivered quickly, effectively and securely. ### Anchore Integration With Azure DevOps Has Officially Arrived Anchore is excited to announce the official release of our integration with Azure DevOps. Azure DevOps is a powerful tool from Microsoft that allows developers to build and release production software. This integration with Anchore allows developers to seamlessly integrate security into their Azure DevOps pipelines with very little effort. Anchore’s robust scanning brings not only vulnerability detection but policy enforcement for any application. All you need to do is add some simple YAML to your existing pipeline to create secure production software. Once the extension is installed into your organization, follow the steps below to get it added to any pipeline. Step 1. Review the Existing Build and Release Pipeline trigger:  - master  - dev variables:  image_name: "localbuild/testimage"  tag: "ci" stages: - stage: Build  displayName: Build application container  jobs:  - job: Build    displayName: Docker Build    steps:     - task: Docker@2      inputs:        command: build        repository: "$(image_name)"        tags: "$(tag)" - stage: Release  displayName: Release the application  ... Right now this pipeline is simply using the Docker task to build a local container and then it will publish the container in the release stage (omitted for simplicity). Step 2. Add the Anchore Scanner Plugin The Anchore scanner will scan a locally built container so it can provide a decision point early in the pipeline. All that needs to happen is add the Anchore scanner plugin to the pipeline right after the build stage so it can scan the local image. trigger:  - master   - dev variables:  image_name: "localbuild/testimage"   tag: "ci" stages: - stage: Build  displayName: Build and scan with Anchore  jobs:  - job: Build    displayName: Build and Scan     steps:    - task: Docker@2      inputs:        command: build        repository: "$(image_name)"         tags: "$(tag)"    - task: Anchore@0      inputs:        image: "$(image_name):$(tag)"        customPolicyPath: ".anchore/policy.json"         dockerfile: Dockerfile    - script: |        echo $(policyStatus)        echo $(billOfMaterials)        cat $(billOfMaterials)        echo $(vulnerabilities)        cat $(vulnerabilities)       displayName: Print scan artifacts In this example, a custom policy is provided alongside the code and it is referenced inside the scan so it can enforce the security required for production software. Step 3. Run the Pipeline Run the pipeline like normal and watch Anchore do its work scanning the local image. Once Anchore has scanned the image, the results of the policy evaluation will be displayed in the terminal along with a table of the discovered vulnerabilities. You can also reference the outputs of Anchore as pipeline variables so you can keep the scan results or policy evaluation in a database for further inspection. Step 4. Customize the Extension The extension can be customized fully to fit the needs of the pipeline, just reference the documentation on the extension page for more in-depth detail about the input parameters. It also does not require access to Anchore Engine or Enterprise. The plugin comes with all the capabilities of Anchore wrapped inside of it including ways to provide custom policies and change the behavior of the pipeline based on results. Azure DevOps is a powerful tool used by many development teams to build and publish production-grade software. With the integration of Anchore into the Azure DevOps environment, producing secure software becomes even more reliable. Anchore enforces consistent security policy for every run of the pipeline and will ensure that software that is not secure never makes it to production. ### Cloud Native Security For DevOps, Applying The 4 C's As Security Best Practice The past decade has seen a massive surge in terms of “cloud” technologies. What used to require on-premises hardware that took up large amounts of space, power and talent to operate efficiently, now can be operated by a small number of DevOps engineers and scaled up or down to meet demand and performance requirements. These new approaches to software deployment have fostered the cloud native principle which centers around the deployment of applications via containers. This new, sweeping technology has brought with it numerous benefits and many more considerations. And perhaps the most important consideration is security.  What are the Four C’s of Cloud Native Security? The concept of cloud native security is best expressed as four building blocks sometimes referred to as the four C’s: cloud, clusters, containers and code. Cloud The cloud is the base of the security layers. Developers cannot simply configure application security at the code level so steps must be taken at the cloud level. Each provider (Azure, GCP, AWS, DigitalOcean, etc.) all make recommendations for running secure workloads in their environments.  Cluster The next layer is the cluster layer. Kubernetes is the standard orchestration software. A cluster is considered secure when both the configurable components within the cluster and the software running in the cluster are secured.  Container Security And following the cluster layer is the container security layer, which is the most critical part of application deployment security which we will discuss in-depth later.  Code The final C is code. Building security into an application’s code is a part of the principle of shifting left or making application security a priority earlier in the application development lifecycle, which in the case of code, is as early as possible. Image source: Kubernetes.io Container Security & Vulnerabilities With the speed of adopting containers as the preferred deployment method, security is a large concern. A Tripwire study found that 60 percent of organizations experienced a container security incident and in this study, 94 percent of participating companies said that they had container security concerns. Each container is a virtual machine running imperfect software that may contain multiple vulnerabilities that the development team may be unaware of. When you consider that a large organization may be running hundreds or even thousands of containers in production, you begin to have a measure of the large amount of compounded risk that can exist inside a highly containerized infrastructure. The good news for development teams is that lots of work is happening in the area of container security in terms of establishing new best-practices and new technologies. Red Hat, Microsoft and many other vendors who publish common containers also publish CVE (common vulnerabilities and exposures) information ranked by severity. These findings show engineers the severity of the vulnerabilities that are present in packages in their containers so they can be mitigated before making their way to production.  This standardization of vulnerability findings has helped DevOps engineers to automate the entire security process. Before, humans needed to comb through code to find security threats and issues, but now scanning for these issues can become a stage in any code delivery pipeline allowing companies to deliver secure code faster than ever.  With the rapid adoption of containerization as the preferred software deployment choice, ensuring that those containers remain secure is one of the most important things that DevOps engineers can do to provide value to a company and one of the most important things companies can invest in to bring peace of mind to their users and anyone else who holds a stake in that software. ### Shift Left With A Real World Guide To DevSecOps A Free Resource: Shifting Security Left, A Real World Guide To DevSecOps Taking your team from DevOps to a DevSecOps approach brings different functions together to achieve better business outcomes, as well as reduce workload fatigue. Alignment across developer, security and operations disciplines depends more on implementing a culture of collaboration that embraces the talent and skillsets of all team members and less on introducing new technologies. In this new 24-page white paper, organizations will get real-world guidance and information to improve their current team structure by shifting security left to support a DevSecOps model. You’ll learn how to: Build an effective and collaborative shift left strategy, while achieving significant advantages across developer, security and operation teams. Recognize team strengths and core skillsets to enable focus, encourage domain expertise and minimize overall interruptions. Strengthen security strategy adoption to improve productivity, increase effective collaboration and overcome common challenges. An exploration of the history of shift left and how changing the development process from a layer placed on top of code to one that integrated in code is shared along with the recognized benefits afforded to organizations that adopt a DevSecOps approach. From planning and the software development cycle to automation and continuous integration, a pragmatic and comprehensive overview is provided to make more informed decisions before embarking on a DevSecOps journey. As a working practice inspired by and promulgated by developers, DevSecOps is quickly becoming the next DevOps. There is a confluence of tooling, appetite and mindshare that is pushing security into the fray and DevSecOps is quickly becoming more prominent as a rapidly growing practice across organizations small and large. Shifting security left has the capability to make developers allies of security, giving them the information they need as early as possible within the development feedback loop, and allowing them to identify issues early and rectify them before the code leaves development. This guide aims to empower organizations and their developers by delving into policy as code and establishing workflows that are able to deliver secure software faster and more efficiently. To learn more about shifting security left and to access this DevSecOps blueprint, please visit Shifting Security Left, A Real Guide To DevSecOps and download for free. ### The Open Source Economy & Modernizing Security To Reduce Vulnerability Risk In February 2020, the Linux Foundation released a report titled “Vulnerabilities in the Core,” a detailed analysis of the usage and security implications of open source software across the computing landscape. In today’s blog post, we will discuss some of the findings contained in the report, and explore how it pertains to the field of DevSecOps. By now, the advantages of open source software are well understood throughout the industry. Software development teams can achieve faster delivery times and reduce costs by building on top of existing open source software components that are available for anyone to use. In the age of faster development cycles and continuous integration, it is often essential to incorporate open source technologies into the development stream in order to achieve and maintain the engineering velocity required for success. However, the report demonstrates that open source software is not immune to the security considerations that affect non-open source software. In fact, the decentralized nature of the open source development model poses some unique security challenges, such as widespread use of outdated versions and exposure to known security vulnerabilities that go undetected and unpatched. So, how best to leverage the benefits from open source building blocks while protecting your organization from some of the risks and vulnerabilities? And how to do that in a way that does not slow down your development velocity? Let's explore. A Simple Build For Container Environments First, embrace the use of a container as the runtime environment for your application. Take a minimalist approach to the construction of the container, so that only the open source packages which your application requires are included. This will limit the number of potential vulnerabilities that the container may be exposed to. You will want to ensure that these open source packages are kept up to date over time. Container Image Scanning Automation Secondly, incorporate an automated container scanning tool that is integrated into your software development process. This is where Anchore Enterprise can help.  Anchore Enterprise plugs into your CI/CD pipeline so that each container is scanned according to a set of policies that you control, and this scanning is done in a way that is not only automated, it is done before the application’s container is deployed into a production environment. Incorporating the hardening process into the development cycle is the defining element of what we mean by DevSecOps. Anchore Enterprise conducts a deep inspection of the container and scans package versions against several vulnerability databases such as VulnDB and NVD. This mechanism ensures that your application’s container will not be exposed to any known security vulnerabilities at the time when it goes into production. Security Measures For Outdated Open Source But what about outdated versions of open source packages? Anchore Enterprise allows additional controls to be set so that the policies can be fine-tuned to your organization’s requirements. For example, certain packages or package versions can be explicitly prohibited from inclusion into the production environment via use of the policy blacklist. In this manner, you could ensure that outdated versions of open source packages could trigger a stop-build event, not because there are any known vulnerabilities but simply because those package versions are outdated and unmaintained. Perhaps most importantly, these security-enhancing mechanisms are performed in a highly automated manner, so that each of the open source components in your development stack are scanned and validated according to the policy automatically every time your application is built.  As a result, your software development teams can take advantage of the compelling advantages that these technologies have to offer, while also providing an automated, low-friction way of guarding against the risks inherent with the decentralized open source development model. ### Jenkins at Scale With Anchore Vulnerability Scanning & Compliance In this blog, we’ll see how we can configure Jenkins on our Kubernetes clusters to scale on-demand, allowing for hundreds or thousands of pipeline jobs per day. Additionally, we’ll see how easy it is to incorporate Anchore vulnerability scanning and compliance into these pipelines to make sure we aren’t deploying or pushing insecure containers into our environments. In this example, we are using Amazon’s EKS, but the same steps can be performed on any Kubernetes cluster. Requirements: A running Kubernetes cluster with Anchore Engine or Anchore Enterprise installed Step 1: Configure First, we need to create a Jenkins deployment, load balancer service, cluster IP service and cluster role binding. To make things simple, we can apply this jenkins-deploy.yaml file which uses the latest Jenkins image from DockerHub. kubectl apply -f jenkins-deploy.yaml Run a kubectl get for the jenkins-lb service that was created for us and navigate to the EXTERNAL-IP from your browser. You will now be at the Jenkins UI (keep in mind it can take some time for a load balancer to be provisioned and become active). kubectl get svc jenkins-lb NAME TYPE CLUSTER-IP EXTERNAL-IP jenkins-lb LoadBalancer 10.100.141.50 aaaceb153e97241fab81d9d4109440c-1811878998 .us-east-2.elb.amazon.com Now that we are at the Jenkins UI, go to Manage Jenkins > Configure Global Security, check the “Enable proxy compatibility” box under CSRF Protection and click “Save.” Checking this box allows us to fix an extremely annoying crumb error. Once that’s complete, we can go to Manage Jenkins > Manage Nodes and Clouds and click the gear icon on the far right of the master node row. Set the “# of executors” to zero and click “Save.” The master instance should only be in charge of scheduling build jobs, distributing the jobs to agents for execution, monitoring the agents and getting the build results. So, since we don’t want our master instance to execute builds, we are setting the executors to zero. From Manage Jenkins > Manage Plugins, install the Anchore Container Image Scanner plugin, Kubernetes plugin and Pipeline plugin. Once those have installed, go to Manage Jenkins > Configure System and scroll down to the Anchore Container Image Scanner settings. Find the “Engine URL” using kubectl describe for the Anchore Engine API pod and enter your Engine Username and Engine Password (default Username: admin; default Password: foobar; default port: 8228), then click “Save.” Don’t forget the http:// and /v1. Now go to Credentials > System > Global credentials (unrestricted) > Add Credentials, add a “Kubernetes Service Account” credential, and click “OK”. This will allow the Jenkins Kubernetes plugin to manage pods in the default namespace of the cluster using the cluster role binding that we created earlier: Next, we need to configure the Kubernetes plugin. Go to Manage Jenkins > Manage Nodes and Clouds > Configure Clouds and add a Kubernetes Cloud. If you’re using EKS, retrieve the API server endpoint from the AWS EKS cluster dashboard and paste it into the “Kubernetes URL” field (other platforms may have different names or locations for the API server endpoint). Add the Kubernetes Service Account credential we just created, test your connection, and enter the Jenkins URL using kubectl describe for the Jenkins Master pod that was created for us earlier. Don’t forget the http:// and :8080. Below that, we must create a Pod Template for our Jenkins Agents. Enter a Name and Label, set the Usage to “Use this node as much as possible,” create a Container Template using the Docker image jenkins/inbount-agent, then click “Save.” We now have our Jenkins Master running, Anchore plugin configured and Kubernetes plugin configured. All that’s left to do is create our pipeline jobs and test! Step 2: Test Create a pipeline job and scroll down to its Pipeline configuration settings. Paste the contents from this Jenkinsfile into the Pipeline script, uncheck the “Use Groovy Sandbox” box, and click “Save.” A traditional Jenkinsfile may involve building an image, running QA tests, scanning with Anchore and then pushing to a registry, but for this example, we’re just showing the “Analyze with Anchore plugin” stage. Create some more copies of this pipeline job using any images you want. A typical workflow may involve triggering these pipelines from a git push or merge request, but we’ll just trigger them manually for the sake of testing by using the clock icon on the far right of each item’s row. We’ll see our jobs in the build queue and our Jenkins Agents spinning up in the build executor status. If we watch our pods, we’ll see the Jenkins Agents pending, creating, running our pipeline and then terminating. If we take a look at our test2 pipeline and select the newly-created “Anchore Report,” we can see that httpd:latest was analyzed and the result was fail due to eight high vulnerability CVEs (common vulnerabilities and exposures). Conclusion We now have the ability within our cluster to dynamically scale Jenkins Agents to run our pipeline jobs. We’ve also seen how to integrate Anchore into these pipeline jobs to analyze containers and prevent non-compliant ones from entering our production environment. ### Cryptocurrency Mining Attacks & Anchore Scanning, A Line of Defense Cryptocurrency Mining Attacks Shifting Left Recently, there has been a flurry of cryptocurrency mining attacks hitting various entities around the globe ranging from celebrity Twitter accounts to customers running workloads across Kubernetes clusters. For today, we'll ignore the celebrity accounts and focus on how Anchore can be used to protect your organization from cryptomining attacks. Back in April, Microsoft did an excellent job providing details into one of these attacks that leveraged a specific cryptomining image that currently has more than 10 million pulls on Docker Hub! The central premise is straightforward, “Allow only trusted images: Enforce deployment of only trusted containers, from trusted registries.” But what happens when using trusted images isn’t enough? First, let’s set up a list of trusted images using Anchore, explore why whitelisting/blacklisting images is a good start to protecting your organization and then discuss how Anchore can amplify your security by creating STOP actions in your CI/CD pipeline using in-depth inspection of the container image itself. Whitelisting/Blacklisting Cryptocurrency Mining Images To cover all of the bases, let’s start by building out a thorough blacklist of some commonly used mining images you can find on Docker Hub. Using Anchore Enterprise, navigate to Policy Bundles > Whitelist/Blacklist Images. From here you can add the specific image you would like to blacklist. In the end, you might have something that looks like this: Additionally, let’s add your approved images to the whitelist. Building off a set of approved and hardened images is a very healthy development practice for teams to adopt. This way Anchore can flag any unapproved images that may be passed through your pipeline. Ultimately, whitelisting is far more powerful, but there is no harm in doubling down here. I went ahead and set up an Ubuntu image on my whitelist below: This is effective because it will prevent one attack scenario, which is an attacker pulling down any of the hundreds of mining images from Docker Hub and running them inside your environment. However, an attacker can easily maneuver around an organization’s whitelist/blacklist. For example, an attacker could always build a custom miner using your approved base image and a series of Docker instruction commands. That is a terrible scenario for an organization to experience, but it could happen if an insider threat or attacker decides to make a few quick crypto-bucks all while using your own approved container images and K8’s infrastructure. Monitor the Instructions in the Dockerfile Let’s take a look at the build steps of the kannix/monero-miner image that was referenced in the Microsoft report and demonstrate how Anchore can detect a threat even if the attacker was building using an approved image or is using a non-blacklisted image. This image is created in a multi-stage build, using FROM ubuntu:latest as the version. Thus, even if we had our whitelist above, the attacker could still build this image successfully using our whitelisted image FROM ubuntu:20.04. To prevent this, Anchore can monitor subsequent lines to detect a Monero mining image is being built. Anchore Enterprise policy does just that. The second RUN command features an apt-get update and apt-get install which is prohibited in Anchore policy bundle using the Dockerfile Gate, and Instruction trigger. This generates an automatic STOP action in Anchore and prevents this from moving further in your pipeline. Failing this check will prevent your image from progressing further in the selected policy bundle. For the sake of this post, let’s see what other harmful instructions generate a STOP action and alert using Anchore. Over the next few lines, the image performs a ‘RUN git clone’ to pull down the build scripts and necessary files for xmrig. This would generate a STOP action in Anchore because it violates Anchore’s Transfer Protocol Checks that are applied to every image. As seen below, Anchore monitors the RUN, FROM, COPY and ADD instructions for external requests using HTTP, HTTPS, FTP and SFTP protocols. Next, Anchore’s cryptomining checks have generated yet another STOP action because Monero already exists as a blacklisted user using the effective user check on the Dockerfile instruction as seen below. Immediately after setting the effective user, they set the working directory to /home/monero. Similar to setting the user as Monero, setting the working directory /home/monero is pretty common in Monero images. Anchore’s cryptomining checks can look for that by monitoring the Dockerfile Instruction WORKDIR as seen here: In the last few crypto mining checks, we can monitor for xmrig itself. I did an attribute match and name match on the file using Anchore which generated two additional stop actions. Lastly, Anchore generated a check around the ENTRYPOINT [“./xmrig”]. After all of these checks are in place your compliance tab of Anchore Enterprise should look a bit like this: Conclusion Cryptocurrency mining attacks will continue to evolve. In this post, we’ve demonstrated the flexibility of Anchore policy enforcement to provide contextualized security enforcement to the user. It’s important that organizations take steps to increase their security posture further to the left to prevent these images from being deployed into a production Kubernetes cluster. DevSecOps is centered on the premise that security actions must run at the same speed and scale as development and operations. Tools like Anchore Enterprise provide organizations with a new line of defense by providing deep image inspection and policy-based enforcement mechanisms that monitor for security threats before they enter the development pipeline. ### Troubleshooting Basic Issues with Anchore As with any application, after deploying Anchore you may run into some common issues. In this post, we’ll walk through troubleshooting Anchore's more common issues we’ve seen to provide you with a better understanding of their cause and how to solve them. Verifying Services and System Health When troubleshooting in Anchore, your first step should start with viewing the event log, then the health of Anchore services and lastly looking into the logs. The event log subsystem provides users with a mechanism to inspect asynchronous events occurring across various Anchore services. Anchore events include periodically triggered activities such as vulnerability data feed sync in the policy_engine service, image analysis failures originating from the analyzer service and other informational or system fault events. The catalog service may also generate events for any repositories or image tags that are being watched, when Anchore Engine encounters connectivity, authentication, authorization or other errors in the process of checking for updates. The event log is aimed at troubleshooting the most common failure scenarios (especially those that happen during asynchronous operations), and to pinpoint the reasons for failures that can be used subsequently to help with corrective actions. To view the event log using the Anchore-CLI: `anchore-cli event list` You can get more details about an event with: `anchore-cli event get ` Each Anchore service has a health check and reports its status after it’s been successfully registered. To view Anchore system status using the Anchore-CLI: `anchore-cli system status` The output will give you a status for each Anchore service to verify that they’re up and running. One of the most helpful tools in troubleshooting issues in Anchore is to view the logs for the respective service. Anchore services produce detailed logs that contain information about user interactions, internal processes, warnings and errors. The verbosity of the logs is controlled using the log_level setting in config.yaml (for manual installations) or the corresponding ANCHORE_LOG_LEVEL environment variable (for Docker ompose or Helm installations) for each service. The log levels are DEBUG, INFO, WARN, ERROR and FATAL, where the default is INFO. Most of the time, the default level is sufficient as the logs will contain warn, error and fatal messages as well. However, for deep troubleshooting, increasing the log level is recommended to DEBUG in order to ensure the availability of the maximum amount of information. Anchore logs can be accessed by inspecting the Docker logs for any Anchore service container using the regular Docker logging mechanisms, which typically default to displaying to the stdout/stderr of the containers themselves, or by the standard Kubernetes logging mechanisms for pods. The logs themselves are also persisted as log files inside the Anchore service containers. You will find the service log files by executing a shell into any Anchore service container and navigating to /var/log/anchore. For more information on where to begin with troubleshooting, take a look at our Trouble Shooting Guide. Feed Sync When Anchore is first deployed, it synchronizes vulnerability feed data with upstream feeds. During this process, vulnerability records are stored in the database for Anchore to use for image analysis. The initial sync can take several hours as there are hundreds of thousands of feed records, but subsequent syncs typically don’t take as long. While the feeds are syncing, it’s best to let the process completely finish before doing anything else as restarting services may interrupt the sync process, requiring it to be re-run. This is a good time to familiarize yourself with Anchore policies, the Anchore-CLI subsystem and other feature usages. The time it takes to successfully sync feeds is largely dependent upon environmental variables such as memory and CPU allocation, disk space and network bandwidth. The policy engine logs have information regarding the feed sync, including task start and completion, records inserted into the DB or information around a failed sync. The status of the feed sync can be viewed by using the Anchore-CLI system feeds subsystem: `anchore-cli system feeds list` Should the sync be interrupted or one of the feeds fail to sync after all other feeds have completed a manual sync can be triggered: `anchore-cli system feeds sync` Feed data is a vital component for Anchore. Ensuring the data is synchronized and up-to-date is the best place to start in order to have a fully functional and accurate Anchore deployment. Analysis Result Questions or Analysis Failing Once your Anchore deployment is up and running, performing image analysis can sometimes lead to an image failing to analyze or questions about the analysis output around false positives. When these occur, the best place to begin is by viewing the logs. Analysis happens in the analyzer pod or container (depending on deployment method), and the logs from the API and analyzer will shed light on the root cause of a failure to analyze an image. Typically, analysis failures can be caused by invalid access credentials, timeouts on image pulls or not enough disk space (scratch space). In any case, the logs will identify the root cause. Occasionally image analyses will contain vulnerability matches on a package that may not seem to be valid, such as a false positive. False positives are typically caused by two things: Package names reused across package managers (e.g. a gem and npm package with the same name). Many data sources, like NVD, don’t provide sufficient specification of the ecosystem a package lives in and thus Anchore may match the right name against the wrong type. This is most commonly seen in non-OS (Java, Python, Node, etc.) packages. Distro package managers installing non-distro packages using the application package format and not updating the version number when backports are added. This can cause a match of the package against the application-package vulnerability data instead of the distro data. The most immediate way to respond to a false positive is to create a rule in the Anchore policy engine by adding it to a whitelist. For more information on working with policy bundles and whitelists, check out our Policy Bundles and Evaluation documentation. Pods/Containers Restarting or Exiting Perhaps the most common issue we see at Anchore is the Anchore service pods or containers restarting, exiting or failing to start. There are multiple reasons that this may occur, typically all related to the deployment environment or configuration of Anchore. As with any troubleshooting in Anchore, the best place to start is by looking at the logs, describing the pod or by looking at the output from the Docker daemon when trying to start services with Docker Compose. One common issue that causes a pod or container to fail to start has to do with volume mounts or missing secrets. For Anchore Enterprise, each service must have a license.yaml mounted as a volume for Docker Compose deployments and a secret containing the license.yaml for Kubernetes deployments. For Anchore Engine, the license is not necessary, however mounting configuration files and other files such as SSL/TLS certificates may result in invalid mounts. One of the most common errors that we see when deploying Anchore has to do with memory and CPU resource allocation. Anchore will typically operate at a steady-state using less than 2 GB of memory. However, under load and during large feed synchronization operations (such as the initial feed sync), memory usage may burst above 4GB. Anchore recommends a minimum of 8GB for each service, for production deployments. Be sure to review our requirements before deploying Anchore to confirm there are enough available resources for Anchore to operate without a hitch. Conclusion For more information, take a look at our documentation and FAQ’s. We hope that these issues aren’t ones you encounter but with a little planning and troubleshooting Anchore know-how, you’ll be up and analyzing in no time. ### Anchore and Azure DevOps: Part 2 Previously in the Part 1 Blog, I showed you how to use Anchore to perform a stateful scan in Azure DevOps using Anchore Engine or Anchore Enterprise. This method works great, but what if you don’t have a running instance of Anchore? What if you just want to run a scan, gather the results, and then move on? Anchore (being the versatile tool it is) has that capability too! Azure Starter Pipeline Remember our simple Azure DevOps pipeline from my previous post: trigger: - master resources: - repo: self stages: - stage: Build displayName: Build and push stage jobs: - job: Build displayName: Build pool: vmImage: ‘ubuntu-latest’ steps: - task: Docker@2 displayName: Build and push an image to container registry inputs: command: buildAndPush repository: jpetersenames/simpleserver dockerfile: Dockerfile containerRegistry: production tags: | $(Build.BuildId) All this pipeline does is build an image and push it to our production registry every time code is pushed to our repository. We want to add security to our pipeline using Anchore, but we don’t have the resources to run a staging registry as well as an instance of Anchore. Perhaps you just want to try out Anchore in your pipeline to see how the compliance scanning works. This is where the inline scan offered by Anchore comes in. You can read more about the tool in the Anchore documentation, but I want to show you how you can seamlessly integrate Anchore into your pipeline with almost no dependencies. Take a look at the pipeline below. You can see that we no longer need a staging registry. Instead, we just build a local image using BuildKit so we have all the nice features; suggested but not required for Anchore. Once we have our local image, we can grab the inline scan script that is publicly available through Anchore. Using the inline scan script and container, we can perform a compliance scan on a locally built image without any outside dependencies. Pretty cool! trigger: - master resources: - repo: self variables: - name: localImage value: 'local/simpleserver:$(Build.BuildId)' - name: productionImage value: 'production/simpleserver:$(Build.BuildId)' stages: - stage: Build displayName: Build and push stage jobs: - job: Build displayName: Build pool: vmImage: 'ubuntu-latest' steps: - script: | DOCKER_BUILDKIT=1 docker build -t $(localImage) -f Dockerfile . displayName: Build the local image - script: | curl -s https://ci-tools.anchore.io/inline_scan-latest | bash -s -- \ scan -b .anchore/policy.json -d Dockerfile -f -r $(localImage) displayName: Anchore Security Scan - script: | docker tag $(localImage) $(productionImage) displayName: Tag the image as production - task: Docker@2 displayName: Push the image to the production registry inputs: command: push repository: jpetersenames/simpleserver dockerfile: Dockerfile containerRegistry: production tags: | $(Build.BuildId) You can see that this pipeline is shorter than our previous pipeline that used anchore-cli and an instance of Anchore. The scan is the exact same as using any other instance of Anchore and it will provide the same results. Inline scan can also be loaded with any policy bundle you want to audit your image as I have done here using the -b option. You can also provide the -f option which will fail the pipeline when the policy scan returns a ‘fail’ result. This will provide output similar to what you see below where you are provided with the ‘fail’ result as well as which gates in the policy bundle were violated. You can also see at the top of the output in the terminal that some reports were generated. These are JSON files that contain the contents Anchore found inside the image as well as a list of the vulnerabilities that were detected. Overall Anchore’s inline scan functionality is a powerful way to integrate security into your Azure DevOps pipeline. It allows you to run a full Anchore compliance scan with no dependencies. This is great for environments that are air-gapped or if it doesn’t make sense to keep a staging registry or a running Anchore instance. ### Why We Recommend Helm for Production Instead of Docker Compose Anchore provides a convenient quick-start using both Docker Compose and Helm to spin up each of its services. Docker Compose may have some advantages over Kubernetes for those new to container architectures, namely the smaller learning curve required, as deployments grow, Kubernetes is a more robust solution to handle scaling, high availability, and multi-node clusters whether in cloud, hybrid, or on-prem environments. In this blog, we’ll outline some pitfalls of deploying Anchore in a production environment using Docker Compose and why we recommend deploying on Kubernetes via Helm. Competition Over Resources The biggest issue with using Docker Compose as a deployment method for Anchore at a production-scale level is that Docker Compose is intended to run on a single host. Anchore services can be resource-intensive when performing actions such as feed synchronization and image analysis. Herein lies the issue: when using Docker Compose on a single host, the containers compete for the same underlying resources including memory, CPU, and disk I/O. By spreading services across a cluster of hosts, fewer containers may run on the same host, reducing the competition over resource allocation. Difficulty Scaling Docker Compose While it’s not impossible to scale with Docker Compose, it’s not as simple as it is using Kubernetes. Since Docker Compose is intended to run on a single host, there may be issues with conflicting ports, log sizes, and service communication. Within Anchore, the number of images analyzed concurrently is dependent on the number of analyzers deployed. Having multiple CI/CD pipelines is a common theme that we see, making the ability to scale analyzers a necessity to increase analysis throughput. Effort Required to Upgrade With Docker Compose, upgrading Anchore services requires modifying the docker compose.yaml, and then relaunching the containers. Should something be incorrect or the deployment needs to be rolled back, the containers would need to be stopped, reverted back to their previous versions, and then redeployed. Kubernetes and Helm provide an easy upgrade method, as well as a rollback should it be necessary. Conclusion Overall, Kubernetes is a more production-ready container orchestration platform than Docker Compose. There are multiple mature products out for monitoring Kubernetes clusters, it better handles secrets, as well as integrates easily with visualization and metrics tools. If you’re unsure about where to start when scaling Anchore, take a look at our Scanning in the Millions blog. To get started with Anchore for either Helm or Docker Compose, check out our installation guide. ### Anchore and Carahsoft When you want to sell to the government, it behooves you to pick your partners wisely—and it’s no accident that Anchore chose to work with the largest trusted government IT solutions provider, Carahsoft Technology Corporation, to distribute Anchore's products to public sector customers. See press release: Carahsoft and Anchore launch partnership in public sector This is a critical time for DevSecOps in government IT. The federal government, along with state and local government agencies and higher education institutions, are looking to new technologies such as containers, Kubernetes, CI/CD pipelines and advanced development methodologies such as DevSecOps to help drive their need for speed. Anchore is a key part of the new technology stack in DevSecOps that can help bring government agencies into the 21st century with increased velocity and agility. Moreover, modern software approaches are designed to dramatically improve services while also saving big bucks for government software factories and the digital transformation they are driving. You need look no further than the cutting edge work being done by US DoD’s DevSecOps initiatives such as the USAF’s Platform One and Iron Bank. Both of which, Anchore is a key component. That's why we recently received a SBIR Phase II contract from the United States Air Force for our work in software container hardening. The Importance of Partners in Selling to Government Customers Most software vendors who do business with the government work through partners and Anchore is no exception. In fact, our public sector sales strategy is partner-centric. With our newly announced partnership with Carahsoft, nearly all of our government business will flow through Carahsoft as our master government aggregator. The Carahsoft partnership signals that Anchore is “open for business” for government, higher education and state and local customers. Carahsoft is able to generate unique volume and velocity for its partners’ sales efforts. Its phenomenal sales organization has the resources to address virtually all RFPs and other opportunities in the public sector space and its marketing/demand-gen and operational capabilities are second to none. The Importance of Real Solutions for Government Customers Carahsoft has been instrumental in building successful public sector businesses for several leading software vendors, from Red Hat, Adobe, VMWare, Google, and AWS, as well as many others. From its vast portfolio of suppliers, Carahsoft is able to create the right solution to meet the needs of the mission. Carahsoft’s dedicated open source practice is a natural home for Anchore. Working with Carahsoft represents an exciting new chapter in Anchore's channel business sales model, and we’re thrilled to be bringing our technology into Carahsoft’s solution-centric motion. Along with Carahsoft and its ecosystem of value-added partners and suppliers, Anchor’s public sector sales team is working hard to accelerate cloud-native development efforts in the government sector. We look forward to the chance to jointly help government agencies and institutions utilize DevSecOps to deliver better outcomes for their customers—the citizens of the United States. ### Anchore and Azure DevOps As I’m sure you have read throughout the previous blogs, Anchore is a very versatile tool that brings security to your containerized workflow. It can be integrated into any CI/CD platform for quick and easy security scans. Today I will show you how to integrate it into Azure DevOps, a useful tool offered by Microsoft. Starter Azure Pipeline Go ahead and take a look at this simple Azure DevOps pipeline: trigger: - master resources: - repo: self stages: - stage: Build displayName: Build and push stage jobs: - job: Build displayName: Build pool: vmImage: ‘ubuntu-latest’ steps: - task: Docker@2 displayName: Build and push an image to container registry inputs: command: buildAndPush repository: jpetersenames/simpleserver dockerfile: Dockerfile containerRegistry: production tags: | $(Build.BuildId) Whenever the code is pushed to this repository, it will kick off this pipeline to build a docker image and push it to our final registry. This is great, but we want to add a security scan for our containers before we push them to the final registry. What better tool to use for this than Anchore! Adding Security So what do we need to do to add Anchore to our pipeline? There are a few ways that you can use Anchore when it comes to integrating it into a pipeline. I am going to show you how to use the cli tool to access a running instance of Anchore Engine from inside your Azure DevOps pipeline. You will need to make sure you have a few things before you start using Anchore: A running instance of Anchore Engine or Anchore Enterprise A staging registry for pre-scanned images To set up an instance of Anchore Engine or Anchore Enterprise, please refer to our quick start documentation. I am going to use an Azure Container Registry as my staging registry. To create the registry go ahead and use your favorite method of creating Azure Resources. I used terraform: provider "azurerm" { version = "=2.0.0" features {} } resource "azurerm_resource_group" "blog" { name = "blog" location = "West US" } resource "azurerm_container_registry" "blog" { name = "anchoreStaging" resource_group_name = azurerm_resource_group.blog.name location = azurerm_resource_group.blog.location sku = "Standard" admin_enabled = true } Once you have your registry you need to set up a service connection so you can access it easily from inside your pipeline. Go ahead and set up a service connection with a Docker Registry, once in the next blade select Azure Container Registry. Authenticate your Azure account and then select the anchoreStaging registry you just created. Alright, now that you have your staging registry you must give Anchore the proper permissions to pull from it. Follow the steps in our documentation if you’re using an Azure Container Registry like I am. These instructions will allow Anchore to pull images from registries that aren’t publicly accessible. Now that all the configuration has been done for your running instance of Anchore, we can add the tooling to our pipeline. We will need our usual information to access our Anchore instance (URL, username, and password); however, we don’t want to expose our password. To keep our password secret, use a variable group in Azure DevOps and make sure to lock the password variable. Now we are all set to add Anchore to our Azure DevOps pipeline. Take a look at the pipeline code below. We must import the variable group that we created which contains our secret password, as well as our username and the URL for our Anchore instance. Note: The Build and Production stages have been left out for brevity. trigger: - master resources: - repo: self variables: - name: stagedImage value: 'anchorestaging.azurecr.io/simpleserver:$(Build.BuildId)' - name: productionImage value: 'production/simpleserver:$(Build.BuildId)' # Use a variable group to store the Anchore credentials - group: anchoreCredentials stages: - stage: Build # Same build stage as previously shown - stage: Security displayName: Security scan stage dependsOn: Build jobs: - job: Security displayName: Security pool: vmImage: 'ubuntu-latest' steps: - script: python -m pip install --upgrade setuptools wheel anchorecli displayName: Install Anchore CLI # Use the variables from the anchoreCredentials variable group - script: | export PATH=$PATH:/home/vsts/.local/bin export ANCHORE_CLI_USER=$(anchore_user) export ANCHORE_CLI_PASS=$(anchore_pass) export ANCHORE_CLI_URL=$(anchore_url) anchore-cli image add $(stagedImage) --dockerfile=Dockerfile anchore-cli image wait $(stagedImage) anchore-cli image vuln $(stagedImage) all anchore-cli evaluate check $(stagedImage) displayName: Anchore Security Scan - stage: Production # Push the image to your production registry and deploy it however you want You can see here that we have added a Security stage to our pipeline. Inside this stage, we install the anchore-cli tool using the python pip module. Since we are using the Ubuntu agent offered by Azure DevOps, the anchore-cli tool will install in the .local directory. This directory isn’t in our path by default so we must add it to our path along with configuring the credentials to access our Anchore instance. Once anchore-cli has been configured, you can use it however you like. I have chosen to simply add an image and wait for it to scan. Once it has been scanned, I print out all the vulnerabilities and get the policy evaluation result. The evaluate check command will fail the pipeline if the policy evaluation returns a ‘fail’ result. Summing Up To sum it all up, it is very easy to integrate strict security into a new or existing Azure DevOps pipeline. As you can see, it only took a few lines of yaml to add a security scan that will keep insecure or non-compliant containers from reaching our production environment. Anchore is a very versatile tool, and this is just one of the ways it can be deployed into a pipeline. This method uses a running instance of Anchore Engine or Anchore Enterprise to scan the staged images. This provides a stateful scan which means users can grab the results after the fact to create reports and provide justifications for passed or failed scans. Security is a requirement when developing modern production-grade software. Using Anchore and Azure DevOps, software developers can quickly and easily integrate security into their daily workflow to ensure only high-quality and secure software ever makes it to production. ### Anchore and Jenkins Pipeline Configuration In this blog, we’ll integrate Anchore Engine into a Jenkins pipeline to prevent vulnerable container images from entering our production environment. We’ll install Docker, Anchore Engine, and Jenkins on a single node (with Ansible) so we can then configure the Anchore plugin into our Jenkins jobs. In this example, we use AWS and a GitLab registry, however, a similar approach can be taken for any platform or registry. Anchore Engine can also be installed on Kubernetes and configured on a separate node from your CI/CD tools. See our docs for more info. Requirements AWS account GitLab account Step 1: Project Setup To get started, let’s sign in to GitLab and create a new group. We’ll need a group so we can fork the repo associated with this post into a GitLab namespace. If you already have an available namespace, you can use that. Once we’ve created a group, let’s fork this repo, clone the forked project to our local machine, and cd into it. git clone cd jenkins-demo In the next step we’ll install Ansible, but for now let’s install Boto, a Python interface that enables Ansible to communicate with the AWS API. After verifying that we have Python and pip installed, we’ll run the following command: pip install boto boto3 For the sake of simplicity, we’ll use command-line flags with our Ansible playbook. Let’s paste our AWS credentials and set the environment variables we need for those flags: export AWS_ACCESS_KEY_ID= export AWS_SECRET_ACCESS_KEY= export AWS_SESSION_TOKEN= export AWS_PRIVATE_KEY= # e.g. ~/.ssh/mykey.pem export AWS_KEYPAIR_NAME= # e.g. mykey export AWS_REGION= # e.g. us-east-2 export REGISTRY= # e.g. registry.gitlab.com//jenkins-demo export REGISTRY_USER= export REGISTRY_PASS= export ANSIBLE_HOST_KEY_CHECKING=False export MY_IP=$(curl -s icanhazip.com) We now have the files and variables needed to set up our infrastructure and configuration. Let’s see how we can use Ansible to do this in the next step. Step 2: Infrastructure Setup If you are unfamiliar with Ansible, check out the link to the quickstart video. Afterward, be sure to install Ansible on your appropriate machine (if you haven’t already). In my case, I am using macOS with Python 3.8 and pip installed, so I ran: pip install --user ansible Once Ansible is installed, let’s change into the ansible directory so we can run some commands: cd ansible In this directory, we have our ansible.cfg file along with our plays. There is a main.yml play that executes our provisioning, installing, and configuring plays in the correct order (we will not need an inventory file for this demo). Let’s create our infrastructure now: ansible-playbook main.yml \ --private-key=$AWS_PRIVATE_KEY \ -e key_name=$AWS_KEYPAIR_NAME \ -e region=$AWS_REGION \ -e registry=$REGISTRY \ -e registry_user=$REGISTRY_USER \ -e registry_pass=$REGISTRY_PASS \ -e my_ip=$MY_IP It will take several minutes for our plays to finish executing all of their tasks. Here is a brief overview of what our playbook is doing: Creating an AWS security group with our machine as the only whitelisted address for ingress (hence the MY_IP variable) Creating an AWS EC2 instance (Ubuntu / t2.xlarge) attached with the security group we just created Installing Docker, Docker Compose, Anchore Engine, and Jenkins on the EC2 instance Adding our registry to Anchore Engine so we can scan images and enforce policy (hence the REGISTRY variables) Note - After you have finished following this post, you can tear down all infrastructure by running: ansible-playbook destroy.yml \ --private-key=$AWS_PRIVATE_KEY \ -e region=$AWS_REGION Now that we have our infrastructure in place, software installed, and a registry added to Anchore Engine, we can move on to setting up our project with the Jenkins UI! Step 3: Jenkins Configuration In this step, we will access Jenkins, configure the Anchore Container Image Scanner plugin, create a credential so Jenkins can access GitLab, and configure a job to use our Jenkinsfile. Within the AWS Management Console, go to the EC2 service and search for our “jenkins-demo” instance. We’ll navigate to the instance’s Public IP on port 8080 (the default Jenkins port) from the browser on our local machine (an ingress rule for port 8080 from our local machine has already been created for us). We should see the Jenkins login page: To retrieve your Jenkins administrator password, we’ll SSH into the instance from our local machine (an ingress rule for port 22 from our local machine has already been created for us) and run: sudo docker logs jenkins Copy the Administrator password from the logs, paste it into the prompt on the Jenkins login page, and click Continue. Select Install Suggested Plugins on the next page. Create a First Admin User and click Save and Continue. Confirm the Jenkins URL on the following page, click Save and Finish, then Start using Jenkins. We should see the Jenkins Dashboard: We will now install the Anchore Container Image Scanner plugin and configure it to access Anchore Engine. On the left-hand side of the page, go to Manage Jenkins > Manage Plugins, click the Available tab, search for “Anchore”, select the Anchore Container Image Scanner Plugin, and click Install without restart: After installing the plugin, go to Manage Jenkins > Configure System, and scroll down to the Anchore Container Image Scanner Plugin settings. We’ll paste our EC2 instance’s Public DNS and set the port to 8228 (the default Anchore Engine port). Enter the Engine Username as “admin” and Engine Password as “foobar” (the default Anchore Engine authentication) then click Save: We will now create a global credential so our Jenkins job can access the Jenkinsfile from our GitLab repo and registry. On the left-hand side of the page, go to Credentials > System, then click “Global credentials (unrestricted)” and Add Credentials. There are several different kinds to choose from, but in this demo we will use Username with password. We’ll add our GitLab username and password and set the ID of the credential to “gitlab-registry” (we use this ID in our Jenkinsfile) then click OK: The last part of this step is to configure a Jenkins job to use the Jenkinsfile from our GitLab repo. From the Jenkins Dashboard, select create new jobs, name the item, select pipeline job, and click OK (the Anchore Container Image Plugin also supports freestyle jobs, but we’ll use a pipeline job for this demo). We are then prompted by our job’s configuration settings. Scroll down to the Pipeline settings, change ‘Definition’ to Pipeline script from SCM, select Git as the ‘SCM’, and paste your forked repository’s URL. Select the credential that we just created and click Save: Step 4: Test In order to test our pipeline, we’ll need to make sure our Jenkinsfile is ready. Change lines 5 and 6 of the Jenkinsfile to use your repository and registry. Once you’ve pushed changes to GitLab, head back to Jenkins and Open Blue Ocean on the left, then run the pipeline job we just created. Our Jenkinsfile builds from the Dockerfile in our repo, which is then analyzed by Anchore Engine. In this example, we are simply analyzing debian:latest and the default Anchore policy issued a PASS, thus our pipeline continues to the next stage: If we change the Dockerfile to build from node:13.14 instead, we’ll see the pipeline fail, preventing us from continuing to the next stage such as deploying the image into production: Heading back to Jenkins classic UI, we can see there is now an “Anchore Report” associated with our Jenkins job. If we click on the report, we’ll find out that the node:13.14 image triggered 12 stop actions in relation to HIGH vulnerabilities that did not comply with the default policy: Step 5: Customize and Take Action We now have Anchore Engine integrated with a Jenkins pipeline! We can add more registries and customize our policies by connecting to our EC2 instance via SSH. For more information on using registries and policies with Anchore Engine, see: Configuring Registries Working with Policies Regardless of which CI/CD tool, cloud platform, source code manager, or registry you’re using, it is critical to prevent bad actors from gaining access to your containers and clusters. With new vulnerabilities being discovered every day, hackers are constantly looking for ways to breach the attack surface and inflict costly damage. Anchore Engine is a great first step towards container security, policy, and compliance. However, if you or your company is interested in a more comprehensive commercial platform, check out Anchore Enterprise and find out why organizations like the U.S. Department of Defense have made Anchore a requirement in their adoption of DevSecOps. ### Anchore and GitLab Pipeline Configuration In this blog, we will add Anchore security and compliance to a GitLab container pipeline. We will be using AWS and a GitLab registry, however the same approach can be taken for any platform or registry. Requirements AWS account GitLab account Step 1: Project Setup To get started, let’s sign into GitLab and create a new group. We’ll need a group so we can fork the repo associated with this post into a GitLab namespace. If you already have an available namespace, you can use that. Once we’ve created a group, let’s fork this repo, clone the forked project to our local machine, and cd into it. git clone cd gitlab-demo Next, we will need a GitLab Runner to execute our .gitlab-ci.yml file. So, back in GitLab, within our forked repo, let’s navigate to Settings > CI/CD and expand the Runners section. In this guide, we will be using a specific runner so Anchore Engine and our GitLab Runner can live on the same machine. Underneath “Shared Runners”, disable shared Runners for the project (if enabled). Lastly, underneath “Set up a specific Runner manually”, copy the registration token. We will use this token in the next step. Step 2: Infrastructure Setup In order to speed up the installation process, we will use Infrastructure-as-Code. If we inspect the terraform.tf file in our repo, we will see that it performs several tasks for us: Creates an AWS EC2 instance (Ubuntu AMI / t2.xlarge / 16 GiB storage) with a security group that allows ssh into the instance from our local machine only Installs and starts Docker Installs and runs Anchore Engine via Docker Compose (Anchore Engine can also be deployed on Kubernetes; see our docs for more info) Adds our registry to Anchore Engine Installs the Anchore CLI Installs, registers, and starts our GitLab Runner as a Shell Executor All of this can be done by exporting 8 simple environment variables and running a few basic commands with Terraform. If you haven't already, install Terraform now. Let’s start by pasting our registration token from the previous step and setting the remaining required environment variables from our local machine. export TF_VAR_gitlab_runner_registration_token= # paste token from previous step export TF_VAR_region= # example: us-east-2 export TF_VAR_key_name= # example: mykey export TF_VAR_key_path= # example: ~/.ssh/mykey.pem export TF_VAR_registry= # example: registry.gitlab.com/container-pipeline/gitlab-demo export TF_VAR_registry_username= export TF_VAR_registry_password= Verify that our AWS credentials file contains non-expired profile credentials (Terraform will hang if these are unset or expired). cat ~/.aws/credentials Copy our AWS profile name. [default] # copy this aws_access_key_id = aws_secret_access_key = aws_session_token = Create the final environment variable Terraform needs to create an AWS connection. export TF_VAR_profile= # example: default Finally, after confirming that we are inside our repo (in the same directory as the terraform.tf file), let’s initialize our project, apply our configuration, and accept changes. terraform init terraform apply yes Terraform is now spinning up our EC2 instance and performing the tasks listed at the beginning of this step (this will take approximately 3.5 minutes). Step 3: Test and Customize By default, when GitLab sees an active runner associated with our project, it triggers our pipeline build every time we push changes. While we could trigger our pipeline manually or with pull requests, try modifying the Dockerfile and push your changes. Check out the results in the CI/CD > Jobs logs. In this example, we simply tested debian:latest and our result was FAIL. Anchore Engine found 2 high vulnerabilities that did not comply with the default policy, thus our pipeline broke and was prevented from continuing to the next stage. If you desire, you can change the ANCHORE_FAIL_ON_POLICY variable in .gitlab-ci.yml to "false" to allow the pipeline to continue. We now have Anchore Engine configured with a GitLab pipeline. You can connect to the EC2 instance via ssh from the local machine you ran the Terraform commands with so you can further manage your registries and policies. For more information on using registries and policies with Anchore Engine, see: Configuring Registries Working with Policies This guide shows just one way you can integrate container security and compliance into a GitLab pipeline. Feel free to use the files in the associated repo when you are integrating Anchore into your pipeline and scanning your own images! ### Anchore Engine: Tips and Tricks for New Users Just like you, I was new to Anchore just a few short weeks ago. Here is a quick run down to make getting started just a little bit easier using the documentation for Anchore Engine. Anchore Engine is an open source project that allows users to inspect and analyze security risks within containers. It can be used as a standalone tool, as a part of a CI/CD pipeline to scan for security vulnerabilities during a software build pipeline, or as a custom solution through integration via the REST API. It is a powerful tool with limitless possibilities, but for our purposes today, we will use Anchore Engine on its own. Pre-installation Setup The quickest way to get started is through Docker Compose. But before pulling the Docker image, we need to make sure that the machine we will be running Anchore on has enough resources to run smoothly. For production environments, we recommend using the Anchore Helm chart as Kubernetes allows for greater flexibility when it comes to load balancing, scalability, and performance. However, for getting started quickly, Docker is perfectly fine. You can refer to other technical specifications that are necessary for provisioning a machine to run Anchore, if needed. Provisioning with Anchore Engine If we want Anchore to detect non-os vulnerabilities coming from different package managers such as pip, yum, etc., we need to configure it to do so in the config.yaml file in the container. Set the nvd parameter to true to sync non-os vulnerability feeds and then restart Anchore. This will start the feed sync again with the new sources. For additional assistance, find information on enabling various feed sources. Once you have the Anchore containers up and running, your next step is to wait. The vulnerability feeds need some time to sync. This will only take a few minutes to complete, and in the meantime, you can install the Anchore CLI. This will make executing commands faster and easier than executing them through the Anchore Engine container. To do this, ensure that Python and pip are installed on your system and run pip install --user --upgrade anchorecli. With Anchore CLI installed, you can add your first image. Additionally, Anchore Engine can be accessed through its API.  *Note. It is highly recommended that you enable Swagger UI as it allows for greater visibility into the Anchore Engine API. The Anchore CLI is built on top of the Anchore REST API. With it installed, we can do a number of things. Once the feeds have finished syncing, we can begin scanning images with a full vulnerability library backing up our scans. Analyzing Images Adding an image is as simple as running the following command anchore-cli image add /library/:. This will pull the requested image and queue it for analysis as well as provide a print out of metadata discovered within the repository. Once the engine has completed its analysis, the status will be set to analyzed and the vulnerability findings can be viewed. If you want to specify a Dockerfile to be analyzed as additional metadata, this can be accomplished by running the command just like it was before, but with the addition of specifying the location of the dockerfile whose content should be passed in along with the image: anchore-cli image add/library/: --dockerfile=/path/to/Dockerfile and if we want to reanalyze an image, we will add it again with a --force tag at the end. We can also analyze images from private repositories. By default, Anchore Engine will only pull images from TLS/SSL enabled registries. If yours is self-signed or has a certificate from an uncommon or unknown CA source, you can still scan your images. Simply run one of the two following commands to add the image. anchore-cli registry add REGISTRY USERNAME PASSWORD --insecure will skip credential validation in the case that you are sure the credentials are correct, but cannot be validated by Anchore Engine. Once an image is analyzed, we will want to view its contents or other information associated with that image. We can do this by running anchore-cli image content INPUT_IMAGE CONTENT_TYPE. Once an image is analyzed, we can view the vulnerabilities present in that particular image. To do so, we will run anchore-cli image vuln IMPUT_IMGAGE VULN_TYPE. The available vuln types are os which are vulnerabilities against operating system packages, non-os which are vulnerabilities against language packages such as pip, or we can display both by adding the tag all. With these commands, we will get a report of the vulnerabilities and their severity. Conclusion With this, we should have a good start on understanding some of the major concepts behind Anchore Engine and how it works. For more information, the documentation is a great place to look. ### Scanning in the Millions: Scaling with Anchore In today’s DevSecOps environment filled with microservices and containers, applications are developed with the idea of scaling in mind. Performing security checks on thousands - or even millions - of container images may seem like a giant undertaking, but Anchore was built with the idea of scaling to handle vast amounts of image analyses. While Anchore conveniently provides quickstarts using both Docker-Compose and Helm for general usage and proof-of-concepts, preparing a production-grade deployment for Anchore requires some more in-depth planning. In this blog, we will take a look at some of the architectural features that help facilitate scaling an Anchore installation into a more production-ready deployment. Every deployment is different, as is every environment, and keeping these general ideas in mind when planning the underlying architecture for Anchore will help reduce issues while setting you up to scale with Anchore as your organization grows. Server Resourcing Whether your Anchore installation is deployed on-premise with underlying virtual machines or in a cloud environment such as AWS, GCP, or Azure, there are some key components that should be considered to facilitate the proper functioning of Anchore. Some of the areas to consider when doing capacity planning are the number of underlying instances, the resource allocation per node, and whether having a few larger nodes is more beneficial than having multiple smaller nodes. Resource Allocation As with any application, resource allocation is a crucial component to allow Anchore to perform at its highest level. With the initial deployment, Anchore synchronizes with upstream feed data providers which can be somewhat resource-intensive. After the initial feeds sync, the steady operating state is much lower, but it is recommended for a production-scale deployment that each of Anchore’s services is allocated at least 8GB of memory; these include the following services: analyzer API catalog queue policy-engine enterprise-feeds (if using Anchore Enterprise) CPU utilization can vary per service, but generally, each service can benefit from 1-2 dedicated vCPUs.  As more images are added for concurrent analysis, these values should also be increased to support the load. Cluster Size and Autoscaling The appropriate sizing for your deployment will vary based on factors such as the number of images you are scanning over a given period of time, the average size of your images, the location of the database service tier, but a good rule of thumb to start is to use a few larger nodes over multiple smaller nodes. This enables the cluster to adequately support regular operations during non-peak times when the system is primarily on standby and provides services room to scale as additional resources are needed. Another approach which adheres more with an autoscaling architecture is to use a combination of larger nodes for the core Anchore services (API, catalog, policy-engine, and queue), and smaller nodes that can be used as dedicated nodes for the analyzer services; ideally one analyzer per smaller node for best results. This can be used in conjunction with autoscaling groups and spot instances, enabling the cluster to scale as memory or CPU utilization increases. Storage Resourcing When considering allocating storage for an Anchore installation, not only does database capacity planning play a crucial role, but underlying instance disk space and various persistent storage volume space should also be considered. Volume space per node can be roughly calculated by 3-4x the size of the largest image that will be analyzed. Anchore uses a local directory for image analysis operations including downloading layers and unpacking the image content for the analysis process. This space is necessary for each analyzer worker service and should not be shared. The scratch space is ephemeral and can have its lifecycle bound to that of the service container. Anchore uses the following persistent storage types for storing image metadata, analysis reports, policy evaluation, subscriptions, tags, and other artifacts. Configuration Volume - This volume is used to provide persistent storage of database configuration files and optionally certificates. (Requires less than 1MB of storage) Object Storage - The Anchore Engine stores documents containing archives of image analysis data and policies as JSON documents. By default, this data is persisted in a PostgreSQL service container defined in the default helm chart and docker-compose template for Anchore. While this storage solution is sufficient for testing and smaller deployments, storage consumption may grow rapidly with the number of images analyzed, requiring a more scalable solution for medium and large production deployments. To address storage growth and reduce database overhead, we recommend using an external object store for long-term data storage and archival. Offloading persistent object storage provides scalability, improves API performance, and supports the inclusion of lifecycle management policies to reduce storage costs over time. External object storage can be configured by updating the following section of your deployment template: ... services:   ...   catalog:   ...   object_store:     compression:       enabled: false       min_size_kbytes: 100     storage_driver:       name: db       config: {} Anchore currently supports the use of Simple Storage Service (AWS S3), Swift, and MinIO for Kubernetes deployments. You can learn more about the configuration and advantages of external object storage in our docs. Database Connection Settings A standard Anchore deployment includes an internal PostgreSQL service container for persistent storage, but for production deployments, we recommend utilizing an external database instance, either on-premises or in the cloud (Amazon RDS, Azure SQL, GCP Cloud SQL). Every Anchore service communicates with the database, and every service has a configuration option that allows you to set client pool connections, with the default set at 30. Client pool connections control how many client connections each service can make concurrently. In the Postgres configuration, max connections control how many clients total can connect at once. By default, the settings in PostgreSQL out of the box are around 100 max connections. To improve scalability and performance, we recommend leaving the Anchore client max connection setting at its defaults and bumping up the max connections in Postgres configuration appropriately. With the client default at 30, the corresponding max connections setting for our deployment of 100 Anchore services should be at least 3000 (30 * 100). Archival/Deletion Rules & Migration As your organization grows, it may not be necessary to store older image analysis in your database in the active working set. In fact, hanging onto this type of data in the database can quickly lead to a bloated database with information no longer relevant to your organization. To help reduce the storage capacity of the database and keep the active working set focused on what is current, Anchore offers an “Analysis Archive” tool that allows users to manually archive and delete old image analysis data or to create a ruleset that automatically archives and deletes image analysis data after a specified period of time. Images that are archived can be restored to the active working set at any time, but using the archive allows users to reduce the necessary storage size for the database while maintaining analysis records for audit trails and provenance. The following example shows how to configure the analysis archive to use an AWS S3 bucket to offload analysis data from the database. ... services: ... catalog: ... analysis_archive: compression: enabled: False min_size_kbytes: 100 storage_driver: name: 's3' config: access_key: 'MY_ACCESS_KEY' secret_key: 'MY_SECRET_KEY' #iamauto: True url: 'https://S3-end-point.example.com' region: False bucket: 'anchorearchive' create_bucket: True For users with existing data who want to enable an external analysis archive driver, there are some additional steps to migrate the existing data to the external analysis archive. For existing deployments, you can learn about migrating from the default database archive to a different archive driver here. For more information, check out our documentation on Using the Analysis Archive. Deployment Configuration One of the quintessential features of Anchore is the ability to customize your deployment, from the aforementioned server and storage resourcing to the number of services and how Anchore can fit into your architecture. From a production perspective, a couple of areas should be considered as the organization scales to support larger numbers of images to analyze while maintaining a steady throughput; the ratio of analyzers to core service and the ability to enable layer caching are two that we have found to be helpful. Service Replicas Specifically, with Kubernetes deployments in mind via Helm, Anchore services can be scaled up or down using a `values.yaml` file and setting the `replicaCount` to the desired number of replicas. This can be achieved with Docker-Compose as well, but the deployment would need to be running in something like Docker Swarm or AWS ECS. ... ... anchoreAnalyzer: replicaCount: 1 ← Here is where the number of Analyzer services can be upped ... Check out these links for scaling services with Docker or scaling with Kubernetes. Also, take a look at the documentation for our Helm chart for some more information on deploying with Helm. Golden Ratio of Thumb When scaling Anchore, we recommend keeping a 4-1 ratio of analyzers to core services. This means for a deployment that runs 16 analyzers, we recommend having 4 of the API, catalog, queue, and policy-engine services. The idea behind this stems from the potential for a situation where there are four concurrent heavy memory, cpu, and input/output tasks all happening at once in one of the core services, such as four analyzers all initiating the same task at once like sending an image to a single policy-engine. While a well-provisioned server may be able to handle something like this while still being able to support other lighter tasks, generally the underlying server can start to be overwhelmed unless it’s specifically provisioned to handle many concurrent workloads simultaneously. Additionally, using the 4-1 analyzer-to-core-services ratio helps spread the memory usage load, and where possible as outlined in the above Server Resourcing section, splitting the analyzers out to dedicated nodes helps ensure healthy resource utilization. Layer Caching In some cases, your container images will share a number of common layers, especially if images are built from a standard base image. Anchore can be configured to cache layers in the image manifest to eliminate the need to download layers present in multiple images. This can improve analyzer performance and speed up the analysis process. Layer caching can be enabled by setting a max value greater than ‘0’ in your helm chart anchoreAnalyzer: layerCacheMaxGigabytes: 0 And under the ‘Analyzer’ section of the docker-compose template: analyzer: enabled: True require_auth: True cycle_timer_seconds: 1 max_threads: 1 analyzer_driver: 'nodocker' endpoint_hostname: '${ANCHORE_HOST_ID}' listen: '0.0.0.0' port: 8084 layer_cache_enable: True layer_cache_max_gigabytes: 4 By default, each analyzer container service uses ephemeral storage allocated to the container. Another consideration to improve performance is to offload temporary storage to a dedicated volume. With the cache disabled the temporary directory should be sized to at least 3 times the uncompressed image size to be analyzed. This option can be set under `scratchVolume` settings in the Global configuration section of the helm chart: scratchVolume: mountPath: /analysis_scratch details: # Specify volume configuration here emptyDir: {} Conclusion In this blog, we’ve briefly touched on several of the areas that we believe to be of critical importance when scaling with Anchore. Some of the more important aspects to keep in mind, and what we’ve seen from our customers who run at scale, are as follows: Resource allocation Proper memory and CPU allocation is a critical component of running a successful Anchore deployment Database provisioning Database sizing is important to consider in the long-term, allowing you to analyze images for years to come without the concern of running out of DB space Connection pooling is another crucial aspect to consider to allow Anchore services to concurrently access the database without hitting limits Tons of configuration options Anchore has a vast amount of different configuration options to help customize Anchore to fit your organizational needs While this was a high-level overview, special attention should be paid to each when performing architectural and capacity planning.  From a broader perspective, cloud providers each offer documentation on architectural planning with autoscaling as well as recommendations for how to scale applications in their specific cloud environments. ### Latest Anchore Action Delivers Container Security as an Integrated GitHub Experience At their recent Satellite event in early May, GitHub released a powerful new addition to their increasingly robust set of security and automation features within GitHub Advanced Security, called code scanning. At a high level, this new feature brings static code analysis (based on the CodeQL technology acquired from Semmle last year), with a focus on identifying common and known security flaws in source code patterns, directly into the software development lifecycle (SDLC). Along with GitHub Actions, users are now even closer to using these native tools to manage their end-to-end ‘commit-to-release’ process, including security checks along the way. At Anchore, we’re a firm believer in the concepts of identifying security issues as far ‘left’ and as part of as many stages of the SDLC as possible, which drastically reduces the impact of a security problem when compared to discovering an issue after software is released (or worse, deployed). Because of this alignment of purpose, we were excited to dive into this new feature in collaboration with our partners at GitHub, and explore ways in which we could potentially leverage this new capability with our own technology for scanning container images for security flaws, using the same framework and management tools that GitHub is providing for source code analysis. Today, we’re happy to announce that Anchore’s GitHub Scan Action now supports integration with GitHub’s code scanning feature on eligible repositories. With this new capability, users can leverage both GitHub’s CodeQL-based security analysis to their action flows, and also now include another vital security step with Anchore that scans and reports on any security, compliance and best-practice flaws that may be present in a final container build artifact. By adding both steps, users are able to not only get high quality source code security scans, but also be assured that any container image that is built from the source code (often a final step that produces the actual artifact that would be deployed) is also scanned and secured. At Anchore, we believe that this is an important step that must be considered as the construction of container images often brings in additional code, dependencies, and configurations that are not directly present in the source code itself. Anchore Scan Action The Anchore Scan Action is a step that any GitHub Actions user can include in their existing workflows. This Action provides a vulnerability scan and/or an Anchore policy evaluation against a locally generated container artifact. We won’t go into the full details of the Anchore Scan Action here, but please refer to the Anchore Scan Action page for more information on configuring and including this action. For the purposes of this discussion, the high level idea of the Anchore Scan Action is that it takes as input a reference to a container image, performs its security and compliance scan, and generates JSON reports for the container image software bill of materials (SBOM), vulnerabilities that have been discovered as present in the container image, and a full (customizable) Anchore policy evaluation report. One of the powerful new features of the GitHub code scanning feature is that the system supports the ability for third-party tools (like Anchore!) to produce results that live alongside the built in CodeQL reports. For the latest release of the Anchore Scan Action, we’ve integrated with this capability - the same container vulnerability scanning step now can generate a document (in SARIF format) that encodes Anchore’s vulnerability report data in a form that can then be uploaded back to GitHub, resulting in a security report that lives alongside the new code scanning alerts. This way, findings from both the CodeQL source code scanning step and the Anchore container image scanning step can be reviewed and managed using a common interface. In the screenshot above, we’re looking at an example of a workflow that checks out code, performs a CodeQL scan, builds a container image from the code, performs an Anchore scan, and completes. Once the run is finished, we see that the report section of the security tab in GitHub now includes both a CodeQL section as well as an Anchore Container Scan section, listing all of the vulnerabilities that Anchore discovered as present in the built container image. Clicking into one of the findings, we’ll get even more detail: Here, we can see that the Anchore scan result includes information about the vulnerability identifier, severity, the vulnerable software artifact metadata (name, location, type and version) and a link to the upstream vulnerability information itself. Example Workflow: Automating a Scan Through GitHub Actions and an increasing tool-chest of powerful security and quality tools, GitHub has made it extremely easy to add this type of scanning and reporting to your existing workflow. Below is a short example of a workflow YAML definition that implements the steps that produced the screenshots in the previous section. If you’re already using the Anchore Scan Action, then the only changes required are to enable the ACS report generation feature, and add an ‘upload’ step at the end of the scan. Example Action YAML: name: "Run Anchore Scan Action (ACS SARIF Demo)" on: [push] jobs: CodeQL-Analysis: runs-on: ubuntu-latest steps: - name: Checkout the code uses: actions/checkout@v2 # Initializes the CodeQL tools for scanning. - name: Initialize CodeQL uses: github/codeql-action/init@v1 # Override language selection by uncommenting this and choosing your languages # with: # languages: go, javascript, csharp, python, cpp, java - name: Perform CodeQL Analysis uses: github/codeql-action/analyze@v1 Anchore-Scan-Action: runs-on: ubuntu-latest steps: - name: Checkout the code uses: actions/checkout@v2 - name: Build the Docker image run: docker build . --file Dockerfile --tag localbuild/testimage:latest - name: Run the local anchore scan action itself with sarif generation enabled uses: anchore/scan-action@v1 with: image-reference: "localbuild/testimage:latest" debug: true acs-report-enable: true acs-report-severity-cutoff: "Medium" - name: Upload Anchore Scan ACS Report uses: github/codeql-action/upload-sarif@v1 with: sarif_file: results.sarif Summary and Further Information This new feature within GitHub Advanced Security is truly exciting for us at Anchore - as more and more processes and best practices continue to favor a ‘shift left’ mindset (something that has been a core focus of Anchore technology throughout its history), we’re looking forward to continuing to work closely with GitHub and the community to bring fully featured security tooling right into your automated workflows quickly and easily. For more information on the above topics, please see the following links: Anchore Scan Action GitHub code scanning Code scanning demo at GitHub Satellite Anchore Documentation ### Watch the Rise of DevSecOps in Gov Software Initiatives On May 27th, Anchore had the privilege of participating in the virtual Microsoft Azure Government DC Meetup. The rise of DevSecOps in gov software initiatives was a fantastic event with a great spread of knowledge. There were demos such as deploying OpenStack onto secure infrastructure and implementing DevSecOps at full speed. I gave a demo showcasing Anchore integrated into Azure DevOps in a daily developers life cycle for full speed security. Utilizing a custom Anchore integration, I showcased how to quickly and easily detect security defects in containers before they are deployed. Also, I shared some common best practices and showed how Anchore can enforce them. The event also featured a panel discussion about DevSecOps in the government sector, consisting of experienced individuals from F35 Joint Strike Fighter Program, NIST, and Azure Gov. Check out the full playlist here! ### Top 5 Tips for New Anchore Engine/Enterprise Users In my first three months here at Anchore, I’ve experienced firsthand the highs and lows of working with new technologies. The adoption of any new tool comes with a learning curve that includes the process of trial and error. In this post, I’d like to share some tips relating to common issues that I’ve seen new users of Anchore Engine and Enterprise encounter in the hope to ease this process for future users. 1. Make Sure to Add Registries to Anchore Before Attempting to Scan Images By default, Anchore will attempt to download images from a registry without further configuration. However, if your registry requires authentication, then registry credentials will need to be defined. If you forget to add your registry before you attempt to scan an image, you will receive a Skopeo error stating “cannot fetch image digest/manifest from registry”. To add a registry via the Anchore CLI: anchore-cli registry add REGISTRY USERNAME PASSWORD See here for more information about configuring registries. 2. Use the API Reference on SwaggerHub and the CLI Debug Flag One of the many great capabilities of Anchore is the ability to interact through a CLI, UI (Enterprise only), or RESTful API. This allows dev, devops, and secops teams to use Anchore however they prefer. If you are having trouble connecting to the API, you could have the username, password, or URL set incorrectly. You can see what each CLI command is doing by passing the --debug flag: anchore-cli --debug system feeds sync See here for more information about configuring the CLI. 3. Be Careful When Adding Repositories When adding a repository, Anchore Engine will automatically add the discovered tags to the list of subscribed tags. By default, repositories added to Anchore Engine are also automatically watched. There have been times when new users have accidentally added a repository with a large number of tags and then froze their system that could not handle the workload. To prevent this from happening, try: anchore-cli repo add repo.example.com/apps --noautosubscribe anchore-cli repo unwatch repo.example.com/myrepo See here for more information about using repositories. 4. Use a Policy Bundle That Fits Your Company’s Security Needs Anchore Engine includes a default policy configured at installation that performs basic CVE and Dockerfile checks. This default policy was not intended to be used in production. You could, however, use the default policy as a building block for your own policy. There are many different ways to customize policies with Anchore to meet security and compliance requirements. For more information, see: Working with Policies Getting Started with Anchore Policy Bundles 5. Make Sure Ingress is Set Up Correctly if You’re Using Cloud Platforms and CI/CD Tools This last tip is rather basic but still relates to a common issue nonetheless. If you’re running Anchore, for example, on a cloud machine, make sure your ingress rules are set up correctly so that your CI/CD tools (e.g. Jenkins, GitLab CI, etc.) are able to access Anchore Engine. A simple check on your inbound rules could present the reason why your pipeline job is “timing out” or “refusing connection” to Anchore. By default, the Anchore service is configured on port 8228; make sure any third-party tools you’re using can access that port. ### Anchore Scan for Atlassian Bitbucket Pipelines Recent announcements from Atlassian have made several powerful new features of the Bitbucket platform available worldwide - at Anchore, this means that our official Anchore Scan Pipe for Atlassian Bitbucket Pipelines is also now generally available, bringing container image security and compliance scanning ever closer to your Atlassian Bitbucket based automated software delivery systems. Pipelines enable users to construct automated CI/CD processes that are closely aligned with source code activities, triggering on events like developer pull requests and code commits to automatically generate executable software (such as container images) that is built, tested, verified, and finally released.  Many modern CI/CD processes generate container images as the final executable software artifact, which introduces a vector by which new software and configurations are included in the executable that were not present in the source code itself.  This introduces potential security and compliance issues that are unique to this step of the build/test/release process - Anchore’s technology focuses on giving users the tools needed to assert flexible security, compliance and best-practice requirements in any container build process as early as possible, which makes the inclusion of Anchore into the Atlassian Bitbucket Pipeline ecosystem a natural fit. The new Anchore Scan Pipe enables users to quickly and easily add Anchore’s container image security and compliance scanning into existing and new pipelines with just a few lines of YAML.  Further, the integration was developed in concert with the availability of Bitbucket’s recently announced Code Insights for Bitbucket Cloud feature, enabling the results of your Anchore scan to be presented natively in the Bitbucket Cloud UI alongside pull requests and commits. To get started, check out the official Anchore Scan Pipe, or see the following quick run-through demonstrating the addition of an Anchore scan to your existing pipeline. Step 1: Review your Container Image Building Pipeline For example, your bitbucket_pipelines.yaml might have a simple step to build a container image similar to the following: script: - export IMAGE_NAME=your_container_repo/your_container_image:$BITBUCKET_COMMIT # build the Docker image (this will use the Dockerfile in the root of the repo) - docker build -t $IMAGE_NAME -f Dockerfile . # push the new Docker image to the Docker registry - docker login --username $DOCKER_HUB_USERNAME --password $DOCKER_HUB_PASSWORD - docker push $IMAGE_NAME Step 2: Add Call to Anchore Scan Pipe Anchore scans container image content, and thus requires that an image is built to be provided as input to the scan. This means that the Anchore Scan Pipe invocation can be placed anywhere between the image build and image push steps. Minimally, only the name of the newly built image must be passed to the pipe. script: - export IMAGE_NAME=your_container_repo/your_container_image:$BITBUCKET_COMMIT # build the Docker image (this will use the Dockerfile in the root of the repo) - docker build -t $IMAGE_NAME -f Dockerfile . # run the anchore scan pipe - pipe: anchore/anchore-scan:0.1.2 variables: IMAGE_NAME: $IMAGE_NAME # push the new Docker image to the Docker registry - docker login --username $DOCKER_HUB_USERNAME --password $DOCKER_HUB_PASSWORD - docker push $IMAGE_NAME When the pipe executes, it will perform a full software package vulnerability scan, as well as an Anchore policy evaluation using a set of checks that are included by default. Step 3: Run the pipeline as usual, and observe the Anchore Scan Pipe executing In the native Bitbucket Pipeline UI, you should now see the Anchore Scan Pipe invoked when the above step is executed. Expanding the pipe dropdown will reveal more messages showing the Anchore Scan Pipe progress. Step 4: Inspect scan results via Code Insights Report Now that the pipe has executed against your commit, the last step is to review the results of the Anchore Scan Pipe, via the native Code Insights Reports section next to PRs and Commits. The Anchore scan will generate two reports (Vulnerabilities, Policy Evaluation) which can be toggled on and off via pipe configuration - by default, they’re both enabled: Step 5: Tune your policy and scan options Anchore has always included very flexible tooling to generate results based on your specifications. The Anchore Scan Pipe exposes this flexibility by enabling you to not only rely on the default Anchore policy but also specify your own by storing your custom policy document alongside your code, to have customized policies per repository. Click here to learn more about the breadth and depth of Anchore’s policy checking capabilities. For more information: Bitbucket Bitbucket pipelines The Anchore Pipe Scan Anchore documentation ### Anchore Enterprise 2.3 Feature Series - Scheduled Reports With the release of Anchore Enterprise 2.3 (built upon Anchore Engine v0.7.1), we are happy to announce a new feature of our reporting service: the ability to run scheduled reports. Scheduled reporting is used to create custom queries, set a report to run on an automated schedule (or store the configuration for future use). Automatic notifications can be configured when a scheduled report is executed, providing insights for account-wide artifacts. The results are provided through a variety of formats in the Anchore Enterprise UI that include tabular, JSON, or CSV. Scheduling a New Report The first step in creating a new reporting schedule is to create a template to be used for the scheduled report. To begin, navigate to the View Reports tab. Under Creating a New Template, there is a drop-down that has several options and their descriptions; each can be used to generate reports. For this example, the template will be for Images with Critical Vulnerabilities. For this example, just the default values will be used, but from the screenshot below, it’s easy to see there are a lot of different options and configurations to customize the report. After adding a name and description, clicking OK will save the template. In the screenshot above, the fields allow users to control what data is shown in the results and are displayed from left to right within a report table. To optionally refine the result set returned, filter options can be added or removed, including setting a default value for each entry and specifying if the filter is optional or required. Now that the template has been created, a new scheduled query using it can be created. In the Create a New Query box, the Critical Vulnerabilities template is displayed as an option in the dropdown. When the Create New Query Using Template window opens, name the query and provide an optional description. Set any optional filters. Create a schedule for the report by clicking on Add Schedule. For this example, the report will be generated daily at 10:00 PM UTC time. Toggling the Enabled slider ensures that the report will be generated at the scheduled time; without enabling it, the query can be saved but it won’t automatically execute the report. The report can be previewed using the Preview Report from Currently Saved Query button. Conclusion By using scheduled reports, users are able to automate analysis reporting for all images across their organization, making it simple to identify images affected and reduce the amount of effort needed to compile the same data. Taking it a step further, users can configure a notification to be triggered when the report is ready using email, GitHub, Jira, Slack, Teams, or a custom webhook. For more information on scheduled reports, take a look at our documentation on Using the Report Manager. As always, you can view our documentation and installation guides here. ### Anchore Scanning for Windows Container Images With the recent release of version 2.3, Anchore Enterprise now supports scanning of Windows container images and the addition of a new feed source for identifying Windows vulnerabilities: Microsoft Security Response Center (MSRC). MSRC Microsoft Security Response Center maintains reports of security vulnerabilities affecting Windows systems in its Security Update Guide. In addition to publishing this data publicly on its website, Microsoft provides programmatic access to retrieve security update details in the Common Vulnerability Reporting Format via its Microsoft Security Update API. In order to access the API, users must obtain an API key using their Microsoft TechNet account. Enabling the MSRC Feed Driver for Anchore Enterprise In order to configure the feed source for use with Anchore Enterprise, the on-premise Enterprise Feeds Service must be enabled with the obtained API key. For instructions on how to obtain an API key from Microsoft, visit Anchore Enterprise Feed Driver Configuration. Note: If you are upgrading an existing deployment via docker-compose, you will need to bring down the deployment WITHOUT deleting existing volume configurations (This can be completed by omitting the ‘-v’ flag via docker-compose). For Kubernetes deployments using Helm, the upgrade can be performed using the helm upgrade command. To enable the on-premise feeds service and configure the MSRC driver on deployments using docker-compose, edit the following section of the compose template: services: ... feeds: ... environment: ... - ANCHORE_ENTERPRISE_FEEDS_MSRC_DRIVER_ENABLED=true - ANCHORE_ENTERPRISE_FEEDS_MSRC_DRIVER_API_KEY= *For deployments using the config.yaml configuration file, update the following sections: services: ... feeds: ... drivers: msrc: enabled: true api_key: To enable the feeds service and the MSRC driver for Kubernetes deployments, update the following section of your custom values file: anchore-feeds-db: enabled: true ... anchoreEnterpriseFeeds: enabled: true ... # Enable microsoft feeds msrcDriverEnabled: true msrcApiKey: ... (For new deployments on Kubernetes using the stable/anchore-engine Helm chart, refer to the installation guide for instructions on deploying Anchore in your cluster). Verify New Feed is Enabled After bringing up the deployment, it may take a while for the feed sync to complete depending on whether or not this is a new deployment or existing upgrade. For details on checking the status of the feeds synchronization, refer to our enterprise docs. Once the feeds have finished synchronizing, verify the MSRC feeds is included in the list: - via Enterprise UI - - or via API - Adding Windows Images Just as with Linux containers, you can analyze a Windows container repository or tag by providing the image registry/repository/tag in the UI or via the API: anchore-cli image add Viewing Compliance and Vulnerabilities Once the image analysis has completed, Anchore provides a detailed view of the image contents, vulnerability findings and compliance reports driven through policy. To produce security information for Windows images, Anchore compares the difference between the latest version (or patch set) of the base image and the image version you are scanning to generate a list of all the vulnerabilities that the image may be exposed to as disclosed by the Microsoft Research Center. In the example below, we can see the vulnerabilities Anchore identified in the image with further details on the severity of the CVE, package name and type and a link to Microsoft’s Security Update Guide for more details on the finding. With the addition of support for Windows container image scanning, you can integrate Anchore into your container-based workflows for your Windows images and leverage our policy engine to enforce compliance. ### Anchore Enterprise 2.3 Feature Series - NuGet Package Support With the release of Anchore Enterprise 2.3, we are happy to share that you can now scan for vulnerabilities in NuGet packages inside your container images. This new language package support is made possible by the addition of the GitHub Security Advisories data source into Anchore. You can read more about GHSA and how to enable the feed source in Anchore in a previous post. Viewing NuGet Feeds Once you have successfully configured the GitHub Security Advisories feeds in your Anchore installation, you can view the status of the feeds synchronization via the Anchore CLI by running the `anchore-cli system feeds list` command, or by navigating to the ‘System’ view in the Anchore Enterprise UI (see below). Viewing NuGet packages With NuGet, just as with any identified package (OS and non-OS), Anchore provides the name, version, location, origin, and license of each identified package easily accessible via the API or UI in Anchore Enterprise (see below). This data is also accessible via the Anchore CLI by running: `anchore-cli image content mcr.microsoft.com/dotnet/core/sdk:2.1.805-nanoserver-1809 nuget` Viewing Compliance and Vulnerabilities Anchore also provides detailed compliance reports driven through policy. Anchore policies allow users to specify which checks to perform on what images and how the results should be interpreted. A policy is expressed as a policy bundle, which is made up of a set of rules that are used to perform an evaluation on a container image. The rules can define checks against an image for things such as security vulnerabilities, package whitelist and blacklists, configuration file contents, presence of credentials in an image, image manifest changes, exposed ports, and more. In the example below, we can see that Medium severity vulnerabilities have been identified in NuGet packages present in the container image. The policy rule definition has been created to associate a WARN action when vulnerabilities of Medium severity are flagged. Finally, to find out more information surrounding the nature of these GHSAs, Anchore users can simply click on the link which, in this case, will take them to the GitHub Security Advisories page where a description of the issue is described in more detail (example). At Anchore, we strive to provide comprehensive, actionable vulnerability identification that enables development without compromising security. The addition of NuGet package support allows users to find vulnerabilities in their .NET applications more quickly, highlighting the value of shifting security further to the left. As always, you can view our documentation and installation guides for more information ### Risk and Reward, Container Security in the Swiss Banking Sector There’s an odd mix of fearlessness and fear that surrounds our constant need for innovation in modern business. It takes courage to risk striking out in a new direction, turning your back on the perceived stability of the status quo. And yet, in many industries, the compulsion for innovation is fuelled by a very real fear of getting left behind. Building on over 150 years of secure Swiss banking heritage, Hypothekarbank Lenzburg (HBL) feels these conflicting pressures more than most. But this hasn’t stopped its technology team from leading the Swiss banking sector in new, risk-fraught areas such as blockchain and open banking. The recent pace of growth and innovation at HBL was fueled by bountiful new CI/CD pipelines, built on containerization and Kubernetes. However, this had also opened up very real risks for the bank’s operational security and stability: "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," explains Sascha Kaufmann, Head of IT Security at HBL, in our latest case study. When HBL looked at solving this new challenge, it soon became clear that a conservative attitude towards IT security was actually the most dangerous approach. Existing, tried-and-tested security vendors were unable to keep pace with the speed of container-based development. And the bold changes the organization had embraced by adopting cloud-native development, demanded a new security solution built for this new environment. The real surprise for HBL was that in taking a new and dedicated approach to container security, the team turned an area of unacceptable risk into a pillar of strengthened security for the bank moving forward. Discover DevSecOps at work in the banking sector with our latest case study. ### Container Security for Government Information Systems Over the last year, we received great feedback from our customers regarding our Container Security for U.S. Government Information Systems white paper. Today, we are publishing version 2.0, which updates and expands upon last year’s document. The two central challenges for Federal organizations remain the same: Security and compliance guidelines are increasing in both urgency and complexity Development velocity must not be sacrificed in the pursuit of stronger security Anchore helps Federal organizations address those two competing needs by providing technologies and services that integrate container security scanning into the development process so that development velocity can be maintained while meeting security requirements prior to launching code into runtime. In version 2.0 of this paper, we dive further into topics such as: Using approved container parent images Protecting against supply chain attacks Leveraging container immutability for increased security Expressing security policy as code To learn more about these topics and Anchore’s guidance for Federal, read our updated Container Security for U.S. Government Information Systems white paper ### Anchore 2.3 Feature Series - GitHub Security Advisories With the release of Anchore Enterprise 2.3 (built upon Anchore Engine v0.7.1), we are happy to announce a new feed provider: GitHub Security Advisories (GHSA). GHSAs are another source of data that Anchore uses to match vulnerabilities to packages within a container. In this post, we will look into what GHSAs include, describe how Anchore use them, and walk through an example GitHub Action using Anchore to identify vulnerabilities from GHSAs. GHSA Explained As described in About GitHub Security Advisories, GHSAs allow code maintainers to privately discuss and fix security issues in their projects, and upon completion of a fix, publish the advisory to the project’s community. In turn, by publishing security advisories, maintainers make it easier for their communities to update affected packages and further investigate the impact of the vulnerability. GHSA Under the Hood GitHub is an authorized CVE Numbering Authority (CNA) and GHSAs created can optionally include an existing CVE reference or request that one be assigned through GitHub. When a new advisory is filed with GitHub, it is reviewed and pushed to the GitHub Advisory Database. Anchore uses this database as an upstream feed data source, allowing us to match vulnerabilities with the most up-to-date vulnerability data available. For more information on CVEs, check out the blog by Anchore’s very own Hayden Smith on Why We Care About CVEs. GHSA as an Anchore Feed Provider Anchore uses GHSAs to match potential vulnerabilities for the following supported language types: Java Python Ruby Gem GHSAs also give us a preview of NuGet (.NET) vulnerabilities, allowing Anchore to discover NuGet packages as part of the image analysis process. Including language packages during image inspection makes Anchore more than just a tool to identify CVEs, it allows fine-grained control over what is included in an image through policies as well. Enabling the GitHub Feed Driver for Anchore Enterprise GHSA is a publicly available feed source with an open API that requires that users generate a Personal Access Token (PAT) from their GitHub account. While GHSA is a feed source included in the open source Anchore Engine version, enabling the GHSA feed driver within Anchore Enterprise requires the PAT to be configured in the on-premise Enterprise Feeds Service; no other special permission or scoping is required. For a full overview and instructions on how to generate and enable the GHSA Feed Driver within Anchore, please refer to Anchore Enterprise Feed Driver Configuration to begin using GHSA feeds in your deployment. GitHub Scan Action with Anchore and GHSA A seamless way to integrate Anchore with GHSA feeds is to use the Github Scan Action. Check out Anchore's GitHub Scan Action for more information on using Anchore within GitHub’s CI/CD. We begin by creating a Dockerfile that installs a package with a known GHSA vulnerability: FROM docker.io/python:3.8.0a3 RUN pip install aubio-0.4.8 CMD echo "This is just a test" Then we add it to a GitHub repository with the following Scan Action defined: name: Docker Image CI on: [push] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v1 - name: Build the Docker image run: docker build . --file Dockerfile --tag localbuild/testimage:latest - uses: anchore/scan-action@master with: image-reference: "localbuild/testimage:latest" dockerfile-path: "./Dockerfile" fail-build: true - name: anchore inline scan JSON results run: for j in `ls ./anchore-reports/*.json`; do echo "---- ${j} ----"; cat ${j}; echo; done We are able to see that the Anchore Scan Action identifies multiple vulnerabilities. Let’s drill down on a known vulnerability identified as `GHSA-grmf-4fq6-2r79`: From the scan results, we can see that GHSA is flagging a Mercurial Python package. It provides a link to the GHSA where we can see details about the vulnerability: From here, end users can determine the best approach to remediation according to their organizational needs. At Anchore, we strive to provide comprehensive, actionable vulnerability identification that enables development without compromising security. The addition of GHSA as a feed data provider allows users to find vulnerabilities more quickly, highlighting the value of shifting security further to the left. ### Introducing Anchore Enterprise 2.3 Today, we announced the availability of Anchore Enterprise 2.3 for our enterprise and federal government customers. Keeping to a 4-month development cycle since our last release, 2.3 includes some big new features that see expanded coverage for Windows containers and .NET packages as the headline. Microsoft is the original developer-champion; combined with their acquisition of GitHub, another ecosystem we are deepening support for, they are critical to the adoption of DevSecOps that is at the heart of Anchore’s mission. Many thanks to the folks at Microsoft and GitHub who helped us with the features in the release, and well done to the engineering team for getting out the release despite the distraction and stresses of the pandemic. Read about this release here, or view this webinar covering all the features of 2.3. Support for Windows Containers While Linux containers continue to represent the lion’s share of containers on Docker Hub and in production, Microsoft has been enthusiastic supporters of containers for Windows since 2016 when they released the first Windows container. Last year, Windows officially became supported on various distributions of Kubernetes. As of 2.3, Anchore Enterprise can now inspect, scan and enforce policies across Windows containers, the same way we support Linux containers.  We perform a deep inspection of the entire image, cataloging all the files and their metadata to produce a software bill of materials (SBOM). These can be viewed in the Files tab of our UI or via the API, just as you can browse a Linux image. Once we have this analysis, we then perform our security assessment. Unlike Linux images, which are collections of multiple packages, each with their own version information, Windows container images are more monolithic. That means the security information for the base OS is produced slightly differently. By comparing the difference between the latest version (or patch set) of the base image and the version you are scanning, we generate a list of all the vulnerabilities that you may be exposed to as disclosed by the Microsoft Research Center. Vulnerability checks, along with all of the other policy gates available in Anchore, can be applied to Windows images. In addition to the OS vulnerabilities, Anchore Enterprise will also report on any additional language vulnerabilities for Python, Ruby, Node or Java apps layered on top of the base image. Of course, the most common application framework used with Windows is .NET which we are also now able to offer in Tech Preview. Vulnerability Scanning for Nuget Packages (Tech Preview) Nuget is a popular package management system for handling .NET packages. Sponsored by Microsoft, it is run as a community project and functions identically to other language packaging systems like npm, pip or gem that provide a central repository for libraries and add-ons. Anchore Enterprise will now scan for Nuget package indexes and map .NET package versions against disclosed vulnerabilities, both on Linux or Windows containers. A new Nuget tab can be seen via our UI and is available as an option via the API which allows you to see what packages are installed. Unlike npm or Python, there is less curation and centralization of security issues in the Nuget community. Individual contributors are left to decide how they want to manage their security notices. For the 2.3 release, we have chosen vulnerability sources that have the highest volume of disclosures and are making this feature available as Tech Preview so we can assess the coverage this provides for customer applications. As new sources become available, we will look to include them in future releases. GitHub Security Database and Red Hat CVE Database Last November, GitHub made several security announcements. Most notable was their ability to create CVEs directly from within their product and the availability of a security database that aggregated these CVEs and any other advisories created by hosted projects. Anchore Enterprise now uses the GitHub Security Database as part of our aggregated vulnerability feed alongside other open and proprietary data sources. Customers should see more vulnerabilities being reported, especially where the source code software originates on GitHub. We really like the security workflows being embedded into GitHub and hope the communities of open source projects will use them to create a high fidelity database over time. We’ve also switched to using the Red Hat CVE database as our primary source for all things RHEL-related. Previously we were using Red Hat Security Advisories which only provided notice of resolved issues and the products affected. The CVE database provides more information about issues that Red Hat has marked as “won’t fix” and uses CVE as the primary key, making it easier to manage policies using just CVE rules. User Interface Improvements: Scheduled Reports and Event Management One of the key differentiators for Anchore compared to other security tools is our ability to produce highly customizable reports that allow security teams to get a clear picture of their risks. Under the hood, we use GraphQL but our UI makes the process of creating a report much easier. Until now, these reports were created ad-hoc. With 2.3, reporting templates can be created and then scheduled for automatic creation. A notification can be configured via email, Slack, MS Teams or other methods, to notify you of the report's availability. Finally, we have also added an event management system to help admins more easily scan the system logs, find errors and prune old entries directly from within the UI. Looking Forward As ever, we look forward to hearing feedback from our open source community, commercial customers and partners. Don’t forget to join our community Slack channel as we discuss features for the next release due later in the year. ### Getting Started With Anchore Policy Bundles In order to shift security left in the development lifecycle without compromising production velocity, security requirements must be automated and embedded into continuous integration / continuous delivery workflows. Organizations can achieve this through the automated implementation, verification, remediation, monitoring and reporting of compliance into the development pipeline. Furthermore, organizations can manage security requirements in code repositories like any other piece of code using Anchore policy bundles. How does Anchore Help Achieve this? At Anchore, our focus is to help organizations embed compliance requirements into their containerized environments, establishing security guardrails earlier in the development pipeline. CVE scanning allows developers to be proactive about security as they will get a near-immediate feedback loop on potentially vulnerable images. As developers add container images to the build pipeline, Anchore image scanning will scan the contents of the image to identify any known vulnerabilities in the container images. Taking this a step further, security and development teams can build policies according to security requirements and evaluate each image in the pipeline against these policies. This adds a layer of control to the images being scanned and facilitates the ability to decide which images should be promoted into production environments. Components of a Policy Bundle Anchore policy bundles (structured as JSON documents) are essentially the unit of policy definition and evaluation for your organization’s requirements. A policy bundle consists of: 1. Policies: A set of rules to evaluate against an image and recommended actions if a match is found. Detail on these rules can be found in our documentation. A policy or whitelist can be used to evaluate an image against the following criteria: Security vulnerabilities Package whitelists and blacklists Configuration file contents Presence of credentials in an image Image manifest changes Exposed ports Anchore policies returning a pass or fail decision result 2. Whitelists: A set of exclusions for matches found during policy evaluation. When a policy rule result is whitelisted, it is still present in the output of the policy evaluation, but it’s action is set to go and it is indicated that there was a whitelist match. 3. Mappings: Ordered rules that determine which policies and whitelists should be applied to a given container registry, repository or image at evaluation. Mappings are evaluated similar to access control lists, where the first rule matching an input is applied and any subsequent rules are ignored. 4. Whitelisted Images: Whitelisted images are images, defined by registry, repository, and tag/digest/imageId, that will always result in a pass status for bundle evaluation unless the image is also matched in the blacklisted images section. 5. Blacklisted Images: Overrides for specific images to statically set the final result of a policy evaluation to fail regardless of the actual evaluation results. Blacklisted image matches override any whitelisted image matches. Policy Bundle Examples Now that we’ve discussed the importance of compliance as code and how Anchore can help integrate your requirements into the container pipeline, let’s walk through some examples of how you can enforce security in your container images using Anchore policies. Ensure a minimal base image is used Utilizing minimal images that bundle only the necessary system tools and libraries minimizes the attack surface and ensures that you ship a secure OS. { "action": "WARN", "comment": "Ensure dockerfile is provided during analysis", "gate": "dockerfile", "params": [], "trigger": "no_dockerfile_provided" }, { "action": "STOP", "comment": "Ensure a minimal base image is used", "gate": "dockerfile", "params": [ { "name": "instruction", "value": "FROM" }, { "name": "check", "value": "!=" }, { "name": "value", "value": "node:stretch-slim" }, { "name": "actual_dockerfile_only", "value": "false" } ], "trigger": "instruction" }   Blacklist exposed ports / ensure sshd is disabled or absent Your container applications shouldn’t be running an SSH or Telnet server. Checking the dockerfile for explicit management ports can ensure that these services are not exposed while blacklisting their associated packages can provide more enhanced security. { "action": "STOP", "comment": "Blacklist ssh package", "gate": "packages", "params": [ { "name": "name", "value": "openssh-server" } ], "trigger": "blacklist" }, { "action": "STOP", "comment": "Blacklist ssh package", "gate": "packages", "params": [ { "name": "name", "value": "libssh2" } ], "trigger": "blacklist" }, { "action": "STOP", "comment": "Blacklist ssh package", "gate": "packages", "params": [ { "name": "name", "value": "libssh" } ], "trigger": "blacklist" }, { "action": "WARN", "comment": "Ensure openssh configuration files are absent from image", "gate": "packages", "params": [ { "name": "only_packages", "value": "ssh" }, { "name": "only_directories", "value": "/etc/sshd" }, { "name": "check", "value": "missing" } ], "trigger": "verify" } Ensure the COPY instruction is used instead of ADD The COPY instruction copies local files recursively, given explicit source and destination files or directories. The ADD instruction copies local files recursively, implicitly creates the destination directory if non-existant, and accepts archives as local or remote URLs as its source, which it expands or downloads respectively into the destination directory. General best practice is to use the COPY command over ADD when copying data to your container image. { "action": "STOP", "comment": "The \"COPY\" instruction should be used instead of \"ADD\"", "gate": "dockerfile", "params": [ { "name": "instruction", "value": "ADD" }, { "name": "check", "value": "exists" }, { "name": "actual_dockerfile_only", "value": "false" } ], "trigger": "instruction" } Checking for secrets Secrets such as API keys and access credentials should never be present in your container image. Scan images for AWS credentials: { "action": "STOP", "gate": "secret_scans", "params": [ { "name": "content_regex_name", "value": "AWS_ACCESS_KEY" }, { "name": "match_type", "value": "found" } ], "trigger": "content_regex_checks" } Scan images for API keys: { "action": "STOP", "gate": "secret_scans", "params": [ { "name": "content_regex_name", "value": "API_KEY" }, { "name": "match_type", "value": "found" } ], "trigger": "content_regex_checks" } Checking for vulnerable packages Identifying vulnerable packages and dependencies in your container images as early as possible can improve production velocity and ensure your container applications are shipped free of bugs and malicious packages. Blacklist malicious package identified as typo-squatting: { "action": "STOP", "comment": "Malicious library discovered [11.29.2019] typosquatting \"jellyfish\"", "gate": "packages", "params": [ { "name": "name", "value": "jeIlyfish" } ], "trigger": "blacklist" }, { "action": "STOP", "comment": "Malicious library discovered [11.29.2019] typosquatting python-dateutil", "gate": "packages", "params": [ { "name": "name", "value": "python3-dateutil" } ], "trigger": "blacklist" } Blacklist vulnerable package versions: { "action": "STOP", "comment": "Django 1.11 before 1.11.29, 2.2 before 2.2.11, and 3.0 before 3.0.4 allows SQL Injection if untrusted data is used as a tolerance parameter in GIS functions and aggregates on Oracle.", "gate": "packages", "params": [ { "name": "name", "value": "Django" }, { "name": "version", "value": "2.2.3" } ], "trigger": "blacklist" }, { "action": "STOP", "comment": "A flaw was found in Mercurial before 4.9. It was possible to use symlinks and subrepositories to defeat Mercurial's path-checking logic and write files outside a repository", "gate": "packages", "params": [ { "name": "name", "value": "mercurial" }, { "name": "version", "value": "4.8.2" } ], "trigger": "blacklist" }, { "action": "STOP", "comment": "Python 2.7.x through 2.7.16 and 3.x through 3.7.2 is affected by: Improper Handling of Unicode Encoding (with an incorrect netloc) during NFKC normalization", "gate": "packages", "params": [ { "name": "name", "value": "Python" }, { "name": "version", "value": "2.7.16" } ], "trigger": "blacklist" } Remove setuid and setgid permissions Removal of setuid and setgid permissions can prevent privilege escalation in running containers. { "action": "STOP", "comment": "Remove setuid and setgid permissions in the images", "gate": "files", "params": [], "trigger": "suid_or_guid_set" }   Ensure images implement use of a non-root user (UID not 0) If not specified in the Dockerfile, a container will be executed as the root user. This is bad practice as it violates least privilege and puts the underlying docker host and any other running containers at risk. { "action": "STOP", "comment": "Blacklist root user (uid 0)", "gate": "retrieved_files", "params": [ { "name": "path", "value": "/etc/passwd" }, { "name": "check", "value": "match" }, { "name": "regex", "value": "root:x:0:0:root:/root:/bin/bash" } ], "trigger": "content_regex" }, { "action": "STOP", "comment": "Ensure user \"root\" is not explicitly referenced in Dockerfile", "gate": "dockerfile", "params": [ { "name": "users", "value": "root" }, { "name": "type", "value": "blacklist" } ], "trigger": "effective_user" } Enforce PID Limits Enforcing PID limits minimizes the number of processes running in each container. Limiting the number of processes in the container prevents excessive spawning of new processes, lateral movement, fork bombs (processes that continually replicate themselves) and anomalous processes. { "action": "STOP", "comment": "Enforce PID Limits", "gate": "retrieved_files", "params": [ { "name": "path", "value": "/proc/sys/kernel/pid_max" }, { "name": "check", "value": "match" }, { "name": "regex", "value": "256" } ], "trigger": "content_regex" } Identify unusually large images Auditing the size of your container images can help identify any anomalies such unsanctioned packages or files that have been added to the image. { "action": "WARN", "comment": "Warn on image size", "gate": "metadata", "params": [ { "name": "attribute", "value": "size" }, { "name": "check", "value": ">" }, { "name": "value", "value": "125000" } ], "trigger": "attribute" } Blacklist unapproved licenses found in a container image Container images can contain thousands of OS files and packages from open source libraries. Identifying the licenses governing these packages can ensure your organization maintains legal compliance. { "action": "WARN", "comment": "Warn on presence of unapproved licenses", "gate": "licenses", "params": [ { "name": "licenses", "value": "GPLv2+, GPL-3+" } ], "trigger": "blacklist_exact_match" } Conclusion These policies are basic, but can help you get started with Anchore policies. Using them, you can establish a security baseline that improves over time. To learn more, visit our documentation. The entire policy, when assembled, looks like this: { "description": "", "name": "anchore-policy-blog", "policies": [ { "comment": "", "name": "General Checks", "rules": [ { "action": "WARN", "comment": "Warn on image size", "gate": "metadata", "params": [ { "name": "attribute", "value": "size" }, { "name": "check", "value": ">" }, { "name": "value", "value": "125000" } ], "trigger": "attribute" }, { "action": "WARN", "comment": "Warn on presence of unapproved licenses", "gate": "licenses", "params": [ { "name": "licenses", "value": "GPLv2+, GPL-3+" } ], "trigger": "blacklist_exact_match" } ], "version": "1_0" }, { "comment": "", "name": "File System Checks", "rules": [ { "action": "STOP", "comment": "Remove setuid and setgid permissions in the images", "gate": "files", "params": [], "trigger": "suid_or_guid_set" }, { "action": "STOP", "comment": "Blacklist root user (uid 0)", "gate": "passwd_file", "params": [ { "name": "user_ids", "value": "0" } ], "trigger": "blacklist_userids" }, { "action": "STOP", "comment": "Blacklist ssh package", "gate": "packages", "params": [ { "name": "name", "value": "openssh-server" } ], "trigger": "blacklist" }, { "action": "STOP", "comment": "Blacklist ssh package", "gate": "packages", "params": [ { "name": "name", "value": "libssh2" } ], "trigger": "blacklist" }, { "action": "STOP", "comment": "Blacklist ssh package", "gate": "packages", "params": [ { "name": "name", "value": "libssh" } ], "trigger": "blacklist" }, { "action": "WARN", "comment": "Ensure openssh configuration files are absent from image", "gate": "packages", "params": [ { "name": "only_packages", "value": "ssh" }, { "name": "only_directories", "value": "/etc/sshd" }, { "name": "check", "value": "missing" } ], "trigger": "verify" }, { "action": "STOP", "comment": "Enforce PID Limits", "gate": "retrieved_files", "params": [ { "name": "path", "value": "/proc/sys/kernel/pid_max" }, { "name": "check", "value": "match" }, { "name": "regex", "value": "256" } ], "trigger": "content_regex" } ], "version": "1_0" }, { "comment": "Blacklist vulnerable packages", "name": "Vulnerable Packages", "rules": [ { "action": "STOP", "comment": "Django 1.11 before 1.11.29, 2.2 before 2.2.11, and 3.0 before 3.0.4 allows SQL Injection if untrusted data is used as a tolerance parameter in GIS functions and aggregates on Oracle.", "gate": "packages", "params": [ { "name": "name", "value": "Django" }, { "name": "version", "value": "2.2.3" } ], "trigger": "blacklist" }, { "action": "STOP", "comment": "A flaw was found in Mercurial before 4.9. It was possible to use symlinks and subrepositories to defeat Mercurial's path-checking logic and write files outside a repository", "gate": "packages", "params": [ { "name": "name", "value": "mercurial" }, { "name": "version", "value": "4.8.2" } ], "trigger": "blacklist" }, { "action": "STOP", "comment": "Python 2.7.x through 2.7.16 and 3.x through 3.7.2 is affected by: Improper Handling of Unicode Encoding (with an incorrect netloc) during NFKC normalization", "gate": "packages", "params": [ { "name": "name", "value": "Python" }, { "name": "version", "value": "2.7.16" } ], "trigger": "blacklist" } ], "version": "1_0" }, { "comment": "Blacklist malicious package types", "name": "Malicious Packages", "rules": [ { "action": "STOP", "comment": "Malicious library discovered [11.29.2019] typosquatting \"jellyfish\"", "gate": "packages", "params": [ { "name": "name", "value": "jeIlyfish" } ], "trigger": "blacklist" }, { "action": "STOP", "comment": "Malicious library discovered [11.29.2019] typosquatting python-dateutil", "gate": "packages", "params": [ { "name": "name", "value": "python3-dateutil" } ], "trigger": "blacklist" } ], "version": "1_0" }, { "comment": "Dockerfile security checks", "name": "Dockerfile Checks", "rules": [ { "action": "STOP", "comment": "The \"COPY\" instruction should be used instead of \"ADD\"", "gate": "dockerfile", "params": [ { "name": "instruction", "value": "ADD" }, { "name": "check", "value": "exists" }, { "name": "actual_dockerfile_only", "value": "false" } ], "trigger": "instruction" }, { "action": "STOP", "comment": "Blacklist SSH & Telnet ports", "gate": "dockerfile", "params": [ { "name": "ports", "value": "22,23" }, { "name": "type", "value": "blacklist" }, { "name": "actual_dockerfile_only", "value": "false" } ], "trigger": "exposed_ports" }, { "action": "STOP", "comment": "Ensure dockerfile is provided during analysis", "gate": "dockerfile", "params": [], "trigger": "no_dockerfile_provided" }, { "action": "STOP", "comment": "Ensure a minimal base image is used", "gate": "dockerfile", "params": [ { "name": "instruction", "value": "FROM" }, { "name": "check", "value": "!=" }, { "name": "value", "value": "node:stretch-slim" }, { "name": "actual_dockerfile_only", "value": "false" } ], "trigger": "instruction" } ], "version": "1_0" } ], "version": "1_0" } ### Building a DevSecOps Platform with the U.S. Air Force When I arrived at Anchore, I joined an amazing group of engineers working to turn a bunch of slides into a tangible reality for the U.S. Air Force (USAF) and U.S. Department of Defense (DoD). Our team of engineers at Anchore quickly became immersed in our first engagement with the DoD, along with Red Hat North American Public Sector consultants. During our initial onboarding, the DevSecOps Platform and Container Hardening teams faced multiple challenges. We had to build Platform One, a secure platform 100% based on OCI compliant images running on Kubernetes. In order to have Platform One running on secure images, we needed to harden and scan 170+ containers from hundreds of different vendors with Anchore. In addition, the USAF needed the image scanning to happen in an automated fashion. The goal was to have a DevSecOps pipeline that “bakes in” 100% of the DoD’s security and compliance checks before anything gets deployed to Kubernetes. The Platform One project has broken new ground in many ways, such as insider threat checks on container images via Anchore and the integration of an entire security pipeline specific to container images. In many respects, the capabilities we have helped develop in the Platform One project surpass even those of our enterprise customers. For most enterprise customers, adopting DevOps and implementing CI/CD gives them the capability to push new code continuously so that the latest version of their enterprise software is available to customers. For the USAF, the goal isn’t just to have unparalleled deployment velocity that enables them to deploy the latest software to fighter aircraft across the globe. They also need additional layers of security with a zero trust model, monitoring for insider threat within the software supply chain, and integration of strict software security best practices into container images. This is a huge advancement - not just for the Air Force, but any service branch within the DoD. Any user can download pre-hardened, OCI-compliant images from Iron Bank, also known as the DoD Centralized Artifact Repository, which stores all of the images secured by the Container Hardening team. DoD users can use these containers to create their own software factories for their respective missions. The consumption of Iron Bank images saves a ton of time and resources that would be needed to build a DevSecOps pipeline from scratch. Developers can now focus on developing, not having to worry about typical STIGs, security, and compliance checks. The Platform One team, with help from Anchore and Red Hat, has taken care of them for you. Read more about the Platform One and container hardening journey that have taken with our partners at Red Hat in our joint case study. ### Anchore Enterprise in the Red Hat Marketplace Anchore Enterprise is now available through Red Hat Marketplace, an open cloud marketplace that makes it easier to discover and access certified software for container-based environments across the hybrid cloud. Built in partnership by Red Hat and IBM, Red Hat Marketplace is designed to make it easy for developers, procurement teams and IT leaders to gain access to popular enterprise software. The software in the marketplace has all been tested and certified for Red Hat OpenShift Container Platform, so it runs anywhere OpenShift runs. We think it’s important to know what’s inside the containers you build and ship. That’s why you should integrate deep container image inspection into every stage of the DevOps workflow. At Anchore, our mission is to make sure that’s easy. We are excited to offer Anchore Enterprise through the Red Hat Marketplace so it can be seamlessly discovered and deployed by software builders everywhere. This has been a big week for our friendship with Red Hat! Just yesterday we released Development at Mach One, a white paper documenting our recent shared mission implementing DevSecOps with the United States Air Force. Read it to learn how powerful Anchore and Red Hat are when we work together with our customers. Then visit out our Red Hat Marketplace entry to get started with Anchore Enterprise today. ### Development at Mach Speed, A Case Study For a little over a year now, engineers at Anchore have been working alongside our friends at Red Hat on an important mission: helping the United States Department of Defense reinvent the way they consume, build, and deploy software. The DoD, just like any major organization, builds and ships a lot of software. This software runs on all kinds of devices, from everyday smartphones to extremely specialized equipment. They have teams of developers working to maintain it all, supported by a network of vendors, consultants, and contractors. There is constant pressure to keep the pace of innovation up. But here’s where the similarities with typical organizations end: when a breach occurs, they stand to lose a whole lot more than just a customer. The DoD’s software ensures the success of critical missions, and that can mean life or death. The answer lies in DevSecOps: the integration of security best practices into a fast-moving development process, using policy-driven automation to create a high level of confidence. Our teams worked with the DoD to implement a flexible, container-based platform for software delivery powered by Red Hat OpenShift and Anchore Enterprise. With this platform, the DoD can maintain a streamlined, zero-trust security and compliance posture while releasing new software as frequently as mission conditions require. To learn more about this project, download our free in depth case study. ### Why We Care About CVEs Common Vulnerabilities and Exposures, or “CVEs”, are identifiers for specific vulnerabilities. MITRE defines its CVE list as a “dictionary of publicly disclosed cybersecurity vulnerabilities and exposures that is free to search, use, and incorporate into products and services.” The CVE list feeds into the National Vulnerability Database (NVD). CVEs allow teams to track vulnerabilities that directly impact their system. In modern DevSecOps environments, it is common for CVE’s to be discovered during both build and runtime. A CVE matters because it provides traceability for each vulnerability that adversely impacts software. It is a way to describe and manage a discrete vulnerability. The name of a CVE simply provides the year each vulnerability was detected, which is useful. But the truly impactful part of each CVE as it matters to our everyday users come from the data and various scoring methods associated with each one. The scoring, description, and intelligence associated with each CVE are far more important than the CVE identifier itself. Anchore includes CVEs in our report generation as they are the primary way our customers trace the impact of a vulnerability on their images. In many popular attacks against container images, attackers focus on the software supply chain (such as storing malicious images in container registries, typosquatting attacks on packages/images, etc.) rather than probing an existing system for a specifically available exploit in a running image. That being said, beyond their value in identifying and tracking specific vulnerabilities, they lack the information required for a security team to take action. So Now What? But how does Anchore incorporate the importance of a CVE into their product? What can your team do to be more proactive with container security? Your security team can definitely help prevent typosquatting (see a good story at The New Stack about typosquatting and the dangers associated) and the downloading of malicious (accidentally, hopefully) images by your developers. Anchore can both help with supply chain oriented attacks in addition to taking the information we know about CVEs and using that as actionable data in our scanning policy. Whitelist/Blacklist Your Images and Packages To prevent this, Anchore easily provides the ability to blacklist images that may be suspicious, malicious, or simply up to no good in a public container registry. Navigate to your “policy tab”, select Edit Policy, then navigate to the whitelisted blacklisting images tab here: Under blacklisted images, you can select “let's add one.” You will see the screen below that allows you to add an image based on name (providing the registry, repo, and tag), by image ID, or by SHA digest. Blacklisting assumes you already know what is malicious and what is not. A more proactive approach would be whitelisting ONLY the images you want to use so that any other images, malicious or otherwise, are flagged for review in Anchore before they hit production. You also have the option to take this a step further and whitelist/blacklist specific packages for your organization to prevent typosquatting attacks. Similarly, typosquatting attacks can happen on URLs, images, and even individual packages as was the case here where python packages contained legitimate code but had a setup.py script that would gather hostname and user information that would be sent back to another system. To prevent these unfortunate events from occurring in your container workloads, Anchore provides the ability to inspect your packages and blacklist specific package contents. You can view package contents here to understand the complete packages and files within your image to hunt for potentially malicious packages that wouldn’t be identified by a CVE. Anchore allows you to make user-defined policy so you can easily blacklist malicious packages that are independently discovered by your security team or a part of any threat intelligence you are acting upon.  You can do this by navigating to policy checks and either adding to an existing policy or creating a new one. For this example, I will create a specific policy called “Typosquatting Checks” here: I will then tailor this policy for specific known malicious packages that may be impersonating legitimate packages, and create a stop action in Anchore for any image that contains a malicious/fake package as seen here where we blacklist urlib3 (malicious package) that is impersonating urllib3 (legitimate package). Don’t Boil the CVE Ocean: Incorporate CVSS Scoring into Scanning Another more proactive way to tackle the management of CVEs in your environment, albeit not perfect given some flaws of scoring, is to integrate scoring into your scanning policy. The Common Vulnerability Scoring System (CVSS) is “an open framework for communicating the characteristics and severity of software vulnerabilities.” A way of explaining this is depicted below: Source: NVD At a high level, you can correlate a CVE with its CVSS score to determine which CVEs have the greatest impact on your system by looking at two things: Exploitability Impact The higher the score on either of these factors, the more concern it should have for your security team. If a CVE has a very high exploitation score of a 9.5, but has a very low impact with a score of 2.0 then maybe it shouldn’t be a high priority. The same is true if you have a high impact score, but low exploitation score, which can commonly be the case if an attack vector isn’t widely available or if certain privileges are required in order to execute the attack and actually exploit the vulnerability. There are many other things that should be looked at when assessing vulnerability exploitation such as attack vectors, associated privileges, and attack complexity. We put the power in the hands of the security teams to define the terms of policy enforcement for their container images. One way to make an intuitive policy using Anchore is to click “Add New Policy.” There are 10+ selectors you can use to create your policy, such as CVSS base score, exploitability score, impact score, and fix availability. This way, you aren’t scanning “just to scan” and check the compliance box for your next audit. You are scanning proactively, using a collection of user-defined acceptance rule checks to generate an actionable list of vulnerability and compliance findings immediately addressable by your security team.  By taking these steps, your teams can gain more security insight about the containers they are using instead of routinely gathering the CVE’s and attempting to solve your security woes by boiling the entire “CVE ocean." ### Anchore and GitHub Actions, A Tutorial In this blog we're going to show you how, with very little code, you can add robust security scanning, alerting and reporting to your existing GitHub projects. (If you don’t get why, check out our GitHub Actions intro blog for some more background). First, go into your Github repository and find the Action tab; it should be about midway along, as shown in the screenshot below: If you've not set up any actions in this repo before, you'll be greeted by the default setup screen. We're going to skip this by selecting the option on the left-hand side titled, 'set up this workflow yourself'. This link takes us to the Action editor. You'll find it has some example code already in place. So, go ahead and replace it with the following workflow: name: Anchore Scan on: [push] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v1 - name: Docker Build run: docker build . --file Dockerfile --tag testrepo/testimage:latest - uses: anchore/scan-action@v1 with: image-reference: "testrepo/testimage:latest" dockerfile-path: "./Dockerfile" fail-build: true If you are unfamiliar with Github Action syntax, you can find an excellent guide here. In this workflow, we are creating a job called 'Anchore Scan', and setting it to scan every time that code is pushed into the repository. In addition, we are checking out our source code into an Ubuntu container and building a container based on a Dockerfile found in the root of the project. Once the container is built, we then utilize Anchore Engine by calling the anchore/scan-action integration. As you can see, the scan-action takes three parameters: First, image-reference, refers to the tag of the Docker image we created in the previous step. Next, the dockerfile-path, highlights the Dockerfile, within the source code that is used to build it. Finally, we have the fail-build. This option marks the action as failed if Anchore Engine finds anything in breach of its default policy. This workflow is already looking pretty good, but we're going to take it a step further and post a Slack alert for failures, offering us interactive feedback on security issues. For the next step, you'll need a slack incoming webhook. Once you have the webhook, add it as a secret to your Github repository by going into Settings and then Secrets in your repository settings. Name the secret SLACK_WEBHOOK, and then add the following code to the workflow: - name: Send alert if: failure() uses: rtCamp/action-slack-notify@v2.0.0 env: SLACK_CHANNEL: general SLACK_COLOR: '#3278BD' SLACK_ICON: https://github.com/rtCamp.png?size=48 SLACK_MESSAGE: 'Post Content :rocket:' SLACK_TITLE: Post Title SLACK_USERNAME: rtCamp SLACK_WEBHOOK: ${{ secrets.SLACK_WEBHOOK }} This code uses another custom action to send messages to slack. Note the if: failure() directive; this ensures that the message is only sent if our Anchore scan failed, which in most cases means it found a security issue (because, although we’re lovely people, you only really want to hear from us if there is a problem). Last up, we're going to add a final action to our workflow to collect the detailed reports that Anchore Engine provides when scanning a container. These reports contain relevant data such as the bill of materials, any CVEs found and detailed build logs (maybe you can think of a security-focused colleague who finds this sort of stuff compelling). Add the following code to your workflow: - name: Upload artifact uses: actions/upload-artifact@v1.0.0 with: name: AnchoreReports path: ./anchore-reports/ This code makes use of the upload-artifact Action. It takes the contents of the anchore-reports directory created by Anchore, zips it, and makes it available as a build artifact. Now we're ready to add our workflow. Click the 'start commit' button on the right-hand side, and commit the action to our repository. Since this is a code push into the repository, it triggers the workflow we've just created. Click on the actions tab in your repository to be taken to a list of workflows. On the left, you should see our workflow, and if you click on it, you'll see the current output for the running job. Once it's finished you should see output similar to the screenshot below: If you examine the details of the `runanchore/scan` step inside the build log, you should see something similar to the following screenshot: We've got a few warnings, but otherwise, we're in good shape. Finally, clicking on the Artifacts tab on the top right-hand side downloads the Anchore Engine reports. This gives us an amazing depth of knowledge on the image we scanned. With Github Actions, a few lines of YAML and Anchore Engine, you can embed container scanning into the developer workflow, pushing this increasingly crucial security practice left and into the hands of developers. This immediate and easy feedback helps you keep your projects and data secure, without an enormous overhead. To check out the full documentation for Anchore Github Actions and take a more detailed look at additional functionality such as custom policies visit the GitHub page. As always, we'd love to hear your feedback, and we hope you love using Anchore in Github as much as we do. ### Anchore and GitHub Actions GitHub gets a lot of love from most developers, and the team here at Anchore are no exception. Deemed worthy of its own top-level tab in every repo, Actions is GitHub's newest tool for automating your software workflows with world-class CI/CD. Users get DevOps pipelines with the ability to build, test, and deploy code directly from GitHub. Add in Anchore to this already heady cocktail, and GitHub Actions can now deliver a practical DevSecOps workflow - straight from the repo. This ensures that, when your container is ready to deploy into any environment, it has had a rigorous security scan. You deploy the code you intend to and nothing else; your dependencies are scanned, and any potentially nasty surprises made visible. If we already have your undivided attention at this point, feel free to jump right into our tutorial, which shows you how, with very little code, you can add robust security scanning, alerting and reporting to your existing GitHub projects. Meanwhile, if you are interested in more of the theory and reasoning behind Anchore, keep reading on... Why Shift Left Using GitHub Software development is now one of the most collaborative of all human endeavors. The web page you are reading right now is almost certainly the sum total of work from thousands of individual developers. Most of these people have never met each other, but they leverage each other’s work to create the technology that now underpins almost every facet of our daily lives. This collaboration extends widely; almost every 'smart' device, from your TV right through to your car makes use of software written by developers from almost every part of the globe. It is a modern-day wonder that powers a dizzying pace of innovation. And for many developers, GitHub has become the focus of much of this collaboration. It is more than just a place to store code, it is a vast, well-connected collaboration platform. Within GitHub, developers can share, review, reuse and work together on code, regardless of background or geographic location. However, maintaining security is challenging in this new collaborative world. It is now almost impossible to manually apply any form of effective security. So, like the Operations teams before, security now has to team up with developers: DevOps is becoming DevSecOps. And like its predecessor, DevSecOps is all about embracing automation, fast feedback loops and, of course, collaboration. Collectively, this trend is now widely referred to as 'shifting left'. Ok. So... why Shift Left Using GitHub? 1. The fast feedback loop Security has long been seen as a final, irritating inconvenience in the development process. Preventing developers from moving on to the next task. Security considerations appeared as late-stage scrutiny, putting developers through the wringer of fixing issues, only to find another bug has popped-up, after yet another manual or late security intervention. By marrying GitHub Actions and Anchore, developers get security feedback right alongside their existing unit tests. Fix, iterate, and fix again. Once your tests are clean, it's ready to go. Security becomes part of the same workflow developers know and love. 2. Easy to set up, easy to use GitHub is built for collaboration, and Actions are no exception. Anchor has done all the hard work for you, meaning you just need to include our Action and a handful of code. We've done the rest, giving you security and peace-of-mind without you having to tear your hair out managing complexity to get there. 3. One place to look GitHub is where developers go to work. It is a tool they interact with throughout the day, using it to store, test and collaborate on code. By making security front and center in their favorite tool, it means they have one place to look. Put the information somewhere else, and after the first rush of curiosity, it'll gather dust, unloved and uninspected. Anchore and GitHub Actions keep the security picture front and center. 4. Comprehensive and complete The Anchore engine is a powerful, Open Source container security scanning tool that the GitHub action makes use of. You get almost the same level of scrutiny, and peace of mind that you would get from running it on your desktop. It’s the perfect mashup of automation and power. To make Anchore engine fit with the ethos of GitHub actions we've chosen defaults that offer fast, concise and actionable reports based on the container contents. However, if you want a slower, but more detailed scan that includes application packages, you can enable it by using the include-app-packages option found in the GitHub Action docs. 5. Policy as code Because it's the full Anchore Engine, it means you can define your security policy as code and make use of it in the Action. This is the perfect blend of a fast feedback loop for developers, based on a security practitioner’s insight. It's like having your security team checking every element of your artifacts, 24/7, and letting the real practitioners drop the grunt work and focus on more valuable endeavors. If this has whetted your appetite, then check out our tutorial on GitHub Actions, which will show you how to integrate some of Anchore’s open source peace-of-mind into your pipeline, with just a handful of code. ### Anchore’s Approach to DevSecOps 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. ### Introducing Anchore Federal Open source software can produce surprising results. Once you create a project or application that solves real problems - and make it available under a license that enables it to be distributed throughout the world - it won’t be long before it turns up in all sorts of interesting projects and organizations. This has certainly been true for Anchore Engine. Since the formation of the project in 2016, we’ve seen over 30,000 separate installations and broad adoption of both Anchore’s open source tools and our enterprise products. So whilst not totally unexpected, in early 2019 we were happy to learn that Anchore had been adopted by the US Department of Defense as part of its software development pipeline. Throughout 2019, the DoD rolled out an aggressive modernization initiative, DoD Enterprises DevSecOps, championed by the USAF Chief Software Officer, Nicolas Chaillan. One of its key objectives is to introduce automated software tools, services, and standards to programs throughout the DoD. Enabling programs to create and deploy software applications in a secure, flexible, and interoperable manner is a mission that resonates strongly with the team here at Anchore. Over the last 12 months, our team has been working extensively with key Air Force stakeholders to meet these challenges, resulting in Anchore being one of the very few tools to be mandated as part of the DoD’s DevSecOps reference design. Our software is uniquely designed to identify and understand the exact composition of software containers and can enforce user-defined acceptance policies based on any DoD compliance standards. Our engineering teams continue to work alongside resources from the DoD and partner organizations to secure and harden software containers held within the DoD’s Centralized Artifact Repository. Based on the lessons we’ve learned so far, and the insight we continue to build, we’re pleased to announce the availability of Anchore Federal. Built on top of Anchore Enterprise, Anchore Federal adds a collection of out-of-the-box policy rules to validate compliance with the rigid security requirements of the DoD program. It also provides access, via support arrangements, to the engineering resources at the very forefront of the project to ensure partners and programs are implementing best practices. As adoption of the platform grows, Anchore engineering teams will continue to update the included policies to reflect the changing security and regulatory landscape. The team here at Anchore are excited about our ongoing participation with the program and are fully aligned behind the mission objectives. With the introduction of Anchore Federal, we look forward to enhancing the security of federal agencies’ application development lifecycles and drive cost savings through automation and shared best practice. ### Anchore: 2020 and Beyond Today marks a major milestone in the Anchore journey. Just a little over 3 years since we opened our doors, we have secured a substantial $20M round of funding that will allow us to address the next wave of container users around the world. I am utterly pleased and totally blown away by what a team of a little less than 20 has achieved in such a short period of time. Like I experienced in the early days of Ansible, just a thousand lines of code and few pages of documentation - built to address an existing gap in the market by smart, capable engineers - can drive ubiquitous adoption in a very short period of time. While building the Ansible brand a few years back, I had an opportunity to speak to customers and partners and see how containers, and Kubernetes, were transforming the way companies innovate. I quickly became convinced that the next generation compute platform would heavily leverage containers, and security would become key. Today, Gartner predicts that more than 75% of global companies will deploy containers in some capacity by 2022, and the total addressable market is estimated to be $2.1B by the year 2024 by MarketsandMarkets. Dan Nurmi, Anchore co-founder, and I knew there was a tremendous opportunity. Needing to better understand the security and compliance needs around containers, we decided to build a SaaS platform to test our assumptions. Thousands of users quickly adopted the platform, providing us critical directional feedback on the challenges users and organizations were facing. We have since used that experience to deliver what is now called Anchore Enterprise, our flagship product that is currently in use at large scale by many Fortune 1000 companies including Cisco and eBay, and is even considered a mandatory part of the United States Department of Defense DevSecOps reference architecture. Anchore’s mission is to empower developers to secure their container workflows in a manner that does not disrupt, distract or encumber them, allowing them to innovate at their own pace. Until now, software workload security has largely been addressed at runtime, but more and more we’re seeing that the majority of issues can be caught more easily during the software development lifecycle. That’s why we want to help organizations shift security left, ensuring that issues are found earlier through seamless integration with all major CICD platforms - whether deployed on-premises, in the public cloud, or through integration with GitHub Actions. But Anchore is more than just the technology we build. An internal company mandate has been to build both our products and our team with the same core principles that guided Ansible: kindness and accountability. Our goal was never to get from A to B in the shortest possible time; instead, to allow our longer-term vision to be realized while truly enjoying the journey of working with others. I am, once again, thrilled by the fact that those same principles led to another great outcome. Finally, in the journey to build a global brand, we’ve embarked on hiring great talent with strong open source and enterprise IT expertise. Our office locations already span both coasts, with team members in many US states and soon Europe. We are a fairly distributed team and we’re expecting aggressive growth in the many months to come. ### A Buyers' Guide to DevSecOps Echoing Dickens, for many in software security, it is the best of times and it is the worst of times. Every day brings literal front page news about software compromises resulting in massive data leaks. Meanwhile, the use of cloud-native technologies has meant that the variety and complexity of the software being deployed has outstripped the ability of traditional security processes and tools to protect their organizations. Security is no longer an afterthought of the IT department but a board-level issue that can cost people their jobs when failures happen. The security domain is finding answers to these challenges with new practices like DevSecOps and “Shift Left” strategies. These responses address the challenges in the security domain in a similar way to how software developers addressed their velocity and scale issues: by focusing on people and processes. As a cultural practice, DevSecOps is about breaking down barriers between developers, product security, and operations teams so security becomes a shared responsibility and is factored into all parts of the software lifecycle. Meanwhile, Shift Left is a posture that believes better security outcomes are achieved by being proactive in the development phase and enforcing best practices as early as possible. While recognizing that the ultimate challenges are often cultural and social, software tools and products can help drive change. But for the owner of the security budget, evaluating tools can be difficult, especially where traditionally the security team has only been called in post-hoc to the development of software or the operation of the platform. What follows are five key new areas to consider when looking at tools for DevSecOps. Process Flexibility Not only are we in the early days of perfecting new security processes but many companies are still adjusting to using CI/CD tools or GitOps-based workflows. It is a safe bet to say that every year, there is some change to how your company does software development as you learn what does and doesn’t work for you. When choosing a security tool, it should have the flexibility to integrate with whatever tools you use to drive automation and be able to work in multiple stages of the software development lifecycle. Look for products with full API coverage and an automation-centric architecture. The GUI is important but it should only be something you interact with for ad-hoc or post-hoc reasons. It’s more important that you can push information into the system and get data out using a variety of tools or custom scripts. Signal to Noise The ultimate goal is to avoid slowing down development velocity while ensuring developers take responsibility for security. This means they can’t be distracted with excessive data or false positive security alerts. Every security tool can generate a long list of issues for almost every software library or container and indeed this has been one of the calling cards of more traditional legacy tools: the more results, the better. You should verify that there is a way to separate the signal from the noise and that developers can get immediate and useful information to help them resolve issues or make updates as efficiently as possible. Following on from process flexibility, you also need to ensure that that information can get to the developers as part of their normal workflow; security issues are just another type of bug and creating separate security-specific workflows will add friction. Software Bill of Materials (SBOM) Supply chain security has become a top issue as a result of the increasing use of open source components and the well-publicized compromises found in various projects. With developers now making the decision about what code to use or re-use and releases often happening multiple times a day, periodic audits don’t work anymore. A Shift Left approach requires that a complete inventory of every piece of code has to be maintained in real-time. This allows ongoing scanning to be performed so the impact of CVEs can be assessed instantly and doesn’t require a crawl of deployed applications. Data-driven Anomaly Detection When it comes to runtime, the environment has changed to zero-trust models and immutability as a line of defense but the security techniques are the same: look for anomalies and alert. Agent-based approaches make much less sense in the cloud where containers may not even make running them possible. This is pushing detection to a data-based approach where algorithms can spot anomalies more effectively than admins looking for odd peaks or troughs in telemetry data. As algorithms are only as effective as the data they are applied, tools that collect data from both the platform and the application layer are critical. Policy as Code For many, a security policy is captured in Word documents and applied variably with product security teams acting as enforcers through spot checks and annoying requests for reports. DevSecOps evangelizes for repeatability, velocity and automation so in other words: no spreadsheets! It’s critical that policy can be codified and enforced consistently throughout the SDLC in a way that evolves as the threats change. Modern security products treat policy as something akin to another QA test that has to be passed. In this way, policy becomes just another software artifact to be developed, versioned and shipped. Out of the box policies can help you create a solid baseline but flexible policy options are critical for any organization that wants to manage the trade-off between shipping velocity and good-enough security. Many of the traditional criteria still apply when choosing a security product: choose a vendor that understands your challenges; look for platform agnosticism and avoid lock-in; and select usability over complexity. But understanding that new challenges require new approaches will help you navigate a growing and complex ecosystem. ### Announcing Anchore Enterprise 2.2 Just in time for the holidays, Anchore Enterprise 2.2, our latest update, is now generally available to all of our customers. For this release, we focus on third-party integrations to send notifications, and a new system dashboard to help customers view the status of their systems. This new enterprise release is based on open source Anchore Engine 0.6.0, also available now. New Integrations with GitHub, Jira, Slack & Microsoft Teams Anchore Enterprise is commonly used in either a CI/CD pipeline with a container registry or with a Kubernetes admission controller, to analyze and report on any container image issues. When an image fails a policy check, you typically want to notify your developers as soon as possible so they can fix the issue. With our new integrations, these notifications can now be sent to popular workflow tools (or via plain old email if you prefer), enabling the information to be used as part of existing processes. Notifications can optionally be separated by account, by type (system or user) and by level (info, warn, error), which allows you to send alerts about security vulnerabilities to one set of users and notifications about the Anchore system itself to another. Importantly for images, notifications are sent not only at the time of the initial scan, but also when a new vulnerability is detected in a previously scanned image, or when a policy is changed that causes an image to be marked as “out of compliance’. The notification service is a fantastic way of creating remediation workflows from the security team to the developers, or as part of an automated system. Look for upcoming Anchore integrations with other systems. System Dashboard and Feed Sync Status Anchore Enterprise is a distributed application consisting of many parts, including a database, a message queue, a report engine, a policy engine and so on. To help users see the status of each component, we’ve added a new system dashboard which makes it easier to troubleshoot issues and understand the roles of the various services. The dashboard also reports which vulnerability data sources have been successfully downloaded. Anchore Enterprise downloads a complete set of vulnerability data for use locally, reducing the need to send data back and forth over the internet, and enabling air-gapped operations. This way, you are ensured that you are receiving data from all relevant sources and that the data is up to date, which is critical for securing your container images. Looking Into 2020 We are planning one more release in the 2 series for early 2020. After that, we will focus on version 3 of the product which will significantly expand Anchore’s policy-based security capabilities by supporting all aspects of the container’s journey, from code to cloud. As more companies adopt DevSecOps practices, we hear feedback from our users that every step of the software development lifecycle should be enforced with clear policies that prevent the introduction of inadvertent or malicious flaws. We look forward to hearing feedback from our users about their experiences with Anchore Enterprise 2.2 and collaborating on the next phase of the Anchore roadmap. ### GitHub Actions Reduces Barrier for Improving Security GitHub has been a key vendor in making the developer experience friction-free and many of the features they announced this week at their GitHub Universe conference continue to set the standard. What was notable at the event this week was that security has now been added to the fiction-free mantra and, for anyone who has worked in the security industry, this is not a combination of words you typically hear. Indeed security is mostly seen as being a friction-adder par excellence, so it was really encouraging to see security as the core theme of the day 2 keynote, along with multiple product announcements and talks. Ensuring that security can be added to container workflows with as little overhead as possible is at the core of Anchore’s mission and a key driver of general DevSecOps practices. The fact that GitHub, as the largest hoster of open source content in the world, is getting behind this is great for everyone in the community. As we announced two days ago, we spent a number of weeks collaborating with GitHub to produce our Anchore Container Scan action. As Zach Hill, Chief Architect at Anchore, and Steve Winton, Senior Partner Engineer at GitHub, demonstrated at one of the breakouts, starting with as little as 4 lines of YAML, you can add Anchore to a CI/CD workflow to generate a full scan of a container and use the output to pass or fail a build. It is hard to conceive of a simpler way to add security to the software development workflow. No manual crafting of Jenkins build jobs, no post-hoc scanning of a content registry - just a simple event-driven model that takes a few minutes to run. The ability to piece multiple actions together is the most interesting part of the GitHub Action story. The obvious workflow for developers to instrument is to build a container with their code, scan it using to Anchore, push it to the Github Packages registry and then deploy it with one of the AWS, Azure or Google cloud actions. But linking this to other security capabilities in GitHub is where it gets interesting. You could programmatically: create GitHub issues with information about security issues found and how to resolve them for developers to act on; create security notifications (or even a CVE) for users to see about your product; or, push all the resulting data from your scans to a database for security researchers to mine. We do seem to be at a moment in the industry where the scale of the problem is clear, the urgency to fix is now felt more broadly within organizations, and, finally, the tools and processes to start fixing it are becoming credible. By removing the friction, GitHub and others are hopefully reducing the cost of improving security while making the benefit ever more clear. As we continue to develop the Anchore Container Scan action, we’re keen to hear your ideas about how we can improve it to support these types of workflows. So please provide feedback in the repo or drop us an email. ### Anchore for GitHub Actions Today at Github Universe, we are announcing the availability of the Anchore Container Scan action for GitHub. Actions allow developers to automate CI/CD workflows, easily integrating tools like Anchore into their build processes. This new action was designed for teams looking to introduce security into their development processes. You can find the action in the GitHub Marketplace.  At Anchore, our mission is to enable secure container-based workflows without compromising velocity. By adding Anchore Container Scan into their build process, development teams can gain deep visibility into the contents of their images and create custom policies that ensure compliance. That means discovering and remediating vulnerabilities before publishing images...without adding manual steps that slow everything down. If you want to learn more about the Anchore Container Scan action, watch our latest webinar where Zach Hill, Chief Architect at Anchore, provides a quick overview and demonstration. ### The Delivery Hero Story, Inviting Security to the Party Last week, the team at Delivery Hero posted the first in a series of articles about bolstering container security and compliance in their DevOps container orchestration model using Anchore Engine. We think they did a fantastic job explaining their goals and sharing the progress they have made. Their article is a great read for those who are grappling with the same challenges. We believe it’s important to incorporate security best practices early in the development process, and the Restaurant Partner Solutions team at DeliveryHero has done so with Anchore Engine while keeping up with over one million daily orders. So if you haven’t yet read about their project, please take a look at the full article. ### Benefits of Static Image Inspection and Policy Enforcement In this post, I will dive deeper into the key benefits of a comprehensive container image inspection and policy-as-code framework.A couple of key terms: Comprehensive Container Image Inspection: Complete analysis of a container image to identify it’s entire contents: OS & non-OS packages, libraries, licenses, binaries, credentials, secrets, and metadata. Importantly: storing this information in a Software Bill of Materials (SBOM) for later use. Policy-as-Code Framework: a structure and language for policy rule creation, management, and enforcement represented as code. Importantly: This allows for software development best practices to be adopted such as version control, automation, and testing. What Exactly Comes from a Complete Static Image Inspection? A deeper understanding. Container images are complex and require a complete analysis to fully understand all of their contents. The picture above shows all of the useful data an inspection can uncover. Some examples are: Ports specified via the EXPOSE instruction Base image / Linux distribution Username or UID to use when running the container Any environment variables set via the ENV instruction Secrets or keys (ex. AWS credentials, API keys) in the container image filesystem Custom configurations for applications (ex. httpd.conf for Apache HTTP Server) In short, a deeper insight into what exactly is inside of container images allows teams to make better decisions on what configurations and security standards they would prefer their production software to have. How to Use the Above Data in Context? While we can likely agree that access to the above data for container images is a good thing from a visibility perspective, how can we use it effectively to produce higher-quality software? The answer is through policy management. Policy management allows us to create and edit the rules we would like to enforce. Oftentimes these rules fall into one of three buckets: security, compliance, or best-practice. Typically, a policy author creates sets of rules and describes the circumstances by which certain behaviors/properties are allowed or not. Unfortunately, authors are often restricted to setting policy rules with a GUI or even a Word document, which makes rules difficult to transfer, repeat, version, or test. Policy-as-code solves this by representing policies in human-readable text files, which allow them to adopt software practices such as version control, automation, and testing. Importantly, a policy as code framework includes a mechanism to enforce the rules created. With containers, standardization on a common set of best-practices for software vulnerabilities, package usage, secrets management, Dockerfiles, etc. are excellent places to start. Some examples of policy rules are: Should all Dockerfiles have effective USER instruction? Yes. If undefined, warn me. Should the FROM instruction only reference a set of “trusted” base images? Yes. If not from the approved list, fail this policy evaluation. Are AWS keys ever allowed inside of the container image filesystem? No. If they are found, fail this policy evaluation. Are containers coming from DockerHub allowed in production? No. If they attempt to be used, fail this policy evaluation. The above examples demonstrate how the Dockerfile analysis and secrets found during the image inspection can prove extremely useful when creating policy. Most importantly, all of these policy rules are created to map to information available prior to running a container. Integrating Policy Enforcement With policy rules clearly defined as code and shared across multiple teams, the enforcement component can freely be integrated into the Continuous Integration / Continuous Delivery workflow. The concept of “shifting left” is important to follow here. The principal benefit here is, the more testing and checks individuals and teams can incorporate further left in their software development pipelines, the less costly it will be for them when changes need to be made. Simply put, prevention is better than a cure. Integration as Part of a CI Pipeline Incorporating container image inspection and policy rule enforcement to new or existing CI pipelines immediately adds security and compliance requirements as part of the build, blocking important security risks from ever making their way into production environments. For example, if a policy rule exists to explicitly not allow a container image to have a root user defined in the Dockerfile, failing the build pipeline of a non-compliant image before pushing to a production registry is a fundamental quality gate to implement. Developers will typically be forced to remediate the issue they’ve created which caused the build failure and work to modify their commit to reflect compliant changes. Below depicts how this process works with Anchore: Anchore provides an API endpoint where the CI pipeline can send an image for analysis and policy evaluation. This provides simple integration into any workflow, agnostic of the CI system being used. When the policy evaluation is complete, Anchore returns a PASS or FAIL output based on the policy rules defined. From this, the user can choose whether or not to fail the build pipeline. Integration with Kubernetes Deployments Adding an admission controller to gate execution of container images in Kubernetes in accordance with policy standards can be a critical method to validate what containers are allowed to run on your cluster. Very simply: admit the containers I trust, reject the ones I don’t. Some examples of this are: Reject an image if it is being pulled directly from DockerHub. Reject an image if it has high or critical CVEs that have fixes available. This integration allows Kubernetes operators to enforce policy and security gates for any pod that is requested on their clusters before they even get scheduled. Below depicts how this process works with Anchore and the Anchore Kubernetes Admission Controller: The key takeaway from both of these points of integration is that they are occurring before ever running a container image. Anchore provides users with a full suite of policy checks which can be mapped to any detail uncovered during the image inspection. When discussing this with customers, we often hear, "I would like to scan my container images for vulnerabilities." While this is a good first step to take, it is the tip of the iceberg when it comes to what is available inside of a container image. Conclusion With immutable infrastructure, once a container image artifact is created, it does not change. To make changes to the software, good practice tells us to build a new container image, push it to a container registry, kill the existing container, and start a new one. As explained above, containers provide us with tons of useful static information gathered during an inspection, so another good practice is to use this information, as soon as it is available, and where it makes sense in the development workflow. The more policies which can be created and enforced as code, the faster and more effective IT organizations will be able to deliver secure software to their end customers. 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: Intro to DoD Software Factory Outline for Getting Up to Speed on the DoD Software Factory How Anchore Secures Software Factories ### Success With Anchore, Best Practices from our Customers Successful container and CI/CD security encompass not only vulnerability analysis but also a mindset based on integrating security with every step of the Software Development Life Cycle (SDLC). At Anchore, we believe incorporating early and frequent scanning with policy enforcement can help reduce overall security risk. This blog shares some of the elements that have helped our customers be successful with Anchore. Scan Early/Scan Often Anchore allows you to start analyzing right away, without changing your existing processes. There is no downside in putting an `anchore-cli image add ` at the end of your CI/CD pipeline, and then exploring how to use the results of vulnerability scans or policy evaluations later. Since all images added to Anchore are there until you decide to remove them, analysis can be revisited later and new policies can be applied as your organizational needs evolve. Scanning early catches vulnerabilities and policy violations prior to deploying into production. By scanning during the CI/CD pipeline, issues can be resolved prior to runtime narrowing the focus to issues that are solely runtime-related at that point. This “Shift Left” mentality moves application quality and security considerations closer to the developer, allowing issues to be addressed sooner in the delivery chain. Whether it’s CI/CD build plugins (Jenkins, CircleCI, etc.) or repository image scanning, adding security analysis to your delivery pipeline can reduce the time it takes to resolve issues as well as lower the costs associated with fixing security issues in production. To learn more about Anchore’s CI/CD integrations, take a look at our CI/CD documentation. To learn more about repository image analysis, see our Analyzing Images documentation. Custom Policy Creation At Anchore, we believe in more than just CVEs. Anchore policies act as a one-stop-checking-spot for Dockerfile best practices, as well as keep policy enforcement in-line with your organizational security standards, such as secret storage and application configuration within your container. At a high level, policy bundles contain the policies themselves, whitelists, mappings, whitelisted images, and blacklisted images. Policies can be configured to be compliant with NIST, ISO, and banking regulations, among many others. As industry regulations and auditing regularly affect the time to deployment, performing policy checks early in the CI/CD pipeline can help increase the speed of deployments without sacrificing auditing or regulation requirements. At a finer-grained level, custom policies can enforce organizational best practices at an earlier point in the pipeline, enabling cross-group buy-in between developers and security personnel. To learn more about working with Anchore policies, please see our Working with Policies documentation. Policy Enforcement with Notifications To build upon the above topic, another best practice is enabling notifications. With a typical CI/CD process, build failures prompt notifications to fix the build, whether it is due to a missing dependency or simply a typo. With Anchore, builds can be configured to fail when an analysis or a policy evaluation fails, prompting attention to the issue. Taking this a step further, Anchore enables notifications through webhooks that can be used to notify the appropriate personnel in the event that there is an update to a CVE or if a policy evaluation status changes. Anchore leverages the ability to subscribe to tags and images to receive notifications when images are updated, when CVEs are added or removed and when the policy status of an image changes so you can take a proactive approach to ensure security and compliance. Having the ability to stay on top of the notifications above allows for the appropriate methods for remediation and triage to take place. To learn more about using webhooks for notifications, please see our Webhook Configuration documentation. For an example of how notifications can be integrated with Slack, please see our Using Anchore and Slack for Container Security Notifications blog. Archiving Old Analysis Data There may be times that older image analysis data is no longer needed in your working set but, for security compliance reasons, the data needs to be retained. Adding an image to the archive includes all analyses, policy evaluations, and tags for an image, allowing you to delete the image from your working set. Manually moving images to an archive can be cumbersome and time-consuming, but automating the process reduces the number of images in your working set while still retaining the analysis data. Archiving analysis data backs it up, allowing it to be removed from the working set; it can always be moved back should something in the policy change, an organizational shift occurs, or you simply want it back in the working set. Archiving image data keeps the live set of images in line with what is current; over time, it could become cumbersome to continuously be running policy evaluations and vulnerability scans against images that are old and potentially not important. Archiving them keeps the working set lighter. Anchore’s archiving service makes it simple to automatically archive images and their data, implemented via adding rules to the analysis archive. With such rules, images with an analyzed date older than a specified number of days, specific tags, and the number of images can be automatically added to the archive, making it simpler to work with the newer images your organization is concerned with while maintaining the analysis data of older images. To learn more about archiving old analysis data, please see our Using the Analysis Archive documentation. To learn more about working with archiving rules, please see our Working with Archive Rules documentation. Leveraging External Object Storage to Offload Database Storage Anchore Engine uses a PostgreSQL database to store structured data for images, tags, policies, subscriptions, and metadata about images by default, but other types of data in the system are less structured and tend to be larger pieces of data. Because of that, there are benefits to supporting key-value access patterns for things like image manifests, analysis reports, and policy evaluations. For such data, Anchore has an internal object storage interface that, while defaulted to use the same PostgreSQL database for storage, can be configured to use external object storage providers to support simpler capacity management and lower costs. By offloading the database storage, it eliminates the need to scale-out PostgreSQL while speeding up its performance. As the database grows, the various queries that are run against it and writing new data to it slow down, in turn slowing the productivity of Anchore. By leveraging an external object store and removing bulk data from PostgreSQL, only the relevant image metadata will be stored there, while other important data is stored externally and can be archived at lower costs. To learn more about using any of our supported external object storage drivers, please see our Object Storage documentation. Conclusion Leveraging some of the best practices that have made our customers successful can help your organization achieve the same success with Anchore. As an open-source community, we value feedback and hearing about what best practices the community has developed. ### Anchore Talk Webinar, Redefining the Software Supply Chain We are pleased to announce Anchore Talks, a series of short webinars to help improve Kubernetes and Docker security best practices. We believe it is important to have excellent security measures in place when adopting containers, and that drives every decision we make when developing Anchore Enterprise and Anchore Engine. These talks, no longer than 15 minutes each, will share our perspective on the challenges and opportunities presented to today’s DevSecOps professionals and offer clear, actionable advice for securing the build pipeline. Containers can create quite a few headaches for security professionals because they increase velocity and allow developers to pull from a wider variety of software. Fortunately, they can also offer more efficient tracking and oversight for your software supply chain, making it much easier to scan, find and patch vulnerabilities during the build process. Using containers, security can be baked in from the start, keeping the velocity of the build process high. Anchore VP of Product Neil Levine has prepared our first Anchore Talk on this new approach to security, starting with how developers can source containers responsibly finishing with container immutability and its impact on audits and compliance. You won’t want to miss this brief 10-15 minute talk live on October 28th, starting at 10 am PST! It will also be available on-demand once you have signed up for a BrightTalk account. If keeping systems secure is your full-time job, we have some exciting content coming your way. ### Anchore and Google Distroless The most recent open source release of Anchore Engine (0.5.1), which is also available as part of Anchore Enterprise 2.1, added support for Google Distroless containers. But what are they and why is the addition notable? When containers were first starting to be adopted, it was natural for many users to think of them as stripped-down virtual machines which booted faster. Indeed, if you look at the container images published by the operating system vendors, you can see that in most instances they take their stock distribution and remove all the parts they consider unnecessary. This still leaves images that are pretty large, in the hundreds of megabytes, and so some alternative distributions have become popular, notably Alpine which based on Busybox and the MUSL C library had its roots in the embedded space. Now images can be squeezed into the tens of megabytes, enabling faster build, downloads and a reduced surface area for vulnerabilities. However, these images still ape VMs, enabling shell access and containing package managers, designed to let users grow and modify them. Google wanted a different approach that saw a container image as essentially a language runtime environment that was curated by the application teams themselves. The only thing that should be added to it was the actual application itself. The resulting family of images known as Distroless are only slightly larger than thin distros like Alpine but, by contrast, have better compatibility by using standard libraries (e.g. libc rather than MUSL). As Google Distroless images are based on Debian packages, Anchore is now able to scan and report on any security findings in the base images as well as in the language files installed. The images are all hosted on the Google Container Registry (GCR) and are available with Java and C (with experimental support also available for Python, NPM, Node and .Net). We can add them using the regular syntax for Anchore Engine on the CLI: anchore-cli image add gcr.io/distroless/java:11 Being so small, the images are typically scanned in a minute or less. Using the Anchore Enterprise GUI, you can see the image is detected as being Debian: Looking at its contents, you can see the image has very little in it - only 19 Debian packages, including libc6: As standard Debian packages, Anchore can scan these and alert for any vulnerabilities. If there are fixes available, you can configure Anchore to trigger a rebuild of the image. There is only one warning generated on the image by the standard Anchore policy which relates to the lack of a Dockerfile health check but other than that, this image - given its lean nature, is vulnerability free. If you are using a compiled binary application like Java, another new feature allows you to add the hash of the binary to the Anchore policy check which means you can enforce a strict compliance check on every build that goes through your CI/CD. This will ensure that literally no other modifications are being made to the base images other than the application being layered on top. For users who still need access to a shell for debugging or viewing locally stored log files, they may still prefer to use Alpine or other minimal ages, but or those fully vested in the cloud-native deployment model where containers conform to 12-factor best practices, Google Distroless images are a great asset to have in your development process. You can find more information about Google Distoless on GitHub and existing users of both Anchore Engine or Anchore Enterprise just need to download the latest version to enable support. ### Anchore Engine 0.5.1 Release We are pleased to announce the immediate availability of Anchore Engine 0.5.1, the latest point update to our open source software from Anchore that helps users enforce container security, compliance, and best practice requirements. This update not only adds bug fixes and performance improvements but also adds a new policy gate check and support for Google’s distroless images. Google’s distroless images are helping businesses tighten up security while speeding up the build, scan, and patch process for DevOps teams. Because these images only contain the application's resources and runtime dependencies, the attack surface is significantly reduced and the process of scanning for and patching vulnerabilities becomes much simpler. Using distroless container images can help DevOps teams save time and become more agile in their development pipeline while keeping security at the forefront. For more documentation on distroless container images, take a look here. Also in this release, our engineers have taken policy check to the next level with our secret search gate. Previously, our secret search gate made sure vulnerable information was not left in plain sight for hackers to exploit. Now you can use it to make sure necessities aren’t missing from your config file within your image. If you haven’t already deployed Anchore Engine, you can stand it up alongside your favorite cloud native tools, begin hardening your container images and adhering to federally accepted compliance and best practices. We are incredibly thankful for our open source community and can’t wait to share more project updates! For more information about the release, check out our release notes. ### Visit AWS Marketplace For Anchore Engine on EKS In this post, I will walk through the steps required to deploy the Anchore Engine Marketplace Container Image Solution on Amazon EKS with Helm. Amazon Elastic Kubernetes Service (Amazon EKS) is a managed service that makes it easy for users to run Kubernetes on AWS without needing to install and operate their own clusters. For many users looking to deploy Anchore Engine, Amazon EKS is a simple choice to reap the benefits of Kubernetes without the operational overhead. Prerequisites Before you begin, please make sure you have fulfilled the prerequisites detailed below. At a minimum, you should be comfortable working with the command-line and have a general understanding of how to work with Kubernetes applications. A running Amazon EKS cluster with worker nodes launched. See EKS Documentation for more information on this setup. Helm client and server installed and configured with your EKS cluster. Anchore CLI installed on localhost. Once you have an EKS cluster up and running with worker nodes launched, you can verify via the following command. $ kubectl get nodes NAME STATUS ROLES AGE VERSION ip-192-168-2-164.ec2.internal Ready 10m v1.14.6-eks-5047ed ip-192-168-35-43.ec2.internal Ready 10m v1.14.6-eks-5047ed ip-192-168-55-228.ec2.internal Ready 10m v1.14.6-eks-5047ed Anchore Engine Marketplace Listing Anchore Engine allows users to bring industry-leading open source container security and compliance to their container landscape in EKS. Deployment is done using the Anchore Engine Helm Chart, which can be found on GitHub. So if you are already running an EKS cluster with Helm configured, you can now deploy Anchore Engine directly from the AWS marketplace to tighten up your container security posture. To get started, navigate to the Anchore Engine Marketplace Listing, and select "Continue to Subscribe", "Continue to Configuration", and "Continue to Launch". On the Launch Configuration screen, select "View container image details" Selecting this will present the popup depicted below. This will display the Anchore Engine container images you will be required to pull down and use with your deployment. There are two container images required for this deployment: Anchore Engine and PostgreSQL. Next, follow the steps on the popup to verify you are able to pull down the required images (Anchore Engine and Postgres) from Amazon ECR. Anchore Custom Configuration Before deploying the Anchore software, you will need to create a custom anchore_values.yaml file to pass the Anchore Engine Helm Chart during your installation. The reason behind this is the default Helm chart references different container images than the ones on AWS Marketplace. Additionally, in order to expose our application on the public internet, you will need to configure ingress resources. As mentioned above, you will need to reference the Amazon ECR Marketplace images in this Helm chart. You can do so by populating your custom anchore_values.yaml file with image location and tag as shown below. postgresql: image: 709373726912.dkr.ecr.us-east-1.amazonaws.com/e4506d98-2de6-4375-8d5e-10f8b1f5d7e3/cg-3671661136/docker.io/library/postgres imageTag: v.0.5.0-latest imagePullPolicy: IfNotPresent anchoreGlobal: image: 709373726912.dkr.ecr.us-east-1.amazonaws.com/e4506d98-2de6-4375-8d5e-10f8b1f5d7e3/cg-3671661136/docker.io/anchore/anchore-engine imageTag: v.0.5.0-latest imagePullPolicy: IfNotPresent Note: Since the container images live in a private ECR registry, you will also need to create a secret with valid Docker credentials in order to fetch them. Example Steps to Create a Secret # RUN me where kubectl is available,& make sure to replace account,region etc # Set ENV vars ACCOUNT=123456789 REGION=my-region SECRET_NAME=${REGION}-ecr-registry EMAIL=email@email.com ( can be anything) # # Fetch token (which will expire in 12 hours) # TOKEN=`aws ecr --region=$REGION get-authorization-token --output text --query authorizationData[].authorizationToken | base64 -d | cut -d: -f2` # # Create registry secret # kubectl create secret docker-registry $SECRET_NAME --docker-server=https://${ACCOUNT}.dkr.ecr.${REGION}.amazonaws.com--docker-username=AWS --docker-password="${TOKEN}" --docker-email="${EMAIL}" Once you have successfully created the secret, you will need to add ImagePullSecrets to a service account. I recommend reading more about how you can add ImagePullSecrets to a service account here. Ingress (Optional) One of the simplest ways to expose Kubernetes applications on the public internet is through ingress. On AWS, an ALB ingress controller can be used. It is important to note that this step is optional, as you can still run through a successful installation of the software without it. You can read more about Kubernetes Ingress with AWS ALB Ingress Controller here. Anchore Ingress Configurations Just as we did above, any changes to the Helm chart configuration should be made in your anchore_values.yaml Ingress First, you should create an ingress section in your anchore_values.yaml file as shown in the code block below. The key properties here are apiPath and annotations. ingress: enabled: true # Use the following paths for GCE/ALB ingress controller apiPath: /v1/* # uiPath: /* # apiPath: /v1/ # uiPath: / # Uncomment the following lines to bind on specific hostnames # apiHosts: # - anchore-api.example.com # uiHosts: # - anchore-ui.example.com annotations: kubernetes.io/ingress.class: alb alb.ingress.kubernetes.io/scheme: internet-facing Anchore Engine API Service Next, you can create an anchoreApi section in your anchore_values.yaml file as shown in the code block below. The key property here is changing service type to NodePort. # Pod configuration for the anchore engine api service. anchoreApi: replicaCount: 1 # Set extra environment variables. These will be set on all api containers. extraEnv: [] # - name: foo # value: bar # kubernetes service configuration for anchore external API service: type: NodePort port: 8228 annotations: {} AWS EKS Configurations Once the Anchore configuration is complete, you can move to the EKS specific configuration. The first step is to create an IAM policy to give the Ingress controller we will be creating the proper permissions. In short, you need to allow permission to work with ec2 resources and create a load balancer. Create the IAM Policy to Give the Ingress Controller the Right Permissions Go to the IAM Console. Choose the section Roles and search for the NodeInstanceRole of your EKS worker nodes. Create and attach a policy using the contents of the template iam-policy.json Next, deploy RBAC Roles and RoleBindings needed by the AWS ALB Ingress controller from the template below: wget https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.0.0/docs/examples/rbac-role.yaml kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.0.0/docs/examples/rbac-role.yaml Update ALB Ingress Download the ALB Ingress manifest and update the cluster-name section with the name of your EKS cluster name. wget https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.0.1/docs/examples/alb-ingress-controller.yaml # Name of your cluster. Used when naming resources created # by the ALB Ingress Controller, providing distinction between # clusters. - --cluster-name=anchore-prod Deploy the AWS ALB Ingress controller YAML: kubectl apply -f alb-ingress-controller.yaml Installation Now that all of the custom configurations are completed, you are ready to install the Anchore software. First, ensure you have the latest Helm Charts by running the following command: helm repo update Install Anchore Engine Next, run the following command to install the Anchore Engine Helm chart in your EKS cluster: helm install --name anchore-engine -f anchore_values.yaml stable/anchore-engine The command above will install Anchore Engine using the custom anchore_values.yaml file you've creaed You will need to give the software a few minutes to bootstrap. In order to see the ingress resource we have created, run the following command: $ kubectl describe ingress Name: anchore-enterprise-anchore-engine Namespace: default Address: xxxxxxx-default-anchoreen-xxxx-xxxxxxxxx.us-east-1.elb.amazonaws.com Default backend: default-http-backend:80 () Rules: Host Path Backends ---- ---- -------- * /v1/* anchore-enterprise-anchore-engine-api:8228 (192.168.42.122:8228) Annotations: alb.ingress.kubernetes.io/scheme: internet-facing kubernetes.io/ingress.class: alb Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal CREATE 14m alb-ingress-controller LoadBalancer 904f0f3b-default-anchoreen-d4c9 created, ARN: arn:aws:elasticloadbalancing:us-east-1:077257324153:loadbalancer/app/904f0f3b-default-anchoreen-d4c9/4b0e9de48f13daac Normal CREATE 14m alb-ingress-controller rule 1 created with conditions [{ Field: "path-pattern", Values: ["/v1/*"] }] The output above shows you that a Load Balancer has been created in AWS with an address you can hit in the browser. A great tool to validate that the software is up and running is the Anchore CLI. Additionally, you can use this tool to verify that the API route hostname is configured correctly: Note: Read more on Configuring the Anchore CLI $ anchore-cli --url http://anchore-engine-anchore-engine.apps.54.84.147.202.nip.io/v1 --u admin --p foobar system status Service analyzer (anchore-enterprise-anchore-engine-analyzer-cfddf6b56-9pwm9, http://anchore-enterprise-anchore-engine-analyzer:8084): up Service apiext (anchore-enterprise-anchore-engine-api-5b5bffc79f-vmwvl, http://anchore-enterprise-anchore-engine-api:8228): up Service simplequeue (anchore-enterprise-anchore-engine-simplequeue-dc58c69c9-5rmj9, http://anchore-enterprise-anchore-engine-simplequeue:8083): up Service policy_engine (anchore-enterprise-anchore-engine-policy-84b6dbdfd-fvnll, http://anchore-enterprise-anchore-engine-policy:8087): up Service catalog (anchore-enterprise-anchore-engine-catalog-b88d4dff4-jhm4t, http://anchore-enterprise-anchore-engine-catalog:8082): up Engine DB Version: 0.0.11 Engine Code Version: 0.5.0 Conclusion With Anchore installed on EKS, Security and DevOps teams can seamlessly integrate comprehensive container image inspection and policy enforcement into their CI/CD pipeline to ensure that images are analyzed thoroughly for known vulnerabilities before deploying them into production. This will not only avoid the pain of finding and remediating vulnerabilities at runtime but also allow the end-user to define and enforce custom security policies to meet their specific company’s internal policies and any applicable regulatory security standards. We are happy to provide users with the added simplicity of deploying Anchore software on Amazon EKS with Helm as a validated AWS Marketplace container image solution. ### Anchore Engine Available in Azure Marketplace We are pleased to announce the immediate availability of Anchore Engine in the Azure marketplace. Microsoft has grown its cloud native development and DevOps offerings significantly in the past two years. The Azure offerings available today such as Azure Container Instances (ACI), Azure Kubernetes Service (AKS), and Azure Pipelines give enterprises and agencies the tools they need to build scalable, cloud native applications. With Azure, Microsoft helps organizations innovate and grow while saving time and money, enabling business transformation and increased competitiveness. At Anchore, we have a similar mission. We want organizations to innovate quickly with containers but be confident that the software they ship is safe. Our comprehensive container image inspection and analysis solution is a perfect fit for the kind of innovative enterprises and agencies that use Azure. That is why we are proud to make it available through the Azure Marketplace. Give it a try! If you don’t already have an Azure account, you can get one for free. Then, check out our marketplace page to get started. ### Anchore Enterprise 2.1 Features Single Sign-On (SSO) With the release of Anchore Enterprise 2.1 (based on Anchore Engine v0.5.0), we are happy to announce integration with external identity providers that support SAML 2.0. Adding support for external identity providers allows users to enable Single Sign-On for Anchore, reducing the number of user stores that an enterprise needs to maintain. Authentication / Authorization SAML is an open standard for exchanging authorization and authentication (auth-n/auth-z) data between an identity provider (IdP) and a service provider (SP). As an SP, Anchore Enterprise 2.1 can be configured to use an external IdP such as Keycloak for auth-n/auth-z user transactions. When using SAML SSO, users log into the Anchore Enterprise UI via the external IdP without ever passing credentials to Anchore. Information about the user is passed from the IdP to Anchore and Anchore initializes the user’s identity within itself using that data. After first sign-in, the username exists without credentials in Anchore and additional RBAC configuration can be done on the identity directly by Anchore administrators. This allows Anchore administrator users to control access of their own users without also having to have access to a corporate IdP system. Integrating Anchore Enterprise with Keycloak The JBoss Keycloak auth-n/auth-z IdP is a widely used and open-source identity management system that supports integration with applications via SAML and OpenID Connect. It also can operate as an identity broker between other providers such as LDAP or other SAML providers and applications that support SAML or OpenID Connect. In addition to Keycloak, other SAML supporting IdPs could be used, such as Okta or Google’s Cloud Identity SSO. There are four key features that an IdP must provide in order to successfully integrate with Anchore: It must support HTTP Redirect binding. It should support signed assertions and signed documents. While this blog doesn’t apply either of these, it is highly recommended to use signed assertions and documents in a production environment. It must allow unsigned client requests from Anchore. It must allow unencrypted requests and responses. The following is an example of how to configure a new client entry in KeyCloak and configure Anchore to use it to permit UI via Keycloak SSO. Deploying Keycloak and Anchore For this example, I used the latest Keycloak image from Docker Hub (Keycloak v7.0.0). The default docker-compose file for Anchore Enterprise 2.1 includes options to enable OAuth. By default, these options are commented out. Uncommenting `ANCHORE_OAUTH_ENABLED` and `ANCHORE_AUTH_SECRET` will enable SSO. Using the following docker-compose file, I can deploy Keycloak with its own Postgres DB: version: '3' volumes: postgres_data: driver: local services: postgres: image: postgres volumes: - postgres_data:/var/lib/postgresql/data environment: POSTGRES_DB: keycloak POSTGRES_USER: keycloak POSTGRES_PASSWORD: password keycloak: image: jboss/keycloak environment: DB_VENDOR: POSTGRES DB_ADDR: postgres DB_DATABASE: keycloak DB_USER: keycloak DB_SCHEMA: public DB_PASSWORD: password KEYCLOAK_USER: admin KEYCLOAK_PASSWORD: Pa55w0rd ports: - 8080:8080 - 9990:9990 depends_on: - postgres Next, I can deploy Anchore Enterprise with the following docker-compose file: # All-in-one docker-compose deployment of a full anchore-enterprise service system --- version: '2.1' volumes: anchore-db-volume: # Set this to 'true' to use an external volume. In which case, it must be created manually with "docker volume create anchore-db-volume" external: false anchore-scratch: {} feeds-workspace-volume: # Set this to 'true' to use an external volume. In which case, it must be created manually with "docker volume create feeds-workspace-volume" external: false enterprise-feeds-db-volume: # Set this to 'true' to use an external volume. In which case, it must be created manually with "docker volume create enterprise-feeds-db-volume" external: false services: # The primary API endpoint service engine-api: image: docker.io/anchore/anchore-engine:v0.5.0 depends_on: - anchore-db - engine-catalog #volumes: #- ./config-engine.yaml:/config/config.yaml:z ports: - "8228:8228" logging: driver: "json-file" options: max-size: 100m environment: - ANCHORE_ENDPOINT_HOSTNAME=engine-api - ANCHORE_DB_HOST=anchore-db - ANCHORE_DB_PASSWORD=mysecretpassword - ANCHORE_AUTHZ_HANDLER=external - ANCHORE_EXTERNAL_AUTHZ_ENDPOINT=http://enterprise-rbac-authorizer:8228 - ANCHORE_ENABLE_METRICS=false - ANCHORE_LOG_LEVEL=INFO # Uncomment both ANCHORE_OAUTH_ENABLED and ANCHORE_AUTH_SECRET to enable SSO feature of anchore-enterprise - ANCHORE_OAUTH_ENABLED=true - ANCHORE_AUTH_SECRET=supersharedsecret command: ["anchore-manager", "service", "start", "apiext"] # Catalog is the primary persistence and state manager of the system engine-catalog: image: docker.io/anchore/anchore-engine:v0.5.0 depends_on: - anchore-db #volumes: #- ./config-engine.yaml:/config/config.yaml:z logging: driver: "json-file" options: max-size: 100m expose: - 8228 environment: - ANCHORE_ENDPOINT_HOSTNAME=engine-catalog - ANCHORE_DB_HOST=anchore-db - ANCHORE_DB_PASSWORD=mysecretpassword - ANCHORE_ENABLE_METRICS=false - ANCHORE_LOG_LEVEL=INFO # Uncomment both ANCHORE_OAUTH_ENABLED and ANCHORE_AUTH_SECRET to enable SSO feature of anchore-enterprise - ANCHORE_OAUTH_ENABLED=true - ANCHORE_AUTH_SECRET=supersharedsecret command: ["anchore-manager", "service", "start", "catalog"] engine-simpleq: image: docker.io/anchore/anchore-engine:v0.5.0 depends_on: - anchore-db - engine-catalog #volumes: #- ./config-engine.yaml:/config/config.yaml:z expose: - 8228 logging: driver: "json-file" options: max-size: 100m environment: - ANCHORE_ENDPOINT_HOSTNAME=engine-simpleq - ANCHORE_DB_HOST=anchore-db - ANCHORE_DB_PASSWORD=mysecretpassword - ANCHORE_ENABLE_METRICS=false - ANCHORE_LOG_LEVEL=INFO # Uncomment both ANCHORE_OAUTH_ENABLED and ANCHORE_AUTH_SECRET to enable SSO feature of anchore-enterprise - ANCHORE_OAUTH_ENABLED=true - ANCHORE_AUTH_SECRET=supersharedsecret command: ["anchore-manager", "service", "start", "simplequeue"] engine-policy-engine: image: docker.io/anchore/anchore-engine:v0.5.0 depends_on: - anchore-db - engine-catalog #volumes: #- ./config-engine.yaml:/config/config.yaml:z expose: - 8228 logging: driver: "json-file" options: max-size: 100m environment: - ANCHORE_ENDPOINT_HOSTNAME=engine-policy-engine - ANCHORE_DB_HOST=anchore-db - ANCHORE_DB_PASSWORD=mysecretpassword - ANCHORE_ENABLE_METRICS=false - ANCHORE_LOG_LEVEL=INFO # Uncomment the ANCHORE_FEEDS_* environment variables (and uncomment the feeds db and service sections at the end of this file) to use the on-prem feed service #- ANCHORE_FEEDS_URL=http://enterprise-feeds:8228/v1/feeds #- ANCHORE_FEEDS_CLIENT_URL=null #- ANCHORE_FEEDS_TOKEN_URL=null # Uncomment both ANCHORE_OAUTH_ENABLED and ANCHORE_AUTH_SECRET to enable SSO feature of anchore-enterprise - ANCHORE_OAUTH_ENABLED=true - ANCHORE_AUTH_SECRET=supersharedsecret command: ["anchore-manager", "service", "start", "policy_engine"] engine-analyzer: image: docker.io/anchore/anchore-engine:v0.5.0 depends_on: - anchore-db - engine-catalog #volumes: #- ./config-engine.yaml:/config/config.yaml:z expose: - 8228 logging: driver: "json-file" options: max-size: 100m environment: - ANCHORE_ENDPOINT_HOSTNAME=engine-analyzer - ANCHORE_DB_HOST=anchore-db - ANCHORE_DB_PASSWORD=mysecretpassword - ANCHORE_ENABLE_METRICS=false - ANCHORE_LOG_LEVEL=INFO # Uncomment both ANCHORE_OAUTH_ENABLED and ANCHORE_AUTH_SECRET to enable SSO feature of anchore-enterprise - ANCHORE_OAUTH_ENABLED=true - ANCHORE_AUTH_SECRET=supersharedsecret volumes: - anchore-scratch:/analysis_scratch - ./analyzer_config.yaml:/anchore_service/analyzer_config.yaml:z command: ["anchore-manager", "service", "start", "analyzer"] anchore-db: image: "postgres:9" volumes: - anchore-db-volume:/var/lib/postgresql/data environment: - POSTGRES_PASSWORD=mysecretpassword expose: - 5432 logging: driver: "json-file" options: max-size: 100m enterprise-rbac-authorizer: image: docker.io/anchore/enterprise:v0.5.0 volumes: - ./license.yaml:/license.yaml:ro #- ./config-enterprise.yaml:/config/config.yaml:z depends_on: - anchore-db - engine-catalog expose: - 8089 logging: driver: "json-file" options: max-size: 100m environment: - ANCHORE_ENDPOINT_HOSTNAME=enterprise-rbac-authorizer - ANCHORE_DB_HOST=anchore-db - ANCHORE_DB_PASSWORD=mysecretpassword - ANCHORE_ENABLE_METRICS=false - ANCHORE_LOG_LEVEL=INFO # Uncomment both ANCHORE_OAUTH_ENABLED and ANCHORE_AUTH_SECRET to enable SSO feature of anchore-enterprise - ANCHORE_OAUTH_ENABLED=true - ANCHORE_AUTH_SECRET=supersharedsecret command: ["anchore-enterprise-manager", "service", "start", "rbac_authorizer"] enterprise-rbac-manager: image: docker.io/anchore/enterprise:v0.5.0 volumes: - ./license.yaml:/license.yaml:ro #- ./config-enterprise.yaml:/config/config.yaml:z depends_on: - anchore-db - engine-catalog ports: - "8229:8228" logging: driver: "json-file" options: max-size: 100m environment: - ANCHORE_ENDPOINT_HOSTNAME=enterprise-rbac-manager - ANCHORE_DB_HOST=anchore-db - ANCHORE_DB_PASSWORD=mysecretpassword - ANCHORE_AUTHZ_HANDLER=external - ANCHORE_EXTERNAL_AUTHZ_ENDPOINT=http://enterprise-rbac-authorizer:8228 - ANCHORE_ENABLE_METRICS=false - ANCHORE_LOG_LEVEL=INFO # Uncomment both ANCHORE_OAUTH_ENABLED and ANCHORE_AUTH_SECRET to enable SSO feature of anchore-enterprise - ANCHORE_OAUTH_ENABLED=true - ANCHORE_AUTH_SECRET=supersharedsecret command: ["anchore-enterprise-manager", "service", "start", "rbac_manager"] enterprise-reports: image: docker.io/anchore/enterprise:v0.5.0 volumes: - ./license.yaml:/license.yaml:ro depends_on: - anchore-db - engine-catalog ports: - "8558:8228" logging: driver: "json-file" options: max-size: 100m environment: - ANCHORE_ENDPOINT_HOSTNAME=enterprise-reports - ANCHORE_DB_HOST=anchore-db - ANCHORE_DB_PASSWORD=mysecretpassword - ANCHORE_ENABLE_METRICS=false - ANCHORE_AUTHZ_HANDLER=external - ANCHORE_EXTERNAL_AUTHZ_ENDPOINT=http://enterprise-rbac-authorizer:8228 - ANCHORE_LOG_LEVEL=INFO # Uncomment both ANCHORE_OAUTH_ENABLED and ANCHORE_AUTH_SECRET to enable SSO feature of anchore-enterprise - ANCHORE_OAUTH_ENABLED=true - ANCHORE_AUTH_SECRET=supersharedsecret command: ["anchore-enterprise-manager", "service", "start", "reports"] enterprise-ui-redis: image: "docker.io/library/redis:4" expose: - 6379 logging: driver: "json-file" options: max-size: 100m enterprise-ui: image: docker.io/anchore/enterprise-ui:v0.5.0 volumes: - ./license.yaml:/license.yaml:ro #- ./config-ui.yaml:/config/config-ui.yaml:z depends_on: - engine-api - enterprise-ui-redis - anchore-db ports: - "3000:3000" logging: driver: "json-file" options: max-size: 100m environment: - ANCHORE_ENGINE_URI=http://engine-api:8228/v1 - ANCHORE_RBAC_URI=http://enterprise-rbac-manager:8228/v1 - ANCHORE_REDIS_URI=redis://enterprise-ui-redis:6379 - ANCHORE_APPDB_URI=postgres://postgres:mysecretpassword@anchore-db:5432/postgres - ANCHORE_REPORTS_URI=http://enterprise-reports:8228/v1 - ANCHORE_POLICY_HUB_URI=https://hub.anchore.io Once all containers are deployed, we can move into configuring SSO. Configure the Keycloak Client Adding a SAML client in Keycloak can be done following the instructions provided by SAML Clients in the Keycloak documentation. Once logged into the Keycloak UI, navigate to Clients and select Add Client. Enter http://localhost:3000/service/sso/auth/keycloak as the Client ID. This will be used later in the Anchore Enterprise SSO configuration. In the Client Protocol dropdown, choose SAML. Enter http://localhost:3000/service/sso/auth/keycloak as the Client SAML Endpoint. Select Save. Once added, I can now configure the Anchore Enterprise SSO relevant sections. The majority of the defaults provided by Keycloak are sufficient for the purposes of this blog. However, some configurations do need to be changed. Adding a Name helps identify the client in a user-friendly manner. Adding a Description gives users more information about the client. Set Client Signature Required to Off. In this blog, I’m not setting up client public keys or certs in the SAML Tab, so I’m turning off validation. Set Force POST Binding to Off. Anchore requires the HTTP Redirect Binding to work, so this setting must be off to enable that. Set Force Name ID Format to On. Ignore any name ID policies and use the value configured in the admin console under Name ID Format. Ensure Name ID Format is set to Username. This should be the default. Enter http://localhost:3000/service/sso/auth/keycloak to Valid Redirect URIs. Ensure http://localhost:3000/service/sso/auth/keycloak is set as the Master SAML Processing URL. This should be the default. Expand Fine Grain SAML Endpoint Configuration add add http://localhost:3000/service/sso/auth/keycloak to Assertion Consumer Service Redirect Binding URL. The configuration should look like the screenshot below, select Save. I can now download the metadata XML to import into Anchore Enterprise. Select the Installation tab. Choose Mod Auth Mellon files from the Format Option dropbox. Select Download. Configure Anchore Enterprise SSO Next, I will configure the Anchore Enterprise UI to use Keycloak for SSO. Once logged into the Anchore Enterprise UI as Admin, navigate to Configuration. Select SSO from the column on the left. Select Let’s Add One under the SSO tab. I will add the following configurations to the fields on the next screen, several fields will be left blank as they are not necessary for this blog. Enter keycloak for the Name. Enter -1 for the ACS HTTPS Port. This is the port to use for HTTPS to the ACS (Assertion Consumer Service, in this case, the UI). It is only needed if you need to use a non-standard https port. Enter http://localhost:3000/service/sso/auth/keycloak for the SP Entity ID. The service provider entity ID must match the client ID used in the Keycloak configuration above. Enter http://localhost:3000/service/sso/auth/keycloak for the ACS URL. Enter keycloakusers for Default Account. This can be any account name (existing or not) that you’d like the users to be members of. Select read-write from the Default Role dropdown. From the .zip file the downloaded from Keycloak in the above section, copy the contents of the idp-metadata.xml into IDP Metadata XML. Uncheck Require Signed Assertions. The configuration should look like the series of screenshots below, select Save. After logging out of the Anchore Enterprise UI, there is now an option to authenticate with Keycloak. After selecting the Keycloak login option, I am redirected to the Keycloak login page. I can now login with existing Keycloak users, in this case, “example”. The example user did not exist in my Anchore environment but was added upon the successful login to Keycloak. Conclusion I have successfully gone through the configuration for both the Keycloak Client and Anchore Enterprise SSO. I hope this step-by-step procedure is helpful in setting up SSO for your Anchore Enterprise solution. For more information on Anchore Enterprise 2.1 SSO support, please see Anchore SSO Support. For the full Keycloak and other examples, see Anchore SSO Examples. ### Seeking DevSecOps Engineers Anchore is on a mission: to enable our customers to deploy software containers with confidence. We allow them to enjoy the benefits of cloud-native application development, safe in the knowledge that the containers they deploy into production are secure and compliant. With that confidence, they can continue to develop and ship software at breakneck speeds. But that’s not all. We are also on a mission to create the defining technology company in one of today’s hottest technology spaces. As a start-up, we are looking for people who are as passionate about DevSecOps as we are and want to spend their days helping customers and users modernize their software development pipelines. We’re always hiring across the team for all positions, but we urgently need DevSecOps Engineers to help our growing customer base adopt Anchore and develop best practices for container hardening and security. We’re looking for people who care passionately about creating something unique and want to have a visible impact on the success of Anchore and our customers. If you’re interested in learning more please contact us at jobs@anchore.com. We’d love to meet you. ### Anchore Engine in the AWS Marketplace Container adoption is soaring in enterprises and the public sector, making services such as Amazon Elastic Kubernetes Service extremely valuable for DevOps teams that want to run containerized workloads in Kubernetes easily and efficiently. For organizations that are already deploying, scaling and managing containerized applications with Kubernetes, Amazon EKS spreads your workload across availability zones to ensure a robust implementation of your Kubernetes control plane. Announcing Anchore Engine in the AWS Marketplace We are very excited to announce the availability of Anchore Engine in the AWS Marketplace. Anchore Engine allows users to bring industry-leading open source container security and compliance to their container landscape in EKS. Deployment is done using the Anchore Engine Helm Chart, which can be found in GitHub. So if you are already running an EKS cluster with Helm configured, you can now deploy Anchore Engine directly from the AWS marketplace to tighten up your Container security posture. With our unique approach to static scanning, DevOps teams can seamlessly integrate Anchore into their CI/CD pipeline to ensure that images are analyzed thoroughly for known vulnerabilities before deploying them into production. This will not only avoid the pain of finding and remediating vulnerabilities at runtime but also allow the end-user to define and enforce custom security policies to meet their specific company’s internal policies and any applicable regulatory security standards. Getting Started To get started, take a look at the Anchore Engine documentation to familiarize yourself with the basics. Then, once you have EKS set up, visit the Anchore Engine AWS Marketplace page to take the next steps.  ### Anchore 2.1 Feature Series, Enhanced Vulnerability Data With the release of Anchore Enterprise 2.1 (based on Anchore Engine 0.5.0), we are pleased to announce that Anchore Enterprise customers will now receive access to enhanced vulnerability data from Risk Based Security's VulnDB for increased fidelity, accuracy, and live-ness of image vulnerability scanning results. Recognizing that container images need an added layer of security, Anchore conducts a deep image inspection and analysis to uncover what software components are inside of the image, and generate a detailed manifest that includes packages, configuration files, language modules, and artifacts. Following analysis, user-defined acceptance policies are evaluated against the analyzed data to certify the container images. As the open-source software components and their dependencies within container images quickly increase, so do the inherent security risks these packages often present. Anchore software will identify all operating systems and supported language packages (npm, Java, Python, Ruby), and importantly, map these packages to known vulnerabilities. In addition to package identification, Anchore also indexes every file in the container image filesystem, providing end-users complete visibility into the full contents. Risk Based Security's VulnDB VulnDB provides the richest, most complete vulnerability intelligence available to help users and teams address points of risk across their organization - in the case of Anchore customers, security risks within container images. VulnDB provides over 70,000 additional vulnerabilities not found in the publicly available source Common Vulnerabilities and Exposures (CVE) database. Additionally, 45.5% of 2018 omissions from the CVE database are high to critical in severity. This ties directly into a key understanding we have here at Anchore: just being reliant on publicly available vulnerability sources is not sufficient for Enterprises looking to seriously improve their security posture. Viewing vulnerability results in the Anchore UI Just as in previous releases, Anchore Enterprise users can view vulnerability results for an image in the UI. Below is a snapshot of Anchore Enterprise with vulnerable packages identified by VulnDB: Diving deeper into a single VulnDB identifier presents the user with more information about the issue and provides links to external sources. Below is a single VulnDB identifier record in Anchore Enterprise: Note: As always, users can fetch vulnerability information via the Anchore API or CLI. Given that more organizations are increasing their use of both containers and OSS components, it is becoming more critical for enterprises to have the proper mechanisms in place to uncover and fix vulnerable packages within container images as early as possible in the development lifecycle. Enhanced Feed Comparison We've also taken it upon ourselves to scan some commonly used images with Anchore Engine (no VulnDB) and Anchore Enterprise (with VulnDB) and investigate the deltas. Here is an example of six images we tested: As shown above, VulnDB provides our customers with additional vulnerability data than what is available publically. Allowing development, security, and operations teams to make more informed vulnerability and policy management decisions around their container image workloads. ### Anchore 2.1 Feature Series, Local Image Analysis With the release of Anchore Enterprise 2.1 (based on Anchore Engine 0.5.0), local image analysis is now available. Inline Analysis gives users the ability to perform image analysis on a locally built Docker image without the need for it to exist inside a registry. Local image scanning analyzes an image from a local Docker engine and exports the analysis into your existing Anchore Engine deployment. Local Analysis vs Typical Anchore Deployments While local scanning is convenient when access to a registry is not available, Anchore recommends scanning images that have been pushed to the registry as it is a more robust solution. Local scanning is not meant to alter the fundamental deployment of Anchore Engine nor the image analysis strategy of Anchore. Adding an image via local scanning removes some of the wonderful features that are included in Anchore, like monitoring a registry for image tag or repository updates, subscriptions, or webhook notifications. Rather, it is intended to allow users to analyze images as one-off events, such as prior to moving them to a registry or deploying them from tarball in an air-gapped network. Additionally, by extracting the image from the Docker engine, local analysis can be used to analyze images from custom-tailored sources, such as OpenShift source-to-image or Pivotal kpack builds, or even on systems that don’t access any Continuous Integration/Continuous Deployment (CI/CD) processes. Running Local Analysis on an Air-Gapped Network As an example for this blog, I chose to perform a local analysis on an image I built but doing so while my network was disconnected from the Internet. Many systems don’t have access to Internet-facing registries, such as Docker Hub. Getting Started To start, an Internet-accessible machine is required to pull the local image analysis script, Anchore Docker images, and the base Alpine Docker image I use for my local build. Using the following docker-compose file on an Internet-accessible machine, I can pull down the Anchore Enterprise Docker images: # All-in-one docker-compose deployment of a full anchore-enterprise service system --- version: '2.1' volumes: anchore-db-volume: # Set this to 'true' to use an external volume. In which case, it must be created manually with "docker volume create anchore-db-volume" external: false anchore-scratch: {} feeds-workspace-volume: # Set this to 'true' to use an external volume. In which case, it must be created manually with "docker volume create feeds-workspace-volume" external: false enterprise-feeds-db-volume: # Set this to 'true' to use an external volume. In which case, it must be created manually with "docker volume create enterprise-feeds-db-volume" external: false services: # The primary API endpoint service engine-api: image: docker.io/anchore/anchore-engine:latest depends_on: - anchore-db - engine-catalog #volumes: #- ./config-engine.yaml:/config/config.yaml:z ports: - "8228:8228" logging: driver: "json-file" options: max-size: 100m environment: - ANCHORE_ENDPOINT_HOSTNAME=engine-api - ANCHORE_DB_HOST=anchore-db - ANCHORE_DB_PASSWORD=mysecretpassword - ANCHORE_AUTHZ_HANDLER=external - ANCHORE_EXTERNAL_AUTHZ_ENDPOINT=http://enterprise-rbac-authorizer:8228 - ANCHORE_ENABLE_METRICS=true command: ["anchore-manager", "service", "start", "apiext"] # Catalog is the primary persistence and state manager of the system engine-catalog: image: docker.io/anchore/anchore-engine:latest depends_on: - anchore-db #volumes: #- ./config-engine.yaml:/config/config.yaml:z logging: driver: "json-file" options: max-size: 100m expose: - 8228 environment: - ANCHORE_ENDPOINT_HOSTNAME=engine-catalog - ANCHORE_DB_HOST=anchore-db - ANCHORE_DB_PASSWORD=mysecretpassword - ANCHORE_ENABLE_METRICS=true command: ["anchore-manager", "service", "start", "catalog"] engine-simpleq: image: docker.io/anchore/anchore-engine:latest depends_on: - anchore-db - engine-catalog #volumes: #- ./config-engine.yaml:/config/config.yaml:z expose: - 8228 logging: driver: "json-file" options: max-size: 100m environment: - ANCHORE_ENDPOINT_HOSTNAME=engine-simpleq - ANCHORE_DB_HOST=anchore-db - ANCHORE_DB_PASSWORD=mysecretpassword - ANCHORE_ENABLE_METRICS=true command: ["anchore-manager", "service", "start", "simplequeue"] engine-policy-engine: image: docker.io/anchore/anchore-engine:latest depends_on: - anchore-db - engine-catalog #volumes: #- ./config-engine.yaml:/config/config.yaml:z expose: - 8228 logging: driver: "json-file" options: max-size: 100m environment: - ANCHORE_ENDPOINT_HOSTNAME=engine-policy-engine - ANCHORE_DB_HOST=anchore-db - ANCHORE_DB_PASSWORD=mysecretpassword - ANCHORE_ENABLE_METRICS=true command: ["anchore-manager", "service", "start", "policy_engine"] engine-analyzer: image: docker.io/anchore/anchore-engine:latest depends_on: - anchore-db - engine-catalog #volumes: #- ./config-engine.yaml:/config/config.yaml:z expose: - 8228 logging: driver: "json-file" options: max-size: 100m environment: - ANCHORE_ENDPOINT_HOSTNAME=engine-analyzer - ANCHORE_DB_HOST=anchore-db - ANCHORE_DB_PASSWORD=mysecretpassword - ANCHORE_ENABLE_METRICS=true volumes: - anchore-scratch:/analysis_scratch command: ["anchore-manager", "service", "start", "analyzer"] anchore-db: image: "postgres:9" volumes: - anchore-db-volume:/var/lib/postgresql/data environment: - POSTGRES_PASSWORD=mysecretpassword expose: - 5432 logging: driver: "json-file" options: max-size: 100m enterprise-feeds-db: image: "postgres:9" volumes: - enterprise-feeds-db-volume:/var/lib/postgresql/data environment: - POSTGRES_PASSWORD=mysecretpassword expose: - 5432 logging: driver: "json-file" options: max-size: 100m enterprise-rbac-authorizer: image: docker.io/anchore/enterprise:latest volumes: - ./license.yaml:/license.yaml:ro #- ./config-enterprise.yaml:/config/config.yaml:z depends_on: - anchore-db - engine-catalog expose: - 8089 logging: driver: "json-file" options: max-size: 100m environment: - ANCHORE_ENDPOINT_HOSTNAME=enterprise-rbac-authorizer - ANCHORE_DB_HOST=anchore-db - ANCHORE_DB_PASSWORD=mysecretpassword - ANCHORE_ENABLE_METRICS=true command: ["anchore-enterprise-manager", "service", "start", "rbac_authorizer"] enterprise-rbac-manager: image: docker.io/anchore/enterprise:latest volumes: - ./license.yaml:/license.yaml:ro #- ./config-enterprise.yaml:/config/config.yaml:z depends_on: - anchore-db - engine-catalog ports: - "8229:8228" logging: driver: "json-file" options: max-size: 100m environment: - ANCHORE_ENDPOINT_HOSTNAME=enterprise-rbac-manager - ANCHORE_DB_HOST=anchore-db - ANCHORE_DB_PASSWORD=mysecretpassword - ANCHORE_AUTHZ_HANDLER=external - ANCHORE_EXTERNAL_AUTHZ_ENDPOINT=http://enterprise-rbac-authorizer:8228 - ANCHORE_ENABLE_METRICS=true command: ["anchore-enterprise-manager", "service", "start", "rbac_manager"] enterprise-feeds: image: docker.io/anchore/enterprise:latest volumes: - feeds-workspace-volume:/workspace - ./license.yaml:/license.yaml:ro #- ./config-enterprise.yaml:/config/config.yaml:z depends_on: - enterprise-feeds-db ports: - "8448:8228" logging: driver: "json-file" options: max-size: 100m environment: - ANCHORE_ENDPOINT_HOSTNAME=enterprise-feeds - ANCHORE_DB_HOST=enterprise-feeds-db - ANCHORE_DB_PASSWORD=mysecretpassword - ANCHORE_ENABLE_METRICS=true command: ["anchore-enterprise-manager", "service", "start", "feeds"] enterprise-reports: image: docker.io/anchore/enterprise:latest volumes: - ./license.yaml:/license.yaml:ro depends_on: - anchore-db - engine-catalog ports: - "8558:8228" logging: driver: "json-file" options: max-size: 100m environment: - ANCHORE_ENDPOINT_HOSTNAME=enterprise-reports - ANCHORE_DB_HOST=anchore-db - ANCHORE_DB_PASSWORD=mysecretpassword - ANCHORE_ENABLE_METRICS=true - ANCHORE_AUTHZ_HANDLER=external - ANCHORE_EXTERNAL_AUTHZ_ENDPOINT=http://enterprise-rbac-authorizer:8228 command: ["anchore-enterprise-manager", "service", "start", "reports"] enterprise-ui-redis: image: "docker.io/library/redis:4" expose: - 6379 logging: driver: "json-file" options: max-size: 100m enterprise-ui: image: docker.io/anchore/enterprise-ui:latest volumes: - ./license.yaml:/license.yaml:ro #- ./config-ui.yaml:/config/config-ui.yaml:z depends_on: - engine-api - enterprise-ui-redis - anchore-db ports: - "3000:3000" logging: driver: "json-file" options: max-size: 100m environment: - ANCHORE_ENGINE_URI=http://engine-api:8228/v1 - ANCHORE_RBAC_URI=http://enterprise-rbac-manager:8228/v1 - ANCHORE_REDIS_URI=redis://enterprise-ui-redis:6379 - ANCHORE_APPDB_URI=postgres://postgres:mysecretpassword@anchore-db:5432/postgres - ANCHORE_REPORTS_URI=http://enterprise-reports:8228/v1 - ANCHORE_POLICY_HUB_URI=https://hub.anchore.io I can pull the images with the following command: $ docker-compose -f docker-compose-enterprise.yaml pull Pulling anchore-db ... done Pulling engine-catalog ... done Pulling engine-analyzer ... done Pulling engine-policy-engine ... done Pulling engine-simpleq ... done Pulling engine-api ... done Pulling enterprise-feeds-db ... done Pulling enterprise-rbac-authorizer ... done Pulling enterprise-rbac-manager ... done Pulling enterprise-feeds ... done Pulling enterprise-reports ... done Pulling enterprise-ui-redis ... done Pulling enterprise-ui ... done Next, I’ll pull the Inline Scan image from Anchore: $ docker pull docker.io/anchore/inline-scan:v0.5.0 Pulling docker.io/anchore/inline-scan:v0.5.0 v0.5.0: Pulling from anchore/inline-scan c8d67acdb2ff: Already exists 79d11c1a86c4: Already exists ced9ca3af39b: Already exists c1e8af2e6afa: Already exists ca674bdc4ffc: Already exists 7fa29b97cf4f: Already exists 15f5109f7371: Already exists 662a1f6a8a80: Already exists 6e87d34cd76e: Pull complete 7f7b513db561: Pull complete 5c7e09ac2f74: Pull complete b50890f6248a: Pull complete 5f8043f17686: Pull complete 3a3cdaeaf045: Pull complete c877ae27c8fe: Pull complete 58edd3c9fcf5: Pull complete 0ef916eddeef: Pull complete Digest: sha256:650a7fae8f95286301cdb5061475c0be7e4fb762ba2c85ff489494d089883c1c Status: Downloaded newer image for anchore/inline-scan:v0.5.0 Now I will pull the local image analysis script using curl from anchore.io’s ci-cd endpoint and make it executable: $ curl -o inline_scan.sh https://ci-tools.anchore.io/inline_scan-v0.5.0 $ chmod +x inline_scan.sh Finally, I will pull down the base Alpine image that I will use to build my local Docker image: $ docker pull docker.io/library/alpine:latest From here, I disconnect my Internet connection as the rest of the example is simulating an air-gapped network Deploying Anchore Enterprise In this example, I deploy Anchore Enterprise because the UI makes it simple to see results from the local image I analyze. Local image analysis is also available with OSS Anchore Engine v0.5.0. Using the same docker-compose-enterprise.yaml from above, I can now deploy Anchore Enterprise: $ docker-compose -f docker-compose-enterprise.yaml up -d Creating network "aevolume_default" with the default driver Creating aevolume_anchore-db_1 ... done Creating aevolume_enterprise-ui-redis_1 ... done Creating aevolume_enterprise-feeds-db_1 ... done Creating aevolume_engine-catalog_1 ... done Creating aevolume_enterprise-feeds_1 ... done Creating aevolume_engine-simpleq_1 ... done Creating aevolume_enterprise-reports_1 ... done Creating aevolume_engine-analyzer_1 ... done Creating aevolume_engine-policy-engine_1 ... done Creating aevolume_enterprise-rbac-authorizer_1 ... done Creating aevolume_enterprise-rbac-manager_1 ... done Creating aevolume_engine-api_1 ... done Creating aevolume_enterprise-ui_1 ... done Build Local Image For this example, I built the simplest Docker image from this Dockerfile: FROM docker.io/library/alpine:latest CMD echo "hello world" Then I built it with: $ docker build . -t local/example:latest Sending build context to Docker daemon 2.048kB Step 1/2 : FROM docker.io/library/alpine:latest latest: Pulling from library/alpine 9d48c3bd43c5: Pull complete Digest: sha256:72c42ed48c3a2db31b7dafe17d275b634664a708d901ec9fd57b1529280f01fb Status: Downloaded newer image for alpine:latest ---> 961769676411 Step 2/2 : CMD echo "hello world" ---> Running in 74bdcd240547 Removing intermediate container 74bdcd240547 ---> 325116ad4e62 Successfully built 325116ad4e62 Successfully tagged local/example:latest Once built, I can view it in my local Docker images with: $ docker images REPOSITORY TAG IMAGE ID CREATED SIZE local/example latest 373de5bd56d3 9 seconds ago 5.58MB Running Local Analysis Since I haven’t really done anything with my local Docker image except echo “hello world”, any vulnerabilities found during the analysis will be a reflection on the base image used; in this case docker.io/library/alpine:latest. I can perform the analysis on the image, passing in the URL to my locally running Anchore Engine, the username (admin), the password (foobar), the path to my Dockerfile, and the full image tag. $ ./inline_scan.sh analyze -r https://localhost:8228/v1 -u admin -p foobar -f dockerfile local/example:latest docker.io/anchore/inline-scan:v0.5.0 Saving local/example:latest for local analysis Successfully prepared image archive -- /tmp/anchore/example:latest.tar Analyzing local/example:latest... [MainThread] [INFO] using fulltag=localbuild/local/example:latest fulldigest=localbuild/local/example@sha256:325116ad4e6211cfec2acaea612b9ae78b2a2768ec71ea37c68e416730c95efa Analysis complete! Sending analysis archive to http://localhost:8228 Cleaning up docker container: c492f64a122a9631eaf616f5018ad22b55379f8595839a9ea1e69fd110a2dfe5 Viewing the Results After running the analysis, the results are imported into my Anchore Engine running locally and can now be viewed in the Enterprise UI. After signing in and navigating to “Image Analysis”, I can see my locally built Docker image listed: When I dig down into the analyzed image, I can see the vulnerability findings from the local analysis as if it were an image pulled from a registry: Conclusion I have successfully executed an analysis of a locally built image on an air-gapped network. I hope this overview of the new local image analysis from Anchore was able to provide some insight into it’s recommended use and that the example provided helps you with your container security needs. For more information regarding local image analysis, please see our inline analysis documentation. ### Announcing Anchore Enterprise 2.1 Today, we’re pleased to announce the immediate availability of Anchore Enterprise 2.1, our latest enterprise solution for container security. Anchore Enterprise provides users with the tools and techniques needed to enforce security, compliance and best-practices requirements with usable, flexible, cross-organization, and—above all—time-saving technology from Anchore. This release is based on the all-new Anchore Engine 0.5.0, which is also available today. New Features of Anchore Enterprise 2.1 Building upon our 2.0 release in May, Anchore Enterprise 2.1 adds major new features and architectural updates that extend integration/deployment options, security insights, and the evaluation power available to all users. Major new features and resources launched as part of Anchore Enterprise 2.1 include: GUI report enhancements: Leveraging Anchore Enterprise’s reporting service, there is a new set of configurable queries available within the Enterprise GUI Reports control. Users can now generate filtered reports (tabular HTML, JSON, or CSV) that contain image, security, and policy evaluation status for collections of images. Single-Sign-On (SSO): Integration support for common SSO providers such as Okta, Keycloak, and other Enterprise IDP systems, in order to simplify, secure, and better control aspects of user management within Anchore Enterprise Enhanced authentication methods: SAML / token-based authentication for API and other client integrations Enhanced vulnerability data: Inclusion of third party vulnerability data feeds from Risk Based Security (VulnDB) for increased fidelity, accuracy, and live-ness of image vulnerability scanning results, available for all existing and new images analyzed by Anchore Enterprise Policy Hub GUI: View, list and import pre-made security, compliance and best-practices policies hosted on the open and publicly available Anchore Policy Hub Built on Anchore Engine v0.5.0: Anchore Enterprise is built on top of the OSS Anchore Engine, which has received new features and updates as well (see below for details) Anchore Engine Anchore Enterprise 2.1 is built on top of Anchore Engine version 0.5.0, a new version of the fully functional core services that drive all Anchore deployments. Anchore Engine has received a number of new features and other new project updates: Vulnerability Data Enhancements: The Anchore Engine API and data model has been updated to include CVE references (for vulnerabilities that can refer to several CVEs) and CVSSv3 scoring information Local Image Analysis: New tooling to support isolated container image analysis outside of Anchore Engine, generating an artifact that can be imported into your on-premises Anchore Enterprise deployment Policy Enhancements: Many new vulnerability check parameters, enabling the use of CVSSv3 scores, vendor-specific scores, and new time-based specifications for even more expressive policy checks For a full description of new features, improvements and fixes available in Anchore Engine, view the release notes. Once again, we would like to sincerely thank all of our open-source users, customers and contributors for spirited discussion, feedback, and code contributions that are part of this latest release of Anchore Engine. If you’re new to Anchore, welcome! We would like nothing more than to have you join our community. Anchore Enterprise 2.1—Available Now With Anchore Enterprise 2.1, available immediately, our goal has been to expand the integration, secure deployment, and policy evaluation power for all Anchore users as an evolution of the features available already to existing users. For users looking for comprehensive solutions to the unique challenges of securing and enforcing best-practices and compliance to existing CI/CD, container monitoring and control frameworks, and other container-native pipelines, we sincerely hope you enjoy our latest release of Anchore software and other resources—we look forward to working with you! ### Precogs for Software To Spot Vulnerabilities? There are some movies which provide an immediate dose of entertainment for 2 hours and you instantly forget them afterwards. Others lurk within you, and constantly resurface to make you think about ideas or concepts. The 2002 movie Minority Report is one of the latter. In it, a police department is setup to investigate “precrime” based on foreknowledge provided by psychic humans called “precogs”. The dilemma of penalizing people who have not actually done anything is an interesting philosophical conundrum that resonates in contemporary topics. One example is the potential for insurance companies to not cover people who show genetic disposition to certain illnesses, even while not being ill. In the modern world rather than the future shown in the movie, computer crime and, more broadly, data breaches are now so common that we barely notice them, despite the fact they often have material impacts on us as individuals (see: Equifax). Fortunately, we actually do have something close to precogs in the software world which, while not allowing us to arrest criminals, do allow us to know when something is really likely to happen and do something about it. Many vendors and government agencies produce long lists of known software vulnerabilities that have a good chance of being exploited. Yet, the reality is that most organizations don’t do anything with them because they don’t even know they are running the affected software or because they do know what is running but don’t have the time to fix it.  I recently joined Anchore as VP of Products motivated by the opportunity to fix this problem. Like many, I’ve been amazed at the huge uptake in containers across the industry and, as a long time open source advocate, excited about the way it has allowed companies to take advantage of the huge ecosystem of open source software. However, I’ve also been cognizant that this new wave of adoption has increased the attack surface for companies and made the challenge of securing dynamic and heterogeneous environments even harder. In meeting with the team at Anchore, it was clear that they really understood containers and had gone a long way to solving the problem. The solution that Anchore has built not only tells you what software you are running (by scanning your repos) but enables teams to prevent bad software being deployed in the first place, using customizable policies which react to defects found in operating system and software library packages, as well as poorly implemented best practices. By enabling so-called DevOpSec processes, Anchore can help development teams become more efficient and spread the load of security responsibility - the only way we can tackle the mountain of vulnerabilities that come out every day. It may not quite be precogs, but it’s pretty close. I’ve been creating and deploying infrastructure software for over 20 years so have probably contributed a fair degree of security flaws to the world. I’m looking forward to joining the other side and working with our customers to making the new cloud native world a more secure one. ### Answers to your Top 3 Compliance Questions Policy first is a distinguishing tenet for Anchore as a product in today’s container security marketplace. When it comes to policy, we at Anchore receive a lot of questions from customers regarding different compliance standards, guidelines, and how the Anchore platform can help meet their requirements which remain a priority. Today, we will review our top three (in no particular order) policy and compliance questions we receive to demonstrate how Anchore can alleviate some of policy/compliance woes when choosing a container security tool to bring into your tech stack. How can Anchore Help me Satisfy NIST 800-53 controls? We receive a lot of questions regarding how Anchore can help different organizations meet compliance baselines that deal heavily with the implementation of NIST 800-53 controls. As a result, we talk about a lot of controls we satisfy in our federal white paper on container security. At a high level, Anchore helps organizations satisfy requirements for RA-5: Vulnerability Scanning, SI-2 Flaw Remediation, CA-7 Continuous Monitoring. However, Anchore does more than just help organizations with vulnerability scanning and policy enforcement with containers. As a part of our process, Anchore provides an in-depth inspection of the image as they pass through Anchore analyzers that enforce whitelisted and blacklisted attributes such as ports/protocols, types of images, and types of OS as described in our previous blog post. Anchore Enterprise users can customize and enforce whitelisting/blacklisting within the Anchore Enterprise UI, navigating to the Whitelists tab will show the lists of whitelists that are present in the current DoD security policies bundle. As a result, this allows organizations to comply with configuration management controls as well, specifically CM-7(5) Least Functionality: Whitelisting/Blacklisting in addition to CM-7(4) Unauthorized Software and Blacklisting. To prevent unauthorized software from entering your image, simply selecting “whitelist/blacklist” images tab as demonstrated below which allows you to blacklist OS, image, or packages : How does Anchore Help Organizations Meet the Guidelines Specified in NIST 800-190: Application Container Security Guide? Anchore provides a policy first approach to automated vulnerability scanning and compliance scanning for Docker images. By having customizable policies at the center of Anchore Engine itself, we provide the capability to react swiftly as new Federal security policies are published. NIST 800-190 was no different for the Anchore team. NIST 800-190 specifies, “Organizations should automate compliance with container runtime configuration standards. Documented technical implementation guidance, such as the Center for Internet Security Docker Benchmark.”  Out of the box, Anchore provides a CIS Policy Bundle for open source and Enterprise users alike which allows you to check for Host Configuration, Docker daemon configuration, Docker daemon configuration files, Container Images and Build File, and Container Runtime. Below, we can see how the latest Postgres image stacks up against the CIS Benchmarks called out in NIST 800-190: From here, we would recommend hardening the image to comply with the CIS benchmarks before advancing this image into production. Is Anchore FIPS 140-2 Validated? Anchore is not a FIPS 140-2 validated product, nor is it a FIPS 140-2 Compliant product. However, it’s important to explain why Anchore has no plans on becoming FIPS 140-2 Validated. As NIST explains FIPS 140-2 applicability is listed here:  “This standard is applicable to all Federal agencies that use cryptographic-based security systems to protect sensitive information in computer and telecommunication systems (including voice systems) as defined in Section 5131 of the Information Technology Management Reform Act of 1996, Public Law 104-106. This standard shall be used in designing and implementing cryptographic modules that Federal departments and agencies operate or are operated for them under contract...” A majority of the products found on the list deal with validating encryption as a protection mechanism for products associated with networking hardware or hardware/software involved in the identification and authentication of users into an environment that is outside of the scope of the Anchore product. Anchore believes it is important to protect sensitive information generated from Anchore scanning. However, Anchore does not provide FIPS 140-2 validated protection of that information. Rather, Anchore believes it is the responsibility of the team managing Anchore deployments to protect the data generated from Anchore which can be done using FIPS 140-2 validated products. As of 2018, Docker became the first container relevant vendor to have a FIPS 140-2 validated product with the Docker Enterprise Edition Crypto Library. Furthermore, no other container security tools in the market are FIPS 140-2 validated.  Conclusion Although we simply covered NIST standards in this post due to its wide use and popularity amongst our customers, Anchore Enterprise exists as a policy first tool that provides teams with the flexibility to adapt their container vulnerability scanning in a timely fashion to comply with any compliance standard across various markets. Please contact our Anchore team if you are having trouble enforcing a compliance standard or if there is a custom Anchore policy bundle we can create in line with your current compliance needs. ### Using Anchore to Identify Secrets in Container Images Building containerized applications inherently bring up the question of how to best give these applications access to any sensitive information they may need. This sensitive information can often be in the form of secrets, passwords, or other credentials. This week I decided to explore a couple of bad practices / common shortcuts and some simple checks you can configure using both Anchore Engine and Enterprise to integrate into your testing to achieve a more polished security model for your container image workloads. Historically, I've seen a couple "don'ts" for giving containers access to credentials: Including directly in the contents of the image Defining a secret in a Dockerfile with ENV instruction The first should be an obvious no. Including sensitive information within a built image, is giving anyone who has access to the image, access to those passwords, keys, creds, etc. I've also seen this placement of secrets inside of the container image using the ENV instruction. Dockerfiles are likely managed somewhere, and exposing them in clear text is a practice that should be avoided. A recommended best practice is not only to check for keys and passwords as your images are being built, but implement the proper set of tools for true secrets management (not the above "don'ts"). There is an excellent article written by Hashicorp on Why We Need Dynamic Secrets which is a good place to start. Using the ENV instruction Below is a quick example of using the ENV instruction to define a variable called AWS_SECRET_KEY. Both AWS Access Keys consist of two parts: an access key ID and a secret access key. These credentials can be used with AWS CLI or API operations and should be kept private. FROM node:6 RUN mkdir -p /home/node/ && apt-get update && apt-get -y install curl COPY ./app/ /home/node/app/ ENV AWS_SECRET_KEY="1234q38rujfkasdfgws" For argument's sake, let’s pretend I built this image and ran the container with the following command: docker run --name bad_container -d jvalance/node_critical_fail $ docker ps | grep bad_container 3bd970d05f16 jvalance/node_critical_fail "/bin/sh -c 'node /h…" 13 seconds ago Up 12 seconds 22/tcp, 8081/tcp bad_container And now exec into it with the following: docker exec -ti 3bd970d05f16 /bin/bash to bring up a shell. Then run the env command: # env YARN_VERSION=1.12.3 HOSTNAME=3bd970d05f16 PWD=/ HOME=/root AWS_SECRET_KEY=1234q38rujfkasdfgws NODE_VERSION=6.16.0 TERM=xterm SHLVL=1 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin _=/usr/bin/env Now you can see that I've just given anyone with access to this container the ability to grab any environment variable I've defined with the ENV instruction. Similarly with the docker inspect command: $ docker inspect 3bd970d05f16 -f "{{json .Config.Env}}" ["PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin","NODE_VERSION=6.16.0","YARN_VERSION=1.12.3","AWS_SECRET_KEY=1234q38rujfkasdfgws"] Storing Credentials in Files Inside the Image Back to our example of a bad Dockerfile: FROM node:6 RUN mkdir -p /home/node/ && apt-get update && apt-get -y install curl COPY ./app/ /home/node/app/ ENV AWS_SECRET_KEY="1234q38rujfkasdfgws" Here we are copying the contents of the app directory into home/node/app inside the image. Why is this bad? Here's an image of the directory structure: and specifically the contents of the credentials file: # credentials [default] aws_access_key_id = 12345678901234567890 aws_secret_access_key = 1a2b3c4d5e6f1a2b3c4d5e6f1a2b3c4d5e6f1a2b [kuber] aws_access_key_id = 12345678901234567890 aws_secret_access_key = 1a2b3c4d5e6f1a2b3c4d5e6f1a2b3c4d5e6f1a2b Same as I did before, I'll try to find the creds in the container. /home/node/app# cat .aws/credentials [default] aws_access_key_id = 12345678901234567890 aws_secret_access_key = 1a2b3c4d5e6f1a2b3c4d5e6f1a2b3c4d5e6f1a2b api_key = 0349r5ufjdkl45 [kuber] aws_access_key_id = 12345678901234567890 aws_secret_access_key = 1a2b3c4d5e6f1a2b3c4d5e6f1a2b3c4d5e6f1a2b Checking for the Above with Anchore At Anchore, a core focus of ours is centered around conducting a deep image inspection to give users comprehensive insight into the contents of their container images, and to provide users the ability to define flexible policy rules to enforce security and best-practices. By understanding that container images are composed are far more than just lists of packages, Anchore takes a comprehensive approach but providing users the ability to check for the above examples. Using the policy mechanisms of Anchore, users can define a collection of checks, whitelists, and mappings (encapsulated as a self-contained Anchore policy bundle document). Anchore policy bundles can then be authored to encode a variety of rules, including checks within (but not limited to) Dockerfile line checks for the presence of credentials. Although I will never recommend the bad practices used in the above examples for secrets, we should be checking for them nonetheless. Policy Bundle A policy bundle is a single JSON document, which is composed of: Policies Whitelists Mappings Whitelisted Images Blacklisted Images The policies component of a bundle defines the checks to make against an image and the actions to recommend if the checks to find a match. Example policy component of a policy bundle: "name": "Critical Security Policy", "policies": [ { "comment": "Critical vulnerability, secrets, and best practice violations", "id": "48e6f7d6-1765-11e8-b5f9-8b6f228548b6", "name": "default", "rules": [ { "action": "STOP", "gate": "dockerfile", "id": "38428d50-9440-42aa-92bb-e0d9a03b662d", "params": [ { "name": "instruction", "value": "ENV" }, { "name": "check", "value": "like" }, { "name": "value", "value": "AWS_.*KEY" } ], "trigger": "instruction" }, { "action": "STOP", "gate": "secret_scans", "id": "509d5438-f0e3-41df-bb1a-33013f23e31c", "params": [], "trigger": "content_regex_checks" },... The first policy rule uses the dockerfile gate and instruction trigger to look for AWS environment variables that may be defined in the Dockerfile. The second policy rule uses the secret scans gate and content regex checks trigger to look for AWS_SECRET_KEY and AWS_ACCESS_KEY within the container image. It is worth noting that there is an analyzer_config.yaml file which is taking care of the regex definitions. For the purposes of this post, I've analyzed an image that includes the two bad practices discussed earlier and evaluated the analyzed image against a policy bundle that contains the rule definitions above. It should catch the poor practices! Here is a screenshot of the Anchore Enterprise UI Policy Evaluation table: The check output column clearly informs us what Anchore found for each particular trigger ID line item and importantly, the STOP action which helps to determine the final result of the policy evaluation. We can see very clearly that these policy rule definitions have caught both the ENV variable and credentials file. If this were plugged into a continuous integration pipeline, we could fail the build on this particular container image and put the responsibility on the developer to fix, rebuild, and never ship this image to a production registry. Putting this in Practice In summary, it is extremely important to put checks in-place with a tool like Anchore to align with your container image build frequency. For secrets management, an overall best practice I recommend is using a secret store like Vault to handle the storage of sensitive data. Depending on the orchestrator you are using for your containers, there are some options. For Kubernetes, there is Kubernetes Vault. Staying with the Hashicorp suite, there are some options here as well for dynamic secrets: Vault Integration and Retrieving Dynamic Secrets. The above is an excellent system to have in place. I will continue to advocate for including image scanning and policy enforcement as a mandatory step in continuous integration pipelines because it directly aligns with the practice of bringing security as far left in the development lifecycle as possible to catch issues early. Taking a step back to plan and put in place solutions for managing secrets for your containers, and securing your images, will drastically improve your container security stance from end to end and allow you to deploy with confidence. ### Securing Multi-Cloud Environments with Anchore Many organizations today are currently leveraging multiple cloud providers for their cloud-native workloads. An example of such could be, a mix of several public cloud providers such as AWS, GCP, or Azure. Or perhaps a combination of a private cloud such as OpenStack, along with any public cloud provider. By definition, multi-cloud is a cloud approach that is made up of more than one cloud service, from more than one cloud vendor (public or private). At Anchore, we work with many users and customers who are faced with the challenge of adopting an effective container security strategy across the multiple cloud environments that they manage. Anchore is a leading provider of container security and compliance enforcement solutions designed for open-source users and enterprises. Anchore provides vulnerability and policy management tools built to surface comprehensive container image package and data content, protect against security threats, and check for best-practices. All of this is wrapped in an actionable policy enforcement engine and language capable of evolving over time as compliance needs change. Flexible and robust enough for the security and policy controls regulated industry verticals need to effectively adopt cloud-native technologies at scale. Deployment Both Anchore Engine and Enterprise are shipped and delivered as Docker containers, providing tremendous deployment flexibility across every major public cloud providers managed Kubernetes service (Amazon EKS, Azure Kubernetes Service, Google Kubernetes Engine), container platform (Red Hat OpenShift), or on-premise. Container Registry Support Anchore natively integrates with any public or private Docker V2 compatible container registry including the major cloud providers (Amazon ECR, Google Container Registry, Azure Container Registry), or on-premise installations (JFrog Artifactory, Sonatype Nexus, Docker, etc.). Continuous Integration Anchore seamlessly plugs into any CI system, providing users with pre-production security, compliance, and best-practice enforcement checks directly in their CI pipelines. Users and customers can use Anchore’s native plugins for Jenkins and CircleCI, or integrate into the CI platform of their choice (Amazon CodeBuild, Azure DevOps, TravisCI, etc.). Kubernetes Admission Control Anchore provides an admission controller for Kubernetes to gate pod execution based on Anchore analysis and policy evaluation of image content. It supports three different modes of operation allowing users to tune the tradeoff between control and intrusiveness for their environments. Anchore Kubernetes Admission Controller supports integrations with the major cloud providers managed Kubernetes services as well as on-premise. Multi-Tenancy Support Anchore Enterprise provides full Role-Based Access Control functionality, allowing organizations to manage multiple teams, users, and permissions, all from a central Anchore installation. Security, Operations, and Development teams can operate separately. Maintaining full isolation of image scan results, policy rule configurations, and custom reports. At Anchore, we understand the benefits of an effective multi-cloud strategy. However, we are also aware of the challenges, and risks development, security, and operations teams face when securing workloads across clouds. By utilizing a CI and container registry agnostic platform, Anchore users can easily adopt a refined container security and compliance practice across all of their public and private cloud environments. ### Bridging the Gap Between Speed and Security: A Deep Dive into Anchore Federal's Container Image Inspection and Vulnerability Management In today’s DevOps environment, developers and security teams are more intertwined than ever with increased speed to production. Enterprises are using hundreds to thousands of Docker images making it more difficult to maintain an accurate list of software inventory, and track software packages and vulnerabilities across their container workloads. This becomes a recurring headache for Federal DevSecOps teams who are trying to maintain control over the environment by monitoring for unauthorized software on the information system. Per National Security Agency (NSA) guidance, security teams should actively monitor and remove unauthorized, outdated, and potentially malicious software from the information system while simultaneously making timely updates to their software stack. Fortunately, Anchore Federal can simplify this process for DevSecOps teams and development teams alike by inspecting Docker images in all container registries, analyzing the specific software components within a given image, and then visualizing every software package for the developer in the Anchore Federal UI. For this blog post, we will explore how we can positively impact our security posture by maintaining strong configuration control over the software in our environment using Anchore Federal to analyze, inspect, and visualize the contents of each image. Looking to learn more about how to achieve container hardening at DoD levels of security? 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. Intro to DoD Software Factory Outline for Getting Up to Speed on the DoD Software Factory How Anchore Secures Software Factories Anchore’s Image Inspection to Support Configuration Management Best Practices For this demo, I’ve selected Logstash version 7.2.0 from DockerHub and analyzed this image against Anchore’s DoD security policies bundle found in Anchore’s policy hub. You can also navigate to the “Policy Bundles” tab in Anchore Federal UI by navigating to the “Policy Bundles” tab where we can see that we are using the “anchore_dod_security_policies” bundle as our default policy. After validating the DoD policies are set, we then initiate the vulnerability scan against the Logstash image. Anchore automatically analyzes the image for not only CVEs, but evaluates the entire image contents against a comprehensive list of DoD security and compliance standards using our DoD security policies bundle. Anchore Federal automatically displays the results of the image scan in our “Image Analysis” tab as depicted below: From the overview page, the user can easily see the compliance and vulnerability results generated against our DoD security policies. Taking this a step deeper, we then can begin inspecting the content of the image itself by navigating to the “Contents” tab. This extends beyond just a list of CVE’s, vulnerabilities and compliance checks. Anchore Federal provides the user with a total list of all of the different types of software packages, OS packages, and files that are found in the selected image: This provides an integral point of analysis that allows the user to inventory and identify the different types of software and software packages that are within your environment. This is greatly needed across Federal organizations aiming to comply with DoD RMF and FedRAMP configuration management security controls. Keeping the importance of configuration management in mind, Anchore Federal seamlessly integrates configuration management with security to magnify specific packages tied to vulnerabilities. Unifying Configuration Management with Container Security Anchore Federal allows the user to focus on adversely impacted packages by placing them front and center to the user. Navigating to the “Vulnerabilities” tab from the overview page allows you to see the adversely impacted packages. Anchore clearly displays that there is a CVE tied to the impacted Python package in the screenshot below: From here, the security analyst would immediately want to be alerted to the other images in their environment that are impacted by the vulnerability. Anchore Federal automatically does this for you and links that affected package across all of the images in your repository. Anchore Federal also automatically generates reports of affected packages by selecting “Other Images Sharing Package.” In this example, we can see that our Elasticsearch image is also impacted by the vulnerability tied to this Python package: You can tailor the reports accordingly by using the parameters to filter on any specific package and package version. Anchore takes care of the rest and automatically informs DevSecOps teams about all of the images tied to every package containing a vulnerability. This provides teams with the vulnerability information necessary to carry out vulnerability remediation across the impacted images for their organization. Anchore Federal takes the burden off of the DevSecOps teams by integrating configuration management with Anchore’s deep image inspection vulnerability scanning and “policy first” compliance approach. As a result, Federal organizations don’t have to worry about sacrificing configuration management. Instead, using Anchore Federal, organizations can enhance configuration control of their environment, gain the valuable insight of software packages within each container, and remediate vulnerable software packages to closure in a timely manner. ### Federal Container Security Best Practices, Whitelist/Blacklist Last week, Anchore went public with our federal white paper ​Container Security for U.S. Government Information Systems​ which contained key guidance for US government personnel responsible for securing container deployments on US government information systems. One of the key components of the whitepaper focused on utilizing a container-native security tool with the ability to whitelist and blacklist different packages, ports/protocols, and services within container images in order to maintain security in depth across environments. Today we will focus on how Anchore integrates whitelisting and blacklisting into our custom DoD Security Policies bundle to provide in-depth security enforcement for our customers. Whitelisting with Anchore Enterprise Anchore provides pre-configured out of the box DoD and CIS policy bundles that serve as the unit of policy definition and evaluation for enforcing container security and compliance. Within these policies, Anchore engineers have worked to develop comprehensive whitelists of authorized software packages, users, and user permissions. Additionally, users can whitelist specific ports that apply to each service running within their container image in order to validate that only authorized ports are open for their containers when they are pushed into production. This is a critical part of maintaining any kind of acceptable cybersecurity posture for a federal information system since assessment teams are constantly inspecting for unauthorized ports, protocols, and services running on US government information systems. Additionally, whitelisting is critical to SecOps teams that need to tailor whitelists for CVE’s to account for false positives that continuously appear in their scans. When done correctly, whitelists are an effective strategy for validating only authorized images and software packages are installed on your system. Through whitelisting, the security team can minimize the false positive rate and simultaneously maximize their security posture by using Anchore’s scanning policies that will only allow authorized images, ports/protocols, and packages in container images that end up handling production workloads. Anchore Enterprise makes whitelisting extremely simple. Within the Anchore Enterprise UI, navigating to the Whitelists tab will show the lists of whitelists that are present in the current DoD security policies bundle.   From here, the user can tailor the whitelist specific to their environment. For example, you can edit the existing DoD security policies bundle to fit the needs of your environment by entering the CVE/Vulnerability identifier and package name:   The policy bundle is then automatically updated to reflect the updated whitelist and you are now ready to begin scanning using your tailored policy. Anchore Enterprise provides this flexibility specifically for security teams and development teams that need to comply with various policy requirements while not adversely impacting deployment velocity. Blacklisting with Anchore Enterprise Conversely, the infosec best practice of blacklisting can also be done using Anchore Enterprise. Again, with Anchore’s out-of-the-box DoD security policy bundle, customers have SSH-22 and Telnet-23 blacklisted by default. Blacklisting of Telnet and SSH as evident in the screenshot of the DoD security policy bundle: SecOps teams can take this a step further and tailor the policy bundle to blacklist additional ports if needed by navigating to edit the exposed ports check: Upon each scan, Anchore can then take inspection a step further to blacklist certain types of effective users found in an image. One of these checks that Anchore incorporated into the DoD security policy is validating the effective user is ​not​ set to root. By looking at the DoD Security Policy Bundle below through our Anchore Enterprise console, we can see that the Anchore DoD Security Policies is automatically validating the effective user that we have blacklisted:   If SecOps teams have data indicating known malicious software packages, then they should be utilizing a tool to block known packages from being incorporated into Docker images that will eventually end up deployed on a Federal information system. Again, you could do this by navigating to the DoD security policies bundle and selecting “whitelisting/blacklisting” as seen below:     From here, you are just seconds away from improving your security posture and blacklisting images from being pushed into production. By simply selecting “let's add one” the user can then specify an image to blacklist based on Image Name, Image ID, or by Image Digest : With Anchore’s policy first approach, enforcing whitelisting/blacklisting for Docker images has never been easier as it serves to meet the various security baselines and requirements that span across the US Government space. Anchore provides the flexibility to meet your security requirements for your federal workloads at scale ranging from classified and unclassified information systems. ### A Policy Based Approach to Container Security & Compliance At Anchore, we take a preventative, policy-based compliance approach, specific to organizational needs. Our philosophy of scanning and evaluating Docker images against user-defined policies as early as possible in the development lifecycle, greatly reduce vulnerable, non-compliant images from making their way into trusted container registries and production environments. But what do we mean by 'policy-based compliance'? And what are some of the best practices organizations can adopt to help achieve their own compliance needs? In this post, we will first define compliance and then cover a few steps development teams can take to help to bolster their container security. An Example of Compliance Before we define 'policy-based compliance', it helps to gain a solid understanding of what compliance means in the world of software development. Generally speaking, compliance is a set of standards for recommended security controls laid out by a particular agency or industry that an application must adhere to. An example of such an agency is the National Institute of Standards and Technology or NIST. NIST is a non-regulatory government agency that develops technology, metrics, and standards to drive innovation and economic competitiveness at U.S. based organizations in the science and technology industry. Companies that are providing products and services to the federal government oftentimes are required to meet the security mandates set by NIST. An example of one of these documents is NIST SP 800-218, the Secure Software Development Framework (SSDF) which specifics the security controls necessary to ensure a software development environment is secure and produces secure code. What do we mean by 'Policy-based'? Now that we have a definition and example, we can begin to discuss the aspect role play in achieving compliance. In short, policy-based compliance means adhering to a set compliance requirements via customizable rules defined by a user. In some cases, security software tools will contain a policy engine that allows for development teams to create rules that correspond to a particular security concern addressed in a compliance publication. 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: Intro to DoD Software Factory Outline for Getting Up to Speed on the DoD Software Factory How Anchore Secures Software Factories How can Organizations Achieve Compliance in Containerized Environments? Here at Anchore, our focus is helping organizations secure their container environments by scanning and analyzing container images. Oftentimes, our customers come to us to help them achieve certain compliance requirements they have, and we can often point them to our policy engine. Anchore policies are user-defined checks that are evaluated against an analyzed image. A best practice for implementing these checks is through a step in CI/CD. By adding an Anchore image scanning step in a CI tool like Jenkins or Gitlab, development teams can create an added layer of governance to their build pipeline. Complete Approach to Image Scanning Vulnerability scanning Adding image scanning against a list of CVEs to a build pipeline allows developers to be proactive about security as they will get a near-immediate feedback loop on potentially vulnerable images. Anchore image scanning will identify any known vulnerabilities in the container images, enforcing a shift-left paradigm in the development lifecycle. Once vulnerabilities have been identified, reports can be generated listing information about the CVEs and vulnerable packages within the images. In addition, Anchore can be configured to send webhooks to specified endpoints if new CVEs have published that impact an image that has been previously scanned. At Anchore, we've seen integrations with Slack or JIRA to alert teams or file tickets automatically when vulnerabilities are discovered. Adding governance Once an image has been analyzed and its content has been discovered, categorized, and processed, the resulting data can be evaluated against a user-defined set of rules to give a final pass or fail recommendation for the image. It is typically at this stage that security and DevOps teams want to add a layer of control to the images being scanned in order to make decisions on which images should be promoted into production environments. Anchore policy bundles (structured as JSON documents) are the unit of policy definition and evaluation. A user may create multiple policy bundles, however, for evaluation, only one can be marked as 'active'. The policy is expressed as a policy bundle, which is made up of a set of rules to perform an evaluation of an image. These rules can define a check against an image for things such as: Security vulnerabilities Package whitelists and blacklists Configuration file contents Presence of credentials in an image Image manifest changes Exposed ports Anchore policies return a pass or fail decision result. Putting it Together with Compliance Given the variance of compliance needs across different enterprises, having a flexible and robust policy engine becomes a necessity for organizations needing to adhere to one or many sets of standards. In addition, managing and securing container images in CI/CD environments can be challenging without the proper workflow. However, with Anchore, development and security teams can harden their container security posture by adding an image scanning step to their CI, reporting back on CVEs, and fine-tuning policies meet compliance requirements. With compliance checks in place, only container images that meet the standards laid out a particular agency or industry will be allowed to make their way into production-ready environments. Conclusion Taking a policy-based compliance approach is a multi-team effort. Developers, testers, and security engineers should be in constant collaboration on policy creation, CI workflow, and notification/alert. With all of these aspects in-check, compliance can simply become part of application testing and overall quality and product development. Most importantly, it allows organizations to create and ship products with a much higher level of confidence knowing that the appropriate methods and tooling are in place to meet industry-specific compliance requirements. Interested to see how the preeminent DoD Software Factory Platform used a policy-based approach to software supply chain security in order to achieve a cATO and allow any DoD programs that built on their platform to do the same? Read our case study or watch our on-demand webinar with Major Camdon Cady. ### Install Anchore Enterprise on Amazon EKS with Helm In this post I will walkthrough the installation of Anchore Enterprise 2.0 on Amazon EKS with Helm. Anchore currently maintains a Helm Chart which I will use to install the necessary Anchore components. Prerequisites A running Amazon EKS cluster with worker nodes launched. See EKS Documentation for more information. Helm client and server installed and configured to your EKS cluster. Note: We've written a blog post titled Introduction to Amazon EKS which details how to get started on the above prerequisites. The prerequisites for getting up and running are the most difficult part of the installation in my opinion, the Anchore Helm chart makes the installation process straightforward. Once you have a EKS cluster up and running and worker nodes launched, you can verify via the following command: $ kubectl get nodes NAME STATUS ROLES AGE VERSION ip-10-0-1-66.us-east-2.compute.internal Ready 1d v1.12.7 ip-10-0-3-15.us-east-2.compute.internal Ready 1d v1.12.7 ip-10-0-3-157.us-east-2.compute.internal Ready 1d v1.12.7 Anchore Helm Chart Configuration To make proper configurations to the Helm chart, create a custom anchore_values.yaml file and utilize it when installing. There are many options for configuration with Anchore, for the purposes of this document, I will only change the minimum to get Anchore Enterprise installed. For reference, there is an anchore_values.yaml` file in this repository, that you may include in your installation. Note - For this installation, I will be configuring ingress and using an ALB ingress controller. You can read more about Kubernetes Ingress with AWS ALB Ingress Controller. Configurations Ingress I've added the following to my anchore_values.yaml file under the ingress section: ingress: enabled: true # Use the following paths for GCE/ALB ingress controller apiPath: /v1/* uiPath: /* # apiPath: /v1/ # uiPath: / # Uncomment the following lines to bind on specific hostnames # apiHosts: # - anchore-api.example.com # uiHosts: # - anchore-ui.example.com annotations: kubernetes.io/ingress.class: alb alb.ingress.kubernetes.io/scheme: internet-facing Anchore Engine API service I've added the following to my anchore_values.yaml file under the Anchore API section: # Pod configuration for the anchore engine api service. anchoreApi: replicaCount: 1 # Set extra environment variables. These will be set on all api containers. extraEnv: [] # - name: foo # value: bar # kubernetes service configuration for anchore external API service: type: NodePort port: 8228 annotations: {} Note - Changed service type to NodePort. Anchore Enterprise Global I've added the following to my anchore_values.yaml file under the Anchore Enterprise global section: anchoreEnterpriseGlobal: enabled: true Note - Enabled enterprise components. Anchore Enterprise UI I've added the following to my anchore_values.yaml file under the Anchore Enterprise UI section: anchoreEnterpriseUi: # kubernetes service configuration for anchore UI service: type: NodePort port: 80 annotations: {} sessionAffinity: ClientIP Note - Changed service type to NodePort. This should be all you need to change in the chart. AWS EKS Configurations Download the ALB Ingress manifest update cluster-name with EKS cluster name in alb-ingress-controller.yaml wget https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.0.1/docs/examples/alb-ingress-controller.yaml Update cluster-name with the EKS cluster name in alb-ingress-controller.yaml wget https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.0.1/docs/examples/rbac-role.yaml From the AWS console, create an IAM policy and manually update the EKS subnets for auto-discovery. In the IAM console, create a policy using the contents of the template iam-policy.json. Attach the IAM policy to the EKS worker nodes role. Add the following to tags to your clusters public subnets: kubernetes.io/cluster/demo-eks-cluster : shared kubernetes.io/role/elb : '' kubernetes.io/role/internal-elb : '' Deploy the rbac-role and alb ingress controller. kubectl apply -f rbac-role.yaml kubectl apply -f alb-ingress-controller.yaml Deploy Anchore Enterprise Enterprise services require an Anchore Enterprise license, as well as credentials with permission to the private docker repositories that contain the enterprise images. Create a Kubernetes secret containing your license file. kubectl create secret generic anchore-enterprise-license --from-file=license.yaml= Create a Kubernetes secret containing Docker Hub credentials with access to the private anchore enterprise repositories. kubectl create secret docker-registry anchore-enterprise-pullcreds --docker-server=docker.io --docker-username= --docker-password= --docker-email= Run the following command to deploy Anchore Enterprise: helm install --name anchore-enterprise stable/anchore-engine -f anchore_values.yaml It will take the system several minutes to bootstrap. You can checks on the status of the pods by running kubectl get pods MacBook-Pro-109:anchoreEks jvalance$ kubectl get pods NAME READY STATUS RESTARTS AGE anchore-cli-5f4d697985-hhw5b 1/1 Unknown 0 4h anchore-cli-5f4d697985-rdm9f 1/1 Running 0 14m anchore-enterprise-anchore-engine-analyzer-55f6dd766f-qxp9m 1/1 Running 0 9m anchore-enterprise-anchore-engine-api-bcd54c574-bx8sq 4/4 Running 0 9m anchore-enterprise-anchore-engine-catalog-ddd45985b-l5nfn 1/1 Running 0 9m anchore-enterprise-anchore-engine-enterprise-feeds-786b6cd9mw9l 1/1 Running 0 9m anchore-enterprise-anchore-engine-enterprise-ui-758f85c859t2kqt 1/1 Running 0 9m anchore-enterprise-anchore-engine-policy-846647f56b-5qk7f 1/1 Running 0 9m anchore-enterprise-anchore-engine-simplequeue-85fbd57559-c6lqq 1/1 Running 0 9m anchore-enterprise-anchore-feeds-db-668969c784-6f556 1/1 Running 0 9m anchore-enterprise-anchore-ui-redis-master-0 1/1 Running 0 9m anchore-enterprise-postgresql-86d56f7bf8-nx6mw 1/1 Running 0 9m Run the following command for details on the deployed ingress resource: MacBook-Pro-109:anchoreEks jvalance$ kubectl describe ingress Name: anchore-enterprise-anchore-engine Namespace: default Address: 6f5c87d8-default-anchoreen-d4c9-575215040.us-east-2.elb.amazonaws.com Default backend: default-http-backend:80 () Rules: Host Path Backends ---- ---- -------- * /v1/* anchore-enterprise-anchore-engine-api:8228 () /* anchore-enterprise-anchore-engine-enterprise-ui:80 () Annotations: alb.ingress.kubernetes.io/scheme: internet-facing kubernetes.io/ingress.class: alb Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal CREATE 18m alb-ingress-controller LoadBalancer 6f5c87d8-default-anchoreen-d4c9 created, ARN: arn:aws:elasticloadbalancing:us-east-2:472757763459:loadbalancer/app/6f5c87d8-default-anchoreen-d4c9/42defe8939465e2c Normal CREATE 18m alb-ingress-controller rule 2 created with conditions [{ Field: "path-pattern", Values: ["/*"] }] Normal CREATE 18m alb-ingress-controller rule 1 created with conditions [{ Field: "path-pattern", Values: ["/v1/*"] }] I can see above that an ELB has been created and I can navigate to the specified address: Once I login to the UI and begin to analyze images, I can see the following vulnerability and policy evaluation metrics displaying on the dashboard. Conclusion You now have an installation of Anchore Enterprise up and running on Amazon EKS. The complete contents for the walkthrough are available by navigating to the GitHub repo here. For more info on Anchore Engine or Enterprise, you can join our community Slack channel, or request a technical demo. ### Vulnerability Remediation Requirements for Internet-Accessible Systems The Department of Homeland Security recently issued the Binding Operational Directive 19-02, "Vulnerability Remediation Requirements for Internet-Accessible Systems." A binding operational directive is a compulsory direction to the federal, executive branch, and departments and agencies for purposes of safeguarding federal information and information systems. Federal agencies are required to comply with DHS-developed directives. As the development and deployment of internet-accessible systems increases across federal agencies, it is imperative for these agencies to identify and remediate any known vulnerabilities currently impacting the systems they manage. The purpose of BOD 19-02 is to highlight the importance of security vulnerability identification and remediation requirements for internet-facing systems. Additionally, layout required actions for agencies when vulnerabilities are identified through Cyber Hygiene scanning. The Cybersecurity and Infrastructure Security Agency (CISA) leverages Cyber Hygiene scanning results to identify cross-government trends and persistent constraints, to help impacted agencies overcome technical and resource challenges that prevent the rapid remediation of security vulnerabilities. These Cyber Hygiene scans are in accordance with Office of Management and Budget (OMB) Memorandum 15-01: Fiscal Year 2014-2015 Guidance on Improving Federal Information Security and Privacy Management Practices, from which the NCCIC conducts vulnerability scans of agencies' internet-accessible systems to identify vulnerabilities and configuration errors. The output from these scans can be known as Cyber Hygiene reports, which score any identified vulnerabilities with the Common Vulnerability scoring system or CVSS. "To ensure effective and timely remediation of critical and high vulnerabilities identified through Cyber Hygiene scanning, federal agencies shall complete the following actions:" Review and Remediate Critical and High Vulnerabilities Review Cyber Hygiene reports issues by CISA and remediates any critical and high vulnerabilities detected on Internet-facing systems: Critical vulnerabilities must be remediated within 15 calendar days of initial detection. High vulnerabilities must be remediated within 30 calendar days of initial detection. How Anchore Fits In As federal agencies continue to transform their software development, it is necessary for them to incorporate proper security solutions purpose-built to identify and prevent vulnerabilities that are native to their evolving technology stack. Anchore is a leading provider of container security and compliance enforcement solutions designed for open-source users and enterprises. Anchore provides vulnerability and policy management tools built to surface comprehensive container image package and data content, protect against security threats, and incorporate an actionable policy enforcement language capable of evolving as compliance needs change. Flexible and robust enough for the security and policy controls regulated industry verticals need to adopt cloud-native technologies in a DevSecOps environment. One of the critical points of focus here is leveraging Anchore to identify known vulnerabilities in container images. Anchore accomplishes this by first performing a detailed analysis of the container image, identifying all known operating system packages and third-party libraries. Following this, Anchore will map any known vulnerabilities to the identified packages within the analyzed image. Viewing Vulnerabilities in the UI Anchore Enterprise customers can view identified vulnerabilities for analyzed images, by logging into the UI, and navigating to the image in question. In the above image, we can see that CVE-2019-3462 is of severity high, linked to the OS package apt-1.0.9.8.4, and there is a fix available in version 1.0.9.8.5. Also presented in the UI, is a link to where the CVE information comes from. Based on the requirements of BOD 19-02, this high-severity vulnerability will need to be remediated within 15 days of identification. Note - A list of vulnerabilities can also be viewed using the Anchore CLI which can be configured to communicate with a running Anchore service. Also, the dashboard view provides a higher-level presentation of the vulnerabilities impacting all images scanned with Anchore. Viewing Vulnerabilities in the Build Phase Anchore scanning can be integrated directly into the build phase of the software development lifecycle to identify security vulnerabilities, and potentially fail builds, to prevent vulnerable container images from making their way into production registries and environments. This point of integration is typically the fastest path to vulnerability identification and remediation for development teams. Anchore provides a Jenkins plugin that will need to be configured to communicate with an existing Anchore installation. The Anchore Jenkins plugin surfaces security and policy evaluation reports directly in the Jenkins UI and as JSON artifacts. Note - For more information on how custom Anchore policies can be created to fulfill specific compliance requirements, contact us, or navigate to our open-source policy hub for examples. Registry Integration For organizations not scanning images during the build phase, Anchore can be configured to integrate directly with any docker_v2 container registry to continuously scan the repositories or tags. Ongoing Vulnerability Identification It is not uncommon for vulnerabilities to be published days or weeks after an image has been scanned. To address this, Anchore can be configured to subscribe to vulnerability updates. For example, if a user is subscribed to the library/nginx:latest image tag and a new vulnerability is added which matches a package in the subscribed nginx image, Anchore can send out a Slack notification. This alerting functionality is especially critical for the BOD 19-02 directive as the remediation requirements are time-sensitive, and agencies should be alerted of new threats ASAP. Conclusion Anchore continues to provide solutions for the government, enterprises, and open-source users, built to support the adoption of container technologies. By understanding that containers are more than just CVEs and lists of packages, Anchore takes a container-native approach to image scanning and provides end-users with a complete suite of policy and compliance checks designed to support a variety of industry verticals from the U.S. Government and F100 enterprises to start-ups. ### Create an Open Source Secure Container Based CI/CD Pipeline Docker gives developers the ability to streamline packaging, storage, and deployment of applications at great scale. With increased use of container technologies across software development teams, securing these images become challenging. Due to the increased flexibility and agility, security checks for these images need to be woven into an automated pipeline and become part of the development lifecycle. Common Tooling Prior to any implementation, it is important to standardize on a common set of tools that will be critical components for addressing the above requirement. The four tools that will be discussed today are as follows: Jenkins Docker Registry Anchore Notary Jenkins Continuous integration tools like Jenkins will be driving the workload for any automated pipeline to run successfully. The three tools below will be used throughout an example development lifecycle. Docker Registry Docker images are stored and delivered through registries. Typically, only trusted and secure images should be accessible through Docker registries that developers can pull from. Anchore Anchore will scan images and create a list of packages, files, and artifacts. From this, Anchore has the ability to define and enforce custom policies and send the results of these back in the form of a pass or fail. Notary Notary is Docker’s platform to provide trusted delivery of images. It does this by signing images, distributing them to a registry, and ensuring that only trusted images can be distributed and utilized. Example CI build steps: Developer commits code to repository. Jenkins job begins to build a new Docker image bring in any code changes just made. Once the image completes it is scanned by Anchore and checked against user-defined policies. If the Anchore checks do not fail, the image gets signed by Notary and pushed to a Docker registry. Anchore Policies As mentioned above, Anchore is the key component to enforcing only secure images progress through the next stages in the build pipeline. In greater detail, Anchore will scan images and create a manifest of packages. From this manifest, there is the ability to run checks for image vulnerabilities. Additionally, the ability to periodically check if new vulnerabilities have been published that directly impact a package contained within a relevant image manifest. Anchore has the ability to be integrated with common CI tools (Jenkins), or in an ad hoc manner from a command line. From these integrations, policy checks can be enforced to potentially fail builds. Anchore checks will provide the most value through a proper CI model. Having the ability to split up acceptable base images and application layers is critical for appropriate policy check abstraction. Multiple Anchore gates specific to each of these image layers is fundamental to the overall success of Anchore policies. As an example, prior to trusted base image promotion and push into a registry, it will need to pass Anchore checks for Dockerfile best practices (USER, non ssh open), and operating system package vulnerability checks. Secondary to the above, once a set of base images have been signed (Notary) and pushed into a trusted registry, it is now a requirement for all 'application specific' images to be created. It is the responsibility of whoever is building these images to make sure the appropriate base images are being used. Inheritance of a base layer will apply here, and only signed images from the trusted registry will be able to pass the next set of Anchore policy checks. These checks will not only focus on the signed and approved base layer images but depending on the application layer dependencies, will check for any NPM or Python packages that contain published vulnerabilities. Policies can be created that enforce Dockerfile and image best practices. As an example, Anchore allows the ability to look for a base image to be in existence via a regex check. These regular expressions can be used to enforce policies specific to image layers, files, etc. While the above is just an example of how to implement, secure, and enforce images throughout its lifecycle, it is important to understand the differences between tools, and the separate functions each play. Without tools similar to Anchore, it is easy to see how insecure or untrusted images can make their way into registries and production environments. By leveraging gated checks with Anchore, not only do you have control around which images can be used, but teams can begin to adopt core functionality of the other tools outlined above in a more secure fashion. ### Anchore & Slack, Container Security Notifications With Anchore you can subscribe to TAGs and Images to receive notifications when images are updated, when CVEs are added or removed and when the policy status of an image changes so you can take a proactive approach to ensure security and compliance. Having the ability to stay on top the notifications above allows for the appropriate methods for remediation and triage to take place. One of the most common alerting tools Anchore users leverage is Slack. How to Configure Slack Webhooks to Receive Anchore Notifications via Azure Functions In this example, we will walk through how to configure Slack webhooks to receive Anchore notifications. We will consume the webhook with an Azure Function and pass the notification data into a Slack channel. You will need the following: Anchore Engine service: Anchore Slack account: Slack Azure account: Azure Slack Configuration Configure incoming webhooks to work with the Slack application you would like to send Anchore notifications to. The Slack documentation gives a very detailed walkthrough on how to set this up. Should look similar to the configuration below (I am just posting to the #general channel): Azure Initial Configuration Once you have an Azure account, begin by creating a Function App. In this example I will use the following configuration: Choose In-Portal development environment and then Webhook + API: Once the function has been setup, navigate to the integrate tab and edit the configuration: Finally, we will to select 'Get function URL' to retrieve the URL for the function we've just created. It should look similar to this format: https://jv-test-anchore-webhook.azurewebsites.net/api/general/policy_eval/admin Anchore Engine Configuration If you have not setup Anchore Engine there are a couple of choices: Navigate to our GitHub repo Head to our support documentation Once you have a running Anchore Engine, we need to configure engine to send out webhook notifications to the URL of our Function App in Azure. Once the configuration is complete, you will need to activate a subscription, you can follow the documentation link above for more info on that. In this example, I have subscribed to a particular tag and am listening for 'policy_eval' changes. From the documentation: "This class of notification is triggered if a Tag to which a user has subscribed has a change in its policy evaluation status. The policy evaluation status of an image can be one of two states: Pass or Fail. If an image that was previously marked as Pass changes status to Fail or vice-versa then the policy update notification will be triggered." Azure Function Code I kept this as minimal as possible in order to keep it open-ended. In short, Anchore will be sending out the notification data to the webhook endpoint we've specified, we just need to write some code to consume it, and then send it to Slack. You can view the code here. Quick note: In the example, the alert to Slack is very basic. However, feel free to experiment with the notification data that Anchore sends to Azure and configure the POST data to Slack. Testing In my example, I'm going to swap between two policy bundles and evaluate them against an image and tag I've subscribed to. The easiest way to accomplish this is via the CLI or the API. The CLI command to activate a policy: anchore-cli policy activate  The CLI command to evaluate an image:tag against the newly activated policy: anchore-cli evaluate check docker.io/jvalance/sampledockerfiles:latest This should trigger a notification give I've modified the policy bundles to create two different final actions. In my example, I'm toggling the exposed port 22 in the default bundle between 'WARN' and 'STOP' Once Anchore has finished evaluating the image against the newly activated policy, a notification should be created and sent out to our Azure Function App. Based on the logic we've written, we will handle the request, and send out a Slack notification to our Slack app that has been set up to receive incoming webhooks. You should be able to view the notification in the Slack workspace and channel: ### Anchore & Enforcing Alpine Linux Docker Images Vulnerability A security vulnerability affecting the Official Alpine Docker Linux images (>=3.3) contain a NULL password for the root user. This particular vulnerability has been tracked as CVE-2019-5021. With over 10 million downloads, Alpine Linux is one of the most popular Linux distributions on Docker Hub. In this post, I will demonstrate an understanding of the issue by taking a closer look at two Alpine Docker images, configure Anchore Engine to identify the risk within the vulnerable image, and give a final output based on Anchore policy evaluation. Finding the Issue In the build of the Alpine Docker image (>=3.3) the /etc/shadow file show the root user password field entry without a password or lock specifier set. We can see this by running an older Alpine Docker image: # docker run docker.io/alpine:3.4 cat /etc/shadow | head -n1 root:::0::::: With no ! or password set, this will now be the condition we wish to check with Anchore. To see this condition addressed with the latest version of Alpine, run the following command: # docker run docker.io/alpine:latest cat /etc/shadow | head -n1 root:!::0::::: Configuring Anchore Secret Search Analyzer We will now set up Anchore to search for this particular pattern during image analysis, in order to properly identify the known issue. Anchore comes with a number of patterns pre-installed that search for some types of secrets and keys, each with a named pattern that can be matched later in anchore policy definition. We can add a new pattern to the analyzer_config.yaml anchore engine configuration file, and start-up anchore with this configuration. The new analyzer_config.yaml, for example, should have a new pattern added, which we've named 'ALPINE_NULL_ROOT': # Section in analyzer_config.yaml # Options for any analyzer module(s) that takes customizable input ... ... secret_search: match_params: - MAXFILESIZE=10000 - STOREONMATCH=n regexp_match: ... ... - "ALPINE_NULL_ROOT=^root:::0:::::$" Note - By default, an installation of Anchore comes bundled with a default analzyer_config.yaml file. In order to address this particular issue, modifications will need to be made to the analzyer_config.yaml file as shown above. In order to make sure the configuration changes make their way into your installation of Anchore Engine, create an analyzer_config.yaml file and properly mount it into the Anchore Engine Analyzer Service. Create an Anchore Policy Specific to this Issue Next, I will create a policy bundle containing a policy rule which explicitly look for any matches found of the above ALPINE_NULL_ROOT regex create above. If any matches are found, the Anchore policy evaluation will fail. # Anchore ALPINE_NULL ROOT Policy Bundle { "blacklisted_images": [], "comment": "Default bundle", "id": "alpinenull", "mappings": } ], "name": "Default bundle", "policies": , "trigger": "content_regex_checks" } ], "version": "1_0" } ], "version": "1_0", "whitelisted_images": [], "whitelists": , "name": "Global Whitelist", "version": "1_0" } ] } Note: The above is an entire policy bundle component which will be needed to effectively evaluate against any analyzed images. The key section within this is the policies section, where we are using the secret_scans gate with content_regex_name and ALPINE_NULL_ROOT parameters. Conduct Policy Evaluation Once this policy has been added and activated to an existing Anchore Engine deployment, we can conduct an analysis and policy evaluation of the vulnerable Alpine Docker image (v3.4) via the following command: # anchore-cli evaluate check docker.io/library/alpine:3.4 --detail Image Digest: sha256:0325f4ff0aa8c89a27d1dbe10b29a71a8d4c1a42719a4170e0552a312e22fe88 Full Tag: docker.io/library/alpine:3.4 Image ID: b7c5ffe56db790f91296bcebc5158280933712ee2fc8e6dc7d6c96dbb1632431 Status: fail Last Eval: 2019-05-09T05:02:32Z Policy ID: alpinenull Final Action: stop Final Action Reason: policy_evaluation Gate Trigger Detail Status secret_scans content_regex_checks Secret search analyzer found regexp match in container: file=/etc/shadow regexp=ALPINE_NULL_ROOT=^root:::0:::::$ stop In the above output, we can explicitly see that the secret search analyzer found a regular expression match in the Alpine 3.4 Docker image we've analyzed and we've associated a stop action with this policy rule definition, and the overall result of the policy evaluation has failed. Given that Alpine is one of the most widely used Docker images, and the impacted versions of it are particularly recent, it is recommended to update to a new version of the image that is not impacted or modify the image to disable the root account. ### How Tremolo Security Deploys Anchore on Openshift When you see a breach in the headlines, it usually reads something like “Known vulnerability exploited to…”Whatever was stolen or broken was compromised because of a bug that had been discovered and fixed by the developers, but not patched in production. Patching is hard. It’s much harder than most security professionals are willing to admit. It’s not hard because running an upgrade script is hard, patching is hard because without a comprehensive testing suite you never know if an update is going to break your application or systems. At Tremolo Security, we have already blogged about how we approach patching our dependencies in Unison and OpenUnison. With our release of Orchestra to automate security and compliance in Kubernetes in the past few weeks, we wanted to apply the same approach to our containers. We turned to Anchore’s open source Anchore Engine to scan the containers we publish and make sure they’re kept up to date. In this post we’re going to talk about our use case, why we chose to use Anchore and how we deployed Anchore to scan and update our containers. Publishing Patched Containers Our use case for container scanning is a bit different then most. In a typical enterprise you want to have a secure registry with containers that are continuously scanned for known vulnerabilities and compliance with policies. For Tremolo Security, we wanted to make sure that the containers we publish are already patched and kept updated continuously. We work very hard to create an easily patched solution and we want to make sure our customers can feel confident that the containers they obtain from us have been kept up to date. When we first started publishing containers, we relied on Dockerhub’s automatic builds to publish our containers whenever one of the base images (CentOS or Ubuntu) were updated. This wasn’t good enough for us. The base containers were usually patched once per month, but that was too slow for us. We’d have customers come to us and say “we scanned your containers and there are patches available.” We wanted to make sure that as patches became available they were immediately integrated into our containers. Why We Chose Anchore We were first introduced to Anchore a few years ago when they were guests on TWIT.tv’s FLOSS Weekly, a podcast about free and open source software. We had submitted our container for a scan by both Anchore’s service and a well-known provider’s service and received very different results. We tweeted our question to Anchore and they responded with a great blog post explaining how they take into account Red Hat’s updates to CVEs in CentOS for far better and more accurate scan results. That deep level of understanding made it clear to us this was a partner we wanted to work with. Deploying Anchore Now for the fun part, we wanted to deploy Anchore’s open source engine on our own infrastructure. We use OKD for various functions at Tremolo Security, including our CI/CD pipeline and publishing. OKD out of the box is far more restrictive than most Kubernetes distributions. It doesn’t allow for privileged containers by default and its use of selinux is very powerful but can be very limiting on containers that are not built to run unrestricted. Finally, OKD doesn’t rely on Helm or Tiller but Anchore does. Helm and Tiller I don’t like to deploy anything in my cluster that has cluster-admin access unless I know and am in control of how and when its used. Helm and Tiller have never given me these warm-and-fuzzies and so we don’t use it. That said we needed it for deploying Anchore so we decided to deploy it into Anchore’s project (namespace). When we deployed tiller, we give it a service account that only had administrator access in the Anchore project. As soon as we had Anchore working, we immediately destroyed the Helm and Tiller deployments. Writing Ephemeral Data The first issue we ran into was that the containers that makeup Anchore’s engine write ephemeral data into their containers. Most k8s distros will let you do this based on file system permissions, but not OKD. When you need to write ephemeral data you need to update your pods to use empty volumes. We went through each of the deployments in the Helm charts to add them: - name: service-config-volume mountPath: /anchore_service_config - name: logs mountPath: /var/log/anchore - name: run mountPath: /var/run - name: scratch mountPath: /scratch and - name: service-config-volume emptyDir: {} - name: logs emptyDir: {} - name: run emptyDir: {} - name: scratch emptyDir: {} Unprivileged Containers Next issue we ran into was that the analyzer needed root access. The other containers thankfully do not. We created a service account and added it to the privileged scc in OKD. SCCs serve the same role in OKD that pod security policies are now serving upstream Kubernetes clusters. Deleting Helm Once Anchore was running, did I mention we deleted Helm? Scanning and Updating Containers Once Anchore was running, we needed to add our containers and then make sure they were updated appropriately. While the anchore-cli works great for one-off commands, it wasn’t going to scale for us. We publish variants for nearly a dozen containers for Ubuntu, CentOS and RHEL so the cli just wasn’t going to work. The great thing is though that Anchore is cloud-native and the cli just uses an API! We decided to create a poor man’s operator. An operator is a pattern in the cloud-native world that says “Take all the repetitive stuff admins do and automate it.” For instance, the operators we’re building for OpenUnison and MyVirtualDirectroy will automate certificate management and trusts. Typically operators revolve around a custom resource definition (CRD) and when an instance of a CRD is updated the operator makes sure the environment is brought into line with the configuration of the custom resource. We call this a poor man’s operator because instead of watching a custom resource, we decided to create a CronJob that would run through the containers listed in a CR and if updates are available to call a webhook to being rebuilding. The great thing about this approach was we could just add new containers to our CR and it would just add them to Anchore’s scans! No fuss, no muss! We’re all open source friends here so we published our code - https://github.com/TremoloSecurity/anchore-os-image-scan. Closing The Loop Anchore’s given Tremolo Security a great platform for keeping our containers patched. Knowing when we walk into a customer that they’re scans will give the best possible results is a competitive differentiator for us. We have enjoyed working with Anchore for the last few years and look forward to working with them for many more to come! ### Anchore 2.0 is Now Built on the Red Hat Universal Base Image Earlier this week Red Hat announced an exciting new offering for developers, technology partners, and users: the Red Hat Universal Base Image (UBI). Anchore is excited to announce that as of Anchore Enterprise 2.0 (including the OSS Anchore Engine), core Anchore container images will now be based on the Red Hat UBI. As an organization that develops software that is primarily distributed to end-users as a collection of container images, we have derived great value and agility through the isolation and encapsulation that comes with developing on, building, testing, and distributing software using containers. The Anchore services themselves are applications that utilize underlying libraries, dependencies and utilities that are typically provided by most Linux OS distributions, and as such our container images have historically been based on either CentOS or Ubuntu base images. It is a testament to the effectiveness of container isolation that even though Anchore has changed which OS base image we’ve used, the user experience of running/upgrading Anchore across these changes has remained largely unchanged. However, there have been users who have asked for more from the underlying OS that Anchore services are built upon - specifically the ability to match the supported container and underlying OS infrastructure, and access to support options from the OS vendor for container-based service deployments. Up until now, we have not been able to provide crystal clear recommendations around these topics to our users. "Red Hat is pleased to welcome Anchore as one of the first partners to adopt the Universal Base Image" said Lars Herrmann, senior director, Ecosystem Program, Red Hat. "We believe the availability of more freely redistributable, well-curated base images can simplify the development process for our partners and enhance the support experience of our mutual customers." The Red Hat Universal Base Image is derived directly from Red Hat Enterprise Linux, and is freely available and redistributable, enabling technology partners and application developers such as ourselves to build and distribute our container-based applications, all based on a familiar and trusted Red Hat based OS. As an application developer, the availability of the UBI short-circuits complications that can arise from users and customers of ours, who are asking for OS-level support for our application, and many other use cases where a supported container OS environment is required (in particular, within large enterprises and regulated industries). In addition, UBI has made the Red Hat OSS software ecosystem fully accessible, when it comes to delivering end-to-end (from development, through build, to distribution) container-based software. Anchore users can now utilize familiarity with Red Hat software for system diagnosis/deep inspection within the Anchore containers (based on UBI), and most importantly can now “turn on” official Red Hat support for any base OS concerns when running on Red Hat Enterprise Linux or Red Hat OpenShift, in addition to the specialized support available from Anchore for our own services. We’re excited to be an early adopter of the UBI offering from Red Hat, and believe that moving to UBI as our base container image clearly and immediately improves the options available to ourselves (as application developers) and to all users of Anchore, across the board. For more information on the Anchore Enterprise 2.0 launch, as well as the Red Hat Universal Base Image announcements and material, please refer to the following links. Learn More About the Red Hat Universal Base Image Learn More About Anchore Enterprise 2.0 ### Announcing Anchore Enterprise Version 2.0 We’re truly excited today to announce the immediate availability of Anchore Enterprise version 2.0, the latest OSS and Enterprise software from Anchore that provides users with the tools and techniques needed to enforce container security, compliance and best-practices requirements with usable, flexible, cross-organization, and above all time-saving technology from Anchore. This release is based on the all-new (and also available today) OSS Anchore Engine version 0.4.0). New Features of Enterprise 2.0 Building on top of the existing Anchore Enterprise 1,2 release, Anchore Enterprise version 2.0 adds major new features and architectural updates that collectively represent the technical expression of discussions, experiences, and feedback from customers and users of Anchore over the last several years. As we continue to gain in-depth insight into the challenges that Dev/Ops and Sec/Ops groups face, we’re observing container-based deployments becoming more of the norm rather than the exception (for production workloads). As a consequence, the size, responsiveness, information retrieval and reporting breadth, and operational needs demanded of Anchore in its role as an essential piece of policy-based security and compliance infrastructure have grown in kind. The overarching purpose of the new features and design of the 2.0 version of Anchore Enterprise is to directly address the challenges of continued growth and scale by extending the enterprise integration capabilities of Anchore, establishing an architecture that grows alongside our users’ demanding throughput and scale requirements, and offering even more insight into users’ container image environments through rich new APIs and reporting capabilities, all in addition to the rich set of enforcement capabilities included with Anchore Enterprise’s flexible policy engine. The major new features and resources launched as part of Anchore Enterprise 2.0 include: GUI Dashboard: new configurable landing page for users of the Enterprise UI, presenting complex information summaries and metrics time series for deep insight into the collective status of your container image environment. Enterprise Reporting Service: entirely new service that runs alongside existing Anchore Enterprise services that exposes the full corpus of container image information available to Anchore Engine via a flexible GraphQL interface LDAP Integration: Anchore Enterprise can now be configured to integrate with your organization’s LDAP/AD identity management system, with flexible mappings of LDAP information to Anchore Enterprise’s RBAC account and user subsystem. Red Hat Universal Base Image: all Anchore Enterprise container images have been re-platformed atop the recently announced Red Hat Universal Base Image, bringing more enterprise-grade software and support options to users deploying Anchore Enterprise in Red Hat environments. Anchore Engine 0.4.0: Anchore Enterprise is built on top of the OSS Anchore Engine, which has received many new features and updates as well (see below for details). New Documentation and Resources: Alongside the release of Anchore Engine 0.4.0, we’ve launched a brand new documentation site that provides a more flexible structure, versioned documentation sets, and greatly enhanced feedback and contribution capabilities. New Support Portal: customers of Anchore Enterprise 2.0 are now provided with full access to a new support portal for better ticket tracking and feature request submissions. Anchore Engine OSS Anchore Enterprise 2.0 is built on top of Anchore Engine version 0.4.0 - a new version of the fully functional core services that drive all Anchore deployments. Anchore Engine has received a number of new features and other new project updates: Automated Data Management: new automation capabilities and rules allow simplified management of the volume of analysis data while still supporting audit capabilities. New data tiers support flexible management of Anchore data resources as your deployment grows and scales over time. Policy Hub: centralized repository of Anchore policies, accessible by all Anchore users, where pre-canned policies are available either to be used directly or as a starting point for your own policy definitions. Rootless Analyzers: new implementation of the core image analysis capabilities of Anchore which no longer require any special access to handle the high variability found within container images, while still providing the deep inspection needed for powerful security and compliance enforcement. Red Hat Universal Base Image: all Anchore Engine container images have been re-platformed atop the recently announced and freely available Red Hat Universal Base Image, bringing more enterprise-grade software and support options to users deploying Anchore Engine in Red Hat environments. For a full description of new features, improvements and fixes available in Anchore Engine OSS, click here. Once again, we would like to sincerely thank all of our open-source users, customers and contributors for all of the spirited discussion, feedback, and code contributions that are all part of this latest release of Anchore Engine OSS! If you’re new to Anchore, we would like nothing more than to have you join our community! Anchore Enterprise 2.0 Available Now With Anchore Enterprise 2.0, available immediately, our goal has been to include a brand new set of large scale and enterprise-focused updates for all Anchore users that can be utilized immediately by upgrading existing deployments of Anchore Enterprise or Anchore Engine OSS. For users looking for comprehensive solutions to the unique challenges of securing and enforcing best-practices and compliance to existing CI/CD, container monitoring and control frameworks, and other container-native pipelines, we sincerely hope you enjoy our latest release of Anchore software and other resources - we look forward to working with you! For more information on requesting a trial, or getting started with Anchore Enterprise 2.0, please direct your browser to the Anchore Enterprise. ### Use Anchore Policies to Reach CIS Docker Benchmark As Docker usage has greatly increased, it has become increasingly important to gain a better understanding of how to securely configure and deploy Dockerized applications. The Center for Internet Security published 1.13 Docker Benchmark, which provides consensus-based guidance by subject matter experts for users and organizations to achieve secure Docker usage and configuration. We previously published a blog on how Anchore can help achieve NIST 800-190 compliance. This post will detail how Anchore can help with certain sections of CIS Docker Benchmarks 1.13. The publication focuses on five areas that are specific to Docker: Host Configuration Docker daemon configuration Docker daemon configuration files Container Images and Build File Container Runtime Anchore is a service that analyzes Docker images pre-runtime and applies user-defined acceptance policies to allow automated container image validation and certification. Anchore is more commonly used with a CI tool similar to Jenkins in order to streamline container image builds in a more automated fashion. The critical component in helping achieve any sort of compliance are Anchore Policy Bundles. With these, users have full control over what specific policy rules they would like their Docker images to adhere to, and potentially fail or warn users based on the outcome of these evaluations. Scoring Information A scoring status indicated whether compliance with the given recommendations impacts the assessed target's benchmark score. Scored Failure to comply with "Scored" recommendations will decrease the final benchmark score. Compliance with "Scored" recommendations will increase the final benchmark score. Not Scored Failure to comply with "Not Scored: recommendations will not decrease the final benchmark score. Compliance with "Not Scored" will not increase the final benchmark score. Profile Definitions The following configuration profiles are defined by this Benchmark: Level 1 - Docker Items in this profile intend to: Be practical and prudent Provide a clear security benefit Not inhibit the utility of the technology beyond acceptable means Level 2 - Docker Items in this profile exhibit one or more of the following characteristics: Are intended for environments or use cases where security is paramount Acts as defense in depth measure May negatively inhibit the utility or performance of the technology 1. Host Configuration Security tools specific to the Host Configuration are not achievable with Anchore. 2. Docker Daemon Configuration Security tools specific to the Docker daemon are not achievable with Anchore. 3. Docker Daemon Configuration Files Security tools specific to the Docker daemon configuration are not achievable with Anchore. 4. Container Images and Build files Docker container images and their corresponding Dockerfiles govern how a container will behave when running. It is important to use the appropriate base images, and best practices when creating Dockerfiles to secure your containerized applications and infrastructure. 4.1 Create a user for the container (Scored) Create a non-root user for the container in the Dockerfile for the container image. It generally good practice to run a Docker container as a non-root user. When creating Dockerfiles make sure the USER instruction exists. This can be achieved with an Anchore policy by checking for the USER instruction, as well as checking to make sure the effective user is not the root. 4.2 Use trusted base images for containers (Not Scored) Ensure that container images come from trusted sources. Official repositories are Docker images curated and optimized by the Docker community or vendor. As an organizational best practice, setting up a trusted Docker registry where your developers are allowed to push and pull images from is seen as secure. Configuration and use of Docker Content trust with Notary is helpful when achieving this. Anchore helps with this when built-in with a secure CI pipeline. As an example, once an image has been built, it is then scanned and analyzed by Anchore, if it passes Anchore policies it is now safe to be pushed to a designated trusted Docker registry. If the image does not pass Anchore checks, it does not get pushed to a registry. Anchore policies can be set up to make sure base images are coming from trusted registries as well. 4.3 Do not install unnecessary packages in the container (Not Scored) It is generally a best practice to not install anything outside of the usage scope of the container. By bringing additional software packages that are not utilized, the attack surface of the container is increased. Anchore policies get be set to look for only a setlist of software packages, or look for a slimmed-down version of the base image by checking the FROM instruction. By using minimal base images or alpine, not only is the size of the image greatly decreased, the threat surface area of the container is decreased. 4.4 Scan and rebuild the images to include security patches (Not Scored) Images should be scanned frequently. If vulnerabilities are discovered within images, they should be patched/fixed, rebuilt, and pushed to the registry for instantiation. Anchore scans can be conducted as part of a normal CI pipeline, doing this ensures the frequency of scans is in-line with image builds. Anchore vulnerability feeds are consistently being updated with newer vulnerabilities as they are made available to the public. By watching image repositories and tags within Anchore, webhook notifications can be configured to alert the appropriate teams when new vulnerabilities are impactful to a watched image or tag. Anchore policy checks during the CI pipeline can be set up to stop container images with vulnerable software packages from ever reaching a trusted registry. 4.5 Enable Content trust for Docker (Scored) Enable content trust for Docker and use digital signatures with a tool like Notary to ensure that only trusted Docker images can be pushed to a registry. While this is not directly enforceable by Anchore, setting up Anchore policy checks within a CI pipeline to only sign images that have passed an evaluation is part of a secure CI best practice. 4.6 Add HEALTHCHECK instruction to the container image (Scored) Add the HEALTHCHECK instruction within your Dockerfiles. This ensures the engine will periodically check the running container against that instruction. Based on the output of the healthcheck, Docker could exit a non-working container and instantiate a new one. Anchore policy checks can be configured to ensure the HEALTHCHECK instruction is present within a Dockerfile. 4.7 Do not use update instructions alone in the Dockerfile (Not Scored) Make sure to not use update instruction alone or in a single line within a Dockerfile. Doing this will cache the update layer, and potentially could deny a fresh update when the Docker image is built again. Anchore policy checks can be configured to look for regular expressions specific to an update instruction alone or in a single line. Following this, a warning notification could be sent out. 4.8 Remove setuid and setgid permissions in the images (Not Scored) Remove setuid and setgid permission in the images to prevent escalation attacks in the containers. Anchore policy checks can be set to only allow setuid and setgid permission on executables that need them. These permissions could be removed during build time by explicitly stating the following in the Dockerfile: RUN find / -perm +6000 -type f -exec chmod a-s {} ; || true 4.9 Use COPY instead of ADD in Dockerfile (Not Scored) Use the COPY instruction instead of the ADD instruction in Dockerfiles. Anchore policy checks can be setup to warn when ADD instruction in the present in a Dockerfile. 4.10 Do not store secrets in Dockerfiles (Not Scored) Do not store secrets in Dockerfiles. Anchore policy checks can be configured to look for secrets (AWS keys, API keys, or other regular expressions) that may be present within an image. 4.11 Install verified packages only (Not Scored) Verify the authenticity of packages before installing them in the image. Since Anchore can inspect the Dockerfile, policy checks can be configured to only allow allowed packages to be installed during a Docker build. 5. Container Runtime Although Anchore focuses on mainly pre-runtime, there are countermeasures that can be taken during the build stage prior to instantiation to help mitigate container runtime threats. 5.6 Do not run ssh within containers (Scored) SSH server should not be running within the container. Anchore policies can be configured to check for exposed port 22. 5.7 Do not map privileged ports within containers (Scored) The TCP/IP port number below 1024 are considered privileged ports. Normal users and processes are not allowed to use them for various security reasons. Anchore policies can be configured to check for these exposed ports. 5.8 Only open needed ports on container (Scored) Dockerfile for container images should only define needed ports for container usage. Anchore policies can be configured to check that the needed exposed ports are open. Conclusion The above findings outline which sections of the CIS Docker Benchmark can achieve with Anchore and Anchore policies. It is highly recommended that other tools be used in combination to achieve and secure CI image pipeline in order to accomplish a more complete CIS Docker Benchmark score. One of the easiest ways to get started with achieving the Docker CIS Benchmark is to use the Anchore Policy Bundle below: Anchore Policy for Docker CIS Get started with the Anchore Policy for Docker CIS Benchmark on the Anchore Policy Hub. ### Testing Anchore with Ansible, K3s and Vagrant 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: Virtualbox v5.2 or later Vagrant v2.0 or later The Vagrant Virtualbox Guest Additions Plugin Ansible v2.7 or later A copy of the project repository (git clone) 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. ### What is the Difference Between Anchore and Clair? As a customer-facing Solutions Architect at Anchore, I have daily conversations with prospects and existing customers about the challenges they face with their container image workloads. During this discovery stage, I often hear a mix of security and DevOps tools used to automate, orchestrate, secure, and release through the lifecycle of containers. One of the tools I hear of quite frequently is CoreOS Clair. Since Anchore and Clair share some of the same characteristics and use cases, I wanted to write up a quick summary of the two tools and point out the similarities and differences. Clair Clair is an open source project for static analysis of vulnerabilities in container images. Clair collects vulnerability data at intervals and stores them in the database, scrubs container images and indexes the installed software packages. If any vulnerabilities are matched to identified software packages in the images, Clair can send out alerts, reports, or block deployments to production environments. For users looking for this specific functionality, Clair is a perfect solution. Additionally, for Quay.io users, Clair security scanning comes baked in. At Anchore, we love Clair and it's capabilities, and certainly agree that security, particularly static analysis of container images, is a critical component to a more mature security posture. Container images are a new artifact, and it is not always known what is inside of them. In addition, developers rather than operations teams are often responsible for creating these container images. Due to the variety in containers the problem of vetting artifacts on the way to production environments is more critical than ever. How Anchore Can Help Many of our new users and customers come from Clair, and most often it is due to a key principle we center on at Anchore: A heavily customizable policy enforcement engine that can evolve over time as needs change. Our most successful open source users and enterprise customers have highlighted the above as a hard requirement for their continued success with a container security tool. Often our customers have specific compliance requirements they need to fulfill. These requirements could be detailed in documents like CIS Docker Benchmark or NIST 800-190. Or they could have internal security and policy requirements they need to adhere to. Whatever the case is, the top two responses we get when asking for an ideal solution is typically: I'm looking for more than just a list of CVEs I'm looking to build customizable policy rules to meet specific compliance needs. Anchore addresses these issues by providing comprehensive coverage of container image contents that extend beyond vulnerability scanning. This includes secrets scanning, misconfigurations, and compliance best practices. In addition to the identification of operating systems and language packages, such as Node, Ruby, Java, and Python, Anchore provides the user with actionable results from a policy engine that can be used to block CI builds, generate reports, or alert via webhook notifications. When it comes to particular industries such as Government, Healthcare, and Financial services, compliance is high on the priority list. Typically, these verticals will have strict policy checks they need enforced and critical software solutions that need certification. To accomplish this, leveraging container-native security tools that provide a complete suite of checks out of the box, becomes a requirement. While Anchore Engine provides key functionality for many users, we wanted to extend its core functionality to address prospects asking for more enterprise features. Anchore’s Enterprise offering fulfills the specific needs of these users by providing a GUI client, RBAC, on-premise data feed aggregation service, high-quality vulnerability data from proprietary sources, enhanced reporting, and full enterprise-grade support. Conclusion It is clear that the importance of static analysis of container images, in particular identifying known vulnerabilities in software packages, is well known at both Anchore and CoreOS Clair. As a potential user or customer deciding on a container security tool, I recommend uncovering some key bullet points you'd like to see in an ideal solution and aligning those points with core principles and problems certain vendors solve. Get started with the open source Anchore Engine. ### Envoy Vulnerabilities and their Impact on Istio In this post, I wanted to take a closer look at two recent vulnerabilities impacting Envoy Proxy versions 1.9.0 and older (CVE 2019-9900 and CVE 2019-9901). Since these two particular CVEs have been identified, they have also been patched in Envoy version 1.9.1. Before diving into the specifics of the vulnerabilities and their impact, I wanted to give some general background on Envoy and Istio. What is Envoy? Envoy Proxy is a modern, high-performance, small-footprint edge and service proxy. Envoy is most comparable to software load balancers such as NGINX and HAProxy. Originally written and deployed at Lyft, Envoy is now an official graduated project of the Cloud Native Computing Foundation. For more information on Envoy and a real-world example of its usage in practice, I recommend watching this video: The Mechanics of Deploying Envoy at Lyft. What is Istio? Istio is an open source service mesh that layers transparently onto existing distributed applications. It is also a platform, including APIs that let it integrate into any logging platform, or telemetry or policy system. Istio lets you successfully, and efficiently, run a distributed microservice architecture, and provides a uniform way to secure, connect, and monitor microservices. For a clear example on Istio, I recommend watching this video: What is Istio? What is a Service Mesh? The term service mesh is used to describe the network of microservices that make up such applications and the interactions between them. As a service mesh grows in size and complexity, it can become harder to understand and manage. Its requirements can include discovery, load balancing, failure recovery, metrics, and monitoring. A service mesh also often has more complex operational requirements, like A/B testing, canary rollouts, rate limiting, access control, and end-to-end authentication. If you are interested in further learning on the concepts of a service mesh and the challenges it is intended to solve, I recommend reading the following post by Hashicorp: What is a Service Mesh? Istio provides behavioral insights and operational control over the service mesh as a whole, offering a complete solution to satisfy the diverse requirements of microservice applications. An Istio service mesh is logically split into a data plane and a control plane. The data plane is composed of a set of intelligent proxies Envoy deployed as sidecars. These proxies mediate and control all network communication between microservices along with Mixer, a general-purpose policy and telemetry hub. The control plane manages and configures the proxies to route traffic. Additionally, the control plane configures Mixers to enforce policies and collect telemetry. Istio and Envoy Istio uses an extended version of the Envoy proxy. Envoy is deployed as a sidecar to the relevant service in the same Kubernetes pod. This deployment allows Istio to extract a wealth of signals about traffic behavior as attributes. Istio can, in turn, use these attributes in Mixer to enforce policy decisions, and send them to monitoring systems to provide information about the behavior of the entire mesh. CVE-2019-9900 Envoy expects that its HTTP codecs enforce RFC constraints on valid header values. In particular, it is expected that there are no embedded NUL characters in paths, header values or keys. When parsing HTTP/1.x header values, Envoy 1.9.0 and before does not reject embedded zero characters (NUL, ASCII 0x0). This allows remote attackers crafting header values containing embedded NUL characters to potentially bypass header matching rules, gaining access to unauthorized resources. Based on current information, this only affects HTTP/1.1 traffic. If this is not structurally possible in your network or configuration, then it is unlikely that this vulnerability applies. View the CVE GitHub Issue. CVE-2019-9901 Envoy does not normalize HTTP URL paths in Envoy 1.9 and before. A remote attacker may craft a path with a relative path, e.g. something/../admin, to bypass access control, e.g. a block on /admin. A backend server could then interpret the unnormalized path and provide an attacker access beyond the scope provided for by the access control policy. View the CVE GitHub Issue. An attacker could bypass access control and could also circumvent DoS prevention system such as rate limiting and authorization for a given backend server. Remediation As mentioned in the introduction, these two vulnerabilities have been patched in Envoy version 1.9.1, and correspondingly in the Envoy builds embedded in Istio 1.1.2 and Istio 1.0.7. they recommend steps for remediation are as follows: For Istio 1.1.x deployments: update to a minimum of Istio 1.1.2 For Istio 1.0.x deployments: update to a minimum of Istio 1.0.7 ### Getting Started with Helm, Kubernetes and Anchore We see a lot of people asking about standing up Anchore for local testing on their laptop and in the past, we’ve detailed how to use Docker to do so. Lately, I have been frequently asked if there’s a way to test and learn with Anchore on a laptop using the same or similar deployment methods as what would be used in a larger deployment. Anchore installation is preferably done via a Helm chart. We can mirror this on a laptop using MiniKube, as opposed to the instructions to use docker-compose to install Anchore. MiniKube is a small testing instance of Kubernetes you can install on your laptop, whether you use Windows, Linux or macOS. Instructions on installing the initial MiniKube virtual machine are here. Prerequisites are different for your platform so read closely. On macOS You need only install VirtualBox, Homebrew, and issue the following command: brew cask install minikube kubernetes-cli Once the installation is complete, you can start your minikube instance with the following command: minikube start Once minikube has started, we can grab helm from the Kubernetes GitHub repository: curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get > get_helm.sh chmod 700 get_helm.sh ./get_helm.sh Or on macOS: brew install kubernetes-helm That will install the latest version of Helm for us to use. Let’s now create a role for helm/tiller to use. Place the following in a file called clusterrole.yaml: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: annotations: rbac.authorization.kubernetes.io/autoupdate: "true" labels: kubernetes.io/bootstrapping: rbac-defaults name: cluster-admin rules: - apiGroups: - '*' resources: - '*' verbs: - '*' - nonResourceURLs: - '*' verbs: - '*' To create the cluster role, let’s run this command: kubectl create -f clusterrole.yaml Now we’ll create a service account to utilize this role with these commands: kubectl create serviceaccount -n kube-system tiller kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller Let’s now initialize helm: helm init --service-account tiller We can verify if that worked with the following command: kubectl --namespace kube-system get pods In that output, you should see a line showing a namespace item of “tiller-deploy” with a status of “running.” Once we have that installed, let’s install Anchore via the helm chart: helm install --name anchore-demo stable/anchore-engine This will install a demo instance of Anchore engine that allows anonymous access. You may want to consult our documentation on helm installs here for more detailed or specific types of configurations to install. Hopefully, you now have a local copy of Anchore to use on your local development processes using MiniKube and Helm. ### Introduction to Kubernetes Security Background Over the past couple of years, the software community has seen the rise of Kubernetes. First developed by Google, Kubernetes is the most popular open-source container management tool which automates container deployment, container scaling, and container load balancing. A few of the major features and benefits of Kubernetes are: Automatic Binpacking Service Discovery & Load Balancing Storage Orchestration Self Healing Horizontal Scaling Kubernetes is also backed by a large community and hosted by the Cloud Native Computing Foundation. When organizations increase their use of containers some of the challenges they being to run into include: Automated scaling up and down of containers, container management and deployment, distributing load between containers, etc. To address these issues, it generally becomes necessary to implement a container orchestration platform to reduce operational burden. Kubernetes can be run on-premises or on any one of the major cloud providers (AWS, Azure, GCP, IBM Cloud). Given that Kubernetes is already being used widely in production environments, securing these workloads should be a top priority. In this post, I will discuss a handful of common Kubernetes security basics and best practices to administer in order to avoid your clusters becoming compromised. Need a better solution for Kubernetes vulnerability scanning and image security? Anchore can help. Staying Up to Date As with any software component, updating to the latest version of the software will greatly reduce the risk of your system being compromised. When running unpatched software components with known vulnerabilities, hackers are typically well-aware, and ready to exploit these weaknesses. One of the more recently well-known vulnerabilities discovered in Kubernetes was CVE-2018-1002105. If you are running managed Kubernetes in a cloud provider, these managed service providers make it simple to upgrade to the latest version. In addition to running the latest version of Kubernetes, it is imperative to stay up to date on the software components that make up the applications you are running. Providing your teams with the necessary tools for SAST for proprietary source code and container image scanning at the CI or container registry layer will help ensure that you are not running vulnerable software in Kubernetes environments. Note: This includes the security and hardening of the underlying hosts. In a similar vein, make sure that Docker itself is also configured, secure, and best practices for Docker development are also being followed. Resource Quotas Take advantage of being able to define resource quotas for your Kubernetes resources. If resources are left unbounded, they have the potential to lead to total cluster unavailability and potentially draw on hardware resources as well. For more information on this, check out the Resource Quotas documentation. Role-based Access Control Kubernetes RBAC allows users to exercise fine-grained control over how users access the API resources running on your cluster. Cloud providers will likely have RBAC enabled by default, but it is a good practice to check to verify that your Kubernetes deployment has enabled this feature. Generally speaking, it is good practice to apply the principle of least privilege to make sure users and services only have the access needed to do their jobs. You can create RBAC permission that applies to your entire cluster, or to specific namespaces within your cluster. For more information of RBAC in Kubernetes, I recommend reading the Kubernetes documentation on Using RBAC Authorization. If you are using a cloud provider to manager Kubernetes I also recommend reading up on how each of these providers works with access and authentication as you may occasionally run into permission issues: AWS Managing Cluster Authentication Making Sense of Kubernetes RBAC and IAM Roles on GKE Access and identity options for Azure Kubernetes Service (AKS) Role API In the Kubernetes RBAC API, a role contains rules that represent a set of permissions. Below is an example Role in the default namespace that can be used to grant read access to pods: kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: namespace: default name: pod-reader rules: - apiGroups: [""] # "" indicates the core API group resources: ["pods"] verbs: ["get", "watch", "list"]t Principle of Least Privilege a Step Further Above I mentioned applying the principle of least privilege to RBAC in Kubernetes. However, this same principle can be applied to your software components as well. By restricting access so components can only access the information and resources they need to operate correctly, the blast radius of attack is greatly reduced should one occur. Enable Audit Logging Kubernetes auditing provides a security-relevant chronological set of records documenting the sequence of activities that have affected the system by individual users, administrators or other components of the system. The logs will help to answer the following questions: What happened? When did it happen? Who initiated it? On what did it happen? Where was it observed? From where was it initiated? To where was it going? Additionally, shipping these logs off the server and connecting to Splunk, Elasticsearch, Kafka, etc. to generate dashboards and alerts for suspicious activity will help with monitoring. Create and Use Namespaces Namespaces are essentially virtual clusters inside of your Kubernetes cluster. You can have multiple namespaces inside a single Kubernetes cluster, and they are all logically isolated from each other. Namespaces help with team organization, security, and performance. Kubernetes namespaces greatly help with organization as different development teams may have different environments and systems they will be working with. The creation of separate namespaces for teams, projects, and environments, will reduce the risk of a team accidentally overwriting or disrupting a service without realizing it. On the security side, imagine a scenario where a development team would like to maintain a space in the cluster with certain, more relaxed permissions, where they can build and run their application. The operations team would also like to maintain a space on the cluster where they can enforce strict procedures on who can or cannot manipulate the set of Pods, Services, and Deployments. By creating two namespaces, one for development, and one for production, these sets of permissions can be abstracted from each other while still allowing both teams to take advantage of the existing Kubernetes cluster. Note: In many cases, the creation and use of namespaces in Kubernetes can actually increase performance as the Kubernetes API will have a smaller set of objects to work with. Create and Define Cluster Network Policies In Kubernetes, a network policy is a specification of how groups of pods are allowed to communicate with each other and other network endpoints. Network Policies allow users to limit connections between Pods, this reduces the compromise radius. An example of a basic network policy would be: Block traffic from other namespaces by default. If you are further interested in network security for Kubernetes, I recommend taking a look at Calico which is an open-source networking and network security solutions for containers, virtual machines, and native host-based workloads. A Change in Security Docker and Kubernetes have changed the way organizations need to implement best practices, policies, and security controls. With the increased adoption of microservices and containers, applications and their environments have become increasingly dynamic. Container technologies allow for rapid development and deployment of applications, and traditional security models are not sufficiently scalable to meet the required security controls for highly-scalable automated solutions like Kubernetes. Security is every team member's responsibility as Development, Platform, Network, QA, and Security teams are now required to collaboratively define the practices they would like in place in order to work together in an agile DevSecOps environment. ### Introduction to Amazon EKS In June of 2018, Amazon announced the general availability of their Elastic Container Service for Kubernetes. Given that at Anchore we deliver our products as Docker container images, it came as no surprise to us that our users and customers would begin deploying our software on EKS. Since Kubernetes, Kubernetes on AWS, and Anchore on EKS adoption have all increased, I thought it best to give EKS a shot. Getting Started For the scope of learning purposes, I thought I'd test out creating an EKS cluster, and launching a simple application. If you aren't completely familiar with Kubernetes I highly recommend checking out the tutorials section of the website just so some of the concepts and verbiage I use make a little more sense. I also recommend reading about kubectl which is the command line interface for running actions against Kubernetes clusters. In addition to the above reading, I also recommend the following: Install kubectl Install aws-iam-authenticator for Amazon EKS Download and Install the Latest AWS CLI Creating a Cluster There are a couple of ways to create an EKS cluster, with the console or with the AWS CLI. Create Cluster Using AWS Console To begin, navigate here and select create cluster. There are several pieces of information you'll need to provide AWS for it to create your cluster successfully. Cluster name (should be a unique name for your cluster) Role name VPC and Subnets Security groups Role name Here I will need to select the IAM role that will allow Amazon EKS and the Kubernetes control plane to manage AWS resources on my behalf. If you have not already, you should create an EKS service role in the IAM console. VPC and subnets Select a VPC and choose the subnets in the selected VPC where the worker nodes will run. If you have not created a VPC, you will need to create one in the VPC console and create subnets as well. AWS has a great tutorial on VPC and Subnet creation here. Note: Subnets specified must be in at least two different availability zones. Security groups Here I choose security groups to apply to network interfaces that are created in my subnets to allow the EKS control plane to communicate with worker nodes. Once all the necessary requirements have been fulfilled, I can create the cluster. Create cluster using AWS CLI I can also create a cluster via the AWS CLI by running the following: aws eks --region region create-cluster --name devel --role-arn arn:aws:iam::111122223333:role/eks-service-role-AWSServiceRoleForAmazonEKS-EXAMPLEBKZRQR --resources-vpc-config subnetIds=subnet-a9189fe2,subnet-50432629,securityGroupIds=sg-f5c54184 I would simply update --role-arn, subnetIds, and securityGroupIds into the above command. Once my cluster has been created the console looks like the following: Next I can use the AWS CLI update-kubeconfig command to create or update my kubeconfig for my cluster. aws eks --region us-east-2 update-kubeconfig --name anchore-demo Then I test the configuration: kubectl get svc Which outputs the following: NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 172.20.0.1 443/TCP 7m Launch Worker Nodes I created and launched worker nodes via the AWS CloudFormation console. It is important to note that Amazon EKS worker nodes are just standard Amazon EC2 instances. To create the stack, I simply selected create stack and added this Amazon S3 template URL, then I just filled out the parameters on the following screens. Next, I need to enable the worker nodes to join the cluster. I will do so by downloading and editing the AWS authenticator configuration map. apiVersion: v1 kind: ConfigMap metadata: name: aws-auth namespace: kube-system data: mapRoles: | - rolearn: username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes Note - The ARN of instance role is the NodeInstanceRole value you can see in the output of the creation of your CloudFormation stack. Next, apply the configuration: kubectl apply -f aws-auth-cm.yaml and view the nodes: kubectl get nodes NAME STATUS ROLES AGE VERSION ip-10-0-1-112.us-east-2.compute.internal Ready 3m v1.11.5 ip-10-0-1-36.us-east-2.compute.internal Ready 3m v1.11.5 ip-10-0-3-21.us-east-2.compute.internal Ready 3m v1.11.5 I can also view them in the EC2 console: Working with Services In Kubernetes, a LoadBalancer service is a service that points to external load balancers that are not in your Kubernetes clusters. In the case of AWS, and this blog, an external load balancer (ELB) will be created automatically when I create a LoadBalancer service. In order to do this, I must first define my service like so: # my-loadbalancer-service.yaml apiVersion: v1 kind: Service metadata: name: mylbservice spec: type: LoadBalancer selector: app: nginx ports: - protocol: TCP port: 80 targetPort: 80 Then I simply create the service. kubectl create -f my-loadbalancer-service.yaml To verify, I can describe my service. kubectl describe service mylbservicet Which outputs the following: Name: mylbservice Namespace: default Labels: Annotations: Selector: app=nginx Type: LoadBalancer IP: 172.20.16.171 LoadBalancer Ingress: a0564b91c4b7711e99cfb0a558a37aa8-1932902294.us-east-2.elb.amazonaws.com Port: 80/TCP TargetPort: 80/TCP NodePort: 32005/TCP Endpoints: 10.0.1.100:80,10.0.1.199:80,10.0.3.19:80 Session Affinity: None External Traffic Policy: Cluster Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal EnsuringLoadBalancer 10m service-controller Ensuring load balancer Normal EnsuredLoadBalancer 10m service-controller Ensured load balancer I can see the created load balancer by navigating to the EC2 console and selecting Load Balancers Or better yet, hit the LoadBalancer Ingress: Conclusion Now I just quickly walked through a simple application deployment on EKS. As you've probably gathered, the most challenging part is all the setup. When you are ready to start deploying more complex containerized applications on EKS you now have all the steps needed to get a cluster set up quickly. At Anchore, I'm always excited to work with our users and customers leveraging Amazon EKS to run Anchore. To find out more about how Anchore can be deployed, I highly recommend checking out our helm chart and reading more about Helm on EKS. There is certainly a learning curve to Amazon EKS that requires a bit of knowledge on several different Amazon services in order to manage Kubernetes clusters effectively. By far the longest piece of this was getting the cluster set up. Any AWS-heavy users should be thrilled about the ability to make running containerized workloads in Kubernetes easy and cost-effective on the most popular cloud provider. With AWS still reigning as the top public cloud provider, it is only fitting Amazon created a service to adhere to the tremendous amount of container and Kubernetes adoption over the past two years. ### Operational Awareness and Performance Tuning For Anchore Part 2 If you haven't read Part 1 please do so before reading this article as we rely heavily on concepts and vocabulary established in that article. In this article, we'll dive more deeply into matching metrics gathered in our first part with opportunities to tune the performance of a given Anchore deployment. Just to refresh, the steps for image analysis and evaluation in Anchore Engine is as follows: 1) The Image is downloaded. 2) The Image is unpacked. 3) The Image is analyzed locally. 4) The result of the analysis is uploaded to core services. 5) The analysis data that was uploaded to core services is then evaluated during a vulnerability scan or policy evaluation. Steps 1-3 are the most intensive operational costs for Anchore. Package, file and image analysis is both CPU and Disk intensive as operations. Making sure we're on a host that has good disk throughput and high single-thread CPU performance will help greatly here. Overall deployment performance depends on a few things: how the services interact and can scale together, how performant the database service is in response to the rest of the services, and how each service is provisioned with their own resources. How To Improve Step 1: Enable Layer Caching It is very likely that many of your images share common layers, especially if a standard base image is being used to build services. Performance can be improved by using caching on each of those layers contained in your image manifest. Anchore has a setting that enables a layer-specific caching for analyzers in order to reduce operational cost over time. In your Prometheus analysis, look at anchore_analysis_time_seconds for insight into when layer caching would be beneficial. To enable the cache you can define a temp directory the config.yaml for each analyzer, shown below. We should make sure that whatever you define should have the same throughput considerations as scaling the overall container throughput: Make sure you have fast SSD or local disk to each analyzer, as the cache layer is not shared between nodes, and is ephemeral. If we have set the following mount for a tmp_dir: tmp_dir: '/scratch' Then in order to utilize /scratch within the container make sure config.yaml is updated to use /scratch as the temporary directory for image analysis. We suggest the temporary directory should be sized to at least 3 times the uncompressed image size to be analyzed. To enable the layer caching, let's enable the "layer_cache_enable" parameter and the "layer_cache_max_gigabytes" parameter as follows: analyzer: enabled: True require_auth: True cycle_timer_seconds: 1 max_threads: 1 analyzer_driver: 'nodocker' endpoint_hostname: '${ANCHORE_HOST_ID}' listen: '0.0.0.0' port: 8084 layer_cache_enable: True layer_cache_max_gigabytes: 4 In this example, the cache is set to 4 gigabytes. The temporary volume should be sized to at least 3 times the uncompressed image size + 4 gigabytes. The minimum size for the cache is 1 gigabyte and the cache uses a least recently used (LRU) policy. The cache files will be stored in the anchore_layercache directory of the /tmp_dir volume. How To Improve Steps 2-3: Improve Service I/O Throughput This is pretty straight forward: better throughput performance for CPU and disk will improve the most I/O and CPU intensive tasks of Anchore's analysis process. High single-thread CPU performance and fast disk read/write speeds for each Anchore analyzer service will speed up the steps where we pull, extract and do file analysis of any given container image. On premise, this may mean a beefier CPU spec and SSDs in your bare metal. In the cloud, you may be choosing to not run EBS to back your analyzer tmp directories and selecting for higher compute instances. How To Improve Step 4: Scaling Anchore Engine Components This tip is to address a very wide scope of performance, so there's a wide scope of metrics to be watching, but in general scaling analyzer services and core services according to a consistent ratio is one way to ensure throughput overall can be maintained. In general, we suggest 1 core service for every 4 analyzers. Keeping this scale means that we can ensure throughput for core services grows with the number of analyzers. How To Improve Step 5: Tune Max Connection Settings For Postgres One of the most common questions about deploying Anchore in production is how to architect the Postgres instance used by Anchore Engine. While Anchore has installation methods that include a Postgres service container in our docker-compose YAML and helm chart, we do expect that production deployments will not use that Postgres container and instead will utilize a Postgres service, either on-premises or in the cloud (such as RDS, etc.) Using a cloud service like Using something like RDS is not only an easy way to control allocated resources to your DB instance but RDS specifically also automatically configures Postgres with pretty good settings for the chosen instance type out of the box. For a more in-depth guide on tuning your Postgres deployments, you'll want to consult with Postgres documentation or use a tool like pg_tune. For this guide's purpose, we can check the performance stats in the DB with "select * from pg_stat_activity;" executed in your Postgres container. When you are looking at Postgres performance stats from your pg_stat_activity table, you want to pay attention to connection statistics. Every Anchore service touches the database, and every service has a config YAML file where you can set client pool connections with a default set to 30. The setting on the anchore services side control how many client connections each service can make concurrently. In the Postgres configuration, max connections control how many clients total can connect at once. Anchore uses sql alchemy, which employs a connection pooling technique, so each service may allocate connection pool size number of client connections. For example, in pg_stat_database we can see numbackends. We can from that number and the max_connections setting in pg_settings infer how close we are to forcing connection waits. This is because the percentage of max connections in use is numbackends as a percentage of max_connections. In a nutshell, with Anchore database client connections setting at 300, and deployment with 100 Anchore services, that could lead to 30000 client connections to the database. Without adjusting max_connections, this could lead to a serious bottleneck. We typically recommend leaving the Anchore client max connection setting at its defaults and bumping up the max connections in Postgres configuration appropriately. With the client default at 30, the corresponding max connections setting for our deployment of 100 Anchore services should be at least 3000 (30 * 100). As long as your database has enough resources to handle incoming connections then the Anchore service pool won't bottleneck. I want to caution that this guide isn't the comprehensive list of things that can be tuned to help performance. It is intended to address a wide audience and is based on the most common performance issues we've seen in the field. ### Going Deeper with Anchore Policies, Using Whitelists At Anchore we are consistently working with our users and customers to help them gain better insight into the contents of their container images, and more importantly, helping them create rules to enforce security, compliance, and best practices. The enforcement element is achieved through Anchore policy evaluations, and more specifically, the rules are defined within the policies component of a policy bundle. Anchore policy bundles are the unit of policy definition and evaluation. Anchore users may have multiple policy bundles, but for policy evaluation, the user must specify a bundle to be evaluated or default to the bundle currently marked as active. One of the components of a policy bundle is whitelists. A whitelist is a set of exclusion rules for trigger matches found during policy evaluation. A whitelist defines a specific gate and trigger_id that should have its action recommendation statically set to go. When a policy rule result is whitelisted, it is still present in the output of the policy evaluation, but its action is set to go and it is indicated that there was a whitelist match. The overarching idea is to give developers, operations, and security team members an effective mechanism for ignoring vulnerability matches that are known to be false positives or ignoring vulnerabilities on specific packages (if they have been patched), or any other agreed-upon reason for creating a whitelist rule. Whitelists in Anchore Enterprise Within the Anchore Enterprise UI, navigating to the Whitelists tab will show the lists of whitelists that are currently present in the current policy bundle. Selecting the edit button on the far right under the action column will bring up the whitelist editor where users have the ability to create new whitelist entries or modify existing ones. The example whitelist above is represented as JSON below: { "comment": "Default global whitelist", "id": "37fd763e-1765-11e8-add4-3b16c029ac5c", "items": , "name": "Global Whitelist", "version": "1_0" } Components of a Whitelist in Anchore   Gate: The gate to whitelist matches from (ensures trigger_ids are not matched in the wrong context). Trigger Id: The specific trigger result to match and whitelist. This id is gate/trigger specific as each trigger may have its own trigger_id format. Most commonly, the CVE trigger ids produced by the vulnerability package gate-trigger. The trigger_id may include wildcards for partial matches as shown with the second item. Id: An identifier for the whitelist rule. It only needs to be unique within the whitelist object itself. It is important to note that if a whitelist item matches a policy trigger output, the action for that particular output is set to go and the policy evaluation result will inform the user that the trigger output was matched for a whitelist item. Uploading a Whitelist in Anchore Enterprise Through the UI, Anchore users have the option to upload a whitelist by selecting the Upload Whitelist button which brings up the following: Viewing Whitelisted Entries Anchore users can view the whitelisted entries in the Policy Evaluation table as shown below: Additionally, users can optionally Add / Remove a particular whitelist item as shown below: Conclusion When working with the security risks associated with both the operating system and non-operating system packages, ignoring issues is sometimes a necessary action. At Anchore, the goal is to provide teams a solid means of managing vulnerabilities and packages that may need to be suppressed. Due to the fact that working with whitelists and policies carries a certain level of risk, Anchore Enterprise provides role-based access control to make policy editing only available to users who have been assigned the appropriate level of permissions. In the example below, the current user only has 'read-only' access and cannot make any changes to the whitelist. When working with whitelisted items, it is important to remember that this does not mean there are no longer security issues, only that these particular items now have a go output associated with them. Remember to use carefully and in moderation. Lastly, as with any CVE remediation and policy rule creation, consult across your development, security, and operations teams to collectively come up with acceptable actions that best suit your organization's security and compliance requirements. Further information on Anchore Enterprise can be found on our website. ### Operational Awareness & Performance Tuning For Anchore This series will focus on topics taken directly from customer interactions, community discussion and practical, real-world use of Anchore Engine deployments. The goal will hopefully be to provide lessons learned from real-world deployments of Anchore. Part 1: Concepts and Metrics In the first set of posts in this series, I will walk through how to evaluate and tune your Anchore deployment for better image analysis performance. To do so, we'll discuss the actions Anchore Engine takes to pull, analyze and evaluate images and how that is affected by configuration and deployment architecture. We'll also point out how you can get metrics on each of these functions to determine what you can do to improve the performance of your deployment. Firstly, I want to take a moment and thank the Anchore Community Slack and also the Anchore Engineering team for helping me delve very deeply into this. They've been fantastic, and if you haven't done so yet make sure you join our slack community to keep up to date with the project and product, as well as exchange ideas with the rest of the community. One thing to understand about Anchore's approach is that the acts of image analysis (downloading and analyzing the image contents) and of image scanning (for vulnerabilities) are separate steps. Image analysis only needs to happen once for any given image digest. The image digest is a unique ID for a given image content set, and Anchore is capable of watching an image tag in an upstream repository and detect when a new version of the content of that image (the digest) has been associated with a tag. Vulnerability scans and policy evaluations are performed against any image (digest) that has been analyzed. When updates happen to either a vulnerability feed or a policy bundle, Anchore can re-scan an image to produce the latest vulnerability report or policy evaluation report for any given digest without the need to re-analyze the image (digest). Put simply, our discovery of the contents of an image digest is separate from our evaluation of the vulnerabilities or policy compliance of the same said image digest. Image analysis (ie: the downloading, unpacking and discovery of contents of an image digest) is a far more expensive operation from an I/O perspective than image scanning (ie: the scanning said image digest analysis data for vulnerabilities or policy evaluation.) Let's review what actually happens to a container image (digest) as Anchore Engine consumes and analyzes it: 1) The Image is downloaded. 2) The Image is unpacked. 3) The Image is analyzed locally. 4) The result of the analysis is uploaded to core services. 5) The analysis data that was uploaded to core services is then evaluated during a vulnerability scan or policy evaluation. The first four steps are what we call image analysis. That last step is image evaluation. Each of those actions has specific performance implications in your deployment. Most importantly is to know what parts of your deployment require changes to improve performance and to do that we need information. Let's start by enabling metrics on our Anchore Engine deployment. To enable the metrics option in Anchore Engine, look to set the following in your Anchore Engine configuration file config.yaml: metrics: enabled: True Once that is enabled and the services brought up a /metrics route will be exposed on all individual Anchore services that are listening on a network interface and require authentication. You can then configure Prometheus to scrape data from each Anchore service. These are those services: 1) apiext: Running on port 8228 this is the External API service. 2) catalog: Running on port 8082 this is the internal catalog service. 3) simplequeue: Running on port 8083 this is the internal queuing service 4) analyzer: Running on port 8084 this is the service that analyzes the containers pulled into Anchore. 5) policy_engine: Running on port 8087 this is the internal service that provides the policy engine for evaluation and action on the analyzed containers. Only the external API service is typically enabled for external access. All other services are used only by the Anchore Engine. Prometheus should have network access to each service to be scraped and the Prometheus service should be configured with credentials to access the engine. Here's an example: global: scrape_interval: 15s scrape_timeout: 10s evaluation_interval: 15s alerting: alertmanagers: - static_configs: - targets: [] scheme: http timeout: 10s scrape_configs: - job_name: anchore-api scrape_interval: 15s scrape_timeout: 10s metrics_path: /metrics scheme: http static_configs: - targets: - anchore-engine:8228 basic_auth: username: admin password: foobar - job_name: anchore-catalog scrape_interval: 15s scrape_timeout: 10s metrics_path: /metrics scheme: http static_configs: - targets: - anchore-engine:8082 basic_auth: username: admin password: foobar - job_name: anchore-simplequeue scrape_interval: 15s scrape_timeout: 10s metrics_path: /metrics scheme: http static_configs: - targets: - anchore-engine:8083 basic_auth: username: admin password: foobar - job_name: anchore-analyzer scrape_interval: 15s scrape_timeout: 10s metrics_path: /metrics scheme: http static_configs: - targets: - anchore-engine:8084 basic_auth: username: admin password: foobar - job_name: anchore-policy-engine scrape_interval: 15s scrape_timeout: 10s metrics_path: /metrics scheme: http static_configs: - targets: - anchore-engine:8087 basic_auth: username: admin password: foobar This config file would go into the anchore-prometheus.yaml file created as part of the docker-compose or helm deployment. The last bit of information you'll want is metrics on the performance of your postgres service. For Anchore specifically, we want to know mostly about connection statistics and I/O timing. This can be discovered with the execution of something like "select * from pg_stat_activity;" within your DB container. If you need help exploring your postgres instance inside of Docker, here's a good post to use as reference: https://markheath.net/post/exploring-postgresql-with-docker Knowing how long it takes your Anchore deployment to scan your images, how the other services are receiving and sending data, and having metrics on the postgres database performance is key to knowing where you can help tune your system. If you would like to see the metrics from Prometheus you need only hit the API endpoint for the service you want metrics on using an authenticated call. For example, using a docker-compose exec command, it would look like this: docker-compose exec anchore-engine curl http://admin:foobar@localhost:8087/metrics That's a call to get metrics on the policy engine. Refer to the config YAML above to hit the port needed for the service you would require metrics from. In Part 2 of this series we will go in-depth to break down the functional steps described above to match them with the gathered metrics, and then evaluate how to tune our configuration and deployment accordingly. ### Inline scanning with Anchore Engine Note: Anchore Engine's feed service will be deprecated in April 2022 (per this announcement) in favor of improved open source tools, Syft and Grype. For full container vulnerability scanning and policy & compliance solutions that address the increasing security demands of the software supply chain, check out Anchore Enterprise. With Anchore Engine, users can scan container images to generate reports against several aspects of the container image - vulnerability scans, content reports (files, OS packages, language packages, etc), fully customized policy evaluations (Dockerfile checks, OSS license checks, software package checks, security checks, and many more). With these capabilities, users have integrated an anchore-engine image scan into CI/CD build processes for both reporting and/or control decision purposes, as anchore policy evaluations include a 'pass/fail' result alongside a full report upon policy execution. Up until now, the general setup required to achieve such integration has included the requirement to stand up an anchore-engine service, with its API exposed to your CI/CD build process and make thin anchore API client calls from the build process to the centralized anchore-engine deployment. Generally, the flow starts with an API call to 'add' an image to anchore-engine via an API call to the engine, at which point the engine will pull the referenced image from a docker v2 registry, and then perform report generation queries and/or policy evaluation calls. This method is still fully supported, and in many cases is a good architecture for integrating anchore into your CI/CD platform. However, there are other use cases where the same result is desired (image scans, policy evaluations, content reports, etc), but for a variety of reasons, it is impractical for the user to operate a centralized, managed and stable anchore-engine deployment that is available to CI/CD build processes. To accommodate these cases, we are introducing a new way to interact with anchore to get image scans, evaluations, and content reports without requiring a central anchore-engine deployment to be available. We call this new approach 'inline scan', to indicate that a single, one-time scan can be performed 'inline' against a local container image at any time, without the need for any persistent data or service state between scans. Using this approach (which ultimately uses exactly the same analysis/vulnerability/policy evaluation and reporting functions of anchore-engine), users can achieve an integration with anchore that moves the analysis/scanning work to a local container process that can be run during the container image build pipeline, after an image has been built but before it is pushed to any registry. With this new functionality, we hope to provide another approach for users to get deep analysis, scanning and policy evaluation capabilities of anchore in situations where operating a central anchore-engine service is impractical. Using the inline_scan Script To make using our inline-scan container as easy as possible, we have provided a simple wrapper script called inline_scan. The only requirement to run the inline_scan script is the ability to execute Docker commands & bash. We host a versioned copy of this script that can be downloaded directly with curl and executed in a bash pipeline, providing you image inspection, reporting and policy enforcement with one command. To run the script on your workstation, use the following command syntax. curl -s https://ci-tools.anchore.io/inline_scan-v0.6.0 | bash -s -- [options] IMAGE_NAME(s) Inline_scan Options -b [optional] Path to local Anchore policy bundle. -d [optional] Path to local Dockerfile. -v [optional] Path to directory to be mounted as docker volume. All image archives in directory will be scanned. -f [optional] Exit script upon failed Anchore policy evaluation. -p [optional] Pull remote docker images. -r [optional] Generate analysis reports in your current working directory. -t [optional] Specify timeout for image scanning in seconds (defaults to 300s). Examples Pull multiple images from DockerHub, scan them all and generate individual reports in ./anchore-reports. curl -s https://ci-tools.anchore.io/inline_scan-v0.6.0 | bash -s -- -p -r alpine:latest ubuntu:latest centos:latest Perform a local docker build, then pass the Dockerfile to anchore inline scan. Use a custom policy bundle to ensure Dockerfile compliance, failing the script if anchore policy evaluation does not pass. docker build -t example-image:latest -f Dockerfile . curl -s https://ci-tools.anchore.io/inline_scan-v0.6.0 | bash -s -- -f -d Dockerfile -b .anchore-policy.json example-image:latest Save multiple docker image archives to a directory, then mount the entire directory for analysis using a timeout of 500s. cd example1/ docker build -t example1:latest . cd ../example2 docker build -t example2:latest . cd .. mkdir images/ docker save example1:latest -o images/example1+latest.tar docker save example2:latest -o images/example2+latest.tar curl -s https://ci-tools.anchore.io/inline_scan-v0.6.0 | bash -s -- -v ./images -t 500 Using Anchore Inline Scan in Your Build Pipeline This same functionality can be utilized on any CI/CD platform that allows the execution of Docker commands. The remainder of this post will be going over implementations of the anchore inline scan on a variety of popular CI/CD platforms. All of the following examples can be found in this repository. CircleCI Implementation CircleCI version 2.0+ allows native docker command execution with the setup_remote_docker job step. By using this functionality combined with an official docker:stable image, we can build, scan, and push our images within the same job. We will also create reports and save them as artifacts within CircleCI. These reports are all created in JSON format, allowing easy aggregation from CircleCI into your preferred reporting tool. This workflow requires the DOCKER_USER & DOCKER_PASS environment variables to be set in a context called dockerhubin your CircleCI account settings at settings -> context -> create Config.yml version: 2.1 jobs: build_scan_image: docker: - image: docker:stable environment: IMAGE_NAME: btodhunter/anchore-ci-demo IMAGE_TAG: circleci steps: - checkout - setup_remote_docker - run: name: Build image command: docker build -t "${IMAGE_NAME}:ci" . - run: name: Scan image command: | apk add curl bash curl -s https://ci-tools.anchore.io/inline_scan-v0.6.0 | bash -s -- -r "${IMAGE_NAME}:ci" - run: name: Push to DockerHub command: | echo "$DOCKER_PASS" | docker login -u "$DOCKER_USER" --password-stdin docker tag "${IMAGE_NAME}:ci" "${IMAGE_NAME}:${IMAGE_TAG}" docker push "${IMAGE_NAME}:${IMAGE_TAG}" - store_artifacts: path: anchore-reports/ workflows: scan_image: jobs: - build_scan_image: context: dockerhub GitLab Implementation GitLab allows docker command execution through a docker:dind service container. This job pushes the image to the GitLab registry, using built-in environment variables for specifying the image name and registry login credentials. To prevent premature timeouts, the timeout has been increased to 500s with the -t option. Reports are generated using the -r option, which are then passed as artifacts to be stored in GitLab. Even if you're not using an aggregation tool for artifacts, the json format allows reports to be parsed and displayed within GitLab pipeline using simple command line tools like jq. .gitlab-ci.yml variables: IMAGE_NAME: ${CI_REGISTRY_IMAGE}/build:${CI_COMMIT_REF_SLUG}-${CI_COMMIT_SHA} stages: - build container_build: stage: build image: docker:stable services: - docker:stable-dind variables: DOCKER_DRIVER: overlay2 script: - echo "$CI_JOB_TOKEN" | docker login -u gitlab-ci-token --password-stdin "${CI_REGISTRY}" - docker build -t "$IMAGE_NAME" . - apk add bash curl - curl -s https://ci-tools.anchore.io/inline_scan-v0.6.0 | bash -s -- -r -t 500 "$IMAGE_NAME" - docker push "$IMAGE_NAME" - | echo "Parsing anchore reports." for f in anchore-reports/*; do if [[ "$f" =~ "content-os" ]]; then printf "n%sn" "The following OS packages are installed on ${IMAGE_NAME}:" jq '[.content | sort_by(.package) | .[] | {package: .package, version: .version}]' $f || true fi if [[ "$f" =~ "vuln" ]]; then printf "n%sn" "The following vulnerabilities were found on ${IMAGE_NAME}:" jq '[.vulnerabilities | group_by(.package) | .[] | {package: .[0].package, vuln: [.[].vuln]}]' $f || true fi done artifacts: name: ${CI_JOB_NAME}-${CI_COMMIT_REF_NAME} paths: - anchore-reports/* CodeShip Implementation Docker command execution is enabled by default in CodeShip, which allows the inline_scan script to run on the docker:stable image without any additional configuration. By specifying the -f option on the inline_scan script, this job ensures that an image that fails it's anchore policy evaluation will not be pushed to the registry. To ensure adherence to the organization's security compliance policy, a custom policy bundle can be utilized for this scan by passing the -b  option to the inline_scan script. This job requires creating an encrypted environment variable file for loading the DOCKER_USER & DOCKER_PASS variables into your job. See - Encrypting CodeShip Environment Variables. codeship-services.yml anchore: add_docker: true image: docker:stable-git environment: IMAGE_NAME: btodhunter/anchore-ci-demo IMAGE_TAG: codeship encrypted_env_file: env.encrypted codeship-steps.yml - name: build-scan service: anchore command: sh -c 'apk add bash curl && mkdir -p /build && cd /build && git clone https://github.com/Btodhunter/ci-demos.git . && docker build -t "${IMAGE_NAME}:ci" . && curl -s https://ci-tools.anchore.io/inline_scan-v0.6.0 | bash -s -- -f -b .anchore_policy.json "${IMAGE_NAME}:ci" && echo "$DOCKER_PASS" | docker login -u "$DOCKER_USER" --password-stdin && docker tag "${IMAGE_NAME}:ci" "${IMAGE_NAME}:${IMAGE_TAG}" && docker push "${IMAGE_NAME}:${IMAGE_TAG}"' Jenkins Pipeline Implementation Jenkins configured with the Docker, BlueOcean, and Pipeline plugins support docker command execution using the shdirective. By using the -d  option with the inline_scan script, you can pass your Dockerfile to anchore-engine for policy evaluation. With the -b  option, a custom policy bundle can be passed to the inline scan to ensure your Dockerfile conforms to best practices. To allow pushing to a private registry, the dockerhub-creds credentials must be created in the Jenkins server settings at - Jenkins -> Credentials -> System -> Global credentials -> Add Credentials This example was tested against the Jenkins installation detailed here, using the declarative pipeline syntax - Jenkins Pipeline Docs Jenkinsfile pipeline{ agent { docker { image 'docker:stable' } } environment { IMAGE_NAME = 'btodhunter/anchore-ci-demo' IMAGE_TAG = 'jenkins' } stages { stage('Build Image') { steps { sh 'docker build -t ${IMAGE_NAME}:ci .' } } stage('Scan') { steps { sh 'apk add bash curl' sh 'curl -s https://ci-tools.anchore.io/inline_scan-v0.6.0 | bash -s -- -d Dockerfile -b .anchore_policy.json ${IMAGE_NAME}:ci' } } stage('Push Image') { steps { withDockerRegistry([credentialsId: "dockerhub-creds", url: ""]){ sh 'docker tag ${IMAGE_NAME}:ci ${IMAGE_NAME}:${IMAGE_TAG}' sh 'docker push ${IMAGE_NAME}:${IMAGE_TAG}' } } } } } TravisCI Implementation TravisCI allows docker command execution by default, which makes integrating Anchore Engine as simple as adding the inline_scan script to your existing image build pipeline. This analysis should be performed before pushing the image to your registry of choice. The DOCKER_USER & DOCKER_PASS environment variables must be setup in the TravisCI console at repository -> settings -> environment variables .travis.yml language: node_js services: - docker env: - IMAGE_NAME="btodhunter/anchore-ci-demo" IMAGE_TAG="travisci" script: - docker build -t "${IMAGE_NAME}:ci" . - curl -s https://ci-tools.anchore.io/inline_scan-v0.6.0 | bash -s -- "${IMAGE_NAME}:ci" - echo "$DOCKER_PASS" | docker login -u "$DOCKER_USER" --password-stdin - docker tag "${IMAGE_NAME}:ci" "${IMAGE_NAME}:${IMAGE_TAG}" - docker push "${IMAGE_NAME}:${IMAGE_TAG}" AWS CodeBuild Implementation AWS CodeBuild supports docker command execution by default. The Anchore inline_scan script can be inserted right into your pipeline before the image is pushed to its registry. The DOCKER_USER, DOCKER_PASS, IMAGE_NAME, & IMAGE_TAG environment variables must be set in the CodeBuild console at Build Projects -> -> Edit Environment -> Additional Config -> Environment Variables buildspec.yml version: 0.2 phases: build: commands: - docker build -t ${IMAGE_NAME}:${IMAGE_TAG} . post_build: commands: - curl -s https://ci-tools.anchore.io/inline_scan-v0.6.0 | bash -s -- ${IMAGE_NAME}:${IMAGE_TAG} - echo $DOCKER_PASS | docker login -u $DOCKER_USER --password-stdin - docker push ${IMAGE_NAME}:${IMAGE_TAG} Summary As you can see from the above examples, the new inline scan makes it easier than ever to implement Anchore Engine image analysis in your Docker build pipeline! You can scan local images before pushing them into a registry, allowing you to inject scans directly into your current workflows. The inline_scan script makes it simple to ensure your Dockerfile meets best practices, perform fine-grained custom policy evaluations, and even pull an image directly from a remote registry for scanning. Anchore inline scan is a zero-friction solution for ensuring that only secure images make it through your build pipeline and get into production. Add it to your pipeline today! Anchore Engine is an open source project, all issues and contribution details can be found on Github. We look forward to receiving feedback and contributions from our users! Links Github - Anchore Engine Github - Inline Scan Github - CI Demos This post has been updated to reflect the newest version of the Anchore Inline Scanner. ### Running Anchore Engine on Openshift In this post, I will run through an installation of Anchore on OpenShift. I'll also discuss in brief how to use Anchore to scan images. Getting Started My environment and tooling consist of the following: CentOS 7 on AWS RedHat OKD version 3.11 in a single node Helm PostgreSQL on RDS (For Anchore external DB) For the purposes of this post, I will assume a successful installation of OKD and Helm. For more information on installing Helm on OpenShift see here. To verify that Helm has been installed and configured successfully, running the command below should yield the following output: [centos@ip-172-31-7-54 ~]$ helm version Client: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"} Server: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"} Using the Anchore Helm Chart I will be installing Anchore via Helm and the chart located here. For my installation, I've set up a PostgreSQl database in Amazon RDS that I will configure Anchore to use. Although there is a managed PostgreSQL service that can be installed with the chart, it is recommended to use an external DB for production installations. Configuring the External db In order to configure the external db, create a new file named anchore-values.yaml and add the following: ## anchore-values.yaml postgresql: # To use an external DB, uncomment & set 'enabled: false' # externalEndpoint, postgresUser, postgresPassword & postgresDatabase are required values for external postgres enabled: false postgresUser: db_username postgresPassword: db_password postgresDatabase: anchore_db # Specify an external (already existing) postgres deployment for use. # Set to the host and port. eg. mypostgres.myserver.io:5432 externalEndpoint: anchore-db-instance.<123456>.us-east-2.rds.amazonaws.com:5432 For more details on using the Helm chart please consult the GitHub repo. Installing Anchore Create a new project via oc new-project anchore-engine. Give Tiller access to the project you created. oc policy add-role-to-user edit "system:serviceaccount:${TILLER_NAMESPACE}:tiller" role "edit" added: "system:serviceaccount:tiller:tiller" Verify you are using the created project. [centos@ip-172-31-7-54 ~]$ oc login -u test -p test https://console.52.14.129.143:8443 Login successful. You have access to the following projects and can switch between them with 'oc project ': * anchore-engine default kube-public kube-service-catalog kube-system management-infra openshift openshift-console openshift-infra openshift-logging openshift-metrics-server openshift-monitoring openshift-node openshift-sdn openshift-template-service-broker openshift-web-console tiller Using project "anchore-engine". Run the following command to install Anchore: helm install --name -f anchore-values.yaml stable/anchore-engine An initial install will take several minutes to complete. Additionally, it will also take some time to perform its initial data feed sync. You can run oc get pods to see how things are doing. [centos@ip-172-31-7-54 ~]$ oc get pods NAME READY STATUS RESTARTS AGE anchore-engine-anchore-engine-analyzer-7d5fc7fb4c-phkt8 1/1 Running 0 1h anchore-engine-anchore-engine-api-55b785794-tk6qt 1/1 Running 0 1h anchore-engine-anchore-engine-catalog-65bbfdd7c7-7ldzj 1/1 Running 0 1h anchore-engine-anchore-engine-policy-8cb4787ff-sdw7v 1/1 Running 0 1h anchore-engine-anchore-engine-simplequeue-5f7b7f866b-2hn2n 1/1 Running 0 1h In addition, you can check on the installation via the OpenShift UI. Exposing the Anchore Engine Service Create a route in the OpenShift UI to expose the Anchore Engine service: The hostname of this route is what I will set our Anchore CLI URL environment variable to in the step below. Installing the Anchore CLI I can now install the Anchore CLI to interact with our running Anchore Engine service. There is also a CLI container. Configure your Anchore CLI environment variables to communicate with the anchore engine API service. Now I can check on the status of the Anchore services by running anchore-cli system status. [centos@ip-172-31-7-54 ~]$ anchore-cli system status Service apiext (anchore-engine-anchore-engine-api-55b785794-5qn79, http://anchore-engine-anchore-engine-api:8228): up Service simplequeue (anchore-engine-anchore-engine-simplequeue-5f7b7f866b-2hn2n, http://anchore-engine-anchore-engine-simplequeue:8083): up Service policy_engine (anchore-engine-anchore-engine-policy-8cb4787ff-p8tpf, http://anchore-engine-anchore-engine-policy:8087): up Service analyzer (anchore-engine-anchore-engine-analyzer-7d5fc7fb4c-2z85z, http://anchore-engine-anchore-engine-analyzer:8084): up Service catalog (anchore-engine-anchore-engine-catalog-65bbfdd7c7-7ldzj, http://anchore-engine-anchore-engine-catalog:8082): up You can also check on the stats of the vulnerability feeds sync by running the anchore-cli system feeds listcommand. [centos@ip-172-31-7-54 ~]$ anchore-cli system feeds list Feed Group LastSync RecordCount nvd nvddb:2002 2019-02-25T21:35:12.802608 6745 nvd nvddb:2003 2019-02-25T21:35:13.188204 1547 nvd nvddb:2004 2019-02-25T21:35:13.774093 2702 nvd nvddb:2005 2019-02-25T21:35:14.281344 4749 nvd nvddb:2006 2019-02-25T21:39:01.936476 7127 nvd nvddb:2007 2019-02-25T21:39:02.432799 6556 nvd nvddb:2008 2019-02-25T22:29:19.704624 7147 nvd nvddb:2009 2019-02-25T22:29:20.292788 4964 nvd nvddb:2010 2019-02-25T22:29:20.720235 5073 nvd nvddb:2011 2019-02-25T21:30:43.003078 4621 nvd nvddb:2012 2019-02-25T21:35:11.663650 5549 nvd nvddb:2013 2019-02-25T21:39:01.289722 6160 nvd nvddb:2014 2019-02-25T21:42:11.148478 8493 nvd nvddb:2015 2019-02-25T21:44:55.773423 8023 nvd nvddb:2016 2019-02-25T21:48:13.150698 9872 nvd nvddb:2017 2019-02-25T22:03:35.550272 15162 nvd nvddb:2018 2019-02-25T22:26:12.131914 13541 nvd nvddb:2019 2019-02-25T22:29:19.116614 963 vulnerabilities alpine:3.3 2019-02-25T21:15:55.103331 457 vulnerabilities alpine:3.4 2019-02-25T21:15:55.428108 681 vulnerabilities alpine:3.5 2019-02-25T21:15:55.795007 875 vulnerabilities alpine:3.6 2019-02-25T21:15:56.135527 918 vulnerabilities alpine:3.7 2019-02-25T21:15:53.751574 919 vulnerabilities alpine:3.8 2019-02-25T21:15:54.071555 996 vulnerabilities amzn:2 2019-02-25T21:15:54.417658 135 vulnerabilities centos:5 2019-02-25T21:15:50.007481 1323 vulnerabilities centos:6 2019-02-25T21:15:50.358919 1317 vulnerabilities centos:7 2019-02-25T21:15:58.630997 754 vulnerabilities debian:10 2019-02-25T21:15:50.692485 19674 vulnerabilities debian:7 2019-02-25T21:15:51.141333 20455 vulnerabilities debian:8 2019-02-25T21:15:51.509929 21179 vulnerabilities debian:9 2019-02-25T21:15:51.872651 19899 vulnerabilities debian:unstable 2019-02-25T21:15:56.488092 20427 vulnerabilities ol:5 2019-02-25T21:15:56.879681 1228 vulnerabilities ol:6 2019-02-25T21:15:57.226619 1382 vulnerabilities ol:7 2019-02-25T21:15:57.570317 854 vulnerabilities ubuntu:12.04 2019-02-25T21:15:57.931096 14946 vulnerabilities ubuntu:12.10 2019-02-25T21:15:48.681891 5652 vulnerabilities ubuntu:13.04 2019-02-25T21:15:49.284442 4127 vulnerabilities ubuntu:14.04 2019-02-25T21:15:52.520471 17927 vulnerabilities ubuntu:14.10 2019-02-25T21:15:54.731972 4456 vulnerabilities ubuntu:15.04 2019-02-25T21:15:52.995122 5748 vulnerabilities ubuntu:15.10 2019-02-25T21:15:53.357807 6511 vulnerabilities ubuntu:16.04 2019-02-25T21:15:58.291030 14906 vulnerabilities ubuntu:16.10 2019-02-25T21:15:46.706940 8647 vulnerabilities ubuntu:17.04 2019-02-25T21:15:47.111422 9157 vulnerabilities ubuntu:17.10 2019-02-25T21:15:47.565082 7935 vulnerabilities ubuntu:18.04 2019-02-25T21:15:48.002361 9158 vulnerabilities ubuntu:18.10 2019-02-25T21:15:48.332466 7245 Once the feeds and synced, you can now begin to can vulnerability matches back on any analyzed images that contain vulnerability packages (both os and non-os). Analyzing an Image The following commands are useful when analyzing images: anchore-cli image add docker.io/library/nginx:stable (Adds an image for analysis) anchore-cli image wait docker.io/library/nging:stable (Waits for an image to complete analysis) anchore-cli image list (Lists all images) While these commands are fetching from Docker Hub, you can configure Anchore to scan images in private registries as well. For example, during my installation of OKD, a Docker registry was deployed automatically, as shown below. I can use command Docker commands to push and pull images to and from this registry, and configure Anchore to watch images in this registry for updates. Get a List of Vulnerabilities The following commands are useful when looking to obtain a list of vulnerabilities within an analyzed image. anchore-cli image vuln docker.io/library/nginx:stable os (Displays any os vulnerabilities) anchore-cli image vuln docker.io/library/nginx:stable non-os (Displays any non-os vulnerabilities) anchore-cli image vuln docker.io/library/nginx:stable all (Displays all vulnerabilities) Note: If there are no vulnerabilities returned and you have a healthy Anchore Engine service, the image may not be triggering any vulnerability matches. Conclusion I have now successfully installed Anchore Engine on OpenShift with Helm and analyzed my first image. Using the Helm chart definitely made the installation very smooth and the OpenShift UI makes pods and services easy to troubleshoot. What I recommend as a next step is to take a deeper look into Anchore policies, and how you can use them to govern images running through a CI tool to potentially stop vulnerable images from making their way to production environments. You can find out more about policies by checking out our public-facing documentation located here. ### Anchore Policies, Understanding the 'Dockerfile' Policy Gate Understanding how to work with policies is a central component of using Anchore container image inspection and enforcement tools effectively. Anchore policies are how users represent which checks to execute on particular images, and how the results of the policy evaluation should be interpreted. At Anchore, policy bundles are the unit of policy definition and evaluation. A user may have multiple bundles, but for policy evaluation, the user must specify a bundle to be evaluated, or default to the bundle currently marked as active. A policy bundle is a single JSON document, composed of policies, whitelists, mappings, whitelisted images, and blacklisted images.A policy is a named set of rules, represented as a JSON object within a policy bundle, each of which defines a specific check to perform and a resulting action to emit if the check returns a match. These checks are defined as Gates that contain Triggers. In this post, I will focus on the 'dockerfile' gate and its triggers. Why Is A Dockerfile Check Needed A Dockerfile is a text file that contains all commands, in order, to build a Docker image. In short, it is the blueprint for the container image environment. Since a container is a running instance of an image, it makes sense to incorporate effective mechanisms to check for best practices and potential misconfigurations with the blueprint as early as possible. Dockerfile Gate The Dockerfile gate allows uses to perform checks on the content of the Dockerfile or Docker history for an image and make policy actions based on the construction of the image, not just it's content. Anchore is either given a Dockerfile or infers one from the Docker image layer history. The actual_dockerfile_only Parameter The actual versus history impacts the semantics of the Dockerfile gate's triggers. To allow explicit control of the differences, most triggers in this gate include a parameter: actual_dockerfile_only that if set to true or false will ensure the trigger check is only done on the source of data specified. If actual_dockerfile_only = true, then the trigger will evaluate only if an actual Dockerfile is available for the image and will skip evaluation if not. If actual_dockerfile_only is false or omitted, then the trigger will run on the actual Dockerfile if available, or the history data if the Dockerfile was not provided. Triggers Instruction: This trigger evaluates instructions found in the Dockerfile. Example of policy looking for the presence of the ADD instruction: { "action": "WARN", "gate": "dockerfile", "id": "c35b7509-b0de-4b7a-9749-47380a2f98f2", "params": , "trigger": "instruction" } In the above example, if the actual Dockerfile contains the instruction ADD a WARN action will result. Generally speaking, using the instruction COPY versus ADD is considered better practice. Read more about it here. Effective User: This trigger processes all USER directives in the Dockerfile or history to determine which user will be user to run the container by default (assuming no user is set explicitly at runtime). The detected value is then subject to a whitelist or blacklist filter depending on the configured parameters. Running containers as root is generally considered to be a bad practice, however, adding a USER instruction to the Dockerfile to specify a non-root user for the container to run as is a good place to start. If you do need to run as root, you can change the user to root at the beginning of the Dockerfile, then change back to the correct user with a second USER instruction. Example policy to blacklist root user: { "gate": "dockerfile", "trigger": "effective_user", "action": "stop", "parameters": } Exposed ports: This trigger processes the set of EXPOSE directives in the Dockerfile or history to determine the set of ports that are defined to be exposed (since it can span multiple directives). The detected value is then subject to a whitelist or blacklist filter depending on the configured parameters. Example of a policy blacklisting ports 21 and 22: { "gate": "dockerfile", "trigger": "exposed_ports", "action": "warn", "parameters": } no_dockerfile_provided: This trigger allows checks on the way the image was added, firing if the dockerfile was not explicitly provided at analysis time. This is useful in identifying and qualifying other trigger matches. Conclusion and Example Below is a short (and intentionally bad) example of why writing secure and efficient Dockerfiles is important. You can probably spot a good chunk of issues with the following Dockerfile: FROM node:latest ## port 22 for testing only EXPOSE 22 3000 RUN apt-get update RUN apt-get install -y curl nginx # LABEL maintainer="jvalance@email.com" ADD example.tar.gz /example # HEALTHCHECK --interval=30s CMD node healthcheck.js # USER node Why is This Not so Great FROM node:latest: This doesn't always have to be bad, but it is something to make developers aware of. If we always use the latest tag, we run the risk of our build suddenly breaking if that image tag gets updated. To prevent this from occurring, using a specific tag will help to ensure immutability. Additionally, depending on use of your image, you may not need the full node:latest image and its dependencies. Many trusted images have alpine version which greatly reduce the total image size, thus reducing the possibility of vulnerabilities in packages, and increasing the time of build. Example of differences is size (node:6 versus node:alpine) # docker images node 6 62905ac2c7de 12 days ago 882MB node alpine ebbf98230a82 2 weeks ago 73.7MB EXPOSE 22 3000: We can see as stated in the comment above the EXPOSE instruction, port 22 is only used for testing, therefore we can remove it when building our production ready images. Note the placement of the EXPOSEinstruction (close to the top). EXPOSE is a cheap command to run, so it is typically best to declare it as late as possible. # LABEL maintainer="jvalance@email.com": We aren't including a LABEL instruction. It is generally considered a good practice to add labels for organization, automation, licensing information, etc. # HEALTHCHECK --interval=30s CMD node healthcheck.js: No HEALTHCHECK instruction. Typically, this is useful for telling Docker to periodically check our container health status. Great article on why located here. # USER node: No user-defined. I've explained above why this is important to include. Read more about it here. ADD example.tar.gz /example: I've mentioned above why using COPY instead of ADD is considered better practice. Making the Dockerfile Better FROM node:6.16.0-alpine LABEL maintainer="jvalance@email.com" RUN apt-get update && apt-get install -y curl nginx COPY example.tar.gz /example HEALTHCHECK --interval=30s CMD node healthcheck.js USER node EXPOSE 3000 Many of these mistakes can be checked and validated with Anchore policies and in particular the Dockerfile gate I've discussed in the previous sections. If you are already leveraging Anchore to inspect your container images, I strongly suggest diving into the Dockerfile gate and adjusting it to suit your needs. If not, feel free to take a look at Anchore and how conducting a deep image inspection coupled with flexible policies helps users gain insight into the contents of their Docker images and enforce security, compliance, and best-practice requirements. ### Container Security & Compliance Scanning For AWS CodeBuild This will walk through integrating Anchore scanning with AWS CodeBuild. During the first step, a Docker image will be built from a Dockerfile. Following this, during the second step, Anchore will scan the image, and depending on the result of the policy evaluation, proceed to the final step. During the final step, the built image will be pushed to a Docker registry. Prerequisites Running Anchore Engine service AWS account Repository that contains a Dockerfile Setup Prior to setting up your AWS CodeBuild pipeline, an Anchore Engine service needs to be accessible from the pipeline. Typically this is on port 8228. In this example, I have an Anchore Engine service on AWS EC2 with standard configuration. I also have a Dockerfile in a GitHub repository that I will build an image from during the first step of the pipeline. In the final step, I will be pushing the built image to an image repository in my personal Dockerhub. The GitHub repository can be referenced here. I've added the following environment variables in the build project setup: ANCHORE_CLI_URL ANCHORE_CLI_USER ANCHORE_CLI_PASS ANCHORE_CLI_FAIL_ON_POLICY dockerhubUser dockerhubPass A buildspec.yml file should exist in the root directory of the Github repository you will link to your CodeBuild setup. Install In the install phase of the buildspec.yml file we install the Anchore CLI. You can find more info by referencing the GitHub repo here. Build Image In the build phase of the buildspec.yml file we build and push a Docker image to Docker Hub. build: commands: - docker build -t jvalance/node_critical_fail . - docker push jvalance/node_critical_fail Conduct Image Scan In the post_build phase of the buildspec.yml file we scan the built image with Anchore, and conduct a policy evaluation on it. Depending on the result of the policy evaluation the pipeline may or may not fail. In this example, the evaluation will not be successful, and the built image will not be pushed to a Docker registry. post_build: commands: - anchore-cli image add jvalance/node_critical_fail:latest - echo "Waiting for image to finish analysis" - anchore-cli image wait jvalance/node_critical_fail:latest - echo "Analysis complete" - if ; then anchore-cli evaluate check jvalance/node_critical_fail:latest ; fi - echo "Pushing image to Docker Hub" - docker push jvalance/node_critical_fail As a reminder, we advise having separate Docker registries for images that are being scanned with Anchore, and images that have passed an Anchore scan. For example, a registry for dev/test images, and a registry to certified, trusted, production-ready images. You may have noticed during this walkthrough I am using the same Docker Hub repository for all steps. This is not recommended for a production-grade deployment. You can read more about Anchore Enterprise here or get started with the Anchore Engine here. Additionally, you can find out more information on AWS CodeBuild by referencing their documentation. ### Introducing Anchore Policy Hub An important, core principle around which the anchore container image inspection, analysis, scanning and enforcement technologies have been built stems from the reality that, when dealing with container deployments in production, there is a great deal of variance in the software, configuration, and other static artifacts that exist across an organization’s container image set. Even within a single application that is delivered in the form of container images evolving over a (often short) period of time, frequent updates and modifications happen, resulting in the catalog of image software/configuration being in a state of flux. Given this characteristic of typical container environments, anchore tools and services have been designed to help users gain insight into container image composition, and importantly be able to specify rules to enforce security, compliance and best-practice requirements, while allowing the workload to be highly dynamic. The core concept we use in anchore to achieve these goals is that of the anchore policy evaluation, which is fed a user-defined document or set of documents that we refer to as anchore policy bundles. Using the policy mechanisms of anchore, users can define a collection of checks, whitelists, and mappings (encapsulated as a self-contained anchore policy bundle document). Anchore policy bundles can then be authored to encode a variety of rules, including checks within (but not limited to) the following categories: Security vulnerabilities Package whitelists and blacklists Presence of credentials in an image Dockerfile line checks Exposed ports Effective user Software licenses Image digest whitelist/blacklist User-defined anchore policies are used to perform evaluations against container images as they move through their lifecycle from CI/CD to production. Using the policy evaluation framework, users / integrated systems can receive reports (evaluation results, security vulnerability scans, image content reports, and more) and control recommendations (policy evaluation pass/fail) at every step during a container image’s lifecycle. Today, we’re pleased to announce the availability of a new service called the Anchore Policy Hub, which offers a store of pre-defined anchore policy bundles, and additionally (importantly!) is intended to serve as a mechanism for container DevOps and SecOps user communities to discuss container security, compliance and best-practices topics, while demonstrating functional working expressions of these topics in the form of fully usable anchore policy bundles, all in a public forum. What is Being Released Specifically, the Anchore Policy Hub is a centralized repository of resources that are publicly available and can be loaded into/consumed by any anchore engine installation, via anchore engine clients. This system serves as a canonical store of source documents (initially, anchore policy bundles), both serving as a location where pre-defined policy bundles can be easily fetched and loaded into anchore engine deployments, to serve as a starting point for creating your own policy bundles, as well as a providing a location where users of anchore can submit and share new policy bundles. Moving forward, our intention is to use this system as a mechanism for storing/sharing other anchore resources as well. For this initial release, we have made available the following new resources: The Anchore Policy Hub source document repository itself, hosted on github, which is initially populated with a set of policy bundles that can be used as a starting point for your own policy definitions. Three pre-defined policy bundles that implement security and best practices checks from a few different perspectives, including a ‘security only’ bundle, a ‘Docker CIS 1.13.0’ bundle, and a ‘mixture of security and best practices’ bundle. A simple, publicly accessible HTTP service, where clients can fetch and install policy bundles generated automatically from the source materials above. New operations in the anchore CLI, version 0.3.2, for listing, inspecting and installing policy bundles served from the hub. Start Using the Hub For those existing anchore users who are anxious to get started right away, we have made available three policy bundles hosted in the hub that can be installed today. The requirements are: Have a deployed anchore engine service up and running (for new users, see the anchore engine installation guides to get started). Installed anchore-cli version 0.3.2 or greater (or simply use the engine-cli:v0.3.2 container), configured to access your anchore engine deployment. The example below shows the process for listing, reviewing, installing and optionally modifying bundles from the anchore policy hub using the CLI: # anchore-cli --version anchore-cli, version 0.3.2 # anchore-cli policy hub list Name Description anchore_security_only Single policy, single whitelist bundle for performing security checks, including example blacklist known malicious packages by name. anchore_default_bundle Default policy bundle that comes installed with vanilla anchore-engine deployments. Mixture of light vulnerability checks, dockerfiles checks, and warning triggers for common best practices. anchore_cis_1.13.0_base Docker CIS 1.13.0 image content checks, from section 4 and 5. NOTE: some parameters (generally are named 'example...') must be modified as they require site-specific settings # anchore-cli policy hub get anchore_cis_1.13.0_base Policy Bundle ID: anchore_cis_1.13.0_base Name: anchore_cis_1.13.0_base Description: Docker CIS 1.13.0 image content checks, from section 4 and 5. NOTE: some parameters (generally are named 'example...') must be modified as they require site-specific settings Policy Name: CIS File Checks Policy Description: Docker CIS section 4.8 and 4.10 checks. Policy Name: CIS Dockerfile Checks Policy Description: Docker CIS section 4.1, 4.2, 4.6, 4.7, 4.9 and 5.8 checks. Policy Name: CIS Software Checks Policy Description: Docker CIS section 4.3 and 4.4 checks. Whitelist Name: RHEL SUID Files Whitelist Description: Example whitelist with triggerIds of files that are expected to have SUID/SGID, for rhel-based images Whitelist Name: DEB SUID Files Whitelist Description: Example whitelist with triggerIds of files that are expected to have SUID/SGID, for debian-based images Mapping Name: default Mapping Rule: */*:* Mapping Policies: CIS Software Checks,CIS Dockerfile Checks,CIS File Checks Mapping Whitelists: DEB SUID Files,RHEL SUID Files # anchore-cli policy hub install anchore_cis_1.13.0_base Policy ID: anchore_cis_1.13.0_base Active: False Source: local Created: 2019-01-31T18:42:50Z Updated: 2019-01-31T18:42:50Z # anchore-cli policy list Policy ID Active Created Updated anchore_cis_1.13.0_base False 2019-01-31T18:42:50Z 2019-01-31T18:42:50Z Once the policy bundle has been installed from the hub, you can perform image add and evaluate actions using the usual mechanisms of anchore, as with any other pre-existing policy bundle and image set: # anchore-cli image add docker.io/alpine:3.8 Image Digest: sha256:616d0d0ff1583933ed10a7b3b4492899942016c0577d43a1c506c0aad8ab4da8 Parent Digest: sha256:dad671370a148e9d9573e3e10a9f8cc26ce937bea78f3da80b570c2442364406 Analysis Status: not_analyzed Image Type: docker Image ID: 491e0ff7a8d51cd66a07e8b98976694174e82c0abbc77a96533c580a11378464 Dockerfile Mode: None Distro: None Distro Version: None Size: None Architecture: None Layer Count: None Full Tag: docker.io/alpine:3.8 # anchore-cli image wait docker.io/alpine:3.8 Status: analyzing Waiting 5.0 seconds for next retry. Image Digest: sha256:616d0d0ff1583933ed10a7b3b4492899942016c0577d43a1c506c0aad8ab4da8 Parent Digest: sha256:dad671370a148e9d9573e3e10a9f8cc26ce937bea78f3da80b570c2442364406 Analysis Status: analyzed Image Type: docker Image ID: 491e0ff7a8d51cd66a07e8b98976694174e82c0abbc77a96533c580a11378464 Dockerfile Mode: Guessed Distro: alpine Distro Version: 3.8.2 Size: 2207038 Architecture: amd64 Layer Count: 1 Full Tag: docker.io/alpine:3.8 # anchore-cli evaluate check docker.io/alpine:3.8 --policy anchore_cis_1.13.0_base --detail Image Digest: sha256:616d0d0ff1583933ed10a7b3b4492899942016c0577d43a1c506c0aad8ab4da8 Full Tag: docker.io/alpine:3.8 Image ID: 491e0ff7a8d51cd66a07e8b98976694174e82c0abbc77a96533c580a11378464 Status: fail Last Eval: 2019-01-31T18:44:30Z Policy ID: anchore_cis_1.13.0_base Final Action: stop Final Action Reason: policy_evaluation Gate Trigger Detail Status dockerfile instruction Dockerfile directive 'ADD' check 'exists' matched against '' for line 'file:91fb97ea3549e52e7b6e22b93a6736cf915c756f3d13348406d8ad5f1a872680 in /' warn dockerfile instruction Dockerfile directive 'HEALTHCHECK' not found, matching condition 'not_exists' check stop dockerfile instruction Dockerfile directive 'FROM' check 'not_in' matched against 'example_trusted_base1,example_trusted_base2' for line 'scratch' stop dockerfile effective_user User root found as effective user, which is explicity not allowed list stop Finally, since some standards require site-specific information be supplied, we have included example values in the policy hub bundles that should be modified for your specific environment/application being scanned. To modify a policy bundle, you can edit the JSON directly, make a copy of the installed bundle and add a new bundle with your included modifications, or Enterprise users can use the Anchore Enterprise UI policy editing feature to make the necessary modifications and manage the installed bundles in anchore-engine. For more examples and information, please visit the Anchore Policy Hub repository on GitHub, which will have all of the latest information on usage, contributing, and deployment options. Summary We’re truly excited to be sharing this service with the anchore and container user communities today, and invite all to visit the Anchore Policy Hub repository on GitHub for more information on how to start using the policy bundles already available, how to contribute your own policy bundles, modify the ones that are there already, discuss the topic generally, and even how to host an on-premises instance of an anchore hub in your own environment using the provided tools. We look forward to working with you via the hub to help advance the cause of bringing high-quality container image inspection, security, compliance and best-practice enforcement tooling to any and all who are deploying containers today! ### Kubernetes Admission Controller Dynamic Policy Mappings & Modes In December, Anchore introduced an admission controller for Kubernetes solution & vulnerability scanner to gate pod execution based on Anchore analysis and policy evaluation of image content. It supports three different modes of operation allowing you to tune the tradeoff between control and intrusiveness for your environments. To summarize, those modes are: Strict Policy-Based Admission Gating Mode - Images must pass policy evaluation by Anchore Engine for admission. Analysis-Based Admission Gating Mode - Images must have been analyzed by Anchore Engine for admission. Passive Analysis Trigger Mode - No admission, requirement, but images are submitted for analysis by Anchore Engine prior to admission. The analysis itself is asynchronous. The multi-mode flexibility is great for customizing how strictly the controller enforces compliance with policy (if at all), but it does not allow you to use different bundles with different policies for the same image based on annotations or labels in Kubernetes, where there is typically more context about how strictly an image should be evaluated. Consider the following scenario: Your cluster has two namespaces: testing and production. You'll be deploying many of the same images into those namespaces, and but you want testing to use much more permissive policies than production. Let's consider the two policies: testing policy - only block images with critical vulnerabilities production policy - block images with high or critical vulnerabilities or that do not have a defined healthcheck Now, let's also allow pods to run in the production environment regardless of the image content if the pod has a special label: 'breakglass=true' These kinds of high-level policies are useful for operations work that requires temporary access using specific tools. Such a scenario would not be achievable with the older controller. So, based on user feedback we've added the ability to select entirely different Anchore policy bundles based on metadata in Kubernetes as well as the image tag itself. This complements Anchore's internal mapping structures within policy bundles that give fine-grained control over which rules to apply to an image based on the image's tag or digest. Broadly, the controller's configuration now supports selector rules that encode a logical condition like this (in words instead of yaml): If metadata property name matches SelectorKeyRegex and its value matches SelectorValueRegex, then use the specified Mode for checking with bundle PolicyBundleId from anchore user Username In YAML, the configuration configmap has a new section, which looks like: policySelectors: - Selector: ResourceType: pod SelectorKeyRegex: breakglass SelectorValueRegex: true PolicyReference: Username: testuser PolicyBundleId: testing_bundle Mode: policy - Selector: ResourceType: namespace SelectorKeyRegex: name SelectorValueRegex: testing PolicyReference: Username: testuser PolicyBundleId: testing_bundle Mode: policy - Selector: ResourceType: namespace SelectorKeyRegex: name SelectorValueRegex: production PolicyReference: Username: testuser PolicyBundleId: production_bundle Mode: policy - Selector: ResourceType: image SelectorKeyRegex: .* SelectorValueRegex: .* PolicyReference: Username: demouser PolicyBundleId: default Next, I'll walk through configuring and deploying anchore and a controller to behave like the above example. I'll set up two policies and two namespaces in Kubernetes to show how the selectors work. For a more detailed walk-thru of the configuration and operation of the controller, see the GitHub project. Installation and Configuration of the Controller If you already have anchore running in the cluster or in a location reachable by the cluster then that will work. You can skip to user and policy setup and continue there. Anchore Engine install requirements: Running Kubernetes cluster v1.9+ Configured kubectl tool with configured access (this may require some rbac config depending on your environment) Enough resources to run anchore engine (a few cores and 4GB+ of RAM is recommended) Install Anchore Engine 1. Install Anchore Engine in the cluster. There is no requirement that the installation is in the same k8s cluster or any k8s cluster, it is simply for convenience helm install --name anchore stable/anchore-engine 2. Run a CLI container to easily query anchore directly to configure a user and policy kubectl run -i -t anchorecli --image anchore/engine-cli --restart=Always --env ANCHORE_CLI_URL=http://anchore-anchore-engine-api.anchore.svc.local:8228 --env ANCHORE_CLI_USER=admin --env ANCHORE_CLI_PASS=foobar 3. From within the anchorecli container, create a new account in anchore anchore-cli account create testing 4. Add a user to the account with a set of credentials (you'll need these later) anchore-cli account user add --account testing testuser testuserpassword 5. As the new user, analyze some images, nginx and alpine in this walk-thru. I'll use those for testing the controller later. anchore-cli --u testuser --p testuserpassword image add alpine anchore-cli --u testuser --p testuserpassword image add nginx anchore-cli --u testuser --p testuserpassword image list 6. Create a file, testing_bundle.json: { "blacklisted_images": [], "comment": "testing bundle", "id": "testing_bundle", "mappings": [ { "id": "c4f9bf74-dc38-4ddf-b5cf-00e9c0074611", "image": { "type": "tag", "value": "*" }, "name": "default", "policy_id": "48e6f7d6-1765-11e8-b5f9-8b6f228548b6", "registry": "*", "repository": "*", "whitelist_ids": [ "37fd763e-1765-11e8-add4-3b16c029ac5c" ] } ], "name": "Testing bundle", "policies": [ { "comment": "System default policy", "id": "48e6f7d6-1765-11e8-b5f9-8b6f228548b6", "name": "DefaultPolicy", "rules": [ { "action": "WARN", "gate": "dockerfile", "id": "312d9e41-1c05-4e2f-ad89-b7d34b0855bb", "params": [ { "name": "instruction", "value": "HEALTHCHECK" }, { "name": "check", "value": "not_exists" } ], "trigger": "instruction" }, { "action": "STOP", "gate": "vulnerabilities", "id": "b30e8abc-444f-45b1-8a37-55be1b8c8bb5", "params": [ { "name": "package_type", "value": "all" }, { "name": "severity_comparison", "value": ">" }, { "name": "severity", "value": "high" } ], "trigger": "package" } ], "version": "1_0" } ], "version": "1_0", "whitelisted_images": [], "whitelists": [ { "comment": "Default global whitelist", "id": "37fd763e-1765-11e8-add4-3b16c029ac5c", "items": [], "name": "Global Whitelist", "version": "1_0" } ] } 7. Create a file, production_bundle.json: { "blacklisted_images": [], "comment": "Production bundle", "id": "production_bundle", "mappings": [ { "id": "c4f9bf74-dc38-4ddf-b5cf-00e9c0074611", "image": { "type": "tag", "value": "*" }, "name": "default", "policy_id": "48e6f7d6-1765-11e8-b5f9-8b6f228548b6", "registry": "*", "repository": "*", "whitelist_ids": [ "37fd763e-1765-11e8-add4-3b16c029ac5c" ] } ], "name": "production bundle", "policies": [ { "comment": "System default policy", "id": "48e6f7d6-1765-11e8-b5f9-8b6f228548b6", "name": "DefaultPolicy", "rules": [ { "action": "STOP", "gate": "dockerfile", "id": "312d9e41-1c05-4e2f-ad89-b7d34b0855bb", "params": [ { "name": "instruction", "value": "HEALTHCHECK" }, { "name": "check", "value": "not_exists" } ], "trigger": "instruction" }, { "action": "STOP", "gate": "vulnerabilities", "id": "b30e8abc-444f-45b1-8a37-55be1b8c8bb5", "params": [ { "name": "package_type", "value": "all" }, { "name": "severity_comparison", "value": ">=" }, { "name": "severity", "value": "high" } ], "trigger": "package" } ], "version": "1_0" } ], "version": "1_0", "whitelisted_images": [], "whitelists": [ { "comment": "Default global whitelist", "id": "37fd763e-1765-11e8-add4-3b16c029ac5c", "items": [], "name": "Global Whitelist", "version": "1_0" } ] } 8. Add those policies for the new testuser: anchore-cli --u testuser --p testuserpassword policy add testing_bundle.json anchore-cli --u testuser --p testuserpassword policy add production_bundle.json 9. Verify that the alpine image will pass the staging bundle evaluation but not the production bundle: / # anchore-cli --u testuser --p testuserpassword evaluate check alpine --policy testing_bundle Image Digest: sha256:25b4d910f4b76a63a3b45d0f69a57c34157500faf6087236581eca221c62d214 Full Tag: docker.io/alpine:latest Status: pass Last Eval: 2019-01-30T18:51:08Z Policy ID: testing_bundle / # anchore-cli --u testuser --p testuserpassword evaluate check alpine --policy production_bundle Image Digest: sha256:25b4d910f4b76a63a3b45d0f69a57c34157500faf6087236581eca221c62d214 Full Tag: docker.io/alpine:latest Status: fail Last Eval: 2019-01-30T18:51:14Z Policy ID: production_bundle Now its time to get the admission controller in place to use those policies Install and Configure the Admission Controller 1. Configure Credentials for the Admission controller to use I'll configure a pair of credentials, the new format supports multiple credentials in the secret so that the controller configuration can map policy bundles in multiple accounts. It is important that all usernames specified in the configuration of the controller have a corresponding entry in this secret to provide the password for API auth. Create a file, testcreds.json: { "users": [ { "username": "admin", "password": "foobar"}, { "username": "testuser", "password": "testuserpassword"} ] } kubectl create secret generic anchore-credentials --from-file=credentials.json=testcreds.json 2. Add the stable anchore charts repository helm repo add anchore-stable http://charts.anchore.io/stable helm repo update 3. Create a custom test_values.yaml In your editor, create a file values.yaml in the current directory credentialsSecret: anchore-credentials anchoreEndpoint: "http://anchore-anchore-engine-api.default.svc.cluster.local:8228" requestAnalysis: true policySelectors: - Selector: ResourceType: pod SelectorKeyRegex: ^breakglass$ SelectorValueRegex: "^true$" PolicyReference: Username: testuser PolicyBundleId: testing_bundle Mode: breakglass - Selector: ResourceType: namespace SelectorKeyRegex: name SelectorValueRegex: ^testing$ PolicyReference: Username: testuser PolicyBundleId: testing_bundle Mode: policy - Selector: ResourceType: namespace SelectorKeyRegex: name SelectorValueRegex: ^production$ PolicyReference: Username: testuser PolicyBundleId: production_bundle Mode: policy - Selector: ResourceType: image SelectorKeyRegex: .* SelectorValueRegex: .* PolicyReference: Username: testuser PolicyBundleId: 2c53a13c-1765-11e8-82ef-23527761d060 Mode: analysis The 'name' values are used instead of full regexes in those instances because if the KeyRegex is exactly the string "name" then the controller will look at the resource name instead of a label or annotation and do the value regex match against that name. 4. Install the controller via the chart helm install --name controller anchore-stable/anchore-admission-controller -f test_values.yaml 5. Create the validating webhook configuration as indicated by the chart install output: KUBE_CA=$(kubectl config view --minify=true --flatten -o json | jq '.clusters[0].cluster."certificate-authority-data"' -r) cat > validating-webhook.yaml < junit junit 4.11 com.fasterxml.jackson.core jackson-databind ${jackson.version} The vulnerable artifact I've added to this particular project can be found on Maven Central here and GitHub here. I will be expecting jackson-databind 2.9.7 to contain vulnerabilities. Building Project Viewing the dependency tree Since we are leveraging Maven to build this project, I can also use a Maven command to view the dependencies. The command mvn dependency:tree will display the dependency tree for this project as seen below.   mvn dependency:tree [INFO] Scanning for projects... [INFO] [INFO] ------------------------< Anchore:anchore-demo >------------------------ [INFO] Building Anchore Demo 1.0 [INFO] ----------------------------------------------------------------- [INFO] [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ anchore-demo --- [INFO] Anchore:anchore-demo:war:1.0 [INFO] +- junit:junit:jar:4.11:compile [INFO] | - org.hamcrest:hamcrest-core:jar:1.3:compile [INFO] - com.fasterxml.jackson.core:jackson-databind:jar:2.9.7:compile [INFO] +- com.fasterxml.jackson.core:jackson-annotations:jar:2.9.0:compile [INFO] - com.fasterxml.jackson.core:jackson-core:jar:2.9.7:compile [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 1.117 s [INFO] Finished at: 2019-01-22T19:39:56-05:00 [INFO] ------------------------------------------------------------------------ Building a war file To create the war file as defined in the pom.xml I will run the command mvn clean package. The important piece here is that package will generate the war file and place it in the target directory as seen below. target jvalance$ ls -la | grep anchore-demo-1.0.war -rw-r--r-- 1 jvalance staff 1862404 Jan 22 19:50 anchore-demo-1.0.war Building and Scanning Docker Images For the purposes of this post, I just need to include the war file created in the previous step in our Docker image. A simple way to do this can be defined below in a Dockerfile. FROM openjdk:8-jre-alpine # Copy target directory COPY target/ app/ Once I've built the image and pushed it to a container registry, I can now scan it with Anchore via the CLI command below. anchore-cli image add docker.io/jvalance/maven-demo:latest Viewing Vulnerabilities Once Anchore has completed an analysis of the image successfully, I can check for non-os vulnerabilities via the following CLI command: anchore-cli image vuln docker.io/jvalance/maven-demo:latest non-os ## The above produces the following output: Vulnerability ID Package Severity Fix Vulnerability URL SNYK-JAVA-COMFASTERXMLJACKSONCORE-72448 jackson-databind-2.9.7 High ! <2.6.7.2 https://snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-72448 SNYK-JAVA-COMFASTERXMLJACKSONCORE-72448 jackson-databind-2.9.7 High ! <2.6.7.2 https://snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-72448 SNYK-JAVA-COMFASTERXMLJACKSONCORE-72449 jackson-databind-2.9.7 High ! <2.6.7.2 https://snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-72449 SNYK-JAVA-COMFASTERXMLJACKSONCORE-72449 jackson-databind-2.9.7 High ! <2.6.7.2 https://snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-72449 SNYK-JAVA-COMFASTERXMLJACKSONCORE-72451 jackson-databind-2.9.7 High ! <2.6.7.2 https://snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-72451 SNYK-JAVA-COMFASTERXMLJACKSONCORE-72451 jackson-databind-2.9.7 High ! <2.6.7.2 https://snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-72451 SNYK-JAVA-COMFASTERXMLJACKSONCORE-72882 jackson-databind-2.9.7 High ! >=2.0.0 <2.9.8 https://snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-72882 SNYK-JAVA-COMFASTERXMLJACKSONCORE-72882 jackson-databind-2.9.7 High ! >=2.0.0 <2.9.8 https://snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-72882 SNYK-JAVA-COMFASTERXMLJACKSONCORE-72883 jackson-databind-2.9.7 High ! >=2.0.0 <2.9.8 https://snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-72883 SNYK-JAVA-COMFASTERXMLJACKSONCORE-72883 jackson-databind-2.9.7 High ! >=2.0.0 <2.9.8 https://snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-72883 SNYK-JAVA-COMFASTERXMLJACKSONCORE-72884 jackson-databind-2.9.7 High ! >=2.0.0 <2.9.8 https://snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-72884 SNYK-JAVA-COMFASTERXMLJACKSONCORE-72884 jackson-databind-2.9.7 High ! >=2.0.0 <2.9.8 https://snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-72884 I also have the option to login and view the vulnerabilities via the UI. By clicking on any of the links on the far right, I can immediately be taken to Snyk's Vulnerability DB to view more information. Example: SNYK-JAVA-COMFASTERXMLJACKSONCORE-72448. For this particular vulnerability, Snyk offers remediation advice located at the bottom. Which states: "Upgrade com.fasterxml.jackson.core:jackson-databind to version 2.6.7.2, 2.7.9.5, 2.8.11.3, 2.9.8 or higher." Given that there are twelve known vulnerabilities found within this image, it is a best practice for a security team to go through each and make a decision with the developer on how to best triage. For the simplicity of this post, if I were to follow the suggested remediation guidance above, and upgrade my vulnerable dependency to 2.9.8, rebuild the war file, rebuild the Docker image, and scan it with Anchore, this particular vulnerability should no longer persist. Quick Test mvn dependency:tree output: Anchore:anchore-demo:war:1.0 [INFO] +- junit:junit:jar:4.11:compile [INFO] | - org.hamcrest:hamcrest-core:jar:1.3:compile [INFO] - com.fasterxml.jackson.core:jackson-databind:jar:2.9.8:compile [INFO] +- com.fasterxml.jackson.core:jackson-annotations:jar:2.9.0:compile [INFO] - com.fasterxml.jackson.core:jackson-core:jar:2.9.8:compile Once I've repeated the steps shown above to build war file, Docker image, and scan newly built image with Anchore, I can then see if the discussed vulnerability is present. Overview of vulnerabilities None present. I can also view the changelog for this image to get a better sense of the modification I just made. Below I can specifically see the version change I made to the jackson-databind library.   Conclusion This was an intentionally simple example of how a vulnerable non-os package within a Docker image can be identified and fixed with Anchore. However, you can see how easily a vulnerable package can potentially wreak havoc if the appropriate checks are not in place. In practice, Docker image scanning should be a mandatory step in a CI pipeline, and development and security teams should maintain open lines of communication when vulnerabilities are discovered within images, and then move swiftly to apply the appropriate fixes. ### 5 CI/CD Platforms Leverage Docker Container Technology As containers have exploded onto the IT landscape over the last few years, more and more companies are turning to Docker to provide a quick and effective means to release software at a faster pace. This shift has caused several Continuous Integration and Continuous Delivery (CI/CD) tools and companies to strategically create and weave new container-native solutions into their platforms. In this blog, we’ll take a look at some of the top CI/CD players in the game and the shifts they’ve made to support their users in this brave new world of containers. 1. Jenkins Cloudbees’ open source Jenkins CI/CD platform is arguably the most popular CI/CD platform available in 2019. Originally created in the early 2000s (as part of the Hudson project) Jenkins now has wide adoption across various types of organizations helping teams to automate any task that would otherwise put a time-consuming strain on your software team. Some of the most common uses for Jenkins include building projects, running tests, bug detection, code analysis, and project deployment. Jenkins can be easily integrated with a Docker workflow where it manages the entire development pipeline of containerized applications. In addition, with one of the largest open source communities among CI/CD providers, Jenkins has a wide variety of container-related plugins available to delivers solutions for source code management to security. **Bonus: With the Anchore plugin for Jenkins, users can quickly and easily scan Docker images in a Jenkins pipeline. 2. CircleCI CircleCI is one of the most nimble and well-integrated of the CI platforms. Founded in 2011 CircleCI provides a state of the art platform for integration and delivery, which has helped hundreds of thousands of teams across the globe to release their code through build automation, test automation, and a comprehensive deployment process. CircleCI can be conveniently configured to deploy code to a number of environments including AWS EC2, AWS CodeDeploy, AWS S3, and Google Container Engine (GKE). CircleCI natively supports the ability to build, test, or run as many Docker containers as you’d like. Users can run any Docker commands as well as access public and private containers registries for full control over your build environment. For convenience, CircleCI also maintains several Docker images. These images are typically extensions of official Docker images and include tools especially useful for CI/CD. Like Jenkins, CircleCI has a robust set of integrations that cater to container users. 3. Codeship Codeship is a CI/CD tool recently acquired by CloudBees that offers efficiency, simplicity, and speed all at the same time. Teams can use Codeship to build, test, and deploy directly from a Bitbucket or GitHub project and it’s a concise set of features combines integration with delivery so that your code is deployed accordingly once test automation has cleared. With Codeship Pro, the build pipeline runs in Docker containers. This enables users to take advantage of features like easy migration through the ability to use large parts of your docker-compose file to set up Codeship and updates whenever the latest stable Docker version is available. You can learn more about how Codeship works in a containerized environment. 4. GitLab GitLab is a rapidly growing code management platform that offers both open source and enterprise solutions for issue management, code views, as well as continuous integration and deployment, all within a single dashboard. While the main Gitlab offering is a web-based Git repository manager with features such as issue tracking, analytics, and a Wiki, Gitlab also offers a CI/CD component that allows you to trigger builds, run tests, and deploy code with each commit or push. You can run build jobs in a virtual machine, Docker container, or on another server. Of all CI/CD platforms, Gitlab has shown a particularly strong focus on containers, even creating GitLab Container Registry, which makes it easy to store and share container images. By building a number of toolsets that integrate seamlessly together and focusing on a growing base of container-native users, Gitlab is definitely worth a look if containers are top of mind for your company Check out their docs to learn how to utilize Docker images within the GitLab suite of tools. 5. Codefresh Codefresh is another CI/CD platform that has placed a heavy focused on its container first user base, offering Docker-in-Docker as a service for building CI/CD pipelines with each step of a pipeline running in its own container. The Codefresh user interface is clear, smart, and easy to understand. You can launch a project and check its working condition as soon as the project is built and the image is created. You can also choose from a number of templates to smoothen the movement of your current project to containers. Codefresh puts a big focus k8s, and in has some neat helm features too. Anchore's helm chart is listed in the codefresh ui. With Codefresh’s suite of tools, users can easily build, test, push, and deploy images, utilize a built-in Kubernetes dashboard, Docker registry, as well as release management making it much easier for container users to get work done quickly and efficiently. Learn more about how Codefresh works with containers in their documentation. Conclusion With the growing move to containers in 2019, we can only expect CI/CD tools to place an even heavier focus on building solutions to support containers. This shift to a container friendly ecosystem has and will help thousands of companies continue to see a decrease in their build time, test time, time to release. ### Improving Open Source Security with Anchore and Snyk Open source software components and dependencies are increasingly making up a vast majority of software applications. Along with the increased usage of OSS comes the inherent security risks these packages present. Enterprises looking to adopt a greater open source footprint should also employ effective tooling and processes to identify, manage, and mitigate the potential risks these libraries impose. Containers have been gaining popularity as well among enterprises. Uniquely allowing for development and packaging of applications, and their dependencies, to improve consistency and speed of production deployments. By nature of consistency, the quality of development and software releases also improves. Recognizing that container images need an added layer of security, Anchore conducts a deep image inspection and analysis to uncover what is within the image and generate a detailed manifest that includes packages, configuration files, language modules, and artifacts. Following analysis, user-defined acceptance policies are evaluated against the analyzed data to certify the container images. Due to an increased number of Anchore customers asking for high-quality vulnerability data for OSS packages, Anchore has partnered with Snyk. Anchore Enterprise customers now have access to third-party vulnerability data for non-OS open source libraries from Snyk. This database is maintained by Snyk's security team, who spends a significant amount of time curating vulnerability data, as well as conducting their own research to uncover previously unknown vulnerabilities. Most of the vulnerabilities in Snyk's database originate from constant monitoring of other vulnerability databases, CVEs from NVD, monitoring user activity on Github, and both manual and bulk security research. Anchore users will get updates to vulnerability feed data at the interval they configure (default is six hours). In addition, Anchore policies can be created to enforce container images that include vulnerable packages from making their way into production environments. Below is a snapshot of Anchore Enterprise with vulnerable Python packages identified by Snyk Given that more organizations are increasing their use of both containers and OSS components, it is becoming more critical for enterprises to have the proper mechanisms in place to uncover and fix vulnerable packages within container images as early as possible in the development lifecycle. Anchore strongly recommends adding image scanning as part of a continuous integration pipeline, and invoking Anchore policies to govern security vulnerabilities, configuration file contents, secrets, exposed ports, or any other user-defined checks. Find out more about Anchore Enterprise and Snyk here: Anchore Enterprise. ### Admission Control in Kubernetes with Anchore Our focus at Anchore is analyzing, validating, and evaluating docker images against custom policies to give users visibility, control-of, and confidence-in their container images before they ever execute. And, its open-source. In this post, learn how to use the new Anchore admission controller for Kubernetes to gate execution of docker images in Kubernetes according to criteria expressed in Anchore policies such as security vulnerabilities, package manifests, image build-instructions, image source, and the other aspects of image content that Anchore Engine can expose via policy. The Anchore admission controller implements a handler for Kubernetes's Validating Webhook payloads specifically configured to validate Pod objects and the image references they contain. This is a well-established pattern for Kubernetes clusters and admission controllers. The Anchore admission controller supports three different modes of operation allowing you to tune tradeoff between control and intrusiveness for your environments. Strict Policy-Based Admission Gating Mode This is the strictest mode and will admit only images that are already analyzed by Anchore and receive a "pass" on policy evaluation. This enables you to ensure, for example, that no image is deployed into the cluster that has a known high-severity CVE with an available fix, or any of a number of other conditions. Anchore's policy language supports sophisticated conditions on the properties of images, vulnerabilities, and metadata. If you have a check or condition that you want to evaluate that you're not sure about, please let us know! Examples of Anchore Engine policy rules that are useful in a strict admission environment: Reject an image if it is being pulled from dockerhub directly Reject an image that has high or critical CVEs that have a fix available, but allow high-severity if no fix is available yet Reject an image if it contains a blacklisted package (rpm, deb, apk, jar, python, npm, etc), where you define the blacklist Never reject images from a specific registry/repository (e.g. internal infra images that must be allowed to run) Analysis-Based Admission Gating Mode Admit only images that are analyzed and known to Anchore, but do not execute or require a policy evaluation. This is useful in cases where you'd like to enforce requirement that all images be deployed via a CI/CD pipeline, for example, that itself manages the Kubernetes image scanning with Anchore, but allowing the CI/CD process to determine what should run based on other factors outside the context of the image or k8s itself. Passive Analysis Trigger Mode Trigger an Anchore analysis of images, but to no block execution on analysis completion or policy evaluation of the image. This is a way to ensure that all images that make it to deployment (test, staging, or prod) are guaranteed to have some form of analysis audit trail available and a presence in reports and notifications that are managed by Anchore Engine. Installation and Configuration of the Controller Requirements: Running Kubernetes cluster v1.9+ Configured kubectl tool with configured access (this may require some rbac config depending on your environment) Enough resources to run anchore engine (a few cores and 4GB+ of RAM is recommended) Install Anchore Engine 1. Install Anchore Engine in the cluster. There is no requirement that the installation is in the same k8s cluster or any k8s cluster, I use it here simply for convenience helm install --name demo stable/anchore-engine 2. Run a CLI container so we can easily query anchore directly to configure a user and policy kubectl run -i -t anchorecli --image anchore/engine-cli --restart=Always --env ANCHORE_CLI_URL=http://demo-anchore-engine-api.default.svc:8228 --env ANCHORE_CLI_USER=admin --env ANCHORE_CLI_PASS=foobar 3. From within the anchorecli container, verify the system is responding (it may take a few minutes to fully bootstrap so you may need to run this a few times until it returns all services in the "up" state). The second command will wait until the security feeds are all synced and cve data is available. anchore-cli system status Which should show the system version and services. If the command hangs for a second, that is normal during service bootstrap, you may need to cancel and re-run the command as all the infrastructure comes up in k8s. Once you have a successful return of system status, run a wait to make sure the system is fully initialized. This may take some time since it requires all vulnerability feed data to be synced. anchore-cli system wait 4. From within the anchorecli container, create a new anchore account anchore-cli account add demo 5. Add a user to the account with a set of credentials (you'll need these later) anchore-cli account user add --account demo controller admissioncontroller123 Now, exit the container 6. Create a new cli container using the new credentials, I'll refer to this as ctluser_cli container kubectl run -i --tty anchore-controller-cli --restart=Always --image anchore/engine-cli --env ANCHORE_CLI_USER=controller --env ANCHORE_CLI_PASS=admissioncontroller123 --env ANCHORE_CLI_URL=http://demo-anchore-engine-api.default.svc:8228/v1/ From within ctluser_cli container, analyze an image to verify things work anchore-cli image add alpine anchore-cli image list 7. Exit the anchore-controller-cli container Configure Credentials The helm chart and controller support two ways of passing the Anchore Engine credentials to the controller: Directly in the chart via values.yaml or on cli:--set anchore.username=admissionuser --set anchore.password=mysupersecretpassword Using kubernetes Secrets: kubectl create secret generic anchore-creds --from-literal=username=admissionuser --from-literal=password=mysupersecretpassword. And on chart execution/upgrade set via cli (--set anchore.credentialsSecret=) or set the key in values.yaml NOTE: Using a secret is highly recommended since it will not be visible in any ConfigMaps For this post I'll use a secret: kubectl create secret generic anchore-credentials --from-literal=username=controller --from-literal=password=admissioncontroller123 Next, on to the controller itself. Install and Configure the Admission Controller I'll start by using the controller in Passive mode, and then show how to add the policy gating. 1. Back on your localhost, get the admission controller chart from Github git clone https://github.com/anchore/anchore-charts cd anchore-charts/stable/anchore-admission-controller 2. Save the following yaml to my_values.yaml anchore: endpoint: "http://demo-anchore-engine-api.default.svc:8228" credentialsSecret: anchore-credentials 3. Install the controller chart helm install --name democtl -f my_values.yaml . 4. Run the get_config.sh script included in the github repo to grab the validating webhook configuration. It will output validating-webhook.yaml ./files/get_validating_webhook_config.sh democtl 5. Activate the configuration kubectl apply -f validating-webhook.yaml 6. Verify its working kubectl run ubuntu --image ubuntu --restart=Never kubectl attach -i -t anchore-cli image list You should see the 'ubuntu' tag available and analyzing/analyzed in Anchore. That is the passive-mode triggering the analysis. For example: zhill@localhost anchore-admission-controller]$ kubectl run -i -t ubuntu --image ubuntu --restart=Never If you don't see a command prompt, try pressing enter. root@ubuntutest:/# exit exit [zhill@localhost anchore-admission-controller]$ kubectl logs test2-anchore-admission-controller-7c47fb85b4-n5v7z ... 1207 13:30:52.274424 1 main.go:148] Checking image: ubuntu I1207 13:30:52.274448 1 main.go:193] Performing passive validation. Will request image analysis and always allow admission I1207 13:30:55.180722 1 main.go:188] Returning status: &AdmissionResponse{UID:513100b2-fa24-11e8-9154-d06131dd3541,Allowed:true,Result:&k8s_io_apimachinery_pkg_apis_meta_v1.Status{ListMeta:ListMeta{SelfLink:,ResourceVersion:,Continue:,},Status:Success,Message:Image analysis for image ubuntu requested and found mapped to digest sha256:acd85db6e4b18aafa7fcde5480872909bd8e6d5fbd4e5e790ecc09acc06a8b78,Reason:,Details:nil,Code:0,},Patch:nil,PatchType:nil,} ... And in the ctluser_cli container I can confirm the image was added an analyzed: / # anchore-cli image get ubuntu Image Digest: sha256:acd85db6e4b18aafa7fcde5480872909bd8e6d5fbd4e5e790ecc09acc06a8b78 Parent Digest: sha256:6d0e0c26489e33f5a6f0020edface2727db9489744ecc9b4f50c7fa671f23c49 Analysis Status: analyzed Image Type: docker Image ID: 93fd78260bd1495afb484371928661f63e64be306b7ac48e2d13ce9422dfee26 Dockerfile Mode: Guessed Distro: ubuntu Distro Version: 18.04 Size: 32103814 Architecture: amd64 Layer Count: 4 Annotations: requestor=anchore-admission-controller Full Tag: docker.io/ubuntu:latest Also, note that the controller has added an Annotation on the anchore image to indicate that it was analyzed at the request of the admission controller. This is useful for later requests to Anchore itself so you know which images were analyzed by the controller compared to those that may have been added as part of CI/CD. Great! Next, I'll walk through using the policy gating mode. Using Strict Policy-Based Admission In policy gating mode, images must both be analyzed and pass a policy evaluation in order to be admitted. It's important to note that the controller requires that the images already be analyzed prior to the admission request. This is because the analysis can take more than a few seconds and may be more (depending on the wait queue), so admission decisions do not wait on an analysis submission and completion. Configure a Specific Policy It's likely that the same policy used for something like CI/CD is not appropriate for execution gating. Anchore Engine directly supports multiple "policy bundles". In a production environment, you'll probably want to set a custom policy bundle for the admission controller to use. 1. So, let's attach to the ctluser_cli pod again and add a new policy kubectl attach -i -t < ctluser_cli pod> 2. Now, from within the ctluser_cli container shell: Create a file, policy.json with the following content (or create a similar policy in the Enterprise UI if you're an Enterprise customer): { "id": "admissionpolicy", "version": "1_0", "name": "AdmissionControllerDefaultPolicy", "comments": "", "policies": [ { "id": "Default", "version": "1_0", "name": "Default", "comments": "Default policy for doing cve checks", "rules": [ { "id": "cverule1", "gate": "vulnerabilities", "trigger": "package", "params": [ {"name": "package_type", "value": "all"}, {"name": "severity", "value": "low"}, {"name": "severity_comparison", "value": ">="} ], "action": "STOP" } ] } ], "whitelists": [], "mappings": [ { "name": "Default", "registry": "*", "repository": "*", "image": { "type": "tag", "value": "*" }, "policy_ids": ["Default"], "whitelist_ids": [] } ], "whitelisted_images": [], "blacklisted_images": [] } For this example, I'm using a policy for triggering low severity vulnerabilities just to show how the gating works. A more appropriate production severity would be high or critical to avoid blocking too many images. To save the policy: anchore-cli policy add policy.json 3. Update your my_values.yaml to be: anchore: endpoint: "http://demo-anchore-engine-api.default.svc:8228" credentialsSecret: anchore-credentials policybundle: admissionpolicy enableStrictGating: true 4. Remove the webhook config to disable admission request for the upgrade of the controller kubectl delete validatingwebhookconfiguration/demo-anchore-admission-controller.admission.anchore.io There are cleaner ways to upgrade that avoid this, such as using distinct namespaces and namespace selectors, but that is a bit beyond the scope of this post. 5. And upgrade the deployment helm upgrade -f my_values.yaml --force democtl . 6. Ensure the controller pod got updated. I'll delete the pod and let the deployment definition recreate it with the new configmap mounted kubectl delete po -l release=demotctl 7. Re-apply the webhook config kubectl apply -f validate-webhook.yaml 8. To show that it's working, use an image that has not been analyzed yet. kubectl run -i -t ubuntu2 --image ubuntu --restart=Never You will see an error response from Kubernetes that the pod could not be executed due to failing policy. [zhill@localhost anchore-admission-controller]$ kubectl run -i -t ubuntu2 --image ubuntu --restart=Never Error from server: admission webhook "demo-anchore-admission-controller.admission.anchore.io" denied the request: Image ubuntu with digest sha256:acd85db6e4b18aafa7fcde5480872909bd8e6d5fbd4e5e790ecc09acc06a8b78 failed policy checks for policy bundle admissionpolicy Configuring How the Controller Operates The controller is configured via a ConfigMap that is mounted as a file into the container. The helm chart exposes a few values to simplify that configuration process. For a full set of configuration options see the chart, Caveats Currently, there is no Docker Registry credential coordination between k8s and Anchore. For Anchore to be able to pull and analyze images you must configure it to have access to your image registries. Future Work and Feedback Mutating Webhook Support Integration into workflows that leverage existing policy systems like the Open Policy Agent, and/or integrating such an agent directly into this controller to expand its context to enable admission decisions based on combinations of image analysis context and k8s object context. Enhanced policy mapping capabilities Dynamically map which policy bundle to evaluate based on labels and/or annotations Enhanced Audit trail and configurability via CRDs Leverage API extensions to allow uses to query k8s APIs for analysis information without special tooling. We love feedback, so drop us a line on Slack or file issues on GitHub The controller code is on Github and so is the chart. ### Anchore Engine on Azure Kubernetes Service Cluster with Helm This post will walk through deploying an AKS Cluster using the Azure CLI. Once the cluster has been deployed, Anchore Engine will be installed and run via Helm on the cluster. Following the install, I will configure Anchore to authenticate with Azure Container Registry (ACR) and analyze an image. Prerequisites Azure Subscription Azure CLI Helm CLI Anchore CLI Create Azure Resource Group and AKS Cluster In order to create a cluster, a resource group must first be created in Azure. Azure CLI: az group create --name anchoreAKSCluster --location eastus Once the resource group has been created, we can create a cluster. The following command creates a cluster name anchoreAKSCluster with three nodes. Azure CLI: az aks create --resource-group anchoreAKSCluster --name anchoreAKSCluster --node-count 3 --enable-addons monitoring --generate-ssh-keys Once the cluster has been created, use kubectl to manage the cluster. To install it locally use the following command: Azure CLI: az aks install-cli Configure kubectl to connect to the cluster you just created: Azure CLI: az aks get-credentials --resource-group anchoreAKSCluster --name anchoreAKSCluster In order to verify a successfull connection run the following: kubectl get nodes Kubernetes Dashboard To view the Kubernetes Dashboard for your cluster run the following command: Azure CLI: az aks browse --resource-group anchoreAKSCluster --name anchoreAKSCluster Helm Configuration Prior to deploying Helm in an RBAC-enabled cluster, you must create a service account and role binding for the Tiller service. Create a file name helm-rbac.yaml: apiVersion: v1 kind: ServiceAccount metadata: name: tiller namespace: kube-system --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: kube-dashboard rules: - apiGroups: ["*"] resources: ["*"] verbs: ["*"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: tiller roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - kind: ServiceAccount name: tiller namespace: kube-system --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: rook-operator namespace: rook-system roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: kube-dashboard subjects: - kind: ServiceAccount name: kubernetes-dashboard namespace: kube-system Run the following command to create the account and role binding: kubectl apply -f helm-rbac.yaml To deploy Tiller in the AKS cluster run the following command: helm init --service-account tiller Install Anchore We will deploy Anchore Engine via the lastest Helm Chart release. For a detailed description of the chart options view the Github repo. helm install --name anchore-demo stable/anchore-engine Following this, we can use kubectl get deployments to show the deployments. Output: $ kubectl get deployments NAME READY UP-TO-DATE AVAILABLE AGE anchore-demo-anchore-engine-core 1/1 1 1 5m36s anchore-demo-anchore-engine-worker 1/1 1 1 5m36s anchore-demo-postgresql 1/1 1 1 5m36s Expose API port externally: kubectl expose deployment anchore-demo-anchore-engine-core --type=LoadBalancer --name=anchore-engine --port=8228 Output: service/anchore-engine exposed View service and External IP: kubectl get service anchore-engine Output: NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE anchore-engine LoadBalancer 10.0.56.241 40.117.232.147 8228:31027/TCP 12m Assuming you have the Anchore-CLI, you can pass the EXTERNAL-IP to the CLI as the --url parameter. View the status of Anchore: anchore-cli --url http://40.117.232.147:8228/v1 --u admin --p foobar system status Output: Service simplequeue (anchore-demo-anchore-engine-core-6447cb7464-cp295, http://anchore-demo-anchore-engine:8083): up Service analyzer (anchore-demo-anchore-engine-worker-746cf99f7c-rkprd, http://10.244.2.8:8084): up Service kubernetes_webhook (anchore-demo-anchore-engine-core-6447cb7464-cp295, http://anchore-demo-anchore-engine:8338): up Service policy_engine (anchore-demo-anchore-engine-core-6447cb7464-cp295, http://anchore-demo-anchore-engine:8087): up Service catalog (anchore-demo-anchore-engine-core-6447cb7464-cp295, http://anchore-demo-anchore-engine:8082): up Service apiext (anchore-demo-anchore-engine-core-6447cb7464-cp295, http://anchore-demo-anchore-engine:8228): up Engine DB Version: 0.0.7 Engine Code Version: 0.2.4 It is recommended to add the URL, username, and password as environment variables to avoid passing them with every anchore-cli command. View repo for more info. You are now ready to begin analyzing images Creating a Container Registry in Azure First, create a resource group. Azure CLI: az group create --name anchoreContainerRegistryGroup --location eastus Create a container registry. Azure CLI: az acr create --resource-group anchoreContainerRegistryGroup --name anchoreContainerRegistry001 --sku Basic Verify login to create ACR. Azure CLI: az acr login --name anchoreContainerRegistry001 Push Image to ACR In order to push an image to your newly created container registry, you must have an image. I've already pulled an image from my Docker Hub account via the following command: docker pull jvalance/sampledockerfiles:latest Once I have the image locally, it needs to be tagged with the fully qualified name of the ACR login server. This can be obtained via the following command: Azure CLI: az acr list --resource-group anchoreContainerRegistryGroup --query "[].{acrLoginServer:loginServer}" --output table Output: AcrLoginServer -------------------------------------- anchorecontainerregistry001.azurecr.io Run the following command to tag and push image: docker tag jvalance/sampledockerfiles anchorecontainerregistry001.azurecr.io/sampledockerfiles:latest docker push anchorecontainerregistry001.azurecr.io/sampledockerfiles:latest View your pushed image in ACR. Azure CLI: az acr repository list --name anchorecontainerregistry001 --output table Output: Result ----------------- sampledockerfiles Now that we have an image in ACR we can add the created registry to Anchore. Add the Created Registry to Anchore and Begin Analyzing images With the anchore-cli we can easily add the created container registry to Anchore and analyzed the image. --registry-type: docker_v2 Registry: myregistryname.azurecr.io Username: Username of ACR account Password: Password of ACR account To obtain the credentials of the ACR account run the following command: Azure CLI: az acr credential show --name anchorecontainerregistry001 Output: { "passwords": [ { "name": "password", "value": "********" }, { "name": "password2", "value": "********" } ], "username": "anchoreContainerRegistry001" } Run the following command to add the registry to Anchore: anchore-cli registry add --registry-type View the added registry: anchore-cli registry list Output: Registry Type User anchoreContainerRegistry001.azurecr.io docker_v2 anchoreContainerRegistry001 Once with configured the registry we can analyze the image we just pushed to it with the following command: anchore-cli image add anchoreContainerRegistry001.azurecr.io/sampledockerfiles:latest We can view the analyzed image via the image list command: anchore-cli image list Output: Full Tag Image ID Analysis Status anchoreContainerRegistry001.azurecr.io/sampledockerfiles:latest be4e57961e68d275be8600c1d9411e33f58f1c2c025cf3af22e3901368e02fe1 analyzed Conclusion Following these examples, we can see how simple it is to deploy an AKS cluster with a running Anchore Engine service, and additionally, if we are using ACR as a primary container registry, easily set up and configure Anchore to scan any images that reside within the registry. ### Anchore Enterprise 1.2 is Available Today We’re happy today to announce the immediate availability of Anchore Enterprise version 1.2, the latest in our journey to provide users with the ability to enforce container security and best-practices with usable, flexible, cross-organization, and above all time-saving technology and techniques from Anchore. This release is based on the all-new (and also available today) OSS Anchore Engine version 0.3.0. New Features In addition to all of the features available already in Anchore Enterprise, Anchore Enterprise 1.2 adds major new features that have been built in response to direct input from existing Anchore users and customers. As organizations continue to push forward with a reliance on container technology as the foundation for production application deployment, organizational needs in the areas of security, compliance and various types of control integration points have become much more broad in scope. The overarching purpose of many of the new features of Anchore Enterprise 1.2 is to directly address these needs, by introducing capabilities that allow for more sophisticated usage of (and refined access to) the core functions of Anchore container image scanning. The major new features of this release are: New Multi-user Support: updated account/user model and management APIs Role Based Access Control (RBAC): configure users and teams with different access levels within a scope of resources New “Security First” Reports: aggregate reports of vulnerable images given security identifier inputs, with formatted report generation available in the Anchore Enterprise UI New UI Controls and Features: User management, RBAC management, User switching support in the Anchore Enterprise UI Inclusion of vulnerability data from Snyk: accurate, high fidelity and frequently updated language package (NPM, GEM, Java, Python, more to come) software vulnerability detection, to seamlessly improve existing security scanning features with best-in-class vulnerability data With the combination of a full set of account and user management APIs and Role Based Access Controls, Anchore users can now overlay a flexible organizational structure atop Anchore, allowing different development teams, security teams, and ops teams with the right levels of access and resource views within a common deployment of Anchore Enterprise, easily managed and accessible via the included GUI. While Anchore continues to allow users to query and generate security and other reports based on image information, Anchore Enterprise 1.2 includes an all-new ‘Security First’ query set, allowing sec/ops oriented users to instead generate reports based on security information (CVE Vulnerability identifiers, vendor vulnerability identifiers, software package information, etc). Finally, the Anchore Enterprise GUI allows for all Anchore core functionality to be accessed quickly by users with different needs and roles and has capabilities allowing enabled users to access resources across accounts in one place. Technology Refresh In addition to this collection of directly usable features in Anchore Enterprise 1.2, there have also been a number of major technology framework updates that are part of OSS Anchore Engine 0.3.0 and Enterprise 1.2, including: Python 3: port Anchore Engine, Anchore-CLI, and all python-based Anchore Enterprise services to Python 3. CI/CD Integrations: In addition to our native Jenkins plugin, we have added integrations and support for CircleCI and Gitlab Major Helm chart update: with support for both OSS and full Enterprise scaled up deployments. Documentation and Resources: Lots of updated documentation, usage guides, concept overviews and installation/deployment material available on our documentation site. For a full description of new features, improvements and fixes available in Anchore Engine OSS. We would like to sincerely thank all of our open-source users, customers and contributors for all of the spirited discussion, feedback, and code contributions that are all part of this latest release of Anchore Engine OSS! Anchore Enterprise 1.2 Available Now With Anchore Enterprise 1.2, available immediately, our goal has been to include a brand new set of exciting and usable updates for existing Anchore users that can be utilized immediately by upgrading existing deployments of Anchore Enterprise, and also to provide an even more compelling starting point for any organizations looking to quickly and easily add powerful security, compliance and best-practice enforcement capabilities to existing container environments. We sincerely hope you enjoy our latest release, and look forward to working with you! ### Integrating Anchore Scanning with Gitlab This will walk through integrating Anchore scanning into a Gitlab container image build pipeline. During the first step, a Docker image will be built from a Dockerfile. Following this, during the second step Anchore will scan the image, and depending on the result of the policy evaluation, proceed to the final step. During the final step, the built image will be published and reports will be generated. Follow along with this blog post by using the GitLab repo here. This approach differs from previous posts where an Anchore engine service has been accessible from the build pipeline. Prerequisites Gitlab account Dockerfile to build container image Build Image In the first stage of the pipeline, we build a Docker image from a Dockerfile as defined in our .gitlab-ci.yml container_build: stage: build image: docker:stable services: - docker:stable-dind variables: DOCKER_DRIVER: overlay2 script: - docker_login - docker pull "${CI_REGISTRY_IMAGE}:${CI_COMMIT_REF_SLUG}" || true - docker build --cache-from "${CI_REGISTRY_IMAGE}:${CI_COMMIT_REF_SLUG}" -t "$IMAGE_NAME" . - docker push "$IMAGE_NAME" Scan Image with Anchore In the second stage of the pipeline, we scan the built image with Anchore as defined in our .gitlab-ci.yml: container_scan: stage: scan image: name: anchore/anchore-engine:latest entrypoint: [""] services: - name: anchore/engine-db-preload:latest alias: anchore-db variables: GIT_STRATEGY: none ANCHORE_HOST_ID: "localhost" ANCHORE_ENDPOINT_HOSTNAME: "localhost" ANCHORE_CLI_USER: "admin" ANCHORE_CLI_PASS: "foobar" ANCHORE_CLI_SSL_VERIFY: "n" ANCHORE_FAIL_ON_POLICY: "true" ANCHORE_TIMEOUT: 500 script: - | curl -o /tmp/anchore_ci_tools.py https://raw.githubusercontent.com/anchore/ci-tools/master/scripts/anchore_ci_tools.py chmod +x /tmp/anchore_ci_tools.py ln -s /tmp/anchore_ci_tools.py /usr/local/bin/anchore_ci_tools - anchore_ci_tools --setup - anchore-cli registry add "$CI_REGISTRY" gitlab-ci-token "$CI_JOB_TOKEN" --skip-validate - anchore_ci_tools --analyze --report --image "$IMAGE_NAME" --timeout "$ANCHORE_TIMEOUT" - | if ; then anchore-cli evaluate check "$IMAGE_NAME" else set +o pipefail anchore-cli evaluate check "$IMAGE_NAME" | tee /dev/null fi artifacts: name: ${CI_JOB_NAME}-${CI_COMMIT_REF_NAME} paths: - image-*-report.json Publish image In the final stage of the pipeline, we push the Docker image to a registry as defined in the .gitlab.yml: container_publish: stage: publish image: docker:stable services: - docker:stable-dind variables: DOCKER_DRIVER: overlay2 GIT_STRATEGY: none script: - docker_login - docker pull "$IMAGE_NAME" - docker tag "$IMAGE_NAME" "${CI_REGISTRY_IMAGE}:${CI_COMMIT_REF_SLUG}" - docker push "${CI_REGISTRY_IMAGE}:${CI_COMMIT_REF_SLUG}" - | if ; then docker tag "$IMAGE_NAME" "${CI_REGISTRY_IMAGE}:latest" docker push "${CI_REGISTRY_IMAGE}:latest" fi Example It contains a very simple Nodejs application, which is published to a registry as a runnable docker container. After the container is built, it is sent through an Anchore engine scan. anchore/anchore-engine:latest is used as the build container for the scan job. anchore/engine-preload-db:latest is a postgres database, preloaded with the Anchore vulnerability data. This is used as a service in the scan job. The default configuration for Anchore Engine is used on the build container. Scans use the default Anchore policy. Using customized policies will become an option at a future time. A timeout of 500s is used for this project, this value can be adjusted for whatever container is being scanned with the ANCHORE_TIMEOUT environment variable. Some containers take longer to scan than others. To gate the container publish on a successful Anchore Engine scan, set the environment variable ANCHORE_FAIL_ON_POLICY='true'. This will cause the pipeline to fail if a scan fails. Reports Provided by Anchore When Anchore scanning finishes, by default, the following reports are available as artifacts. Report generation is configurable in anchore_ci_tools.py with the --content & --report flags. image-content-os-report.json - all OS packages installed in the image image-content-npm-report.json - all NPM modules installed in the image image-content-gem-report.json - all Ruby gems installed in the image image-content-python-report.json - all Python modules installed in the image image-content-java-report.json - all Java modules installed in the image image-vuln-report.json - all CVE's found in the image image-details-report.json - image metadata utilized by Anchore Engine image-policy-report.json - details of the policy applied to the Anchore scan ### Integrating Anchore Scanning with CircleCI This post will walk through integrating Anchore scanning into a CircleCI pipeline. During the first step, a Docker image will be built from a Dockerfile. Following this, during the second step Anchore will scan the image, and depending on the result of the policy evaluation, proceed to the final step. During the final step, the built image will be pushed to a Docker registry. Prerequisites CircleCI account Anchore Engine Setup Prior to setting up your CircleCI build pipeline, an Anchore Engine service needs to be accessible from the pipeline. Typically this is on port 8228. In this example, I have an Anchore Engine service on AWS EC2 with standard configuration. I also have a Dockerfile in a Github repository that I will build an image from during the first step of the pipeline. In the final step, I will be pushing the built image to an image repository in my personal Dockerhub. The Github repository can be referenced here. Repository contents: .circleci directory (Contains config.yml needed to define CircleCI build) Dockerfile Most typically, we advise on having a staging registry and production registry. Meaning, being able to push and pull images freely from the staging/dev registry while maintaining more control over images being pushed to the production registry. In this example, I am using the same registry for both. I've added the following environment variables via the configuration settings page within Circle: ANCHORE_CLI_PASS ANCHORE_CLI_URL ANCHORE_CLI_USER ANCHORE_FAIL_ON_POLICY ANCHORE_RETRIES ANCHORE_SCAN_IMAGE DOCKER_PASSWORD DOCKER_USERNAME Build Image In the first step of the pipeline, we build a Docker image from a Dockerfile and push it to a registry as defined in our config.yml: build: machine: true steps: - checkout - run: name: Build and push Docker image command: | docker login -u $DOCKER_USERNAME -p $DOCKER_PASSWORD docker build -t $DOCKER_USERNAME/sampledockerfiles:latest . docker push $DOCKER_USERNAME/sampledockerfiles:latest Scan Image with Anchore In the second step of the pipeline, we scan the built image with Anchore as defined in our config.yml: scan: docker: - image: anchore/engine-cli:latest steps: - run: name: Anchore Scan command: | echo "Adding image to Anchore Engine" anchore-cli image add $ANCHORE_SCAN_IMAGE echo "Waiting for image analysis to complete" counter=0 while (! (anchore-cli image get $ANCHORE_SCAN_IMAGE | grep 'Status: analyzed') ) ; do echo -n "." ; sleep 10 ; if ; then echo " Timeout waiting for analysis" ; exit 1 ; fi ; counter=$(($counter+1)) ; done echo "Analysis complete" if ; then anchore-cli evaluate check $ANCHORE_SCAN_IMAGE ; fi Depending on the output of the policy evaluation, the pipeline may or may not fail. In this case, I have set ANCHORE_FAIL_ON_POLICY to true and exposed port 22. This is in violation of a policy rule, so the build will fail during this step. Push Image In the final step of the pipeline, we push the Docker image to a registry as defined in the config.yml: push: machine: true steps: - run: name: Push image to Docker hub command: | docker login -u $DOCKER_USERNAME -p $DOCKER_PASSWORD docker build -t $DOCKER_USERNAME/sampledockerfiles:latest . docker push $DOCKER_USERNAME/sampledockerfiles:latest CircleCI Workflow Putting all the steps together, we define a sequential workflow in our config.yml as follows: workflows: version: 2 build_scan_push: jobs: - build - scan: requires: - build - push: requires: - scan As a reminder, we advise having separate Docker registries for images that are being scanned with Anchore, and images that have passed an Anchore scan. For example, a registry for dev/test images, and a registry to certified, trusted, production-ready images. ### Integrating Anchore Scanning in a Codefresh Pipeline In this template, we will walk through how to configure a Codefresh pipeline to build an image from a Dockerfile, conduct an Anchore scan, evaluate the scanned image against an Anchore policy, and push it to a Docker registry. Codefresh pipelines, are the core component of the Codefresh platform. These pipelines are workflows that contain user-defined steps that are all executed inside a user-chosen Docker container. These steps are defined using a codefresh.yaml file. The Anchore scanning step will take place prior to the image being pushed to a Docker registry. Depending on the output of the policy evaluation and pipeline configuration, the image may not be pushed into the registry. Setup Prior to setting up our Codefresh pipeline, an Anchore Engine service needs to be accessible from the pipeline. Typically this is on port 8228. In this example, I have an Anchore Engine service on AWS EC2 with standard configuration. I also have a Dockerfile in a Github repository that I will build an image from during the first step of the pipeline. In the final step, I will be pushing the built image to an image repository in my personal Dockerhub. Most typically, we advise on having a staging registry and production registry. Meaning, being able to push and pull images freely from the staging/dev registry, while maintaining more control over images being pushed to the production registry. In this example, I am using the same registry for both. In the configuration section of the Codefresh pipeline, I've added the following environment variables: If ANCHORE_FAIL_ON_POLICY is set to true, the pipeline will fail, and the image will not be pushed to the registry. dockerhubUsername dockerhubPassword ANCHORE_CLI_URL ANCHORE_CLI_USER ANCHORE_CLI_PASS ANCHORE_CLI_IMAGE ANCHORE_RETRIES ANCHORE_FAIL_ON_POLICY Build Image In the first step of the pipeline, we build a Docker image from a Dockerfile as defined in our codefresh.yaml: build_image: title: Building Docker Image type: build image_name: jvalance/sampledockerfiles working_directory: ./ dockerfile: Dockerfile Conduct Anchore Scan In the second step of the pipeline, we scan the built image with Anchore as defined in our codefresh.yaml: anchore_scan: title: Scanning Docker Image image: anchore/engine-cli:latest description: Analyzing Image with Anchore... commands: - echo "Adding image to Anchore engine" - anchore-cli image add ${{ANCHORE_SCAN_IMAGE}} - echo "Waiting for image analysis to complete" - counter=0 - while (! (anchore-cli image get ${{ANCHORE_SCAN_IMAGE}} | grep 'Status: analyzed') ) ; do echo -n "." ; sleep 10 ; if ; then echo " Timeout waiting for analysis" ; exit 1 ; fi ; counter=$(($counter+1)) ; done - echo "Analysis complete" - if ; then anchore-cli evaluate check ${{ANCHORE_SCAN_IMAGE}} ; fi Depending on the output of the policy evaluation, the pipeline may or may not fail. In this case, I have set ANCHORE_FAIL_ON_POLICY to true and exposed port 22. This is in violation of a policy rule, so the build will fail during this step. Push Image In the final step of the pipeline, we push the Docker image to a registry as defined in the codefresh.yaml: push_image: title: Push Docker Image description: Pushing Docker Image... type: push candidate: '${{build_image}}' tag: latest registry: docker.io credentials: username: '${{dockerhubUsername}}' password: '${{dockerhubPassword}}' As a reminder, we advise having separate Docker registries for images that are being scanned with Anchore, and images that have passed an Anchore scan. ### Vendorless, Security the Open Source Way Whether you love or hate the term, ‘serverless’ is one of the hottest new trends in the cloud computing world. Despite what the name may suggest, there are certainly still servers running your code, the real innovation here is that you do not need to manage these servers you just publish your code to be run by the serverless infrastructure. This architecture can be better described as FaaS: functions as a service or BaaS: backend as a service. Amazon leads this innovation with its Lambda service and other cloud providers have followed suit, including Google with Google Cloud Functions and Microsoft with Azure Functions. Of course, this innovation is not restricted to proprietary offerings from large vendors, there are a number of open source projects offering serverless frameworks including Kubeless, Nuclio, OpenFaas, OpenWhisk, among many others. A couple of years ago if an organization wanted to adopt the serverless architecture then they would have needed to engage with a vendor such as Amazon however today a growing number of open source projects address that need which leads me to the subject of this blog. One of the most common trends we have seen in the industry is one that is rarely spoken about, in fact, it is so common now that it’s really the norm: Vendorless. To best describe the term let’s walk through the way that most organizations started building their container infrastructure: Linux as the foundation of their infrastructure: Pick your favorite distribution Ansible (or Puppet, Chef, etc) to deploy the infrastructure Docker to run containers Jenkins to run the build pipeline Kubernetes to handle container orchestration Prometheus for monitoring Elasticsearch + Fluentd + Kibana (EFK) for logging and analytics The common theme here is obviously open source. A few years ago, with the exception of Linux, this list would look very different, either build using a monolithic solution form vendors such as IBM and Oracle or comprised of a number of proprietary products. Today the majority of cloud infrastructure deployments are built using open source solutions. Getting started with an open source project such as Jenkins is simple, you can download a container image or packages for most Linux distributions and follow great documentation provided by the upstream project. There are often support forums or online communities using IRC or Slack. To get started you don’t need to call a vendor, sign an NDA, fill out an evaluation request to obtain a time-limited eval key and then be hounded by sales. You can get started without even talking to a vendor. Most of the container projects we have seen today start ‘vendorless’ in this manner. But as deployments move from simple POCs and development environments to production that is often when vendors do get involved, typically the driver is the need for commercial support or to obtain value-added features. In the example we used above of Jenkins, we see many organizations move from Jenkins community edition to Cloudbees Jenkins Enterprise or from upstream Kubernetes to Red Hat OpenShift. So thankfully, speaking as a vendor, there is still a role for vendors, however, they typically get involved a little later in the project lifecycle and have to really earn their seat at the table with added features, certifications and support. While open source solutions have historically provided the core layer of infrastructure, there have been areas in which organizations would need to look at proprietary solutions. The most notable of which is the security which had until recently remained the bastion of commercial vendors. For container infrastructure there are typically two key security needs: Image Security - Analyzing images to ensure they do not contain vulnerabilities and are in compliance with your organization’s operational and security policies. Runtime Security - Real-time monitoring of containers to ensure report on or block malicious activity at the network, system or storage layers. We have spoken at length about the first area: image security and covered how the open source Anchore Engine can quickly and easily be integrated into your CI/CD pipeline, container registries and Kubernetes infrastructure to ensure that only images that meet your organization’s policies are deployed. Over the last decade, it has become clear that open source technologies provide the right foundation for infrastructure and at Anchore we believe that security and analysis tools should be open source so that anyone can inspect the code to validate that the results are fair and accurate. And since security tools typically are granted the highest level of privilege in terms of access and control of resources you need the mantra of “Trust but verify” is especially true. With Anchore Engine we ensure that only the right content, from known sources configured in the right way, is promoted from your CI/CD system and deployed in production but once deployed unknown vulnerabilities or misconfigurations can lead to a container being exploited. The traditional approach to security monitoring involved looking for known signatures is network traffic, files, etc. Similar to the approach taken in the early days of antivirus software where security vendors played an endless game of cat and mouse with virus authors, requiring the antivirus software to be continually updated with new signatures and new viruses were detected in the wild. Over time these solutions evolved to use heuristics in addition to signature mapping. A similar technique is used by the Falco project which takes a more behavioral approach to detection. While there are many different ways that a container could be compromised all of which would need to be explicitly monitored for Falco looks at what is happening once the attacker has compromised the container allowing you to report and then block anomalous behaviors. For example, why would a reverse proxy container need to write a file into the /bin directory, why would a PostgreSQL container make an outbound network connection, why would your Redis server spawn a shell process? With the addition of Anchore Engine and Sysdig Falco you can build an open and secure container infrastructure. ### Introducing Anchore Enterprise 1.1 Today, we’re proud to be announcing the availability of Anchore Enterprise version 1.1. This release of services and software from Anchore will now provide a common framework for users seeking to achieve a secure, compliant container image environment. As container-based deployments are extending further into enterprise infrastructure, our objective has remained the same: provide technology and expertise in the areas of security and operational best-practices enforcement, in order to remove as many barriers as possible toward achieving a fully automated container build process. With Anchore Enterprise 1.1, we have added some major improvements to core Anchore technology, based on the team’s insights as well as feedback from a growing Anchore user community. We believe that both existing and new users of Anchore will find these updates and additions powerful and easy to use. Anchore Engine: OSS for Enterprise At the core of Anchore Enterprise 1.1 is the open-source Anchore Engine. Anchore Engine is a stand-alone service that deploys anywhere that can run a container, providing a broad API for users, clients and CI/CD frameworks alike to request container image content analyses, perform security scans, generate a variety of reports, and execute customizable security and best-practice policy evaluations. Anchore Engine can be used interactively, has been integrated into leading CI/CD frameworks for build-time security enforcement, and provides mechanisms to constantly scan and evaluate policies against your container images as new vulnerabilities are published or your own policy definitions evolve. While the latest Anchore Engine is always freely available as an open-source offering, many enterprise-focused improvements have been introduced since the last Anchore Enterprise release, including: Ability to scale up the Anchore Engine service to accommodate large numbers of image scans, both in aggregate and per unit time Introduction of both OS package (RPMs, Debian Package, Alpine Package) scans as well as Non-OS, language package (Node NPM, Ruby GEM, Python, and Java Archive) content and security scans Refined policy language, including the ability to tune, in fine detail, security checks and image content checks Extended query capabilities, for obtaining deep information about the contents of container images and their build metadata Enterprise storage integrations against AWS S3, Swift, and other S3 compatible storage back-ends Introduction of an event subsystem that provides detail records for information and error level system events, from the engine Availability of Prometheus metrics, for integration into service monitoring systems that can consume Prometheus data sources Many system improvements largely targeted at processing and reporting against very large container image sets, over time. The latest version of Anchore Engine is 0.2.4, which is at the core of Anchore Enterprise 1.1. Anchore Enterprise   New for this release, we’re excited to introduce the Anchore Enterprise UI, which is an on-premises service that provides Anchore users a fully graphical console, accessible via any client browser. The Anchore Enterprise UI console includes: Graphical container image navigation, showing all container registries, repositories, images and image histories in an interface that makes for simple viewing and navigation of the global collection of container images Ability to add new images or entire image repositories via a simple graphical control Complete and deep image overview, including individual controls for reviewing image contents, security scan reports, and policy evaluation results Ability to generate PDF reports for sharing or offline review A graphical changelog application, where users can see at a glance the differences between container images over time, at a fine-grained level of detail An event log viewer, for Anchore operators to see and filter operational events that are being retrieved from the Anchore Engine Container image registry configuration UI, where users can add image public and private registry credentials, supporting Azure, AWS, Google, and any docker v2 on-premises registry A policy manager control, to help manage your set of policies for the different phases of your container environment A graphical policy editor for creating, testing and tuning Anchore security, compliance and best-practice enforcement policies Anchore Enterprise On-prem Services Full Control Over Vulnerability Data & Air-Gapped Operation Anchore Enterprise 1.1 includes access to a fully on-premises Anchore Feed Service, which gives users the ability to control the access and update frequency of external vulnerability data. With the inclusion of this service, users can deploy Anchore Enterprise in an air-gapped (limited/manual access to the Internet) environment, to fully support deployments running with strict data provenance and access requirements. The Anchore Feed Service includes: Ability to enable air-gapped installations of Anchore API that is accessible to Anchore Engine seamlessly, for transferring vulnerability and other external data sources API for monitoring the operation of the Feed Service itself With Anchore Enterprise 1.1, available immediately, we aim to provide organizations who have already deployed a container-based environment, groups in the process of migrating to containers now, and teams planning for the future with a suite of tools and services that provide automated enforcement of security, compliance and best-practice policies, integrated directly in the build process or anywhere container images exist. We sincerely hope you enjoy our latest release, and look forward to working with you! For more information on requesting a trial, or getting started with Anchore Enterprise 1.1, go to anchore.com/enterprise or click the button below: Try our enterprise-ready security and compliance platform today. ### Integrate Anchore Scanning into Jenkins Pipeline This blog highlights one of the ways in which Anchore plugin can be integrated in a Jenkins Pipeline. The example is based on a simple Node application in a Docker container. A Jenkinsfile defines the Pipeline project used for building the Docker image with the application and running tests (this can be the CI process that triggers off of commits to a code repository). This example introduces Anchore scanning as one of the stages in the Jenkinsfile. The Analyze stage uses the Anchore plugin to submit the Docker image to an Anchore Engine installation for analysis. The analysis and resulting policy evaluation determine the overall status of the Jenkins build which in turn may be helpful in the decision making process in subsequent steps (such as promote build for deployment if the build passes or fix the issues and retry if the build fails). All the code used for this example can be found here on GitHub. Let’s get started Before going any further, make sure that you have access to an Anchore Engine installation. Installation If you have a Jenkins instance with Blue Ocean, Pipeline, Docker and Anchore Container Image Scanner plugins installed skip to Setup Pipeline Project. Otherwise, continue reading Install and Configure Jenkins This example runs Jenkins in a Docker container. It employs jenkinsci/blueocean Docker image since the image contains the current LTS release of Jenkins along with most of the required plugins (Blue Ocean, Pipeline and Docker). Docker must be installed on your operating system before you can start using it. For more information about prerequisites and installation options refer to the official docs on Jenkins. $ docker run -u root -d --name jenkins -p 8080:8080 -p 50000:50000 -v /var/run/docker.sock:/var/run/docker.sock -v jenkins-data:/var/jenkins_home jenkinsci/blueocean Follow the steps in https://jenkins.io/doc/book/installing/#setup-wizard to access the Jenkins instance and complete the setup Install Anchore Container Image Scanner Plugin Go to Manage Jenkins->Plugin Manager->available tab, search and select Anchore Container Image Scanner, click Download now and install after restart. Select Restart checkbox to restart Jenkins instance and activate the plugin Setup Pipeline Project This section assumes that you have a Jenkins instance running with Blue Ocean, Pipeline, Docker and Anchore Container Image Scanner plugins installed Login to the Jenkins classic UI and access the Blue Ocean UI by clicking Open Blue Ocean on the left If your Jenkins instance is new or has no Pipeline projects, then Blue Ocean UI displays a Welcome to Jenkins box with a Create a new Pipeline button. Click the button to start the Pipeline project. If the Blue Ocean UI displays a dashboard view with existing Pipeline projects, click the New Pipeline button on the top right corner. Select Git from the list of code repositories and enter “https://github.com/nightfurys/anchore-jenkins-example” for the Repository URL. Credentials are optional. Click Create Pipeline Note: The Pipeline project can also be configured to scan and poll a GitHub repository for commits. For instructions, refer to Jenkins. This should start up a new job that immediately transitions to a paused state The Pipeline pauses and waits for interactive input, click anywhere on the paused row to navigate to the Configure stage of the Pipeline To provide the configuration, click Resolve Input and enter the requested input. Enter the details for the Docker registry and repository of your choice for staging the images. Create the credentials to the Docker registry and Anchore Engine. Click Proceed The Blue Ocean UI displays stages that have completed and the current stage in progress. While waiting on analysis to complete, you can click the dropdown button adjacent to the step to expand details In this example, the Analyze stage uses Anchore plugin for scanning the Docker container image. At the time of analyzing this Docker image, Anchore Engine issued a policy evaluation report with a “fail” end result due to the policy in play (which contains a rule that triggers upon finding high severity CVEs in the Docker container image). As a result, Anchore plugin fails the Jenkins build indicated by the Blue Ocean interface turning red Follow Up Policy bundles must be created/managed in Anchore Engine, independent of Jenkins. Anchore plugin is configurable and allows the user to supply a Policy Bundle ID to be used by Anchore Engine on policy evaluations. The plugin can also be configured to not fail the Jenkins build on policy evaluation failure if necessary. Pipeline Syntax/Snippet Generator tool is a good way to explore plugin options and tune them according to your requirements Anchore plugin generates reports that are accessible only from the classic Jenkins UI. Exit the Blue Ocean view by clicking the Go to classic icon at the top right corner Navigate to the build page in the classic UI and look for the Anchore Report icon. Clicking the link should display the Anchore report with Policy and Security tabs Policy Evaluation Summary and Report Vulnerabilities List Conclusion You’ve just used Anchore Container Image Scanner plugin in a stage defined in the Jenkinsfile. The Pipeline project defined by this Jenkinsfile builds the Docker image with the application and scans the image using Anchore plugin Jenkinsfile for this Pipeline project along with the Node application is on GitHub. You can try out this example as it is without forking the repository. If you are interested in tailoring this example to your use cases such as replace the Node application with your own, use predefined configuration instead of interactive input or other customizations, fork the repository and edit the Jenkinsfile and other application code Add security and compliance to your CICD container pipeline in minutes with the Anchore Plugin for Jenkins ### Updates to the Anchore Plugin for Jenkins An update to the Anchore Container Scanner Plugin is now available through the Jenkins Plugin Manager. Version 1.0.16 adds to the existing configurability and allows the plugin to exercise a broader set of functionality offered by Anchore Engine. This version of the plugin was developed and tested against Anchore Engine version 0.2.3.   Anchore Container Scanner Plugin Version 1.0.16 New configuration to specify policy bundle ID for image evaluation. The policy bundle must exist on Anchore Engine in advance of the plugin usage. If left blank, Anchore Engine will use the default bundle for policy evaluation New configuration to specify annotations on images submitted to Anchore Engine for analysis Project level overrides for the plugin’s global settings. The plugin can be configured to use a different Anchore Engine URL, credentials or SSL verification in a given Jenkins project without impacting the global settings or other projects Raw vulnerability report in addition to previously existing policy evaluation report post-completion In addition to the new features, this update has a few improvements to the plugin operation Enable/disable toggle in global settings has been deprecated. Anchore Container Scanner plugin is enabled by default Improved logging reduces the verbosity of the logs in the default INFO level and makes it easier to follow the progress of the plugin operations These updates are intended to improve the pipeline scripting usage of the plugin significantly and to keep the plugin up-to-date with the latest Anchore Engine functionality. Add security and compliance to your CICD container pipeline in minutes with the Anchore Plugin for Jenkins ### Container Security & Compliance Scanning For Codeship This will walk through integrating Anchore scanning into a Codeship pipeline. During the first step, a Docker image will be built from a Dockerfile. Following this, during the second step Anchore will scan the image, and depending on the result of the policy evaluation, proceed to the final step. During the final step, the built image will be pushed to a Docker registry. Prerequisites Docker Installed Jet CLI Codeship Pro Account Github Account Anchore Engine Setup Prior to setting up your Codeship build pipeline, an Anchore Engine service needs to be accessible from the pipeline. Typically this is on port 8228. In this example, I have an Anchore Engine service on AWS EC2 with standard configuration. I also have a Dockerfile in a Github repository that I will build an image from during the first step of the pipeline. In the final step, I will be pushing the built image to an image repository in my personal Dockerhub. The Github repository can be referenced here. Repository contents: codeship-services.yml (Contains all services needed to run your CI/CD builds) codeship-steps.yml (Contains all the steps for your CI/CD process) Dockerfile dockercfg.encrypted (Docker registry credentials) env.encrypted (Environment variables) For more info on using encrypted files with Jet CLI visit here. Most typically, we advise on having a staging registry and production registry. Meaning, being able to push and pull images freely from the staging/dev registry while maintaining more control over images being pushed to the production registry. In this example, I am using the same registry for both. I've added the following environment variables via the envfile: If ANCHORE_FAIL_ON_POLICY is set to true, the pipeline will fail, and the image will not be pushed to the registry. ANCHORE_CLI_URL ANCHORE_CLI_USER ANCHORE_CLI_PASS ANCHORE_CLI_IMAGE ANCHORE_RETRIES ANCHORE_FAIL_ON_POLICY The Docker registry has been configured with the dockercfg file: { "auths": { "https://index.docker.io/v1/": { "auth": "anZhbGFuY2U6MjI2MTM3QGtLaw==" } }, "HttpHeaders": { "User-Agent": "Docker-Client/17.10.0-ce (linux)" } } Build Image In the first step of the pipeline, we build a Docker image from a Dockerfile as defined in our codeship-steps.yml: - name: imagebuildstep service: imagebuild type: push image_name: jvalance/sampledockerfiles encrypted_dockercfg_path: dockercfg.encrypted and our codeship-services.yml: imagebuild: build: dockerfile: Dockerfile cached: true Conduct Anchore Scan In the second step of the pipeline, we scan the built image with Anchore as defined in our codeship-steps.yml: - name: anchorestep service: anchorescan command: sh -c 'echo "Adding image to Anchore engine" && anchore-cli image add $ANCHORE_IMAGE_SCAN && echo "Waiting for image analysis to complete" && counter=0 && while (! (anchore-cli image get $ANCHORE_IMAGE_SCAN | grep 'Status: analyzed') ) ; do echo -n "." ; sleep 10 ; if ; then echo " Timeout waiting for analysis" ; exit 1 ; fi ; counter=$(($counter+1)) ; done && echo "Analysis complete" && if ; then anchore-cli evaluate check $ANCHORE_IMAGE_SCAN ; fi' encrypted_env_file: env.encrypted and our codeship-services.yml: anchorescan: image: anchore/engine-cli:latest encrypted_env_file: env.encrypted Depending on the output of the policy evaluation, the pipeline may or may not fail. In this case, I have set ANCHORE_FAIL_ON_POLICY to true and exposed port 22. This is in violation of a policy rule, so the build will fail during this step. Push Image In the final step of the pipeline, we push the Docker image to a registry as defined in the codeship-steps.yml: - name: imagepushstep service: imagebuild type: push image_name: jvalance/sampledockerfiles encrypted_dockercfg_path: dockercfg.encrypted and our codeship-services.yml: anchorescan: image: anchore/engine-cli:latest encrypted_env_file: env.encrypted As a reminder, we advise having separate Docker registries for images that are being scanned with Anchore, and images that have passed an Anchore scan. For example, a registry for dev/test images, and a registry to certified, trusted, production-ready images. ### Anchore & Falco, End-to-End OSS Container Security Solution While open source solutions have historically provided the core layer of infrastructure, there have been areas in which organizations would need to look at proprietary solutions. The most notable of which is a security that had until recently remained the bastion of commercial vendors. For container infrastructure there are typically two key security needs: 1. Image Security Analyzing images to ensure they do not contain vulnerabilities and are in compliance with your organization’s operational and security policies. 2. Runtime Security Real-time monitoring of containers to ensure report on or block malicious activity at the network, system or storage layers. We have spoken at length about the first area: image security and covered how the open source Anchore Engine can quickly and easily be integrated into your CI/CD pipeline, container registries and Kubernetes infrastructure to ensure that only images that meet your organization’s policies are deployed. In this blog, we will introduce you to another open source project, Falco, from the team at Sysdig. Like Anchore Engine, Falco is open source, making it easy for organizations to download and run Falco in their environment and like Anchore there is company behind Falco that provides a commercial offering with centralized management, added features and integration. Over the last decade, it has become clear that open source technologies provide the right foundation for infrastructure and at Anchore we believe that security and analysis tools should be open source so that anyone can inspect the code to validate that the results are fair and accurate. And since security tools typically are granted the highest level of privilege in terms of access and control of resources you need the mantra of “Trust but verify” is especially true. With Anchore Engine, we ensure that only the right content, from known sources configured in the right way, is promoted from your CI/CD system and deployed in production but once deployed unknown vulnerabilities or misconfigurations can lead to a container being exploited. The traditional approach to security monitoring involved looking for known signatures is network traffic, files, etc. Similar to the approach taken in the early days of antivirus software where security vendors played an endless game of cat and mouse with virus authors, requiring the antivirus software to be continually updated with new signatures and new viruses were detected in the wild. Over time these solutions evolved to use heuristics in addition to signature mapping. A similar technique is used by the Falco project which takes a more behavioral approach to detection. While there are many different ways that a container could be compromised all of which would need to be explicitly monitored for Falco looks at what is happening once the attacker has compromised the container allowing you to report and then block anomalous behaviors. For example, why would a reverse proxy container need to write a file into the /bin directory, why would a PostgreSQL container make an outbound network connection, why would your Redis server spawn a shell process? Falco taps into host kernel for syscall monitoring using either a kernel module or a new approach using extended Berkley Packaged Filters (eBPF) which is available in modern kernels (see an excellent introduction to eBFG in LWN). This approach maximizes visibility into the system while minimizing overhead. Rules can be created that can monitor any activity including network access, file I/O and even interprocess communication (IPC). The Falco Wiki contains some great examples that illustrate the power of this level of integration, for example alerting when a process attempts to write into a directory containing system binaries, they even created default runtime security rules for the most popular Docker images. With the addition of Anchore Engine and Sysdig Falco you can build an open and secure container infrastructure. ### How Often are Docker Images Updated - Revisited Refreshing the Data Almost a year ago we looked at the frequency with which some of the most popular images in the Docker registry are updated and compared the frequency of base image (alpine, debian, etc) updates with that of popular non-OS images. We found that while updates to base images came in around once a month, non-OS images updated much more frequently - up to eight to ten updates in the case of the widely used node:latest and php:latest packages. We learned that while all official images should follow DockerHub best practices and should, therefore, be well maintained it is clear from our historic data that many images can be updated infrequently and carry security vulnerability for many weeks. Understanding these gaps in the update is crucial to a comprehensive and container and application security policy, so we decided it was time to take a second look. Using Anchore Cloud (anchore.io) makes it easy to check the update history of each image: This lets us easily see the image creation date as well as the date of the most recent Anchore analysis. The Anchore service continually polls DockerHub and when an update to a repository has detected the list of tags and images are retrieved and any new images are downloaded and analyzed. In addition, Anchore scans images on a regular cadence to ensure that the results of each scan include the latest CVEs and other known vulnerabilities. We went ahead and pulled the data from the last 18 months for the library/debian:latest images from the database: Our last analysis was in September of 2017 you can see that since then updates have become more infrequent. We observed in September that while a monthly cadence can seem ideal, what really matters is the timeliness of updates, particularly updates that fix new critical vulnerabilities. With updates coming less frequently (as seen above) this image becomes less likely to have rapidly addressed any issues that may have arisen. Users of these base images need to be proactive about their own image fixes during these periods to avoid exposure. Tools like Anchore.io allow users of images to subscribe to the results of each Anchore CVE analysis, an analysis that is conducted regularly in-between image updates and well as immediately after updates occur. Update Frequency - Most Popular Images Let’s look at the relative update frequency across popular base images: We see a similar pattern across the major operating system repositories. None have a fixed update schedule, and while some such as Ubuntu and Oracle Linux are consistent, repositories like Fedora and Alpine can go up to four months without an update! As we pointed out in our previous post on this topic, these gaps do not immediately imply vulnerabilities. Lightweight operating systems like Alpine and BusyBox require less maintenance due to the relatively small number of packages and therefore potential vulnerabilities. However, if an image hasn’t been updated it is always worth analyzing and confirming the image you are using for production applications is still protected. An encouraging pattern to look for is present in the Ubuntu and Oracle Linux update timings as well. In addition to the semi-regular monthly updates, updates are pushed at seemingly random times throughout the month. These updates each represent opportunities for the various teams to address new security concerns in a timely fashion. Anchore’s regular post-update scans serve to confirm this to be the case. Moving on to some popular non-OS images we see a much greater update frequency. The increased complexity in the images necessitates these shortened update cycles and ideally, there is also an update that follows soon after the underlying base image is updated. This is not always the case our analysis shows that some applications are not rebuilt for several weeks or are rebuilt on top of an older base image. Our assessment from September holds true today. While all official images should follow DockerHub best practices and be well maintained many images can be updated infrequently and carry security vulnerabilities for many weeks. The timing of an image update can be an indicator of the health of the image, but the content of an image is even more important. Check out the Anchore Cloud to explore image contents, update timelines, and vulnerabilities as well as subscribe to the analysis of the images you use every day. If you'd like to do this scanning on-prem, check out the open source anchore-engine. For a great follow-up and to help understand the best course of action to take when it comes to determining how often you update the images your applications rely on, check out Just because they pushed doesn’t mean you need to pull. ### The Real Difference Between CI & CD? Confidence As an industry when we talk about DevOps we tend to lump together the terms CI and CD as if they are exactly the same thing. Looking back on our blogs and collateral, we are certainly guilty of that, but there are a number of differences between CI and CD and the implications of these differences are significant, so in this blog, we wanted to set the record straight and discuss the differences and talk about an interesting new project that promises to simplify CI and CD for Kubernetes environments. There are three terms that we will cover: Continuous Integration Continuous Delivery Continuous Deployment While each of these practices shares common practices but differs in terms of scope - how far they go in terms of automation and release. Continuous Integration (CI) Over recent years continuous Integration has become the norm for engineering teams, where every merge to a source control repository such as git triggers and automatic build of the application which then passes through automated testing. If the build fails or if the automated testing shows regressions the commit does not get accepted into the master branch. This methodology improves the overall quality of a product by finding problems early in the cycle. For CI to work you need extensive and robust automated testing, the successful compilation is not enough,  your application needs to be run through an extensive set of automated tests to ensure that each small, incremental change does not break existing functionality. This model requires more upfront work in writing tests alongside your code, often writing tests before code is implemented but this investment pays off in terms of quality, velocity and resources as the need for long manual QA cycles is drastically reduced. Automated testing should be quick so a developer can address issues rapidly and then get to work on the next test, bugfix or feature. In most of our users’ deployments we see the Anchore scan happening after a container is built and before automated testing. This allows any security and compliance issues to be flagged before automated testing to save time and resources - there is no point testing an application that will be failed due to security and compliance issues later. Some users run Anchore after automated testing as they argue that there’s no point running a security and compliance test on broken code. Anchore is flexible to be run in either model, we would recommend that you run the shortest tests first, whether that is Anchore or your automated test suite. Continuous Delivery (CD) Continuous Delivery builds on top of the CI process. There is no deliverable produced as part of the CI process, the result of CI is a well-tested codebase in your source control system. CD goes a step further by automating the next steps in the release process by taking all the steps necessary to prepare for a deployment such as building and packaging the application. While no code is deployed to production all the steps necessary have been performed and so the software can be released or deployed as required however the next step, the actual deployment, is manual. When running with a CD model there is no need to deploy every build, you make the business decision when you release or promote your software. The beauty of this model is that you can deploy at any time. Continuous Deployment Continuous Deployment goes one step further: every commit to the source code repository for a given project is built, tested, packaged and deployed into production automatically. There are no manual steps, no final approval. If the software passes all testing then it is deployed. While the move step from continuous delivery to continuous deployment may only involve a single click there is are huge organizational implications not least of which is the need for robust operational, monitoring and support practices. For this reason, most organizations stop at continuous delivery until they have the confidence in their infrastructure, testing and procedures. Jenkins X The name Jenkins is synonymous with CI/CD and in survey after survey we see their continued domination of the space. But the industry is changing rapidly with cloud deployments being the norm, organizations now deploying microservices, implementing DevOps practices and generally moving to a ‘cloud native’ philosophy. It’s fair to say that even with recent updates Jenkins is showing its age (or perhaps it’s maturity). Recently the Jenkins community announced Jenkins X which represents the next generation of Jenkins which focuses on the cloud, more specifically on Kubernetes with built-in DevOps best practices, extensive automation and tooling. Over the years we have become used to building Dockerfiles, Jenkins files and now Helm charts and then piecing together tools to automate builds and deployment. The goal of Jenkins X is to automate this work and let developers concentrate on building applications and not infrastructure.  You can read more about Jenkins X in their project announcement blog. This week the Jenkins X team announced the release of their add-on for the Anchore Engine. With a single command: jx create addon anchore Anchore scanning is automatically added to your Jenkins X pipelines allowing every image built to be scanned for security vulnerabilities. You can now simply call jx get cve to produce a security vulnerability report showing the vulnerabilities in your environments. This is just the first step in integrating security and compliance more deeply into Jenkins X, there are a number of interesting possibilities that are opened up by integrating two open source projects: Policy-based scanning: Looking at more than just CVEs - adding support for policy checks that can include checks for secrets (keys, passwords), required packages, blacklisted packages, dockerfile best practices, etc. Automating remediation Once Anchore has scanned an image it can continually track the policy and security status of the image. For example, if a new vulnerability has been discovered in an application that has already been built and deployed in your Kubernetes infrastructure. Anchore can send a webhook to notify Jenkins X that a vulnerability has been discovered and that a fix has been published by the operating system or library vendor. What if Jenkins X then automatically triggered a rebuild and test cycle to remediate this issue? We’re excited to work with the Jenkins X team and encourage you to check out Jenkins X and the Anchore integration.  But you don’t need to be running Jenkins X to take advantage of Anchore’s security and compliance scanning, you can add Anchore to your existing Jenkins projects today whether you are using freestyle or pipeline syntax using our free Jenkins plugin. ### Why CVE Scanning Still Isn't Enough On Thursday the Node Package Manager team removed a node package from the NPMJS.org registry. You can read more about the discovery in this bleepingcomputer article or on the incident reported on the npm blog. This package was found to have a malicious payload which provided a framework for a remote attacker to execute arbitrary code. While the module was removed from the NPM registry you may already have this module in your environment. We saw something very similar last year and blogged about adding an Anchore policy to blacklist this node module to block it. You can follow the same steps to block the getcookies module today. This will stop future deployments of images with this vulnerability and allow you to scan previously created images to ensure they do not contain this malicious content. As of today, there is no CVE published for this vulnerability in the NIST National Vulnerability Database (NVD) and since this module was not packaged by operating distributions such as Red Hat and Debian it will not appear in their custom vulnerability feeds but this can still simply be added to a custom policy check-in Anchore Cloud or Anchore Engine. Two weeks ago we blogged about adding scanning to your container infrastructure even if you were not yet ready to consider policy checks or some form of gating in your CI/CD infrastructure. This incident provides a great example of why scanning your environment now will pay off later. ### The Container Chronicle Volume 2 When we launched the Container Chronicle newsletter we planned on making this a monthly newsletter to make sure there was enough content to make it a worthwhile read while not making it too long. Well, two weeks later there was so much interesting news even before we covered the KubeCon announcements that we decided to release early. New Month, New Releases! Red Hat announced the release of Red Hat Enterprise Linux 7.5 which includes a number of container-related improvements including a move to fully support OverlayFS, which becomes the default storage driver for containers, replacing device-mapper. Buildah is now fully supported allowing you to build Docker and OCI compliant container images without the need for any a container runtime and more significantly without any Docker tools. If you are wondering how buildah should be pronounced then you really need to hear it from Red Hat’s Dan Walsh. Two of the most popular Linux distributions for developers announced major releases: Fedora 28 and Ubuntu 18.04 (Bionic Beaver) which is the latest long term support release from Canonical. Microsoft announced the general availability of Azure Container Instances (ACI) which were initially previewed in the summer of 2017, allowing users to run containers directly without worrying about the underlying host OS or creating and managing clusters. Netflix open sourced its Titus container management platform which is built on top of Apache Mesos. While Titus is designed to be a challenger to Kubernetes in the mainstream market opening up the codebase allows the wider community to benefit from the extensive operational experience that Netflix has codified in Titus. Digital Ocean announced an early access program for their managed Kubernetes service The Rancher team announced the release of Rancher 2.0 which includes the Rancher Kubernetes Engine (RKE) in addition to a unified cluster management system for managing RKE, Google Kubernetes Engine, Azure Container Service and Amazon EKS from a single interface. News from KubeCon EMEA Over 4,300 developers and operators attend KubeCon in Copenhagen and there were a number of exciting announcements including: Red Hat Operator Framework The CoreOS team at Red Hat announced the release of the Operator Framework based on the operator's concept they introduced in 2016. The Framework provides a toolkit and services to help manage and deploy Kubernetes applications at scale. Google had a Number of Announcements  gVisor a new container runtime designed to provide more isolation than containers but with less overhead than a virtual machine. Unlike The Kata Containers project (previously Intel Clear Containers) which relies on a lightweight virtualization approach, gVisor provides a userspace kernel implementation that exposes most Linux syscalls to the container. The beta release of Stackdriver a Kubernetes monitoring solution that integrates metrics from native Kubernetes sources including metrics, events and logs as well as from Prometheus instrumentation. Buoyant announced the 1.0 release of the Lingerd service mesh Bitnami announced the 1.0 release of Kubeless, their Kubernetes-native serverless framework in addition to the 1.0 release of Kubeapps which provides a simple way to launch and manager Kubernetes applications using Helm. Tip: Head over to the Kubeapps public hub to find a simple way to install Anchore Engine. ### Driving Open Source Container Security Forward A little over seven months ago we announced the open source Anchore Engine project and since then we have seen hundreds of organizations deploy Anchore Engine to add security and compliance to their container environments. Most organizations build their container infrastructure with open source solutions: Linux for the container host Docker for container runtime Jenkins for CI/CD Kubernetes for orchestration Prometheus for monitoring When Anchore was formed there was an obvious gap in terms of open source container security and our goal was to fill that gap with the best in breed container scanning solution that added not just reporting but policy-based compliance. At the same time, we were working on Anchore CoreOS released the Clair project which provided an open source vulnerability scanner. We are big fans of the work CoreOS has done in the container community so we looked into that project but saw a number of gaps: firstly its focus was reporting on operating system CVEs (vulnerabilities). While CVE scanning is an important first step it is just the tip of the iceberg, container security and compliance tool should be looking at policies that cover licensing, secrets, configuration, etc. The second challenge we saw was that Clair was focused more on the registry use case which given the Clair use in the CoreOS Quay registry made perfect sense. So we built a series of tools to address container scanning and compliance from the ground up. Since then we have been glad to see more open source container security solutions come to market such as Sysdig’s Falco runtime security project. In building the Anchore Engine our philosophy has been to keep the core engine open source and feature-complete while providing value-added services on top of the engine - for example, a user interface in addition to the AP and CLI, added enterprise integrations. A user should be able to secure their CI/CD pipeline with our open source engine without requiring a commercial product and without sharing their container and vulnerability data with third parties - everything should work on-premises for free. Of course, we are happy to sell you an enterprise offering on top of the open source solution and if you are ever not satisfied with our enterprise offering you should be able to remove the added services and roll back to the fully functional open source engine. Roughly every month we have released an update to the open source project and this week we are proud to announce the 0.2.0 release that adds a number of interesting new features including Prometheus integration, improved Debian vulnerability reporting and a number of scalability related enhancements to allow our users to scale to handle thousands of builds a day. Prometheus Integration Prometheus is an open source event monitoring system with a time series database inspired by Google’s internal monitoring tools (Borgmon). Prometheus has rapidly become the de facto standard for monitoring and metrics in cloud-native environments. Anchore Engine 0.2.0 adds support for exposing metrics for consumption by Prometheus allowing collection of metrics, reporting and monitoring of Anchore Engine. Improved Debian CVE reporting The Anchore Engine and the Anchore Feed service have been extended to track the Debian specific no-DSA flag that indicates that while the package version is vulnerable to a given CVE the Debian build of this package, either because of build options or environment is not vulnerable. In previous versions of the Anchore Engine whitelists were used to filter these records from policy output, with Anchore Engine 0.2.0 these CVEs will not be shown on the default CVE report nor within the policy output. Scalability Improvements Anchore Engine 0.2.0 includes a number of features to simplify scale-out deployments of Anchore Engine on Kubernetes, Amazon ECS and other large scale environments. Many features have been added to allow Anchore Engine to support thousands of builds a day and hundreds of thousands of images stored within the Anchore database Support for running multiple core services (catalog, API, queue and policy engine). Previous releases had supported the scale-out of analyzer workers only. Support for storing analysis and other data in external storage systems such as Amazon S3, Swift and clustered file systems in addition to the native database support. You can read more about the changes in the online documentation or in the changelog on GitHub. We are currently working on a number of exciting new features for delivery over the next couple of months including: Support for matching NVD vulnerabilities in software libraries including Java, Python, Ruby and Node.JS. Support for scanning nest Java archives. eg. Java JAR files stored in WAR files stored in EAR files. Layer reporting - exposing image layer data in the Anchore CLI and API Layer based policies - allowing policies such as “only allow images built on selected based images." ### No Excuses, Start Scanning One of the most popular features of the Anchore Cloud service is the ability to deep dive into any container image to inspect its contents to see what files, packages and software libraries make up an image. Before I import any public image into my development environment I check out the list of security vulnerabilities in the image, if any, the policy status (does it fail basic compliance checks) and then I dig into the contents tab to see what operating system packages and libraries are in the image. I am still surprised at just how large many images are. This content view allows you to dig into every artifact in the image - what operating system packages, what Node.JS NPM modules including details such as their license and versions as well as how they got pulled in - for example, multiple copies of the same module being pulled in as dependencies of other modules. While this level of inspection is useful before you pull in a new public Docker image this level of detail is even more useful when applied to your own internal images. When most people talk about container security and compliance the focus is on security vulnerabilities: “Do I have any critical or high vulnerabilities in my image." As we have covered previously CVEs are just the tip of the iceberg and that organizations should be looking at policies that cover licensing, secrets, configuration, etc. Many organizations that we talk to see the value in policy-based compliance and are planning to implement container scanning as part of their CI/CD workflows but are not ready to make the investment required to add checkpoints and gates within their build or deployment infrastructure. When the Equifax news broke about their massive breach caused by an unpatched Apache Struts vulnerability I think that every CIO in every organization was on the phone with their operations team and developers to ask if they had a vulnerable version of Apache Struts. While it’s simple to find out what version of a library you are running today on your servers, do you know what was run on your production cluster last week, last month, last year? Even if you do not have the time or resources to invest in securing your CI/CD pipeline today with policies, reports and compliance checks it will take less than 10 minutes to download Anchore’s open source Engine, point it to your container registry and start it scanning. The Anchore Engine will discover new tags and images deployed to your repos, download and analyze them and maintain a history of tags and images over time. When you are ready to start putting in place policies, vulnerabilities, or gate deployments based on compliance checks you already have data at hand to help you track trends, compare images and run reports on changes over time. We find many organizations just using this data to produce detailed build summaries or changelogs. Get started today, for free, either with Anchore’s cloud service or download and run the open source Anchore Engine on-premises today. ### Welcome to the Container Chronicle Things change rapidly in the fast fluid world of Containers, sometimes it’s hard to keep up. So we’re starting a new newsletter called The Container Chronicle to help you stay on top of everything newsworthy from Cloud to Kubernetes, Docker to DevOps, and Beyond. We will periodically be sending out The Container Chronicle, with the first edition shipping out this morning but in case you aren't subscribed yet we've included it below so you don't miss out. If you'd like to subscribe and stay on top of important industry news fill out the form at the bottom of the page and we will make sure it hits your inbox! March ended on a high with the release of Kubernetes 1.10 but April is already shaping up to be a busy month in the world of containers and we are only halfway through. Docker + Java 10 = ❤️ The month began with the general availability of Java 10 which includes a number of interesting new features, the most significant of which to container users is the ability of the Java runtime to recognize memory and CPU constraints applied to the container using cgroups. Previous versions of the Java runtime were not aware of resource constraints applied to the container in which it was running, requiring manual configuration of JVM parameters. With Java 10, memory and CPU limits are automatically detected and accounted for by the JVM’s resource management. The folks at Docker produced a great blog covering the details: Improved Docker Container Integration with Java 10 OCI Locks in a Distribution Specification The Open Container Initiative announced a new project to standardize the container distribution specification. The Docker Registry API specification is already the de-facto standard for distributing container images. Any time you push or pull an image, your Docker (or compatible) client is using the Docker registry API to interact with the registry. All the major registry providers already support this API but the specification was controlled by a single vendor. While Docker has proven to be a good citizen in the open source community having a single vendor dictate standards is not conducive to cross-vendor collaboration. As happened previously with the image and runtime specification Docker has now donated the specification to the Open Container Initiative (OCI) which has adopted the standard and will continue to drive it forward. The OCI includes industry leaders such as Amazon, Docker, Google, IBM, Microsoft and Red Hat. You can read more about the announcement at The New Stack. Canary in the Kayenta Google and Netflix announced the Kayenta project which was jointly developed by the two companies and now licensed as an Apache 2 project under the umbrella of the Spinnaker continuous delivery platform. Kayenta is an automated canary analysis tool. The idea behind canary analysis is that you push a new release of a service or program to a small number of users. Since only a few users get the new release any problems are limited to a small subset of users and can easily be rolled back. If the release proves successful the test audience can be expanded. Unlike the original canary in a coal mine no animals are actually harmed during these test deployments. You can read more about Kayenta on Google’s blog or on ZDNet. Docker Embraces Kubernetes in Docker EE   Yesterday Docker announced the release of Docker Enterprise Edition 2.0 which includes support for both Docker’s own Swarm orchestration system but also adds support for Kubernetes. Docker Inc are not alone in shifting focus away from their own orchestration platform to Kubernetes, only a few short weeks ago we saw Mesosphere announce Kubernetes-as-a-service integrated with their DC/OS offering. While Kubernetes clearly won the short-lived orchestration war, the real beneficiaries are the end-users who now can standardize on a single platform that can be deployed on public clouds, on-premises or even on a stack of Raspberry Pis. This standardization helps to drive a rich ecosystem of vendors to provide value-added solutions that can now focus on a single, open source platform. Thanks for hanging with us in this first edition of The Container Chronicle. You'll see us again soon (but not too soon) so keep an eye out for our next newsletter. ### How to integrate Kubernetes with Anchore Engine By integrating Anchore and Kubernetes you can ensure that only trusted and secure images are deployed and run in your Kubernetes environment Overview Anchore provides the ability to inspect, query, and apply policies to container images prior to deployment in your private container registry, ensuring that only images that meet your organization’s policies are deployed in your Kubernetes environment. Anchore can be integrated with Kubernetes using admission controllers to ensure that images are validated before being launched. This ensures that images that fall out of compliance, for example, due to new security vulnerabilities discovered, can be blocked from running within your environment. Anchore can be deployed standalone or as a service running within your Kubernetes environment. Getting Started with Integration How to Integrate Anchore and Kubernetes We have recently packaged the Anchore Engine as a Helm Chart to simplify deployment on Kubernetes. Now Anchore can be installed in a highly scalable environment with a single command. Within 3 minutes you can have an Anchore Engine installed and running in your Kubernetes environment. The following guide requires: A running Kubernetes Cluster kubectl configured to access your Kubernetes cluster Helm binary installed and available in your path Tiller, the server side component of Helm, should be installed in your Kubernetes cluster. To installer Tiller run the following command: $ helm init $HELM_HOME has been configured at /home/username/.helm Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster. ⎈ Happy Helming! ⎈ If Tiller has already been installed you will receive a warning messaging that can safely be ignored. Next we need to ensure that we have an up to date list of Helm Charts. $ helm repo update Hang tight while we grab the latest from your chart repositories... ...Skip local chart repository ...Successfully got an update from the "stable" chart repository Update Complete. ⎈ Happy Helming!⎈ By default, the Anchore Engine chart will deploy an Anchore Engine container along with a PostgreSQL database container however this behavior can be overridden if you have an existing PostgreSQL service available. In addition to the database the chart creates two deployments Cores Services: The core services deployment includes the external api, notification service, kubernetes webhook, catalog and queuing service. Worker: The worker service runs the image analysis and can be scaled up to handle concurrent evaluation of images. In this example we will deploy the database, core services and a single worker. Please refer to the documentation for more sophisticated deployments including scaling worker nodes. The installation can be completed with a single command: $ helm install --name anchore-demo stable/anchore-engine Read the Documentation Read the documentation on Anchore integration with Jenkins and get started with the integration. ### Jenkins + Anchore Anchore has been designed to plug seamlessly into your container-based CI/CD pipeline to add analytics, compliance and governance to your workflow. Overview Using Anchore’s freely available and open source Jenkins plugin you can secure your Jenkins CI/CD pipeline in less than 30 minutes. By adding image scanning, including not just CVE based security scans but policy-based scans that can include checks around security, compliance and operational best practices, you can ensure only trusted vetted container images make it into production with Anchore. Getting Started with the Integration How to integrate Anchore and Jenkins Anchore has published a plugin for Jenkins which, along with Anchore’s open source engine or Enterprise offering, allows container analysis and governance to be added quickly into the CI/CD process. The following guide will allow you to add image scanning and analysis into your CI/CD process in less time than it has already taken to read this blog post! Requirements This guide presumes the following prerequisites have been met: - Jenkins 2.x running on a virtual machine or physical server - Each Jenkins node should have Docker 1.10 or higher installed. - Anchore’s Jenkins plugin can work with single node installations or installations with multiple worker nodes. Notes - Docker should be configured to allow the Jenkins user to run Docker commands either directly or through the use of sudo. - For most platforms you can simply add the Jenkins user to the docker group in /etc/group. - For Red Hat based systems using Red Hat’s Docker distribution rather than Docker Inc. then typically the use of sudo is required. - To use sudo ensure that the Jenkins user is part of the wheel group in /etc/group and ensure that requiretty is not set in /etc/sudoers. Read the Documentation Read the documentation on Anchore integration with Jenkins and get started with the integration. ### Installing Anchore with a Single Command Using Helm Helm is the package manager for Kubernetes, inspired by packaged managers such as homebrem, yum, npm and apt. Applications are packaged in Charts which are a collection of files that contain the definition and configuration of resources to be deployed to a Kubernetes cluster. Helm was created by Deis who donated the project to the Cloud Native Computing Foundation (CNCF). Helm makes it simple to package and deploy applications to be deployed including versioning. upgrade and rollback of applications. Helm does not replace Docker images, in fact, docker images are deployed by Helm into a Kubernetes cluster. Helm is comprised of two components a server-side service running on the Kubernetes cluster called Tiller and the client-side component, Helm. Using helm applications, packaged as charts, can be deployed and managed using a single command: $ helm install myApp We have recently packaged the Anchore Engine as a Helm Chart to simplify deployment on Kubernetes. Now Anchore can be installed in a highly scalable environment with a single command. Within 3 minutes you can have an Anchore Engine installed and running in your Kubernetes environment. The following guide requires: A running Kubernetes Cluster kubectl configured to access your Kubernetes cluster Helm binary installed and available in your path Tiller, the server-side component of Helm, should be installed in your Kubernetes cluster. To installer Tiller run the following command: $ helm init $HELM_HOME has been configured at /home/username/.helm Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster. ⎈ Happy Helming! ⎈ If Tiller has already been installed you will receive a warning messaging that can safely be ignored. Next, we need to ensure that we have an up to date list of Helm Charts. $ helm repo update Hang tight while we grab the latest from your chart repositories... ...Skip local chart repository ...Successfully got an update from the "stable" chart repository Update Complete. ⎈ Happy Helming!⎈ By default, the Anchore Engine chart will deploy an Anchore Engine container along with a PostgreSQL database container however this behavior can be overridden if you have an existing PostgreSQL service available. In addition to the database, the chart creates two deployments Cores Services: The core services deployment includes the external API, notification service, Kubernetes webhook, catalog and queuing service. Worker: The worker service runs the image analysis and can be scaled up to handle the concurrent evaluation of images. In this example, we will deploy the database, core services and a single worker. Please refer to the documentation for more sophisticated deployments including scaling worker nodes. The installation can be completed with a single command: $ helm install --name anchore-demo stable/anchore-engine If there server-side component, Tiller, is not installed you will see the following error message: Error: could not find tiller You may wish to configure Anchore Engine to synchronize policies from the Anchore Cloud service, allowing you to use the free graphical policy editor to build policies, whitelists and map these to your own repositories and images. If you have not already created an account on the Anchore Cloud you can sign up for free at anchore.io/signup We can pass your username and password to the Helm chart in either by using command line options or by creating a values.yaml file containing these parameters. In the following example, the anchore.io username and password are being passed using command line options. Note: In addition to passing your authentication credentials we also need to enable synchronization of policy bundles and disable anonymous access. $ helm install --name anchore-demo stable/anchore-engine --set coreConfig.policyBundleSyncEnabled=True --set globalConfig.users.admin.anchoreIOCredentials.useAnonymous=False --set globalConfig.users.admin.anchoreIOCredentials.user=myemail@example.com --set globalConfig.users.admin.anchoreIOCredentials.password=verysecret Alternatively, the updated values file can be passed as a parameter to the installation. $ helm install --name anchore-demo stable/anchore-engine --values=values.yaml In both examples the --name parameter is optional and if omitted a name will be randomly assigned to your deployment. The Helm installation should complete in a matter of seconds after which time it will output details of the deployed resources showing the secrets, configMaps, volumes, services, deployments and pods that have been created. In addition, some further help text providing URLs and a quick start will be displayed. Running helm list (or helm ls) will show your deployment $ helm ls NAME REVISION UPDATED STATUS CHART NAMESPACE anchore-demo 1 Wed Jan 20 10:46:10 2018 DEPLOYED anchore-engine-0.1.0 default We can use kubectl to show the deployments on the Kubernetes cluster. $ kubectl get deployments NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE anchore-demo-anchore-engine-core 1 1 1 0 1m anchore-demo-anchore-engine-worker 1 1 1 1 1m anchore-demo-postgresql 1 1 1 1 1m When the engine is started for the first time it will perform a full synchronization of feed data, including CVE vulnerability data. This first sync may last for several minutes during which time the service will be responsive but will queue up images for analysis pending successful completion of the feed sync. The Anchore Engine exposes a REST API however the easiest way to interact with the Anchore Engine is through the Anchore CLI which can be installed using Python PiP. $ pip install anchorecli Documentation for installing the CLI on Mac, Linux and Windows can be found in the wiki. The Anchore CLI can be configured using command line options, environment variables or a configuration file. See the getting started wiki for details. In this example, we will use environment variables. ANCHORE_CLI_USER=admin ANCHORE_CLI_PASS=foobar The password can be retrieved from Kubernetes by accessing the secrets passed to the container. ANCHORE_CLI_PASS=$(kubectl get secret --namespace default anchore-demo-anchore-engine -o jsonpath="{.data.adminPassword}" | base64 --decode; echo) Note: The deployment name in this example, anchore-demo-anchore-engine, was retrieved from the output of the helm installation or helm status command. The helm installation or status command will also show the Anchore Engine URL, for example: ANCHORE_CLI_URL=http://anchore-demo-anchore-engine.default.svc.cluster.local:8228/v1/ To provide external access you can use kubectl to expose the external API port, 8228 to the internet. $ kubectl expose deployment anchore-demo-anchore-engine-core --type=LoadBalancer --name=anchore-engine --port=8228 service "anchore-engine" exposed The external IP can be retrieved from the Kubernetes cluster using the get service call: $ kubectl get service anchore-engine NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE anchore-engine 10.27.245.63 8228:31622/TCP 22s If the external IP is shown as pending then try re-running the command after a minute. $ kubectl get service anchore-engine NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE anchore-engine 10.27.245.63 35.186.160.168 8228:31622/TCP 49s In this example the Anchore URL should be set to: ANCHORE_CLI_URL=http://35.186.160.168:8228/v1 Now you can use the Anchore CLI to analyze and report on images. For example: To view the status of the Anchore Engine: $ anchore-cli system status To add an image to be analyzed: $ anchore-cli image add docker.io/library/alpine:latest To list images: $ anchore-cli image list To list CVEs found in an image: $ anchore-cli image vuln library/alpine:latest os You can follow the Getting Started Guide to learn more about using the Anchore Engine including adding subscriptions, evaluating policies and inspecting images. ### Handling False Positives If like me you’re subscribed to receive updates for popular base images such as CentOS, then this morning you may have received an email like this from Anchore: Here, you are receiving a warning that a new, HIGH severity CVE was just found in the CentOS image. You can read more about the vulnerability in Red Hat’s security advisory RHSA-2018:0102 which covers the impact of CVE-2017-3145 on the BIND DNS package. As you can see from reading the advisory, an attacker could “potentially use this flaw to make named, acting as a DNSSEC validating resolver, exit unexpectedly … via a specially crafted DNS request.” However the base CentOS image does not include the BIND DNS package, but it does include the bind-license package which contains a single text file container copyright information for BIND. While the security advisory lists all bind-* packages the copyright license file can obviously not be exploited by a specially crafted DNS request! While this CVE can safely be ignored in the security vulnerability page for library/centos:latest or any images built from this base image it is likely that your policy checks will fail this image due to the High Severity vulnerability. In my environment, I use the Global Whitelist feature for this very reason. It allows me to add an exception to ensure that the RHSA-2018:0102 vulnerability does not incorrectly block my CentOS or RHEL images. In the screenshot below you can see that I have whitelisted RHSA-2018:0102 and in the package field I have specified the bind-license package to ensure that we only whitelist this package and not a binary package that is actually exploitable. Using the free Anchore Cloud service you can receive notifications for image updates, paid subscribers receive policy and CVE updates such as the one covered by this blog. ### Scanning Images on Amazon Elastic Container Registry (ECR) The Anchore Engine supports analyzing images from any Docker V2 compatible registry however when accessing an Amazon ECR registry extra steps must be taken to handle Amazon Web Services authentication. The Anchore Engine will attempt to download images from any registry without requiring further configuration. For example, running the following command: $ anchore-cli image add prod.example.com/myapp/foo:latest This would instruct the Anchore Engine to download the myapp/foo:latest image from the prod.example.com registry. Unless otherwise configured the Anchore Engine will try to pull the image from the registry without authentication. In the following example, we fail to add an image for analysis due to an error. $ anchore-cli image add prod.example.com/myapp/bar:latest Error: image cannot be found/fetched from registry HTTP Code: 404 In many cases it is not possible to distinguish between an image that does not exist and an image that you are not authorized to access since many registries do not wish to disclose the existence of private resources to unauthenticated users. The Anchore Engine can store credentials used to access your private registries. Running the following command lists the defined registries. $ anchore-cli registry list Registry User docker.io anchore quay.io anchore registry.example.com johndoe 123456789012.dkr.ecr.us-east-1.amazonaws.com ABC Here we can see that 4 registries have been defined. When pulling an image the Anchore Engine checks to see if any credentials have been defined for the registry, if none are present then the Anchore Engine will attempt to pull images without authentication but if a registry is defined then all access of metadata or pulls for images from that registry will use the specified username and password. Registries can be added using the following syntax: $ anchore-cli registry add REGISTRY USERNAME PASSWORD The REGISTRY parameter should include the fully qualified hostname and port number of the registry. For example registry.anchore.com:5000 Amazon AWS typically uses keys instead of traditional usernames & passwords. These keys consist of an access key ID and a secret access key. While it is possible to use the aws ecr get-login command to create an access token, this will expire after 12 hours so it is not appropriate for use with Anchore Engine, otherwise, a user would need to update their registry credentials regularly. So when adding an Amazon ECR registry to Anchore Engine you should pass the aws_access_key_id and aws_secret_access_key. For example: $ anchore-cli registry add / 1234567890.dkr.ecr.us-east-1.amazonaws.com / MY_AWS_ACCESS_KEY_ID / MY_AWS_SECRET_ACCESS_KEY / --registry-type=awsecr The registry-type parameter instructs Anchore Engine to handle these credentials as AWS credentials rather than traditional usernames and passwords. Currently, the Anchore Engine supports two types of registry authentication standard username and password for most Docker V2 registries and Amazon ECR. In this example we specified the registry type on the command line however if this parameter is omitted then the CLI will attempt to guess the registry type from the URL which uses a standard format. The Anchore Engine will use the AWS access key and secret access keys to generate authentication tokens to access the Amazon ECR registry, the Anchore Engine will manage regeneration of these tokens which typically expire after 12 hours. In addition to supporting AWS access key credentials Anchore also supports the use of IAM roles for authenticating with Amazon ECR if the Anchore Engine is run on an EC2 instance. In this case, you can configure the Anchore Engine to inherit the IAM role from the EC2 instance hosting the engine. When launching the EC2 instance that will run the Anchore Engine you need to specify a role that includes the AmazonEC2ContainerRegistryReadOnly policy. While this is best performed using a CloudFormation template, you can manually configure from the launch instance wizard. Select Create new IAM role. Under the type of trusted entity select EC2. Ensure that the AmazonEC2ContainerRegistryReadOnly policy is selected. Give a name to the role and add this role to the Instance you are launching. On the running EC2 instance you can manually verify that the instance has inherited the correct role by running the following command: #curl http://169.254.169.254/latest/meta-data/iam/info { "Code" : "Success", "LastUpdated" : "2018-01-1218:45:12Z", "InstanceProfileArn" : "arn:aws:iam::123456789012:instance-profile/ECR-ReadOnly", "InstanceProfileId" : "ABCDEFGHIJKLMNOP” } By default the support for inheriting the IAM role is disabled. This can be enabled by adding the following entry to the top of the Anchore Engine config.YAML file. allow_awsecr_iam_auto: False When IAM support is enabled instead of passing the access key and secret access key use “awsauto” for both username and password. This will instruct the Anchore Engine to inherit the role from the underlying EC2 instance. $ anchore-cli registry add / 1234567890.dkr.ecr.us-east-1.amazonaws.com / awsauto / awsauto / --registry-type=awsecr You can learn more about Anchore Engine and how you can scan your container images whether they are hosted on cloud-based registries such as DockerHub and Amazon ECR or on private Docker V2 compatible registries hosted on-premises. ### How Many CVEs? For most users analyzing or auditing container images usually means running a CVE scan and while that is certainly required, it should be just the first step. Anchore supports creating policies that can be used to assess the compliance of your containers, these policy checks could cover security, starting with the ubiquitous CVE scan but then going further to analyze the configuration of key security components, for example, you could have the latest version of the apache webserver but have configured the wrong set of TLS Ciphers suites leading to insecure communication. Outside of security, policies could cover application-specific configurations to comply with best practices or to enable consistency and predictability. Today there are many tools that can perform CVE scans of a container image however when we speak to users we often hear that either they do not perform these scans or if they do they do not gate container deployments based on the results of these scans. When we asked these users why they didn’t stop their deployment based on the CVE scanner’s results, we were told “if we did then we’d not deploy any containers - they all fail! “ This is a common issue, for example, if you look at the official images on Docker Hub or Docker Store for CentOS, Debian, Oracle or Ubuntu they all appear to have high or critical vulnerabilities many of which are unfixed, some appear to be CVEs that are unresolved for over a year or more. We have covered this topic previously with respect to CentOS where we saw many vulnerabilities reported by other tools in the CentOS image that were not accurate and similar issues with Oracle and RHEL images. It has been pointed out that Debian, which as we discussed in our previous blog, is the most popular operating system used on Docker Hub seems to have the most vulnerabilities. Regardless of the CVE scanner used, the Debian image looks insecure with many unpatched vulnerabilities, but looks can be deceptive. We will take a look at the Debian image and discuss the results found by various scanners, explain the differences in results and show how you can remove the noise and get a clear view of the security of your containers. Which Package is Vulnerable? Let’s start by looking at a vulnerability reported in the latest Debian image: CVE-2017-12424 which describes a vulnerability in the shadow project which provides tools and libraries for maintaining the password database. Looking at the output of most of the CVE scanners you will see output similar to the following: Here we can see that shadow version 4.4-4.1 is installed and vulnerable to the critical severity CVE 2017-12424. But if you look for the shadow package in your image you will not find it. root@debian:/# dpkg -s shadow dpkg-query: package 'shadow' is not installed and no information is available So if you try to upgrade that individual package you’ll receive an error. Debian reports CVEs against source packages rather than against binary packages so in this example while the source package was shadow the binary package is called passwd. You can look up the source package for a given binary package either using the dpkg utility or using apt-get source. root@debian:/# dpkg -s passwd | grep Source Source: shadow This example using the shadow package is rather straight forward, I would expect that most readers of this article would quickly work out the mapping to the passwd binary package however in many other cases things are not so simple. For example, many non-kernel binaries are created from the Linux source package this leads to some tools reporting kernel CVEs in a container image that includes no kernel. For this reason in the Anchore Cloud and Anchore Engine both report on the binary package not the underlying source package. How Many Vulnerabilities? Analyzing the same image with different scanners often results in very different numbers of reported vulnerabilities. In some cases, as we described in a previous blog, this may be a result of the scanner not taking into backporting of fixes, or not using distribution’s own security vulnerability feed. In other cases the mapping of CVE to source and image package causes confusion. For example, looking at the current debian:latest image using Anchore’s scanner we can see eight packages are shown as being vulnerable to the vulnerability described in CVE 2016-2779. This CVE was reported against the util-linux source package. The binary packages listed in this report are all built from the util-linux source package. A tool, such as Anchore, that reports on binary packages will report seven packages against that CVE while a tool that reports on source packages may only report one. Whether one or all of these binary packages are vulnerable to the vulnerability described in the CVE is something that requires digging deeper into the bug reports and mailing list traffic. Ideally, the distributions would provide more binary specific details in the vulnerability data to assist in this mapping. A more interesting question is: if even one of these packages was vulnerable why after nearly 18 months are fixes not available for these packages? We need to dig deeper. Is it Really Vulnerable? As we saw in the previous example we often see unfixed CVEs in images. For example in the current debian:latest image we see 50 vulnerabilities that have no fixes and 12 of these are rated as High severity. Even if we just counted the number of unique CVEs, not packages, we still see: three high, three medium, one low and 15 Negligible CVEs. Why is that number so high? Since this is the latest official Debian image there is certainly more to this, especially given the fact that the Debian security team are renowned for their focus and responsiveness. We can start by looking at the CVE in Debian’s security tracker: CVE-2016-2779. Here you can see that the current stable version of Debian, stretch, is classified as being vulnerable, however, looking in the notes section we see the following: The security team notes that no Debian Security Advisory will be issued for this vulnerability (no-dsa). You can read more about this on the Debian Security FAQ here, however, the concept here is that while a source package may be vulnerable the way that it is compiled or deployed may mitigate the issue. In some cases, this may be because the package is built with specific compile-time options that don’t trigger the security issue in other cases this may be due to the environment in which it is run. In this specific case, it was decided that the best approach was to address the underlying issue in the Linux kernel so that no version of this package could trigger the vulnerability. Based on this data we should not be concerned about this high criticality CVE in our scan results. There is certainly an argument to be made that given this fact maybe this CVE should not be reported in the Debian vulnerability feed, which is the approach that the Red Hat-based distributions such as CentOS, Oracle and RHEL take. I have not looked into the history around this decision but can imagine the strong arguments to be made on both sides. Presumably anticipating this issue, the Debian team includes metadata in their vulnerability feed that indicates the No Debian Security Advisory decision and commentary. This is data we can then use as part of our analysis of the image. Looking at the current debian:latest image using Anchore Cloud we can view the image’s policy status to see if it PASSES or FAILES based on the default image policy. Here we can see that the image has failed, scrolling down we can see 12 High criticality vulnerabilities that led to this result. You can read more about the image policies here. Anchore includes support for whitelists which allows for certain policy checks, such as select CVEs, to be suppressed. A CVE may be present in a package but not exploitable in that package’s configuration as we saw earlier in this blog. So using the Anchore policy editor a user can create and manage whitelists to filter out false positives. Whitelists can be created and managed in the policy editor or from the image’s policy view but in the case of Debian security advisories it is easier to create a whitelist and upload into the Anchore Cloud. We have published a simple utility that creates whitelists based on the data published in the Debian security tracker. You can clone this utility from our public GitHub repository. git clone Running the debian-whitelist.py utility will create a JSON document for each of the current Debian releases: Wheezy, Jessie, Stretch and Buster (which right now has no whitelisted CVEs). 1. Create a free account on the Anchore Cloud 2. Open the Policy editor by selecting the menu icon on the left navigation menu. 3. Expand the Whitelist editor 4. For each whitelist press the "Upload Whitelist Item" button and upload the JSON document. The whitelists will be named based on the version of Debian and the date. These names can be edited to be more user friendly. You will now have whitelists for each Debian version. Next, we need to use the Mapping Editor to define what whitelist is used for a specific image. 5. Expand the Mapping Editor 6. Select "Create New Mapping" to create a new mapping. 7. Give your mapping a name, eg. “Debian latest” 8. Specify library/debian as the repository name 9. Specify latest as the tag 10. Select the whitelist you created from the dropdown. 11. Select "Save All" to save the whitelist and policy mapping. Now when you view the Debian image you will see that a user-defined policy has been used and that the image passes. The whitelists CVEs can be viewed by checking the Show Whitelisted entries checkbox. Currently, Anchore only applies the whitelist to the policy view and not to the list of CVEs presented in the security tab which shows all CVEs present in the image. By using the default policy we are just performing basic CVE policy checks on the image but using the policy editor you can create policies that do much more. ### Anchore Cloud 2.0 Today Anchore announced the release of Anchore Cloud 2.0 which builds on top of Anchore’s open source Engine to provide a suite of tools to allow organizations to perform a detailed analysis of container images and apply user-defined policies to ensure that containers meet the organization's security requirements and operational best practices. Anchore released the Anchore Navigator back in October 2017 and since then thousands of users have used the service to search for container images, perform analysis on these images and sign up to receive notifications when images were updated. The Anchore Cloud 2.0 release adds a number of exciting new features for all users and a new paid tier which offers support and added features for subscribers. Graphical Policy Editor The new graphical policy editor allows all users to define their own custom policies and map which policies are used with which images. These policies can include checking for security vulnerabilities, package whitelists, blacklists, configuration files, secrets in image, manifest changes, exposed ports and many other user-defined checks. The policy editor supports CVE whitelisting – allowing a curated set of CVEs to be excluded from security vulnerability reporting. Using the policy mapping feature, organizations can set up multiple different policies that will be used on different images based on use case. For example, the policy applied to a web-facing service may have different security and operational best practices rules than a database backend service. Private Repositories Subscribers can configure the Anchore Cloud to scan and analyze images in private repositories stored on DockerHub and Amazon EC2 Container Registry (ECR). Once configured the service checks for changes to the repository approximately every 15 minutes. When a change is detected, for example, a new image is added to the repository or changes to tags, Anchore will download any new images, perform deep inspection and evaluate the images based on the policies defined by the user. Notifications Previously the Anchore Cloud allowed users to subscribe to a tag and be notified when that tag was updated – for example when a new debian:latest images were pushed to Docker Hub. For subscribers, the Anchore Cloud can now alert you by email when CVEs have been added or removed from your image and when the policy status of your image has changed, for example, an image that previously passed is now failing policy evaluation. On-Premises Integration Anchore Cloud supports integration with Anchore’s open-source Engine for on-premises deployments, allowing the policies defined on Anchore Cloud service to be applied to images created and stored on-premises. Anchore Cloud supports integration with CI/CD platforms such as Jenkins, allowing containers built in the cloud or on-premises to be scanned as part of the CI/CD workflow ensuring proper compliance prior to production deployment. ### More Than Just Security Updates In our last blog, we talked about how quickly different repos respond to updates to their base images. Any changes made by the base image will need to be implemented in the application images built on top of it, so updates to popular base images spread far and, as we saw from the last blog, quickly. The only type of update we have covered so far in this series of blogs is security updates. However, that is only one part of the picture; package updates may contain non-security bug fixes and new features. To gain some insight into what is being changed in these updates, we have broken down exactly what packages change for a few of the more popular operating system images. One interesting time to look at package differences is when the operating system gets updated to a new version.   Looking at the overview tab for library/centos:latest, when it just got updated to version 7.4, the Navigator shows in the chart on the righthand side that there were many changes with this update. Shown below is a breakdown of which packages have been updated since last September. Only a portion of the packages are shown, you can find the rest in the link below. Focusing in on just that most recent update, we see that 80 of the 145 packages have been updated. The image from Sep 13th was CentOS 7.3, while the one from Sep 14th is CentOS 7.4. Looking into some of the changes, bash, like many others, received backports of bug fixes. Other packages were new additions, such as elfutils-default-yama-scope, while one, pygobject3-base, was removed from the image. In terms of CVE/Security updates, this was an ineffectual update; a quick check of the security tab of both versions (7.3, 7.4) shows that there were no changes in CVEs between the two. Click the button below to access the full spreadsheet with all package updates for 6 popular operating systems. View the Full Spreadsheet In the spreadsheet, you’ll see Alpine stands out in terms of image size and reduced package count. Having more packages means having more packages to maintain. Even if Alpine were to update almost all of its 11 packages, as it did on May 25th, there would not be as many changes as a standard Debian update, such as the one on June 7th, where 25 of 81 packages were updated. There is a trend towards lightweight images, and the appeal of simpler updates might be one reason behind it. Among public repositories, Alpine is growing its share of usage as a base image. Other base operating systems are beginning to including slim versions of their containers, such as Debian, which has a slim version of each of its releases as well as Oracle and Red Hat. Comparing the sizes of the two Debian tags included in the spreadsheet, stretch and stretch-slim, we see that the slim version is about half the size of the original, 95 MB vs 53 MB. The trend goes across releases too; Debian Stretch (Debian 9) images are around 90 MB while Jessie (Debian 8) images are around 120 MB. Ubuntu 16.04 is around 120 MB while 17.04 is around 90 MB. One repository not slimming its images is CentOS. It does not currently include slim versions, even though Red Hat Enterprise Linux, from which CentOS is based, has a slim image known as RHEL Atomic. Part of slimming down containers is removing packages that are not necessary. In some instances, packages are included that are arguably not required in the context of a container, such as device-mapper or dracut. This harkens back to a previous blog, where we discussed how containers are often being used as micro-VMs rather than microservices. The packages listed above, among others, lend themselves to running a full machine, rather than running just a single application. Removing these extra packages is not as simple as it initially appears. For example in the CentOS 7 image dracut, which builds initramfs images to boot an OS, is pulled in as a requirement by kmod, which provides an infrastructure for kernel module loading, which is pulled in by systemd. We see many similar examples in the traditional Linux vendors’ images, where the package management system was designed before the advent of containers. This is a topic we will revisit in a future blog. Even though smaller base images require less maintenance and storage, having fewer packages means less functionality. Most application images built on top of Alpine require that users add many more packages onto the base image so application images are often significantly larger than the 4MB base image. But having the choice to add to an image rather than working out how to remove packages certainly simplifies maintenance for the developer and allows for a reduced attack surface. In our next blog, we will look at some popular application images that are available based on multiple distributions to see how the image size, bug count and update frequencies compare. ### To Update or Not to Update In the previous blog, we presented our analysis of image update frequency for official DockerHub images and the implications for application images built on top of these base images. It was pointed out in a Reddit reply by /u/AskOnDock29 that users can update the operating system packages in the images themselves, independently of the official image and so the frequency, or infrequency, of base image updates, is not a concern since this is easily manageable by end-users. This Redditor is indeed correct, users can update operating system packages when building on top of an official or other base image. Whether this happens, in reality, is an interesting question that we will get to shortly. When the Anchore Navigator downloads images from Docker Hub we derive the Dockerfile from metadata contained in the image. The Anchore Navigator’s Build Summary pane on the overview tab displays this information by showing the commands run in each layer of the dockerfile. Using library/msyql as an example, we see that new files and packages are added to the image however the base packages are not updated. This is the view that the navigator gives of the mysql dockerfile. The derived Dockerfile is not identical to the Dockerfile used to construct the image, since metadata such as the name of files copied or the image that was used as a base, for example, are lost during the build. But the derived Dockerfile does include the commands used and image metadata. In this example, searching through each layer, we do not find package update instructions. Running some quick analysis against our dataset, out of the 22,413 non-official images tagged as ‘latest’ since September of last year, 6,099 (27%) included package update commands in their Dockerfiles. Grouping by repository instead of image, 80 out of 559 (14%) non-official repositories at some point over the last year had update commands. This does not mean that all of these images have outdated packages or known CVEs since their base images may be up to date and there are other ways to include the latest packages, for example starting from scratch and adding in files and packages manually. Anchore’s dataset includes file and package manifests for all of these images so we can verify the package set to look for updates without requiring analysis of the Dockerfile. So should a user upgrade operating system packages when they build their images? Ideally no. Docker’s best practices recommend that the user should not run apt-get upgrade or dist-upgrade within their Dockerfile, but should instead contact the maintainer of the parent image used. Minimizing package changes within the image also helps to improve the reproducibility of the build. If there are no upgrade/update commands or manual package management, then there are two ways to keep the base image up to date: the user can update it manually, or the maintainers can push a new image whenever the base image is updated, which the user then has to use as they rebuild their image. As previously covered, the second method is preferable. Since the majority of repositories do not use upgrade commands and therefore depend on the maintainer or user updating the base image, it would be interesting to see how well repositories are at handling the responsibility and keeping up to date with base image updates. Starting with about 10,000 public community images, we see that a new, updated image is pushed close to a week (six days and 20 hours) after an updated operating system image is made available. We have excluded the first image of each repository from the analysis since our focus is the frequency and timing of updates. The analysis does include many images that are just small side projects that served a single purpose and aren’t actively updated. At the same time, images that get updated nightly are also in there, so there is a balance. However, looking at a number of the most popular community images offers a view into repositories that have a following and need to be maintained more actively than other images. Here, the average time to update is just a little over five days, a good bit lower than the average for all of the images. As mentioned earlier, no official images include update commands, so updates have to come in the form of image updates. Due to their elevated standard and visibility, these updates need to be timely; an update to the base image should be responded to quickly. We see that this is, in fact, the case; the average update times across the official images are about one day and 10 hours. Taking a similar look into popular images, things to note are that none of these respond in longer than three days, and there is no real correlation between popularity and update times among these images. A repo like library/node takes nearly three days on average, while library/mysql takes a little over half a day. There is certainly a correlation on a larger scale - more popular images have quicker update times - but there is quite a bit of variance along the way. To fully visualize see why these updates matter, we’ll go through the life cycle of a security flaw, RHSA-2017:1481. This flaw exploited the glibc package in Red Hat Enterprise Linux (RHEL) and could allow a user to increase their privileges. Because CentOS is compiled from RHEL sources, any images that are built on top of RHEL or CentOS carry this flaw. To focus on just one, we will be looking at jboss/wildfly, which is built on top of CentOS. Knowledge of the flaw was made public on June 19th of this year, and a fix was published by Red Hat almost immediately, with the fix for CentOS being made available on June 20th. The CentOS image was then updated to include the fix 15 days later on July 5th. Using the security tab for that image, you can see that RHSA-2017:1481 is not present. However, clicking on the previous image button will take you to the image that was pushed on June 5th, which was affected by the glibc flaw. The maintainers of the jboss/wildfly image, have a really good update schedule, so a new image that implemented the fix was made available within only 50 minutes of the CentOS image being released, however since the parent image was only updated after 15 days the wildfly image was vulnerable during that period. There are a number of key points to take away from this analysis: Choose your base images carefully. Ensure that the base image you are using is well maintained. If not consider maintaining your own base image or pick a different base image to use. Just because an image is official that does not mean that it is frequently updated or necessarily the best image to build from. You may other repos that have images suited to your needs. Keep track of updates to the base images that you use. One method for tracking updates and receiving notifications is covered in this blog. The frequency of updates is not the only metric to consider when looking at images; you need to know what has changed. Was the image just rebuilt based on a schedule? Or were files and packages changed? Users often focus solely on CVE (security) updates but do not consider other package updates that include bugfixes. In our next blog, we will take a deeper look into what changes in an image update. ### A Look at How Often Docker Images are Updated In our last blog, we reported on operating systems usage on Docker Hub, focusing on official base images. Most users do not build their container image from scratch, they build on top of these base images. For example, extending an image such as library/alpine:latest with their own application content. Whenever one of these base operating system images is updated, images built on top are typically rebuilt in order to inherit the fixes included in the base image. In this blog, we will be looking at the update frequency of base images: frequency of updates, changes made and how that impacts end users. Whenever one of these base operating system images is updated, images built on top are typically rebuilt in order to inherit the fixes included in the base image. In this blog, we will be looking at the update frequency of base images: frequency of updates, changes made and how that impacts end users. If you want to check on the updated history of a particular image the Navigator makes that simple. For example, looking at debian:latest, currently the most popular base operating system among official images. Here you can see the date that the image was created and when it was analyzed by Anchore. The Anchore service continually polls Docker Hub and when an update to a repository is detected the list of tags and images are retrieved and any new images are downloaded and analyzed. Anchore maintains a database with image and tag history so at any point in time previous versions of a Tag may be inspected. Clicking on the Previous Image button navigates to the image that was tagged library/debian:latest previously. The Next Image button is disabled because, at the time the screenshot was acquired, image ID this was the latest image tagged as library/debian:latest. By clicking on Previous Image in the top left, you can explore the Navigator’s analysis of older images of the same tag. In this case, the previous version is only a week old, but for the most part, you will see that Debian is updated every two to five weeks. Putting these dates onto a timeline, we see that debian:latest is updated roughly every month. Looking at the update frequency of other popular official operating system images, once a month is just about average. While this might seem ideal, what really matters is the timeliness of updates and the content of the update. For example, if a new critical vulnerability is discovered the day after the scheduled image update then a user should not wait another month for an update. Users can certainly update these images with fixes, in fact, this should be part of the due diligence that is performed in creating images, however, the content published in public registries should be secure off-the-shelf. This timeline compares the update frequency of some major operating system repositories. Of these repos, none have a fixed update schedule. Ubuntu and Debian are pretty consistent, while the rest are quite varied. For example, CentOS sticks to about an update a month now, but before would have large gaps, up to 3 months long, between updates. On the flip side, Oracle Linux has clusters where multiple updates will come out in a short time period. What is interesting is that there are 4 that all have had 8 or 9 updates over the last year. Is that the number where exposure to security issues and pushing too many updates is balanced? Something else to consider is that having more packages means that there are more things to keep up to date, so lightweight operating systems like Alpine and BusyBox do not need as much maintenance. However, this doesn’t explain why CentOS and Fedora are updated infrequently, as they are both much larger than Debian and Ubuntu. Moving on to popular non-OS images, the difference in update frequency is striking. NGINX, the repo with the fewest updates here, has more updates than Oracle Linux, which had the most updates of all the operating systems. Calling back to the fact that more complexity means more maintenance, this increase makes sense. In future blogs, we will dig into what is changing between image updates. Because many of the application images are built on top of official base operating system images, in theory, they should be rebuilt when the underlying base image is updated. Sadly that is often not the case, where we will see a base operating system image be updated with a fix but the application image may not be rebuilt for several weeks and in some cases, it is rebuilt on top of an older base operating system image. While all official images should follow Docker Hub best practices and should, therefore, be well maintained it is clear from our historic data that many images can be updated infrequently and carry security vulnerability for many weeks. If you are trying to choose a non-official image, it is important that you look into its update history, since many images on Docker Hub are one-offs that were built by an engineer to ‘scratch an itch’ pushed to Docker Hub and never maintained. While that image may seem to have exactly what you are looking for it’s important to note that you are in effect adopting the image and you are then responsible for its care and feeding! One last interesting piece of information is that there are a few days (10/21, 1/17, 2/28, 4/25, …) where many of the repos push updates at the same time. In many cases this occurs the day after their base image, debian:latest was updated. This backs up the idea that these images update more frequently because they have to keep up with updates of their base image. As we alluded to earlier the content of an image update is just as, if not more, important than the timing of an update. In the next blog, we’ll dig into a more detailed timeline of updates, starting with the disclosure of a vulnerability, when the operating system vendor patched it, when that patch was included in a container image and when an application image pulled in the update. ### Just Because They Pushed Doesn’t Mean You Need to Pull While that may sound like advice your mother gave you after you got into a fight at school we are actually talking about Docker images. Yesterday we started to notice a lot of activity on our worker nodes on anchore.io which were analyzing a large number of images that were updated on Docker Hub. The Anchore service monitors Docker Hub looking for changes made to our customer’s private images, official images and thousands of other tags of popular images on Docker Hub. We poll Docker Hub and when images are updated our workers pull down the new images and perform analysis and policy evaluations. Users can also subscribe to images to get notifications when images they use are updated. Since yesterday we’ve seen over a thousand images get updated including official OS based images such as Alpine, CentOS, Debian, Oracle, and Ubuntu. What was odd was that looking at these images we saw no changes in files or package manifests. As part of Anchore’s analysis we look at all the files in the image down to the checksum level and all the package data, this allows us to perform policy checks that go beyond the usual CVE checks that you see with most tools. We show a brief changelog summary on the overview page for an image, showing how many files and packages were added, removed or changed. What had us scratching our heads yesterday was the high number of images with no apparent changes. The image metadata, such as ID and Digest were changed but the underlying content was the same. Digging deeper it appears that while with the actual content of the images has not changed, the manifests have been updated. This seems to have been driven by a change to the bashbrew utility which is used to build official images. Bashbrew now defaults to using the manifest list format which allows for multi-arch images, so even if an image has been built only for a single architecture it will now use the manifest list. We will continue to dig into this but in the meantime, we’d recommend that you look to see what, if anything, changed in an image before you rebuild all your application images on top of a new base image. ### Introducing the Anchore Engine Update: Anchore Engine has been replaced by Anchore's open source software supply chain developer tools (Syft, Grype, Grant, etc.) and Anchore Enterprise.  Today Anchore announced a new open source project that allows users to install a local copy of the powerful container analysis and policy engine that powers the Anchore Navigator service. The Anchore Engine is an open source project that provides a centralized service for inspection, analysis and certification of container images. The Anchore Engine is provided as a Docker container image that can be run standalone or on an orchestration platform such as Kubernetes, Docker Swarm, Rancher or Amazon ECS. Using the Anchore Engine, container images can be downloaded from Docker V2 compatible container registries, analyzed and evaluated against user-defined policies. The Anchore Engine can integrate with Anchore's Navigator service allowing you to define policies and whitelists using a graphical editor that is automatically synchronized to the Anchore Engine. The Anchore Engine can be integrated into CI/CD pipelines such as Jenkins to secure your CI/CD pipeline by adding image scanning including not just CVE based security scans but policy-based scans that can include checks around security, compliance and operational best practices. The Anchore Engine can be accessed directly through a RESTful API or via the Anchore CLI. Adding an image to be analyzed is a simple one-line command: $ anchore-cli image add docker.io/library/nginx:latest The Anchore Engine will now download the image from the registry and perform deep inspection collecting data on packages, files, software artifacts and image metadata. Once analyzed we can retrieve information about the image. For example, retrieving a list of packages: $ anchore-cli image content docker.io/library/nginx:latest os Will return a list of operating system (os) packages found in the image. In addition to operating system packages, we can retrieve details about files, Ruby GEMs and Node.JS NPMs. $ anchore-cli image content docker.io/library/rails:latest gem Package Version Location actioncable 5.0.1 /usr/local/bundle/specifications/actioncable-5.0.1.gemspec actionmailer 5.0.1 /usr/local/bundle/specifications/actionmailer-5.0.1.gemspec actionpack 5.0.1 /usr/local/bundle/specifications/actionpack-5.0.1.gemspec actionview 5.0.1 /usr/local/bundle/specifications/actionview-5.0.1.gemspec activejob 5.0.1 /usr/local/bundle/specifications/activejob-5.0.1.gemspec activemodel 5.0.1 /usr/local/bundle/specifications/activemodel-5.0.1.gemspec activerecord 5.0.1 /usr/local/bundle/specifications/activerecord-5.0.1.gemspec activesupport 5.0.1 /usr/local/bundle/specifications/activesupport-5.0.1.gemspec arel 7.1.4 /usr/local/bundle/specifications/arel-7.1.4.gemspec And if we wanted to see how many security vulnerabilities in an image you can run the following command: $ anchore-cli image vuln docker.io/library/ubuntu:latest os Vulnerability ID Package Severity Fix Vulnerability URL CVE-2013-4235 login-1:4.2-3.1ubuntu5.3 Low None http://people.ubuntu.com/~ubuntu-security/cve/CVE-2013-4235 CVE-2013-4235 passwd-1:4.2-3.1ubuntu5.3 Low None http://people.ubuntu.com/~ubuntu-security/cve/CVE-2013-4235 CVE-2015-5180 libc-bin-2.23-0ubuntu9 Low None http://people.ubuntu.com/~ubuntu-security/cve/CVE-2015-5180 CVE-2015-5180 libc6-2.23-0ubuntu9 Low None http://people.ubuntu.com/~ubuntu-security/cve/CVE-2015-5180 CVE-2015-5180 multiarch-support-2.23-0ubuntu9 Low None http://people.ubuntu.com/~ubuntu-security/cve/CVE-2015-5180 As with the content sub-command we pass a parameter for the type of content we want to analyze - in this case, OS for operating system packages. Future releases will add support for non-package vulnerability data. Next, we can evaluate the image against a policy that was defined either manually on the command line or using the Anchore Navigator $ anchore-cli evaluate check registry.example.com/webapps/frontend:latest Image Digest: sha256:86774cefad82967f97f3eeeef88c1b6262f9b42bc96f2ad61d6f3fdf54475ac3 Full Tag: registry.example.com/webapps/frontend:latest Status: pass Last Eval: 2017-09-09T18:30:22 Policy ID: 715a6056-87ab-49fb-abef-f4b4198c67bf Here we can see that the image passed. To see the details of the evaluation you can add the --detail parameter. For example: $ anchore-cli evaluate check registry.example.com/webapps/broker:latest --detail Image Digest: sha256:7f97f3eeeef88c1b6262f9b42bc96f2ad61d6f3fdf54475ac354475ac Full Tag: registry.example.com/webapps/broker:latest Status: fail Last Eval: 2017-09-09T17:30:22 Policy ID: 715a6056-87ab-49fb-abef-f4b4198c67bf Gate Trigger Detail Status DOCKERFILECHECK NOHEALTHCHECK Dockerfile does not contain any HEALTHCHECK instructions warn ANCHORESEC VULNHIGH HIGH Vulnerability found in package - libmount1 (CVE-2016-2779 - https://security-tracker.debian.org/tracker/CVE-2016-2779) stop ANCHORESEC VULNHIGH HIGH Vulnerability found in package - libncurses5 (CVE-2017-10684 - https://security-tracker.debian.org/tracker/CVE-2017-10684) stop ANCHORESEC VULNHIGH HIGH Vulnerability found in package - libncurses5 (CVE-2017-10685 - https://security-tracker.debian.org/tracker/CVE-2017-10685) stop Here you can see that the broker image failed the policy evaluation due to 3 high severity vulnerabilities. We can subscribe to an image to receive webhook notifications when an image is updated when new security vulnerabilities are found or if the image’s policy status is updated - for example going from Fail to Pass. $ anchore-cli subscription activate image tag_update registry.example.com/webapps/broker:latest ### A Breakdown of Operating Systems of Docker Hub While containers are thought of as “micro-services” or applications, if you open up the image you will see more than just an application - more often than not, you’ll see an entire operating system image along with the application. If you dig into the image you will find that certain parts of the operating system are missing such as kernel and hardware-specific modules and often, but sadly not always, the package list is reduced. If you are deploying a pre-packaged container built by a 3rd party you may not even know what operating system has been used to build the container let alone what packages are inside. As part of the analysis that Anchore performs on the container, it identifies the underlying operating system. To check this out go to the Anchore Navigator and search for the image that you wish to inspect. Halfway down on the overview tab you’ll see the operating system name and version listed. For example, searching for library/nginx:latest will show that it is built on top of Debian 9, Stretch. Let’s take a look at what operating systems are used on Docker Hub: Which operating system gets used the most? How has the choice of operating system changed over time? Are there different usage patterns for official images compared to public images? To get our toes wet, here is the breakdown of what operating systems official images are being built on. It is clear that Debian is the most popular, with Alpine taking second place, and then a number of others each taking a smaller share. Raspbian will also be analyzed even though it doesn’t appear in this chart, because it is not used as a base OS by any official images. When looking at public images’ usage of operating systems, we will see that Raspbian gets used a fair bit. These make up the 7 most popular operating systems amongst Docker repositories, with all others taking up a little less than 2% of the share, so they will be excluded to keep things uncluttered. A notable exclusion here is Red Hat Enterprise Linux. The license agreement prohibits redistribution, which is likely why we see CentOS but no RHEL in the list of official images however, our data shows many public RHEL images from users. The repositories that are included in our dataset are those that have been analyzed by Anchore. This means all official repos, the most popular (based on a combination of pulls and stars) public community repos, and user-requested images. Right now Anchore is pulling data only from Docker Hub, but soon we will be expanding to includes images on Amazon EC2 Container Registry (Amazon ECR). From these repositories, we looked at only the latest tag so that the information was pulled from tags that were being consistently updated. Also, different repositories have different update schedules; where one will push updates every other month, another might update every week. If we counted each update, it would skew results towards operating systems that have a couple of repositories that update multiple times a day. For this reason, we only counted a repository’s use of an operating system on its latest tag once, unless it switched to a different operating system later on. Something else to note is the “Unknown” on the chart. If you look at library/swarm:latest, for example, you will see that the operating system is listed as “Unknown.” What this means is that swarm doesn’t have a standard operating system install and so the system cannot recognize what it is built on top of. Images like these are often statically compiled binaries, and so don’t require anything extra beyond what’s needed to run the application. With Docker’s recent improvements to multi-stage builds, binaries might see a rise in the near future as developers become more familiar with the process and greatly decrease their file size. Image size is often used as a criteria for the selection of base images so we performed some quick analysis to see the average size of official images broken down by the operating system distribution. To get some context, here are the sizes of the images of popular operating systems. The difference in image size is striking: the range goes from BusyBox at 1MB all the way up to Fedora at 230MB. It’s interesting to see the clustering happening. Alpine and BusyBox are lightweight and right near 0MB, then the midweights like Debian and Ubuntu are around 100MB, and the largest are heavyweights such as CentOS and Oracle Linux up by 200MB. Shown here is the size of official images split by what underlying OS it uses. Do note that the OS image is not excluded from the average, so for lesser-used operating systems, the average is brought down. You can see that as application images are built on top of these base images their size grows as dependencies are added. For example, adding required runtimes such as Python or Java. The pie chart above showing official OS distribution only covers the creation of images in the last three months, but our data extends further back. Taking a look at the distribution of operating systems over the course of the past year, we see that Debian has always held its popularity among official repositories. It had a peak of over 80% back in February, and since then appears to have been ever so slowly tailing off. It looks like Alpine is gradually growing, but it is difficult to see any sure trends due to the fluctuation of the data, especially during the summer months which are traditionally slower. We will continue to monitor and report on this trend. Digging more into Debian’s two-thirds share, we can look at the distribution of versions of Debian. Debian 8, Jessie, has held near 100% of the share until July amongst official images, with only a small number of images being built on Wheezy (7) and Stretch (9). This, of course, makes sense as Debian 9 was only released halfway through June, and has since been adopted by more than a third of images and growing. Before its stable release, a few repositories were using the unstable release, presumably favoring new features enough to make the jump ahead of everyone else. Docker Hub official repositories make up only a small number of the total repositories on DockerHub. They follow best practices, are often base images that users build their own apps on top of, and are updated frequently. These standards don’t apply to community images. However, the most popular ones - those that we analyze - only just don’t make that mark. Despite that, there are quite a few differences in operating system usage between the community and official images. Debian still holds the largest share, but only just. Both Alpine and Ubuntu see their percentage nearly double, with raspbian emerging and taking a small percentage, focused on IoT use cases. Ubuntu’s popularity might be explained by the fact that it is the most commonly used Linux distribution by users, and people like to work with something they are familiar with especially as they learn new technology. For Alpine, it’s possible that community repos are quicker to change tech quicker, and the appeal of the security and tiny size of Alpine is pulling more developers towards it. To counter that willingness to change, Stretch doesn’t see as much adoption amongst community images as official ones, getting about half as much usage. What is interesting, however, is that unstable Stretch received more usage here than among official images, which may come from some users experimenting with it to see new features. The graph of community operating system usage over time is much more interesting than the graph for official images, as there are a few trends to see. At the end of 2016, the distribution of operating systems was much more spread. Although Debian was leading then, it had a smaller share than it does now. Starting in February we saw a reduction in the usage of Ubuntu, and now it only has half of the usage of the leaders. Alpine started growing shortly after to take Ubuntu’s place at the top, joining Debian. The other four operating systems all have steadily tailed off, as developers choose to use one of the main three. Going forward, it will be interesting to see if Ubuntu’s recent uptick will continue at the expense of Debian. Official images are typically smaller than public images since they are used as a foundation to build an application image. However, Alpine contradicts this trend, and public images using it are half the size of official images on average. In our next blog, we will dig deeper into updates - looking at how frequently images are updated and the relationship between operating system patches, base image patches and updates to end-user images. ### Scanning for Malicious Content Ivan Akulov just published a rather worrying blog entitled Malicious Packages in NPM in which he documents a recent discovery of several malicious NPM packages that were copies of existing packages with similar names which, while they contained the same functionality, also included malicious code that would collect and exfiltrate environment variables from your system in the hope of finding sensitive information such as authentication tokens. In the past, a developer would either write a software library or purchase a library from a software vendor. Today you can pick a free, open source library off-the-shelf from one of many different registries, each catering to a different community: NuGet for .NET developers, CPAN for Perl developers, RubyGems.org for Ruby developers, npmjs.org for Node.js developers, PyPi for Python developers, maven.org, etc. This move to open source and community-focused development has helped drive the rapid pace of innovation that we’ve seen over the last 10 to 15 years. But as this story shows us, free software doesn’t come without a cost! Just because a piece of software is free that doesn’t mean that you shouldn’t perform the same level of due diligence in assessing the software as you would if you had to pay for it: where is the software coming from? how well is it maintained? how is it licensed? This process should not discourage the adoption of open source however it should ensure that you know what open source components you have, where they came from and how to support them internally. The best approach is to start this process as early in the development cycle as possible, putting in place a process to screen software and libraries before they enter your ‘supply chain’. There are many tools that can help in this regard and the newer generation of tools from other vendors are designed with this new open source software paradigm in mind. But no matter what tools and policies you have in place there will always be something that slips through the cracks, so it’s good to have a final check that you can put in place to ensure that software you deploy meets your compliance and operational best practices. And this is where Anchore comes in. One of the policy rules that Anchore supports is the ability to blacklist certain packages, not just operating system packages but also software libraries such as Ruby Gems or Node.js NPMs. So inspired by Ivan’s blog let’s add a policy check that blacklists these NPMs which will allow us to see if any of our images include these modules. Once logged on launch the policy editor from the icon on the Navigation Bar. For simplicity, we’ll just edit the default policy however you can create custom policies that can be mapped to images based on their registry, repository, and tag. Pressing the   icon expands the list of policy items We will create a new rule by pressing the button. In the Gate field select NPM Checks and in the Trigger field select NPM Package Match (Name). Then in the Parameters field select NPM Name-only match. We now need to enter the modules that we are looking for. Paste the following into the field and press the save button: babelcli, crossenv, cross-env.js, d3.js, fabric-js, ffmepg, gruntcli, http-proxy.js, jquery.js, mariadb, mongose, mssql.js, mssql-node, mysqljs, nodecaffe, nodefabric, node-fabric, nodeffmpeg, nodemailer-js, nodemailer.js, nodemssql, node-opencv, node-opensl, node-openssl, noderequest, nodesass, nodesqlite, node-sqlite, node-tkinter, opencv.js, openssl.js, proxy.js, shadowsock, smb, sqlite.js, sqliter, sqlserver, tkinter Under action, select  WARN to indicate that the presence of these packages will raise a warning rather than fail or stop the image. Finally, click the  button to save the policy. Next, from the Anchore Navigator home page search for an image that you wish to check. Once you have found the image navigate to the Image Policy tab to see if any warnings have been raised based on our new policy. One of the great features of the Navigator is that it keeps historic data about tags and images so that you can navigate back through a tag’s history to look at previous versions. So perhaps the image you have deployed today does not include one of the trojan modules however an older version of this tag may have included a vulnerable component. This ability to look back may prove valuable in reviewing previous deployments either for audit purposes or when performing a post-mortem as part of incidence response. ### The Case of the Missing Vulnerability We extended one of the most popular features of the Anchore Navigator, tag notifications, in our latest Previously users could subscribe to a tag and receive a notification when a new image was pushed with that tag. For example, if you used the Debian image as the base image for your containers then you could subscribe to receive a notification when a new release was pushed. In addition to tag update notifications, the Navigator can now send notifications when we detect changes to the policy status of your image, for example, if your image is now failing its policy check, or when CVEs change on your image. Seeing a CVE change notification is common but usually, you expect to see “CVE Added” however this email is different. Here you can see that I subscribed to library/python:latest and the current image ID that’s tagged with that tag is 968120d8…. and in the body of the notification you can see that one medium severity CVE has been removed. When the Anchore Navigator first analyzed image ID 968120d8… a list of packages was retrieved. The Anchore service regularly pulls down vulnerability data from sources such as operating system distributors and the National Vulnerability Database (NVD). We match this data against the package manifest to identify vulnerabilities in the image. The most common change we see is when a new vulnerability is reported against a specific package. The actual workflows we see vary from distribution to distribution. It is common to see a vulnerability of unknown severity added to an image when the vulnerability is first been disclosed then once the vulnerability has been triaged it moves from unknown severity to a specific severity such as Critical, High, Medium, Low or Negligible. In some cases as more in-depth analysis occurs a distributor or the upstream vulnerability database provider may change their assessment of not just the severity but also the version number of the vulnerable package. For example, if may initially be thought that version 2.x of package foo is vulnerable to a CVE but on further analysis, it may be found that only version 2.1 is vulnerable. In this example, the vulnerability was analyzed and it was found that the current version of ImageMagick (version 8:6.8.9.9-5+deb8u9) in Debian Jessie is not vulnerable to this issue and so the associated feed was updated by the Debian security team. Anchore picked up the change to this feed which triggered the notifications. Sadly seeing vulnerabilities being removed from an image is not very common, you are more likely to see new vulnerabilities being added to images or vulnerability severities being increased which is why it’s important not just to check the image once but keep a constant eye on the status of the image which is where the Anchore Navigator’s notifications feature can help. ### Democratizing Container Certification Today Red Hat announced a new certification program for container images. Key to this announcement is the concept of a container health index that is used to grade a container which is “determined by Red Hat’s evaluation of the level of critical or important security errata that is missing from an image”. Certifications are certainly not a new thing for Red Hat, it could be said that Red Hat built their enterprise business on top of an industry-leading certification program. Enterprises need to have confidence in their deployments, to know that when they deploy an application it will work, it will be secure, it can be maintained, and it will be performant. In the past, this confidence came through certification. In the early days of Linux, Red Hat really set the standard and worked with hardware and software vendors on certification programs to give a level of assurance to end-users that the operating system would run reliably on their hardware and also offer insurance in the form of enterprise-grade commercial support if they encountered issues. One Size Doesn't Fit All Today the problem is more complex and there can no longer be just a single certification. For example, the requirements of a financial services company are different from the requirements of a healthcare company handling medical records, and these are different from the needs of a federal institution and so on. Even the needs of individual departments within any given organization may be different. What is needed now is for IT operations and security to be able to define their own certification requirements, which may differ even from application to application, allowing them to define these policies and evaluate them before applications are deployed into production. What we are talking about is the democratization of certification. Rather than placing certification in the hands of a small number of vendors or standards bodies, organizations need to define what certification means to them. Anchore’s goal is to provide a toolset that allows developers, operations, and security teams to maintain full visibility of the ‘chain of custody’ as containers move through the development lifecycle while providing the visibility, predictability, and control needed for production deployment. At the heart of Anchore’s solution is the concept of users certifying container images based on rules that they define. In the past, certifications for applications typically came from operating systems vendors who defined their own standards and worked with independent software vendors (ISVs) on certification programs to give a level of assurance to end users that the application was compatible with the underlying operating system. Other organizations have created standards and certification tests to cover various forms of compliance validation, especially in the government sector or regulated industries. Container Certification on Your Terms Today the baseline feature set for container security is a CVE scan and that’s certainly required but it’s just the first step. An image may contain no operating system CVEs but may still be insecure, misconfigured or in some other way out of compliance. Container images typically contain hundreds, often thousands of files – some coming from operating system packages, some from configuration files, some from 3rd party software libraries such as Node.JS NPMs, Ruby GEMs, Python modules, Java Archives, and some may be supplied by the user. Each one of these artifacts should undergo the same level scrutiny as the operating system packages. I’m sure that the policies you have in place today for your traditional deployments are more than just ensuring that you’ve updated all operating system packages. While these policies should cover security, starting with the ubiquitous CVE scan, they should go further to analyze the configuration of key security components, for example, you could have the latest version of the Apache or NGINX web server but have configured the wrong set of TLS Ciphers suites leading to insecure communication. Outside of security, certification policies should cover application-specific configurations to comply with best practices or to enable consistency and predictability. With Anchore organizations can define policies and certify containers on their terms - applying the specific policies that matter to them which can even be workload specific and these policies can be applied to any operating system. As we move away from traditional IT models toward cloud, PaaS, containers and hybrid deployments, the operating system becomes less visible and applications become the focus. However, the operating system is still critical whether as part of a container or underpinning your PaaS platform, and as such it should be secure and well maintained. Some of Anchore’s users have policies requiring that containers should only be built on top of Red Hat Enterprise Linux (RHEL) since this is their corporate standard. Others may use different base operating systems but apply a consistent set of policies to all of these images. Tthis becomes especially important as organizations may consume containers from many sources, including freely available containers on public registries as well as containers provided by software vendors. With Anchore you own the certification. ### Watching Images for Updates The majority of Docker users do not build their images from scratch, instead, they are built on top of base images that have been created and published by others. Usually, these are official images that have been created by an organization or community and submitted to Docker Inc. and the community for official review. Images should be regularly updated by their publishers to include the latest content like the latest release of operating system packages to add new features or fixes to security vulnerabilities or new versions of an application or software library. As a developer how do I know when an image has been pushed? DockerHub supports the concept of webhooks that allow a user to receive a notification via an HTTP message when a new image has been pushed. This feature can be used in a number of ways, most commonly it’s used to trigger builds or deployments of applications based on a specific image. This feature has a major limitation: It only supports webhooks for images owned by a user, meaning you can trigger webhooks for images you have created but not for other images such as a base image from an official publisher. Yesterday the Debian team updated their base image; you can inspect the image here using the Anchore Navigator. But how would you know that the image has been updated? The most common approach is just to try and pull the image to see if a new version has been published. # docker pull debian:latest If an updated image is present the docker client will download the newer image. Trying to pull repository docker.io/library/debian ... sha256:476959f29a17423a24a17716e058352ff6fbf13d8389e4a561c8ccc758245937: Pulling from docker.io/library/debian 10a267c67f42: Pull complete Digest: sha256:476959f29a17423a24a17716e058352ff6fbf13d8389e4a561c8ccc758245937 Status: Downloaded newer image for docker.io/debian:latest If you already have the latest image then the docker client will report that your image is up to date. Trying to pull repository docker.io/library/debian ... sha256:476959f29a17423a24a17716e058352ff6fbf13d8389e4a561c8ccc758245937: Pulling from docker.io/library/debian Digest: sha256:476959f29a17423a24a17716e058352ff6fbf13d8389e4a561c8ccc758245937 Status: Image is up to date for docker.io/debian:latest One of the most popular free features of the Anchore Navigator is the ability to subscribe to images in order to receive notifications when images are updated. In the search results you will see a list of repositories. Anchore Navigator can search through all public images on DockerHub. You will see two types of repositories: Analyzed and Preview. Repositories and TAGs that Anchore is monitoring. For these repositories and TAGS any time a new image is pushed Anchore will download the image and perform detailed inspection including image metadata, package manifests, file lists, security vulnerabilities and policies. Repositories that are publicly available on DockerHub but that Anchore has not yet downloaded images. For example, searching for debian gives the following initial results. As you can see the first two repositories in the results list have already been analyzed and you can select the repository to view a list of tags and inspect individual images. If the repository and tag that you wish to monitor has not yet been analyzed you can press the button to submit this TAG to Anchore to be analyzed. All the official repositories and several hundred of the most popular public repositories are already analyzed by Anchore so the chances are you’ll find the image you are looking for right away. Here you can see the overview page for the official Debian image. If you want to receive notifications from Anchore when the image is updated press the Subscribe button and Anchore will notify you when the image has been updated. You can unsubscribe from the image from the image’s overview page and you can see a list of your image subscriptions and favorited images from the “My Images” page accessible from the left navigation menu. Here’s an example notification email including details of which subscribed images have been updated. From here you can click on the links to be taken to the overview for the new images: This is just one example of the features available for free to all Anchore Navigator users. ### A Snapshot of the Container Ecosystem Over the last 2 months, we ran a short survey to collect information about Container usage. The survey was slightly shorter than the one we performed in conjunction with DevOps.com and Redmonk 6 months ago but provides deep insight into how the container ecosystem has shifted and continued to evolve over a short period of time. Running multiple surveys gives us the ability to see trends develop and as we review the results of each survey we think of new questions to ask in the next survey to dig deeper. One of the most interesting data points we extracted, which backs up what we’ve seen in the field, is who is paying for container infrastructure: how much of the container infrastructure is paid -vs- free. In our next survey, we'll dig deeper into this topic to see where organizations are financially investing in their container infrastructure. Another interesting finding from the survey data was that many companies/container users still lack the necessary security practices to safely deploy containers in production environments.  Operations and security are still racing to catch up with developers when it comes to the use of containers, but they will need to adapt quickly and put the governance in place to effectively execute and capitalize on the benefits of true microservices architecture. ### Anatomy of a CVE We often mention CVEs in our blogs but we usually skip over the topic, explaining that while CVE checking is important, it is just the tip of the iceberg and that you need to look deeper into the image to check configuration files, non-packaged files, software artifacts such as Ruby GEMs and Node.JS NPMs. We recently got a Tweet from Marc Boorshtein from Tremolo Security asking why Anchore reported less CVEs in an image than were reported in scan results from the Docker Store. interesting, @anchore scan shows much fewer CVE hits then @docker store for the same image. wonder why that is — Marc Boorshtein (@mlbiam) March 31, 2017 So we’re going to take this opportunity to dig into some more details about CVEs to understand what they are, where the data comes from, and how we report on vulnerabilities, and then we’ll use that information to answer Marc’s question. For those who don’t want to read all the way through, the tl;dr here is that Anchore’s results are correct! The Common Vulnerabilities and Exposures (CVE) system establishes a standard for reporting and tracking vulnerabilities. CVE Identifiers are assigned to vulnerabilities to make it easier to share and track information about these issues. The identifier takes the following form: CVE-YEAR-NUMBER, for example CVE-2014-0160. The CVE identifier is the official way to track vulnerabilities, however, in some cases, well-known vulnerabilities are given names and even logos such as the famous Heartbleed vulnerability. Whether this trend of naming and branding vulnerabilities is a good thing is debatable. Some argue that this branding helps raise awareness others feel it’s a distraction. Either way this trend started by Codenomicon with Heartbleed has continued with many new vulnerabilities receiving catchy names such as Dirty Cow and Badlock. Not all serious vulnerabilities get branded and not all branded vulnerabilities are serious. The CVE database is maintained by the Mitre Corporation under contract from the US Government. While Mitre retains responsibility for maintaining the CVE list there are a number of organizations who, under Mitre’s direction, can issue CVE numbers - these are called CVE Numbering Authorities. As of today, there are 53 organizations participating in this program, usually, these are hardware or software vendors such as Canonical, Google, IBM and Red Hat. Many vendors have their own vulnerability tracking databases and CVE helps by providing the glue that links these databases together, for example, a vulnerability in vendor’s hardware appliance may be traced back to an issue in a software library used by many other applications. Having a common identifier to refer to this issue simplifies tracking and reduces complexity. Another database that you’ll see referenced frequently is the National Vulnerability Database (NVD) which is run by the National Institute of Science and Technology (NIST). This database builds on top of the CVE database by adding extra information such as severity scores, fix information and vendor-specific details. Let’s use an example to dig deeper into CVEs: CVE-2016-5195 is a bug that impacts the Linux kernel. It’s a race condition that if successfully exploited can allow local users to gain root privileges. This vulnerability is better known as “Dirty COW,” since it leverages incorrect handling of a copy-on-write (COW) feature. Reading the details in the CVE database you can see that this issue impacts Linux kernel versions 2.x, 3.x and 4.x before version 4.8.3. More details can be found in the NVD database here. Listed in the NVD database you will find information about the severity score of the vulnerability and links to vendors advisories. So, in theory, any Linux kernel prior to version 4.8.3 is vulnerable to this exploit however in practice things are more complicated. Take for example CentOS, where the latest available kernel is version 3.10 (or more accurately 3.10.0-514.10.2). At first, you might expect this kernel to be vulnerable to “Dirty Cow” however Red Hat backported the fix from 4.8.3 into an older kernel version. Backporting is a popular practice for enterprise focussed software products whose users want to keep a well known, stable version of a software platform but still take advantage of security fixes or new features. Backporting selective features and fixes minimize the risk of adopting a completely new release of a software platform. As you can see from this example, while the practice of backporting has many advantages for end-users it complicates the process of auditing installed software using the CVE database. For this reason, many vendors produce their own vulnerability tracking feeds that link back to the CVE database but provides vendor-specific information. For example, Red Hat issues Red Hat Security Advisories (RHSAs) which are publicly available and can also be used to map between RHSAs and CVEs. Other distributions such as Debian, Oracle, SUSE and Oracle provide similarly detailed feeds. These vendor-specific feeds contain valuable information that may not be easily obtained from the NVD database. For example, a Linux distributor may discern that while the upstream project that they are using for a given software package may be impacted with a certain CVE, the way that the package is configured and compiled on their platform may not be impacted by this CVE. A good example can be seen here in Debian’s security tracker. For this reason, a combination of using a vendor’s specific feed and whitelists will provide more accurate information in a security scan. We started this blog by referencing a Tweet that compared Anchore’s scan results to Docker Store’s scan result. The image is question was based off CentOS so we will use this as the foundation for comparison. You can view Anchore’s analysis of the latest CentOS image in the Anchore Navigator here: Selecting the Security tab will show known vulnerabilities. Inspecting the same image in DockerHub or DockerStore will show significantly more vulnerabilities. With at least 12 packages with critical vulnerabilities. For example, here we see that the bash package has 3 critical vulnerabilities two of which date back to 2014. Let’s review the first vulnerability: CVE-2014-6277: While the CVE database does show that bash prior to version 4.3 is vulnerable to this CVE Red Hat’s analysis of the fixes applied in their release states the following: Red Hat no longer considers this bug to be a security issue. The change introduced in bash errata RHSA-2014:1306, RHSA-2014:1311 and RHSA-2014:1312 removed the exposure of the bash parser to untrusted input, mitigating this problem to a bug without security impact. Using Red Hat’s data feed allows us to benefit from their detailed analysis and provide more accurate and relevant information. While this requires that Anchore needs to add distribution specific features to our codebase the benefits far outweigh the cost. Looking in detail through the results for CentOS in DockerStore and in Anchore we are confident that we are displaying the correct results, however, this leads to a very interesting question - how would you know if we were making a mistake? In a previous blog, we discussed Hanlon’s Razor which states: “Never attribute to malice that which is adequately explained by stupidity." Mistakes can obviously be made in security scanners, those mistakes could be deliberate - to purposely hide an issue for some nefarious reasons, but more likely they are just innocent mistakes. At Anchore we believe that security and analysis tools should be open source so that anyone can inspect the code to validate that the results are fair and accurate. In short, we live by the mantra “trust but verify." But that all said, remember that CVEs are just the tip of the iceberg and you need to look far deeper into your images. ### Whitelisting CVE's In last week’s blog, we covered how to create custom policies that can be used to evaluate your container images as part of your CI/CD pipeline or at any time during their lifetime. We explained that you should always perform a CVE scan of your container but that this is only the first step, in fact security vulnerabilities in the operating system packages are just the tip of the iceberg in terms of the tests that you should be performing. Today we want to dig a little deeper into CVEs. Let’s start by looking at the NGINX image in the Anchore Navigator. NGINX is one of the most downloaded images on DockerHub and the chances are that if you are reading this blog you are running NGINX somewhere in your environment. The following link will take you directly to the Security tab for the image to show you the CVEs found in this image. At first glance, looking at the summary, you will probably be concerned: 18 high-level CVEs. The chances are that your policies are configured to fail the image and stop the deployment if any high-level CVEs are found but it’s not that simple. Let’s drill down into the details of the first two entries in the list. Here you can see that two packages include the following vulnerability: CVE-2016-7943 and that, currently, there is no fix available in the version of Debian that this container is built from. You may be tempted to ignore any CVE for which there is not yet a fix, however, there are may not be a fix because one is not required or perhaps there is a real vulnerability but the vendor has not yet released a patch. So let’s click on the link for CVE-2016-7943 to dig a little deeper. This CVE has been issued against the libx11 library for X.org the graphical display server. Libx11 is present in the image as it was pulled in by dependencies (libx11 -> libxpm4 -> nginx-module-image-filter). The National Vulnerability Database (NVD), maintained by NIST, has this categorized as high severity. As you can see from the description this vulnerability may allow remote X servers to gain higher-level privileges. At the bottom of the page you will see the following notes: Here you can see that the Debian security team has described it as a “minor issue”. Given the Debian security team’s assessment, not to mention the fact that there will be no remote X window connections to this server we can safely ignore this high vulnerability. That’s 1 down, 17 more to go ……. For the sake of this example, let’s presume that all the 18 high-level CVEs aren’t exploitable in our image. While that is certainly reassuring it’s also a lot of work for a DevOps engineer to review all CVEs in an image - there’s just too much noise and mistakes are bound to be made. At Anchore we don’t believe that we should be producing lists of issues for engineers to review, the result of a policy evaluation should be a decision, does the image pass or fail? You will see that result on the Policy tab for this image. We have evaluated this image with our default policy and with no whitelist, hence the failure. The Anchore engine supports the notion of whitelists that allow users to define exceptions that should be ignored. For example, if we included CVE-2016-7943 in our whitelist then those first two high vulnerabilities would not have been shown in our policy evaluation. Let’s move the command line to continue. We’ll start by pulling down the latest nginx image and performing an analysis using Anchore. # docker pull nginx:latest # anchore analyze --image=nginx:latest Next, we’ll create a very simple policy file called mypolicy, containing only two checks - for High and Critical CVEs ANCHORESEC:VULNCRITICAL:STOP ANCHORESEC:VULNHIGH:STOP And then run a gate check against the image # anchore gate --image=nginx:latest --policy=mypolicy +--------------+------------------------+------------+----------+-----------------------------+-------------+ | Image Id | Repo Tag | Gate | Trigger | Check Output | Gate Action | +--------------+------------------------+------------+----------+-----------------------------+-------------+ | 5e69fe4b3c31 | docker.io/nginx:latest | ANCHORESEC | VULNHIGH | High Vulnerability found in | STOP | | | | | | package - libx11-data | | | | | | | (CVE-2016-7943 - https | | | | | | | ://security-tracker.debian. | | | | | | | org/tracker/CVE-2016-7943) | | | 5e69fe4b3c31 | docker.io/nginx:latest | ANCHORESEC | VULNHIGH | High Vulnerability found in | STOP | | | | | | package - libx11-6 | | | | | | | (CVE-2016-7943 - https | | | | | | | ://security-tracker.debian. | | | | | | | org/tracker/CVE-2016-7943) | | | 5e69fe4b3c31 | docker.io/nginx:latest | ANCHORESEC | VULNHIGH | High Vulnerability found in | STOP | | | | | | package - libc-bin | | | | | | | (CVE-2014-9761 - https | | | | | | | ://security-tracker.debian. | | | | | | | org/tracker/CVE-2014-9761) | | | 5e69fe4b3c31 | docker.io/nginx:latest | ANCHORESEC | VULNHIGH | High Vulnerability found in | STOP | | | | | | package - multiarch-support | | | | | | | (CVE-2014-9761 - https | | | | | | | ://security-tracker.debian. | | | | | | | org/tracker/CVE-2014-9761) | | | 5e69fe4b3c31 | docker.io/nginx:latest | ANCHORESEC | VULNHIGH | High Vulnerability found in | STOP | | | | | | package - libc6 | | | | | | | (CVE-2014-9761 - https | | | | | | | ://security-tracker.debian. | | | | | | | org/tracker/CVE-2014-9761) | | | 5e69fe4b3c31 | docker.io/nginx:latest | ANCHORESEC | VULNHIGH | High Vulnerability found in | STOP | | | | | | package - libx11-data | | | | | | | (CVE-2016-7942 - https | | | | | | | ://security-tracker.debian. | | | | | | | org/tracker/CVE-2016-7942) | | | 5e69fe4b3c31 | docker.io/nginx:latest | ANCHORESEC | VULNHIGH | High Vulnerability found in | STOP | | | | | | package - libx11-6 | | | | | | | (CVE-2016-7942 - https | | | | | | | ://security-tracker.debian. | | | | | | | org/tracker/CVE-2016-7942) | | | 5e69fe4b3c31 | docker.io/nginx:latest | ANCHORESEC | VULNHIGH | High Vulnerability found in | STOP | | | | | | package - libxml2 | | | | | | | (CVE-2016-4448 - https | | | | | | | ://security-tracker.debian. | | | | | | | org/tracker/CVE-2016-4448) | | | 5e69fe4b3c31 | docker.io/nginx:latest | ANCHORESEC | VULNHIGH | High Vulnerability found in | STOP | | | | | | package - libvpx1 | | | | | | | (CVE-2015-1258 - https | | | | | | | ://security-tracker.debian. | | | | | | | org/tracker/CVE-2015-1258) | | | 5e69fe4b3c31 | docker.io/nginx:latest | ANCHORESEC | VULNHIGH | High Vulnerability found in | STOP | | | | | | package - libtiff5 | | | | | | | (CVE-2015-7554 - https | | | | | | | ://security-tracker.debian. | | | | | | | org/tracker/CVE-2015-7554) | | | 5e69fe4b3c31 | docker.io/nginx:latest | ANCHORESEC | VULNHIGH | High Vulnerability found in | STOP | | | | | | package - libtiff5 | | | | | | | (CVE-2016-9535 - https | | | | | | | ://security-tracker.debian. | | | | | | | org/tracker/CVE-2016-9535) | | | 5e69fe4b3c31 | docker.io/nginx:latest | ANCHORESEC | VULNHIGH | High Vulnerability found in | STOP | | | | | | package - libxml2 | | | | | | | (CVE-2016-1761 - https | | | | | | | ://security-tracker.debian. | | | | | | | org/tracker/CVE-2016-1761) | | | 5e69fe4b3c31 | docker.io/nginx:latest | ANCHORESEC | VULNHIGH | High Vulnerability found in | STOP | | | | | | package - libtiff5 | | | | | | | (CVE-2017-5225 - https | | | | | | | ://security-tracker.debian. | | | | | | | org/tracker/CVE-2017-5225) | | | 5e69fe4b3c31 | docker.io/nginx:latest | FINAL | FINAL | | STOP | +--------------+------------------------+------------+----------+-----------------------------+-------------+ For the sake of this example let’s presume that all of these CVEs have been analyzed and based on the results whitelisted. We’ll create a file called mywhitelist that contains a line for each unique CVE along with the name of the gate: ANCHORESEC Eg. ANCHORESEC CVE-2014-9761 ANCHORESEC CVE-2015-1258 ANCHORESEC CVE-2015-7554 ANCHORESEC CVE-2016-1761 ANCHORESEC CVE-2016-2779 ANCHORESEC CVE-2016-3881 ANCHORESEC CVE-2016-4448 ANCHORESEC CVE-2016-6711 ANCHORESEC CVE-2016-6712 ANCHORESEC CVE-2016-7942 ANCHORESEC CVE-2016-7943 ANCHORESEC CVE-2016-9535 ANCHORESEC CVE-2017-0393 ANCHORESEC CVE-2017-5225 Now if we run the gate analysis passing the whitelist we’ll see a very different result. # anchore gate --image=nginx:latest --policy=mypolicy --global-whitelist=mywhitelist +--------------+------------------------+-------+---------+--------------+-------------+ | Image Id | Repo Tag | Gate | Trigger | Check Output | Gate Action | +--------------+------------------------+-------+---------+--------------+-------------+ | 5e69fe4b3c31 | docker.io/nginx:latest | FINAL | FINAL | | GO | +--------------+------------------------+-------+---------+--------------+-------------+ The gate command supports a --show-whitelisted flag that shows which allows a user to see which items were whitelisted and from which whitelist. # anchore gate --image=nginx:latest --policy=mypolicy --global-whitelist=mywhitelist --show-whitelisted +--------------+------------------------+------------+----------+-------------------------+-------------+-------------+ | Image Id | Repo Tag | Gate | Trigger | Check Output | Gate Action | Whitelisted | +--------------+------------------------+------------+----------+-------------------------+-------------+-------------+ | 5e69fe4b3c31 | docker.io/nginx:latest | ANCHORESEC | VULNHIGH | High Vulnerability | STOP | global | | | | | | found in package - | | | | | | | | libx11-data | | | | | | | | (CVE-2016-7943 - https | | | | | | | | ://security-tracker.deb | | | | | | | | ian.org/tracker/CVE-201 | | | | | | | | 6-7943) | | | | 5e69fe4b3c31 | docker.io/nginx:latest | ANCHORESEC | VULNHIGH | High Vulnerability | STOP | global | | | | | | found in package - | | | | | | | | libx11-6 (CVE-2016-7943 | | | | | | | | - https://security-trac | | | | | | | | ker.debian.org/tracker/ | | | | | | | | CVE-2016-7943) | | | | 5e69fe4b3c31 | docker.io/nginx:latest | ANCHORESEC | VULNHIGH | High Vulnerability | STOP | global | | | | | | found in package - | | | | | | | | libvpx1 (CVE-2017-0393 | | | | | | | | - https://security-trac | | | | | | | | ker.debian.org/tracker/ | | | | | | | | CVE-2017-0393) | | | | 5e69fe4b3c31 | docker.io/nginx:latest | ANCHORESEC | VULNHIGH | High Vulnerability | STOP | global | | | | | | found in package - | | | | | | | | libc-bin (CVE-2014-9761 | | | | | | | | - https://security-trac | | | | | | | | ker.debian.org/tracker/ | | | | | | | | CVE-2014-9761) | | | | 5e69fe4b3c31 | docker.io/nginx:latest | ANCHORESEC | VULNHIGH | High Vulnerability | STOP | global | | | | | | found in package - | | | | | | | | multiarch-support | | | | | | | | (CVE-2014-9761 - https | | | | | | | | ://security-tracker.deb | | | | | | | | ian.org/tracker/CVE-201 | | | | | | | | 4-9761) | | | | 5e69fe4b3c31 | docker.io/nginx:latest | ANCHORESEC | VULNHIGH | High Vulnerability | STOP | global | | | | | | found in package - | | | | | | | | libc6 (CVE-2014-9761 - | | | | | | | | https://security-tracke | | | | | | | | r.debian.org/tracker/CV | | | | | | | | E-2014-9761) | | | | 5e69fe4b3c31 | docker.io/nginx:latest | ANCHORESEC | VULNHIGH | High Vulnerability | STOP | global | | | | | | found in package - | | | | | | | | libx11-data | | | | | | | | (CVE-2016-7942 - https | | | | | | | | ://security-tracker.deb | | | | | | | | ian.org/tracker/CVE-201 | | | | | | | | 6-7942) | | | | 5e69fe4b3c31 | docker.io/nginx:latest | ANCHORESEC | VULNHIGH | High Vulnerability | STOP | global | | | | | | found in package - | | | | | | | | libx11-6 (CVE-2016-7942 | | | | | | | | - https://security-trac | | | | | | | | ker.debian.org/tracker/ | | | | | | | | CVE-2016-7942) | | | | 5e69fe4b3c31 | docker.io/nginx:latest | ANCHORESEC | VULNHIGH | High Vulnerability | STOP | global | | | | | | found in package - | | | | | | | | libvpx1 (CVE-2016-6711 | | | | | | | | - https://security-trac | | | | | | | | ker.debian.org/tracker/ | | | | | | | | CVE-2016-6711) | | | | 5e69fe4b3c31 | docker.io/nginx:latest | ANCHORESEC | VULNHIGH | High Vulnerability | STOP | global | | | | | | found in package - | | | | | | | | libvpx1 (CVE-2016-6712 | | | | | | | | - https://security-trac | | | | | | | | ker.debian.org/tracker/ | | | | | | | | CVE-2016-6712) | | | | 5e69fe4b3c31 | docker.io/nginx:latest | ANCHORESEC | VULNHIGH | High Vulnerability | STOP | global | | | | | | found in package - | | | | | | | | libxml2 (CVE-2016-4448 | | | | | | | | - https://security-trac | | | | | | | | ker.debian.org/tracker/ | | | | | | | | CVE-2016-4448) | | | | 5e69fe4b3c31 | docker.io/nginx:latest | ANCHORESEC | VULNHIGH | High Vulnerability | STOP | global | | | | | | found in package - | | | | | | | | libvpx1 (CVE-2015-1258 | | | | | | | | - https://security-trac | | | | | | | | ker.debian.org/tracker/ | | | | | | | | CVE-2015-1258) | | | | 5e69fe4b3c31 | docker.io/nginx:latest | ANCHORESEC | VULNHIGH | High Vulnerability | STOP | global | | | | | | found in package - | | | | | | | | libvpx1 (CVE-2016-3881 | | | | | | | | - https://security-trac | | | | | | | | ker.debian.org/tracker/ | | | | | | | | CVE-2016-3881) | | | | 5e69fe4b3c31 | docker.io/nginx:latest | ANCHORESEC | VULNHIGH | High Vulnerability | STOP | global | | | | | | found in package - | | | | | | | | libtiff5 (CVE-2015-7554 | | | | | | | | - https://security-trac | | | | | | | | ker.debian.org/tracker/ | | | | | | | | CVE-2015-7554) | | | | 5e69fe4b3c31 | docker.io/nginx:latest | ANCHORESEC | VULNHIGH | High Vulnerability | STOP | global | | | | | | found in package - | | | | | | | | libtiff5 (CVE-2016-9535 | | | | | | | | - https://security-trac | | | | | | | | ker.debian.org/tracker/ | | | | | | | | CVE-2016-9535) | | | | 5e69fe4b3c31 | docker.io/nginx:latest | ANCHORESEC | VULNHIGH | High Vulnerability | STOP | global | | | | | | found in package - | | | | | | | | util-linux | | | | | | | | (CVE-2016-2779 - https | | | | | | | | ://security-tracker.deb | | | | | | | | ian.org/tracker/CVE-201 | | | | | | | | 6-2779) | | | | 5e69fe4b3c31 | docker.io/nginx:latest | ANCHORESEC | VULNHIGH | High Vulnerability | STOP | global | | | | | | found in package - | | | | | | | | libxml2 (CVE-2016-1761 | | | | | | | | - https://security-trac | | | | | | | | ker.debian.org/tracker/ | | | | | | | | CVE-2016-1761) | | | | 5e69fe4b3c31 | docker.io/nginx:latest | ANCHORESEC | VULNHIGH | High Vulnerability | STOP | global | | | | | | found in package - | | | | | | | | libtiff5 (CVE-2017-5225 | | | | | | | | - https://security-trac | | | | | | | | ker.debian.org/tracker/ | | | | | | | | CVE-2017-5225) | | | | 5e69fe4b3c31 | docker.io/nginx:latest | FINAL | FINAL | | GO | none | +--------------+------------------------+------------+----------+-------------------------+-------------+-------------+ Whitelisting with Jenkins Plugin The latest version of the Anchore plugin for Jenkins (version 1.0.9) includes the ability to pass a whitelist file to Anchore to the custom policy file. Using this mechanism you can include a whitelist in the workspace of your project that will be automatically picked up at analysis time. To update to the latest version of Anchore login to the Jenkins web interface and select: Manage Jenkins -> Manage Plugins Press the “Check now button” to ensure that you have the latest plugin metadata. From the “Updates” tab ensure that you’re upgrading to the latest Anchore plugin - at least version 1.0.9. To use whitelists within your Jenkins project go to the Anchore Container Image Scanner build step where you will see a similar screen as shown above including the new “Global White list file” entry field. From this screen press the “Save” button the new setting will not be honored until Save is pressed once. The upcoming Anchore 2.0 release will support the graphical creation of whitelists and policies along with the ability to define a mapping file that allows the user to define which policies and whitelists are used for any given image based on its registry, repo name and tag. In our next blog, we’ll dig deeper into advance policy and whitelist options as well as discussing curated whitelists. ### Becoming a Container Security Champion Since we released Anchore’s open source project almost a year ago we’ve seen fast-growing adoption by users who want to perform detailed inspection and analysis of their container images. By far the most common use case we see with our users is deploying Anchore within their continuous integration and deployment pipelines (CI/CD) especially with Jenkins. In some of the recent events we’ve attended it’s been great to talk to end-users who are already using Anchore. We’ve heard a pretty consistent message in the conversations we’ve had: Developers love Docker and it’s already a vital part of their development process and they are either already deploying Docker in production or are planning to do so. What we hear from operations and security folks is often a little different! We hear talks of ‘Shadow IT’ and unmanaged deployments. Right now it seems like the security and operations teams are racing to catch up with development. Rather than trying to slow things down, most of the operations teams that we talk to want to just “get out of the way and let developers innovate” but they need to balance this with their organization’s needs around security and compliance. Based on the experience we have already built with organizations in addressing these issues, today we are launching a new offering that we call Anchore Champion that provides a combination of services and support to jumpstart the process of securing an organization's CI/CD pipeline and adding compliance and governance into their DevOps environment. The Anchore Champion service begins with a container policy and compliance working session where we, virtually, get together with all the stakeholders: developers, operations and security to work through their requirements for compliance and then build a set of sample policies and whitelists that encompass their needs. Next, we provide support for architecting a secure container build environment - helping integrate Anchore into a Jenkins or other CI/CD pipeline. And we provide ongoing support for creating policies, configuration and general operation of Anchore. ### Creating Policies At the heart of Anchore’s solution is the concept of users certifying container images based on rules that they define. In the past certifications for applications typically came from operating systems vendors who defined their own standards and worked with independent software vendors (ISVs) on certification programs to give a level of assurance to end users that the application was compatible with the underlying operating system. Other organizations have created standards and certification tests to cover various forms of compliance validation, especially in the government sector or regulated industries. Today the problem is more complex and there can no longer be just a single certification. For example, the requirements of a financial services company are different from the requirements of a healthcare company handling medical records and these are different from the needs of a federal institution and so on. Anchore believes that rather than having certification in the hands of a small number of vendors or standards bodies, we want to allow organizations to define what certification means to them. In effect, we want to democratize certification. Today we are seeing the baseline feature set for container security is a CVE scan and that's certainly required but it's just the first step.I'm sure the policies and you have in place today for your traditional deployments are more than just ensuring that you've updated all operating system packages. These policies could cover security, starting with the ubiquitous CVE scan but then going further to analyze the configuration of key security components, for example, you could have the latest version of the apache webserver but have configured the wrong set of TLS Ciphers suites leading to insecure communication. Outside of security, policies could cover application-specific configurations to comply with best practices or to enable consistency and predictability. In this blog, we will walk through some sample policies and cover how users can customize these policies as well as create and share their own policies. Let’s start by looking at the policy evaluation of a test image. We will be using the anchore gate command. In Anchore’s terminology gates are checks that are run on images as they pass through the CI/CD pipeline or later when performing an evaluation on existing images. Instead of using the default policy, we will use a customized policy called “basic-policy” that will be loaded by the CLI. # anchore gate --image=testimage --policy=basic-policy +--------------+------------------+-----------------+---------------+-------------------------+-------------+ | Image Id | Repo Tag | Gate | Trigger | Check Output | Gate Action | +--------------+------------------+-----------------+---------------+-------------------------+-------------+ | 9ebc746ba558 | testimage:latest | DOCKERFILECHECK | NOHEALTHCHECK | Dockerfile does not | WARN | | | | | | contain any HEALTHCHECK | | | | | | | instructions | | | 9ebc746ba558 | testimage:latest | PKGBLACKLIST | PKGNAMEMATCH | Package is blacklisted: | STOP | | | | | | openssh-server | | | 9ebc746ba558 | testimage:latest | ANCHORESEC | VULNMEDIUM | Medium Vulnerability | WARN | | | | | | found in package - | | | | | | | bind-license | | | | | | | (RHSA-2017:0276 - https | | | | | | | ://rhn.redhat.com/errat | | | | | | | a/RHSA-2017-0276.html) | | | 9ebc746ba558 | testimage:latest | ANCHORESEC | VULNMEDIUM | Medium Vulnerability | WARN | | | | | | found in package - | | | | | | | openssl-libs | | | | | | | (RHSA-2017:0286 - https | | | | | | | ://rhn.redhat.com/errat | | | | | | | a/RHSA-2017-0286.html) | | | 9ebc746ba558 | testimage:latest | ANCHORESEC | VULNMEDIUM | Medium Vulnerability | WARN | | | | | | found in package - vim- | | | | | | | minimal (RHSA-2016:2972 | | | | | | | - https://rhn.redhat.co | | | | | | | m/errata/RHSA-2016-2972 | | | | | | | .html) | | | 9ebc746ba558 | testimage:latest | ANCHORESEC | VULNHIGH | High Vulnerability | STOP | | | | | | found in package - | | | | | | | bind-license | | | | | | | (RHSA-2017:0062 - https | | | | | | | ://rhn.redhat.com/errat | | | | | | | a/RHSA-2017-0062.html) | | | 9ebc746ba558 | testimage:latest | IMAGECHECK | BASEOUTOFDATE | Image base image | WARN | | | | | | (docker.io/acathrow | | | | | | | /aic-test:1a) ID is | | | | | | | (9ebc746ba558), but the | | | | | | | latest ID for | | | | | | | (docker.io/acathrow | | | | | | | /aic-test:1a) is | | | | | | | (f3e982542816) | | | 9ebc746ba558 | testimage:latest | FINAL | FINAL | | STOP | +--------------+------------------+-----------------+---------------+-------------------------+-------------+ Here the output is formatted in a tabular view for a command line user to read however if you want to automate the processing of the output then the anchore command supports a --json or --plain command line option to output the results in a format that is easily parsed by other tools. The most important part of the output is the last line that indicates that the final policy evaluation is “STOP”. Anchore gates will output one of three actions: GO: The gate is open and the image should be allowed to pass through to the next stage. STOP: The gate is closed and the image should not proceed WARN: The gate is open and should proceed to the next step however warnings have been raised that should be reviewed. If you are automating the use of Anchore from the command line then the return code from the anchore command can be used to evaluate the status: 0 = Go, 1 = Stop, 2 = Warn. Looking at the output of the policy evaluation we can see that two policy checks outputted a “STOP” action. The first was due to a blacklisted package being present in the image and the second was due to a high-level CVE vulnerability. Next, we’ll take a look at the policy. DOCKERFILECHECK:NOTAG:STOP DOCKERFILECHECK:NOFROM:STOP DOCKERFILECHECK:NOHEALTHCHECK:WARN DOCKERFILECHECK:EXPOSE:STOP:DENIEDPORTS=22 SUIDDIFF:SUIDFILEDEL:GO SUIDDIFF:SUIDMODEDIFF:STOP SUIDDIFF:SUIDFILEADD:STOP IMAGECHECK:BASEOUTOFDATE:WARN PKGBLACKLIST:PKGNAMEMATCH:STOP:BLACKLIST_NAMEMATCH=openssh-server ANCHORESEC:FEEDOUTOFDATE:STOP:MAXAGE=2 ANCHORESEC:UNSUPPORTEDDISTRO:STOP ANCHORESEC:VULNCRITICAL:STOP ANCHORESEC:VULNHIGH:STOP ANCHORESEC:VULNMEDIUM:WARN The policy file lines are of the following format: Gate name : Trigger : Action : Optional Parameters You can consider a Gate as a family of checks that can be performed. Checks can raise triggers that may have parameters. Once a trigger is raised then an action (GO, STOP or WARN) is defined. For example, looking at the following snippet from this simple policy: DOCKERFILECHECK:NOHEALTHCHECK:WARN Within the Dockerfilecheck gate there is a that looks for a healthcheck statement in the Dockerfile. If no healthcheck statement is found then the NOHEALTHCHECK trigger is raised. In this example, we have configured Anchore to raise a warning if the Dockerfile does not include a health check. In the next example we’ll blacklist two packages: PKGBLACKLIST:PKGNAMEMATCH:STOP:BLACKLIST_NAMEMATCH=openssh-server,foolib Here we have configured the PKGNAMEMATCH trigger to issue a STOP action if either openssh-server or foolib is present in the image. The PKGBLACKLIST gate has two triggers : PKGFULLMATCH which matches both a package name and version and PKGNAMEMATCH which matches just the name of the package. Anchore comes pre-installed with a number of policy modules that can be extended by the user and we regularly add new modules. You can retrieve a full list of available policy options by running the following command: # anchore gate --show-policytemplate This will output a sample policy including all available gates including all available parameters. The policy template option is useful for providing a policy file that you can further customize. To get more detailed descriptions of gates, triggers and configuration options you can run the following command: # anchore gate --show-gatehelp PKGCHECK: PKGNOTPRESENT: description: 'triggers if the package(s) specified in the params are not installed in the container image. PKGFULLMATCH param can specify an exact match (ex: "curl|7.29.0-35.el7.centos"). PKGNAMEMATCH param can specify just the package name (ex: "curl"). PKGVERSMATCH can specify a minimum version and will trigger if installed version is less than the specified minimum version (ex: zlib|0.2.8-r2)' params: PKGFULLMATCH,PKGNAMEMATCH,PKGVERSMATCH In this snippet, you can see the configuration options for the Package Check gate which allows a policy to specify that certain packages should be installed in the image. In addition to checking for the presence of a package, the user can configure minimum required versions. We have set up a git repository to make it easier to share sample policies and allow the community to collaborate. You can access the repository here. In our next blog, we’ll cover whitelists and show how you can reduce some of the noise that is often seen in CVE scans by whitelisting vulnerabilities that are not exploitable in your image. ### Microservices -vs- MicroVMs At Anchore we spend a whole lot of time looking at container images to provide detailed analysis and certification. Most of the discussions we hear in the industry around image analysis focus on CVE scanning: how many CVEs are in an image, what severity, etc. As we’ve mentioned before, we see CVE scanning as just the tip of the iceberg and that it’s possible to have all the latest operating system packages but still have an image that has security vulnerabilities or is otherwise not compliant with your operational, security or business policies. There is another common issue in the tens of thousands of images that we’ve analyzed which we feel is more fundamental. As an industry we are moving to an architecture based on microservices and containers are really the key to enabling this. While the containers we've seen are often designed to run microservices, I’d argue that the majority of containers we see (both on DockerHub as well as our customer’s private images) are more like MicroVMs than Microservices. These images typically have a hundred or more packages and several thousand files. In most cases, the images are general-purpose operating system images and differ only from their virtual machine brethren by not having a kernel installed. There has been much debate in the industry about image size and how smaller is better, allowing images to be rapidly deployed over the network. Others argue that size doesn’t matter and that the layered nature of Docker’s image format and caching largely mitigates this issue, but looking just at the size of the image doesn’t give you the complete picture. While it’s certainly an important point to consider the real concern should be not the size of the image, but the content of the images. Let’s take Alpine as an example. Let's use the Anchore Navigator to view the contents and select the files tab to drill down further. Filtering this list to show the files in /bin highlights just how many executables are in the image. In a microservice, why does my image need utilities for process or file management? These come from having the busybox package in the image. While that may certainly be useful in some use cases I’d argue that having these kinds of binaries in an image that never directly calls them is an accident waiting to happen. I don’t mean to pick on Alpine which weighs in at 4MB (twenty-five times smaller than most base operating system images and certainly has less attack surface) but the point you must consider is that you must ensure that every artifact in your image serves a purpose and goes through some form of quality control to ensure that the final image is secure and meets your operational best practices. Last month Oracle released a slimmed down Oracle Linux image which reduced the footprint down from 225MB to 114MB, you can read our analysis here, this week Red Hat upped the ante when they announced a slimmed down Red Hat Enterprise Linux Atomic Base Image. The new RHEL image weighs in at 75MB, compared to 192MB for the standard RHEL image. In this image, Red Hat has removed a number of packages that are deemed not necessary for container deployments, two of the most interesting removals are systemd and Python. Traditionally all RHEL installs have included python since the YUM package manager is written in Python. To get around this Red Hat has created a new mini package manager called microdnf. While microdnf is not as functional as YUM or as DNF, the next generation package manager for RHEL based distributions, it does just what is needed: install, remove and update packages. I wanted to look at what else changed in the image so I pulled the RHEL Atomic image from Red Hat’s registry. If you don’t have access to the RHEL registry, you can take a look at the analysis of the image using the Anchore navigator here: Note: This image is not available publicly on DockerHub. For the rest of the analysis, I’m going to use Anchore’s command line tools. First I need to analyze the image. # anchore analyze --image=registry.access.redhat.com/rhel7-atomic I’ve already analyzed the standard rhel 7 image so now I want to run a query to compare the packages installed in the RHEL Atomic image with the standard RHEL image using the show-pkg-diffs query. # anchore query --image=registry.access.redhat.com/rhel7 show-pkg-diffs registry.access.redhat.com/rhel7-atomic   Package RHEL 7 RHEL Atomic python-chardet 2.2.1-1.el7_1 Not Installed librhsm Not Installed 0.0.1-1.el7 yum-plugin-ovl 1.1.31-40.el7 Not Installed libuser 0.60-7.el7_1 Not Installed json-glib Not Installed 1.0.2-1.el7 python-urlgrabber 3.10-8.el7 Not Installed libblkid 2.23.2-33.el7 Not Installed audit-libs 2.6.5-3.el7_3.1 Not Installed libsolv Not Installed 0.6.20-5.el7 xz 5.2.2-1.el7 Not Installed file-libs 5.11-33.el7 Not Installed rpm-build-libs 4.11.3-21.el7 Not Installed python-libs 2.7.5-48.el7 Not Installed qrencode-libs 3.4.1-3.el7 Not Installed gdbm 1.10-8.el7 Not Installed cryptsetup-libs 1.7.2-1.el7 Not Installed dbus-libs 1.6.12-17.el7 Not Installed tar 1.26-31.el7 Not Installed dbus-glib 0.100-7.el7 Not Installed cracklib-dicts 2.9.0-11.el7 Not Installed kmod 20-9.el7 Not Installed systemd 219-30.el7_3.7 Not Installed subscription-manager 1.17.15-1.el7 Not Installed libpwquality 1.2.3-4.el7 Not Installed pygpgme 0.3-9.el7 Not Installed python-dmidecode 3.10.13-11.el7 Not Installed pyliblzma 0.5.3-11.el7 Not Installed device-mapper 1.02.135-1.el7_3.3 Not Installed kmod-libs 20-9.el7 Not Installed shadow-utils 4.1.5.1-24.el7 Not Installed python-pycurl 7.19.0-19.el7 Not Installed libcap-ng 0.7.5-4.el7 Not Installed python-rhsm-certificates 1.17.9-1.el7 Not Installed kpartx 0.4.9-99.el7_3.1 Not Installed python-iniparse 0.4-9.el7 Not Installed microdnf Not Installed 2-3.el7.1.1 pam 1.1.8-18.el7 Not Installed cracklib 2.9.0-11.el7 Not Installed procps-ng 3.3.10-10.el7 Not Installed pyxattr 0.5.1-5.el7 Not Installed vim-minimal 7.4.160-1.el7_3.1 Not Installed python 2.7.5-48.el7 Not Installed python-rhsm 1.17.9-1.el7 Not Installed python-ethtool 0.8-5.el7 Not Installed cpio 2.11-24.el7 Not Installed libutempter 1.1.6-4.el7 Not Installed device-mapper-libs 1.02.135-1.el7_3.3 Not Installed systemd-libs 219-30.el7_3.7 Not Installed dmidecode 3.0-2.el7 Not Installed m2crypto 0.21.1-17.el7 Not Installed hardlink 1.0-19.el7 Not Installed rpm-python 4.11.3-21.el7 Not Installed yum-utils 1.1.31-40.el7 Not Installed dbus-python 1.1.1-9.el7 Not Installed python-dateutil 1.5-7.el7 Not Installed librepo Not Installed 1.7.16-1.el7 util-linux 2.23.2-33.el7 Not Installed usermode 1.111-5.el7 Not Installed yum-metadata-parser 1.1.4-10.el7 Not Installed pygobject3-base 3.14.0-3.el7 Not Installed dracut 033-463.el7 Not Installed rootfiles 8.1-11.el7 Not Installed ustr 1.0.4-16.el7 Not Installed elfutils-libs 0.166-2.el7 Not Installed diffutils 3.3-4.el7 Not Installed dbus 1.6.12-17.el7 Not Installed libuuid 2.23.2-33.el7 Not Installed gdb-gdbserver 7.6.1-94.el7 Not Installed libmount 2.23.2-33.el7 Not Installed libxml2-python 2.9.1-6.el7_2.3 Not Installed yum 3.4.3-150.el7 Not Installed virt-what 1.13-8.el7 Not Installed libdnf Not Installed 0.7.4-2.el7.el libsemanage 2.5-5.1.el7_3 Not Installed gzip 1.5-8.el7 Not Installed passwd 0.79-4.el7 Not Installed python-kitchen 1.1.1-5.el7 Not Installed libnl 1.1.4-3.el7 Not Installed binutils 2.25.1-22.base.el7 Not Installed acl 2.2.51-12.el7 Not Installed Here you’ll see there are 80 package differences. Six packages have been added to support the new package manager: librhsm, json-glib, libsolv, microdnf, librepo and libdnf.74 packages have been removed leaving just the minimum set of packages. Out of interest, I wanted to see how this package list differed from Oracle’s slim image. Package Oracle Linux Slim RHEL Atomic python-chardet 2.2.1-1.el7_1 Not Installed nss-tools 3.21.3-2.0.1.el7_3 3.21.3-2.el7_3 python-urlgrabber 3.10-8.el7 Not Installed libxml2 2.9.1-6.0.1.el7_2.3 2.9.1-6.el7_2.3 audit-libs 2.6.5-3.el7 Not Installed nss-sysinit 3.21.3-2.0.1.el7_3 3.21.3-2.el7_3 file-libs 5.11-33.el7 Not Installed rpm-build-libs 4.11.3-21.el7 Not Installed python-libs 2.7.5-48.0.1.el7 Not Installed json-glib Not Installed 1.0.2-1.el7 gdbm 1.10-8.el7 Not Installed nss 3.21.3-2.0.1.el7_3 3.21.3-2.el7_3 pyxattr 0.5.1-5.el7 Not Installed yum-plugin-ovl 1.1.31-40.el7 Not Installed basesystem 10.0-7.0.1.el7 10.0-7.el7 pygpgme 0.3-9.el7 Not Installed coreutils 8.22-18.0.1.el7 8.22-18.el7 shadow-utils 4.1.5.1-24.el7 Not Installed python-pycurl 7.19.0-19.el7 Not Installed libcap-ng 0.7.5-4.el7 Not Installed bash 4.2.46-21.0.1.el7_3 4.2.46-21.el7_3 python-iniparse 0.4-9.el7 Not Installed microdnf Not Installed 2-3.el7.1.1 librhsm Not Installed 0.0.1-1.el7 kernel-container 3.10.0-0.0.0.2.el7 Not Installed gobject-introspection Not Installed 1.42.0-1.el7 python 2.7.5-48.0.1.el7 Not Installed cpio 2.11-24.el7 Not Installed yum-utils 1.1.31-40.el7 Not Installed pyliblzma 0.5.3-11.el7 Not Installed rpm-python 4.11.3-21.el7 Not Installed librepo Not Installed 1.7.16-1.el7 yum-metadata-parser 1.1.4-10.el7 Not Installed libsolv Not Installed 0.6.20-5.el7 ustr 1.0.4-16.el7 Not Installed oraclelinux-release 7.3-1.0.4.el7 Not Installed diffutils 3.3-4.el7 Not Installed redhat-release-server 7.3-7.0.1.el7 7.3-7.el7 libxml2-python 2.9.1-6.0.1.el7_2.3 Not Installed yum 3.4.3-150.0.1.el7 Not Installed libdnf Not Installed 0.7.4-2.el7.el libsemanage 2.5-5.1.el7_3 Not Installed python-kitchen 1.1.1-5.el7 Not Installed gpg-pubkey ec551f03-53619141 Not Installed Ignoring the version differences, there are 7 packages in RHEL Atomic not present in the Oracle Slim image which support the new microdnf package manager. There are 28 packages in Oracle Slim that are not in the RHEL Atomic image - unsurprisingly most of these relate to the inclusion of YUM. It will be interesting to see if Oracle Linux and the other RHEL derivatives follow suit and use microdnf in their images. This is a great step forward for RHEL users, reducing the image size and the attack surface but still leaves a lot of, arguably, unnecessary content in the image. Take a look at the files view in the content tab of the Anchore Navigator for this image here and, as we did for Alpine earlier, filter for /bin to see the utilities and other libraries installed in the image. At this point, the challenge in reducing the image further is that most of the packages left are required either in whole or more likely in part due to dependencies. For example, you could argue that there is no good reason to have the /bin/chmod command in the image however that is part of the coreutils package which is required by multiple other packages so any further steps forward will require some major changes in packaging. If you have a Red Hat Enterprise Linux subscription I’d encourage you to check out the new Atomic base image and see how you can reduce the footprint and attack surface of your RHEL based images. And whether you use RHEL, CentOS, Debian, Ubuntu, Alpine or other distributions you can use Anchore’s image analysis and compliance tools to ensure that the images you deploy meet your security and best practices requirements. ### Improved Jenkins Integration Today we have released an update to our popular open source Jenkins plugin adding a number of powerful new features. Using Anchore’s freely available and open source Jenkins plugin you can secure your Jenkins pipeline in less than 30 minutes adding image scanning including not just CVE based security scans but policy-based scans that can include checks around security, compliance and operational best practices. The first new feature to highlight is an updated user interface that improves both the aesthetic and the functionality of the UI. In the first screenshot below you can see that while the build has succeeded we have raised a number of warnings.     The container was built from a base image with the tag latest rather than from a specific named tag     The Dockerfile does not include any health check instructions which would simplify ongoing monitoring of the service.     The acme-logging package has not been installed which is a recommended package for this organization. Policies are customizable, along with whitelists, and are typically defined by the Security or Operations team. The Policy evaluation summary is always produced by the Anchore plugin, however, there are other reports that a user can define to be run during the CI/CD pipeline. In the first example, you can see a package manifest that has been produced - both in the form of a searchable web interface but also as a JSON file in the Jenkins project workspace that contains machine-readable output. In the final example, we see a report detailing the difference in packages between the base image and the final image produced by the build. Select:   Manage Jenkins > Manage Plugins > Updates If you are already running the Anchore Jenkins plugin then you can update the Anchore plugin directly from the Jenkins web interface. At the time of writing the latest version of the plugin is version 1.0.7. If you are not running Anchore’s plugin, there is detailed instructions on the following page. The second interesting new feature is support for Jenkins Pipelines. In our previous examples, we have illustrated the use of Anchore within a Jenkins Freestyle Project which is the traditional way of architecting a Jenkins build, using the Jenkins web interface to define projects, adding build steps, scripts, etc. In the Pipeline model, the entire build process is defined as code in a Jenkinsfile. This file can be created, edited and managed in the same way as any other artifact of your software project. For example, you can check your pipeline definition into your source control system, dynamically create the build instructions based on the configuration of your application or perform countless other forms of automation. Pipeline builds can be more complex including forks/joins and parallelism. The pipeline is more resilient and can survive the master node failure and restarts. Pipelines are written in Groovy scripts and to add an Anchore scan you need to add the following simple code snippet. node { def imageLine = IMAGE + ' ' + env.WORKSPACE + '/DockerFile' writeFile file: 'anchore_images', text: imageLine anchore name: 'anchore_images', policyName: 'anchore_policy', bailOnFail: false, inputQueries: [[query: 'list-packages all'], [query: 'cve-scan all']] } Here the IMAGE is the ID of the container image that was just created. This could be in the form of an image ID (short or long-form), for example, 67591570dd29. Or the REPO/TAG can be used -for example, webapp/frontend:123456. This code snippet writes out the anchore_images file that is used by the plugin to define which images are to be scanned. The Dockerfile is read from the project workspace as is the file containing the policy that you wish to evaluate against the image, in this case, we have called the policy file anchore_policy and have stored this file in the project’s workspace. This code snippet can be crafted by hand or built using the Jenkins UI. Select:  Pipeline Syntax from the Project This will launch the Snippet Generator where you can enter the required parameters and press the Generate Pipeline Script button which will produce the required snippet. It’s quick and easy to add Image scanning and policy to your Jenkins project and we’re here to help. If you have any questions or would like to learn more you can join our slack channel by clicking the button below or fill out the form to send us a direct message. ### Updates to Anchore Open Source Project What’s going on in the world of Anchore’s open source platform? As you might know, Anchore has an online container image navigator that provides unique visibility into the contents of container images--our system is constantly watching for updates to public container repositories, and runs a series of comprehensive analyses for every new revision. You can see how containers change over time, what packages and files have been installed, and if any known security vulnerabilities have been fixed or introduced. In our most recent update, we’ve added features to let you subscribe to images you are particularly interested in and request that we scan specific images that we may not already be processing. Underneath the web UI that we host, that functionality is driven by our open source Anchore Engine, which you can run locally to do a wide variety of queries on your on-premise container images. There is a lot of functionality built into the tools: package queries for a number of different packaging formats including RPM, dpkg, Ruby Gem, and Node packages, and scans for known security vulnerabilities. There is also a “multitool” called anchore-toolbox that can show you a variety of other information about your containers, including the Dockerfile used to create the image, its family tree relative to other containers, and it can simply unpack a container into a directory on the filesystem for troubleshooting or examination by other tools. We are also working on improvements to the packaging and deployment of our OSS tools. We are going to be expanding API access for easier integration into different deployment pipelines, and shipping a pre-built container image for multi-user environments. Stay tuned for updates on this effort: you can watch our progress on our GitHub page. If you’re interested in contributing to the project, here are some ways to get started: Add a new query, gate, or analyzer. These are small modules, usually written in Python, that implement a small piece of functionality. You can read a lot more about these modules here.  Check our open issue list for “low-hanging fruit”  Finally, we are planning on continuing our efforts to build useful integrations with third-party tools such as Jenkins. We know that a successful production container pipeline is made up of at least several components, and we want it to be as easy as possible to connect Anchore’s analysis and gating functionality into your own environment and make sure that every container you ship to production is safe, secure, and configured appropriately. Check out a detailed intro to our Jenkins plugin for more info. We know that an open source project’s success depends on its community, so we want to hear from you. Stop by and say Hi, and we hope you enjoy using Anchore for all of your container analysis needs! ### Slimming Down Images Oracle just announced a new container image: Oracle Linux 7-Slim. Their goal was to create a more lean image and improve security in the process, since reducing the footprint of the container also reduces the attack surface. You can check out that image here using Anchore Navigator where you can see that the image weighs in at a little over 100MB, compared to the standard Oracle Linux image which is over twice that size. While that’s nowhere near as small as Alpine, which is a minuscule 4MB, Oracle’s base image is much smaller than the other major Linux distros. The Anchore service, which powers the Navigator, tracks the most popular images on DockerHub along with images requested by registered users, so when a new image is published we pull down the image and perform our detailed analysis. From that data we can tell that Oracle does a good job of regularly updating their base image and usually this image has no security vulnerabilities (CVEs) as it’s updated frequently. You can subscribe to any image on the Navigator to receive notifications when the TAGs are updated - for example when Oracle updated their standard image on the 21st of February all users who subscribed to that image received email notification. Last month we blogged about how you can use Anchore to compare images to see what has changed so today we took a look at the new Oracle slim image to see how Oracle shaved around 100MB off the image. For those who want to follow along you can use the following command: # anchore query --image=oraclelinux show-pkg-diffs oraclelinux:7-slim   Package Oracle Linux Oracle Linux Slim procps-ng 3.3.10-10.el7 Not Installed openssh-clients 6.6.1p1-33.el7_3 Not Installed libuser 0.60-7.el7_1 Not Installed oracle-logos 70.0.3-4.0.7.el7 Not Installed tar 1.26-31.el7 Not Installed json-c 0.11-4.el7_0 Not Installed iputils 20160308-8.el7 Not Installed pygobject2 2.28.6-11.el7 Not Installed rhnsd 5.0.13-5.0.1.el7 Not Installed rhn-check 2.0.2-8.0.4.el7 Not Installed xz 5.2.2-1.el7 Not Installed iproute 3.10.0-74.0.1.el7 Not Installed libmnl 1.0.3-7.el7 Not Installed python-hwdata 1.7.3-4.el7 Not Installed rsyslog 7.4.7-16.0.1.el7 Not Installed bind-license 9.9.4-38.el7_3.2 Not Installed pam 1.1.8-18.el7 Not Installed acl 2.2.51-12.el7 Not Installed dbus-glib 0.100-7.el7 Not Installed cracklib-dicts 2.9.0-11.el7 Not Installed vim-minimal 7.4.160-1.el7_3.1 Not Installed systemd 219-30.0.1.el7_3.6 Not Installed libpwquality 1.2.3-4.el7 Not Installed libnetfilter_conntrack 1.0.4-2.el7 Not Installed python-dmidecode 3.10.13-11.el7 Not Installed newt-python 0.52.15-4.el7 Not Installed hostname 3.13-3.el7 Not Installed libestr 0.1.9-2.el7 Not Installed device-mapper 1.02.135-1.el7_3.2 Not Installed rhnlib 2.5.65-2.0.1.el7 Not Installed passwd 0.79-4.el7 Not Installed yum-rhn-plugin 2.0.1-6.0.1.el7 Not Installed kpartx 0.4.9-99.el7_3.1 Not Installed libblkid 2.23.2-33.0.1.el7 Not Installed dracut 033-463.0.1.el7 Not Installed python-gudev 147.2-7.el7 Not Installed policycoreutils 2.5-11.0.1.el7_3 Not Installed cracklib 2.9.0-11.el7 Not Installed iptables 1.4.21-17.el7 Not Installed fipscheck 1.4.1-5.el7 Not Installed yum-plugin-ulninfo 0.2-13.el7 Not Installed dbus-libs 1.6.12-17.0.1.el7 Not Installed kmod 20-9.el7 Not Installed openssh-server 6.6.1p1-33.el7_3 Not Installed GeoIP 1.5.0-11.el7 Not Installed systemd-libs 219-30.0.1.el7_3.6 Not Installed python-ethtool 0.8-5.el7 Not Installed bind-libs-lite 9.9.4-38.el7_3.2 Not Installed libutempter 1.1.6-4.el7 Not Installed device-mapper-libs 1.02.135-1.el7_3.2 Not Installed sysvinit-tools 2.88-14.dsf.el7 Not Installed m2crypto 0.21.1-17.el7 Not Installed hardlink 1.0-19.el7 Not Installed libgudev1 219-30.0.1.el7_3.6 Not Installed dbus-python 1.1.1-9.el7 Not Installed dhcp-libs 4.2.5-47.0.1.el7 Not Installed slang 2.2.4-11.el7 Not Installed util-linux 2.23.2-33.0.1.el7 Not Installed usermode 1.111-5.el7 Not Installed libnl 1.1.4-3.el7 Not Installed newt 0.52.15-4.el7 Not Installed dhclient 4.2.5-47.0.1.el7 Not Installed libnfnetlink 1.0.1-4.el7 Not Installed qrencode-libs 3.4.1-3.el7 Not Installed rootfiles 8.1-11.el7 Not Installed elfutils-libs 0.166-2.el7 Not Installed libedit 3.0-12.20121213cvs.el7 Not Installed tcp_wrappers-libs 7.6-77.el7 Not Installed pyOpenSSL 0.13.1-3.el7 Not Installed openssh 6.6.1p1-33.el7_3 Not Installed dbus 1.6.12-17.0.1.el7 Not Installed libuuid 2.23.2-33.0.1.el7 Not Installed logrotate 3.8.6-12.el7 Not Installed dhcp-common 4.2.5-47.0.1.el7 Not Installed cryptsetup-libs 1.7.2-1.el7 Not Installed libmount 2.23.2-33.0.1.el7 Not Installed initscripts 9.49.37-1.0.1.el7 Not Installed kmod-libs 20-9.el7 Not Installed rhn-client-tools 2.0.2-8.0.4.el7 Not Installed hwdata 0.252-8.4.el7 Not Installed gzip 1.5-8.el7 Not Installed fipscheck-lib 1.4.1-5.el7 Not Installed libselinux-utils 2.5-6.el7 Not Installed binutils 2.25.1-22.base.el7 Not Installed rhn-setup 2.0.2-8.0.4.el7 Not Installed Here you can see that 85 packages were removed from the standard image. Some of the removals are obvious optimizations - removing unneeded utilities and libraries and others are notable as they highlight some interesting issues in the regular image - for example, openssh-server has been removed - which you might argue has no business being installed in a container image in the first place. There are other changes such as the removal of dbus and kmod that really go to highlight how many containers are being built today. I’d argue that in many cases organizations aren’t deploying microservices they are deploying microVMs. Many images look like a whole operating system but just packaged up in a Docker image. There’s a lot of other fat that can be trimmed from most containers - for example take a look at the contents of this image: navigate to the contents tab, look at the files view and filter for /bin and while you scroll through the 51 pages ask if these binaries are really needed in your image. There’s a lot of work still to be done by most Linux distro vendors to build more efficient and more secure images. Removing selected RPMs and DEBs helps but the size and scope of many of the operating system packages still lead to more content being installed that is required. One cautionary note: While size certainly does matter it should not be your only consideration in selecting a base image to use from DockerHub or any other registry. Ensure that the image is well maintained - for example, check that it gets updated frequently enough to meet your needs. Is the content coming from known-good sources? You certainly don’t want to bring in packages from an unknown origin. Are the operating system packages being maintained and tested including security fixes with published CVE security feeds, is the default out-of-the-box configuration secure? Anchore can help you answer those questions - whether it’s by using the Navigator to pre-screen images for security issues and to view update history or by building custom policies that define your own rules for certifying your containers. ### Keeping Secrets Docker recently announced an exciting new release of Docker Datacenter that included Integrated Secrets Management from Docker 1.13. Many containers need access to sensitive information as part of their configuration, for example, they may need the password to access a database or the API key to access web services. These secrets need to be securely passed to the running container. In the past various other mechanisms have been used to pass secrets including using environment variables and volume mounting files from the host into the container. Each of these, and other, alternatives have their own individual drawbacks but all share the same issue: they store unencrypted secrets on the host that an administrator may be able to see. There are other solutions that can be used to securely manage secrets, for example, the popular Vault project from HashiCorp, however, having integrated secrets management is a great step forward. As many organizations are now moving away from legacy approaches such as environment variables and volumes to pass secrets to using Docker’s new integrated secrets management or 3rd party solutions such as Vault it is important to ensure that you are not already inadvertently including sensitive information such as passwords, certificates and API keys within your image. During testing and development, it is very easy to leave artifacts such as private certificates or keys within your image to simplifying testing and in many cases these can inadvertently be carried forward into your production deployment. The most famous example of this occurred last summer when Twitter’s now-defunct Vine service was analyzed by a security researcher who found that they had mistakenly disabled authentication on their Internet-facing Docker registry. The researcher was able to pull Vine’s images down to his laptop and inspect them. Within these images, he found API keys, source code and other secrets. While many users are scanning their images for CVEs, an image may pass this basic check but may still be insecure, misconfigured or in some other way out of compliance. Container images typically contain hundreds, often thousands of files – some coming from operating system packages, some from configuration files, some from 3rd party software libraries such as Node.JS NPMs, Ruby GEMs, Python modules, Java Archives, and some may be supplied by the user. Each one of these artifacts should undergo the same level scrutiny as the operating system packages. One of the critical checks that should be performed before an image is deployed is to ensure that it does not contain source code, sensitive configuration information and secrets such as API keys and passwords. Anchore takes a very different approach to image security than traditional image scanners that look for CVEs. Using Anchore users can define policies that specify rules to govern security vulnerabilities, package whitelists and blacklists, configuration file contents, presence of credentials in an image, manifest changes, exposed ports or any user-defined checks. These policies can be deployed site-wide or customized for specific images or categories of applications. You can read more about Anchore’s policy-based approach, however, if you want to take a more practical approach you can use open source Anchore Engine to inspect your own images and look for secrets. The following guide will walk you through setting up Anchore and analyzing your images, it should take no more than 10 minutes. There are a number of ways to install Anchore including using operating system packages, PIP or even via a container. In this example, I’m using a CentOS 7 host that is already running Docker. If the system is not already configured to use the Extra Packages for Enterprise Linux (EPEL) repository then I need to run: # yum install epel-release Installing Anchore is as simple as installing a YUM repo file and then installing a single package. # yum install http://repo.ancho.re/anchore/1.1/centos/7/noarch/anchore-release-1.1.0-1.el7.centos.noarch.rpm # yum install anchore At this point Anchore is installed, all we need to do now is run a sync to download the latest security data from the Anchore service. # anchore feeds sync Now we are ready to analyze containers. Presuming the container image has been pulled to the localhost you can simply run the analyze command. In my example, I’m analyzing the myapp:latest image. # anchore analyze --image=myapp:latest If the Dockerfile is available then you can pass the Dockerfile to the anchore command, this provides a little more information to the analysis routine but is not required. # anchore analyze --image=myapp:latest --dockerfile=/path/to/my/Dockerfile We can now run a policy check on the image. The default policy does not perform any checks for secrets but we can easily add that check. Create a file named mypolicy and enter the following lines: DOCKERFILECHECK:NOTAG:STOP DOCKERFILECHECK:SUDO:GO DOCKERFILECHECK:EXPOSE:STOP:DENIEDPORTS=22 DOCKERFILECHECK:FROMSCRATCH:WARN DOCKERFILECHECK:NOFROM:STOP SUIDDIFF:SUIDFILEDEL:GO SUIDDIFF:SUIDMODEDIFF:STOP SUIDDIFF:SUIDFILEADD:STOP PKGDIFF:PKGVERSIONDIFF:STOP PKGDIFF:PKGADD:WARN PKGDIFF:PKGDEL:WARN ANCHORESEC:VULNUNKNOWN:GO ANCHORESEC:VULNHIGH:STOP ANCHORESEC:VULNMEDIUM:WARN ANCHORESEC:VULNLOW:GO ANCHORESEC:VULNCRITICAL:STOP ANCHORESEC:UNSUPPORTEDDISTRO:WARN FILECHECK:FILENAMEMATCH:STOP:FILECHECK_NAMEREGEXP=.*/.ssh/id_rsa$ The last line uses the FILECHECK policy check. Here we are looking at a list of all the files in the image and using a regular expression to look for any private ssh keys in the image. The FILECHECK policy module (or gate) can do matching on filenames or on filecontents, for example looking for specific strings within any file in the image. In this example, we are simply looking for ssh keys. # anchore gate --image=myapp:latest --policy=/path/to/mypolicy In my test image policy check returns two lines. The last line gives the final result of the policy check issuing a “STOP” meaning that the image has failed. The first line shows the policy that triggered this failure. Depending on your image you may see more or fewer policy violations. +--------------+-------------------+-----------+---------------+-------------------+-------------+ | Image Id | Repo Tag | Gate | Trigger | Check Output | Gate Action | +--------------+-------------------+-----------+---------------+-------------------+-------------+ | 9f767c5486f4 | aic-secret:latest | FILECHECK | FILENAMEMATCH | application of | STOP | | | | | | regexp matched | | | | | | | file found in | | | | | | | container: file=/ | | | | | | | root/.ssh/id_rsa | | | | | | | regexp=.*/.ssh/id | | | | | | | _rsa$ | | | 9f767c5486f4 | aic-secret:latest | FINAL | FINAL | | STOP | +--------------+-------------------+-----------+---------------+-------------------+-------------+ This simple policy performs just a few checks on your image and in the case of secrets only looks for private SSH keys however this policy can easily be extended to look for any secrets or blacklisted artifacts in your image. ### Anchore 1.1 Has Arrived We started the week with an exciting announcement about the Anchore Navigator which received a significant update with many new features, the two new features that are proving to be the most popular are the ability submit an image for analysis and the ability to subscribe to receive notifications when an image has been updated. But that’s not the only release that Anchore is announcing this week. We are proud to announce the 1.1 release of the Anchore’s open source project. The open source engine is at the heart of all of our products - the Navigator, our SaaS service and our on-premise solution. The team at Anchore believes strongly in open source and especially in the need for open source solutions around compliance and governance. How do you have confidence in a certification test if you don’t know that the test is being performed accurately and without any bias? By building the solution on top of an open source engine with compliance policies that are publicly available, anyone can re-run these tests to verify the results, in short, you can “trust but verify”. The Most Notable Improvements in the 1.1 Release   Support for Ruby Gems Anchore now supports detailed scanning for Ruby Gems. All Gems within the container image are reported including their name, version, origin, source, license and location. Anchore’s commercial release now includes a Gem data feed that provides detailed information about Ruby Gems published on the official Gem repository and this information can be used during policy evaluations. For example to check if a Gem comes from the official repository or to report on Ruby Gems that are not up to date. Other policy checks include blacklisting and license checking. CVE scanning for Alpine Linux Previously Anchore could report on files and packages within Alpine Linux based images but not report on CVEs. This release adds support for scanning Alpine images and reporting on known CVEs based on the vulnerability data found in Alpine’s security database and within the National Vulnerability Database (NVD) maintained by NIST. Global Whitelisting Anchore supports the creation of whitelists on a per-image basis - for example, “exclude CVE-2015-8710 from policy evaluation for image myapp:latest”. The 1.1 release allows a global whitelist to be created allowing organizations to define a curated list of CVEs or other policy checks that are globally excluded during policy evaluation. Debian CVE scanning Debian CVE reporting has been updated and will show the binary package that contains the CVE rather than the corresponding source package. UX and performance A number of additional improvements have been made to improve user experience - for example simplifying command line options and to improve the performance of scanning. More details can be found in the changelog on GitHub. You learn more about our open source release here or contact us using the form below to schedule a 1-on-1 product demonstration. ### A Better Way to Navigate Container Registries In October 2016 Anchore announced the first release of our commercial product, built on top of our open source container analysis engine. The focus of the open source project and the commercial offering is to deliver tools that perform deep analysis on container images and allow organizations to define policies that govern the deployment of their containers, ensuring that only containers that comply with the organization's security policy or operational best practices are deployed. At the same time, we also released the Anchore Navigator which provided a free service to allow users to discover and analyze images on public container registries. At launch, the Navigator included in-depth analysis of all official repositories on DockerHub and 50 of the most popular repositories. Then early in December, we updated the Navigator to add support for basic analysis of all public images on DockerHub allowing users to view basic information such as the image size, layer information, image ID, Digest and creation date. Today we are announcing a new release of the Navigator that adds a number of powerful new features to this free SaaS service. Submit Images for Analysis The first new feature adds the ability for users to submit any public tagged image to Anchore for analysis. At the top of the preview page for an image, there is a button to submit the image for analysis. Once submitted this TAG is added to Anchore’s catalog and will be queued up to be downloaded and analyzed. After the first analysis, Anchore will poll the registry for changes and will download new versions of the TAG for analysis whenever the TAG is updated. Subscriptions Another powerful new feature is Subscriptions. Users can subscribe to a TAG and will be notified when the TAG is updated. For example, if you use ubuntu:latest as the base image for your containers then when the Ubuntu community push a new ubuntu:latest image to the registry you will receive a notification email from Anchore. Webhook notifications will be added in an upcoming release. Images can be marked as “favorites” to allow users to quickly access these images. Organizing Images A new option has been added on the menu bar for “My Images” Within the ‘My Images’ page users can view their favorite and subscribed images and quickly see the status of these images - for example, to see when an image was last updated. Ruby Gems Support In addition to operating system packages, all files and Node.JS NPMs the Navigator now allows you to see a detailed list of all Ruby GEMs installed in the image, showing details of the packages, including version, license, location and Origin. Support for Alpine Linux Anchore Navigator now supports CVE scanning of Alpine Linux images, incorporating security feeds from the Alpine Projects Vulnerabilities database and the National Vulnerabilities Database. Registry Support The Navigator has been built to support multiple registries both public and private registries and to analyze images in Docker’s native format and the upcoming Open Containers Initiative (OCI) Image Format. Over the coming months, more registries including private ISV registries will be included within the Navigator’s catalog. There are more interesting features in development including support for WebHook and Slack notifications, support for deeper analysis of Python libraries and Java Archives along with the ability to analyze private images and define custom policies and whitelists in the commercial Navigator offering. ### Comparing Images As anyone who has worked in IT support or operations for any period of time will tell you, if you get a call telling you that something stopped working, then the first question you should ask is “what changed?”. This is especially true if the application or server in question has been working well for sometime before. Keeping track of what changed, or preventing changes from occurring is an important part of IT today, so much so that there is a large ecosystem of vendors and open source projects covering change/release management and monitoring. Knowing just that something has changed is a good first step but you really need to know the details of what changed. The most common way to do this is to look at the changelog. Maintaining a changelog for your application or other software project is considered best practice today and it is important to make sure the changelog is well structured and contains all relevant, but notable, information. As one great resource explains “Don’t let your friends dump git logs into CHANGELOGs”. Operating system vendors typically create release notes that provide a high-level summary of the notable changes in a release, for example in the release notes for CentOS 7.3 and these vendors also include changelogs for individual software packages. For example: # rpm -q --changelog glibc * Fri Dec 23 2016 Carlos O'Donell - 2.24-4 - Auto-sync with upstream release/2.24/master, commit e9e69e468039fcd57276f783a16aa771a8e4214e, fixing: - Shared object unload assert when calling dlclose (#1398370, swbz#11941) - Fix runtime resolver routines in the presence of AVX512 (swbz#20508) - Fix writes past the allocated array bounds in execvpe (swbz#20847) - Fix building with GCC 6.2 on i686 with stack protector. - Fix building with GCC 7. - Fix POWER6 memset with recent binutils. - Fix POWER math test expected failures. - Fix cancellation in posix_spawn. - Fix multiarch builds for POWER9. … But in the world of containers things aren’t quite so easy. Containers are, by design, opaque. A user downloads an application container for the application they want, for example, NGINX, and may not know how that container is built, for example, what operating system is used under the covers, let alone what changes were made between releases. There are no easy ways to perform a “diff” on Docker container images to see what has changed between versions. While there is a docker diff command this command shows what files have changed in a running container but will not show changes between container images. You could also look at the Dockerfile, however, the same Dockerfile used at two different times will likely produce different images since the underlying operating system packages and application files may have been updated. So today we want to show you how you can compare two container images to see what changes have been made. For this example, I’ll compare the latest version of the CentOS image with the previously published version. If you want to visually inspect the latest CentOS image you can do so using Anchore Navigator you can simply search for CentOS and then select the ‘latest’ tag or you can go directly to this link: Here you can see that this image was last updated on the 15th of December. I’m going to pull down this image to my local machine by running # docker pull centos:latest Running docker images  on my local machine will show this latest version of CentOS, however, if I don’t have the previous centos:latest image I need to pull that image from Docker Hub. While it’s simple to get the current centos:latest image from Docker Hub it’s not quite so easy to find the previous version, however, that’s something that Anchore Navigator can help with. On the overview page of the centos:latest image you’ll see a Previous Image button in the top left, clicking that will take you to the previous version of centos:latest, or you can go directly there using this link. In the screenshot below you can see that this version is no longer tagged, it’s still available on Docker Hub but no longer has the latest tag or any other tag. It was published on the 2nd of November and then replaced on the 15th of December. One little known feature of Docker & Docker Hub is the ability to pull an image by its digest. So you can click the  button next to the digest to copy the digest into the clipboard and then run the following command: docker pull centos@sha256:b2f9d1c0ff5f87a4743104d099a3d561002ac500db1b9bfa02a783a46e0d366c This will pull down the previous version of centos:latest. Running docker images --digests centos will show the centos images along with their corresponding digests and IDs. REPOSITORY TAG DIGEST IMAGE ID CREATED SIZE docker.io/centos latest sha256:c577af3197aacedf79c5a204cd7f493c8e07ffbce7f88f7600bf19c688c38799 67591570dd29 3 weeks ago 191.8 MB docker.io/centos sha256:b2f9d1c0ff5f87a4743104d099a3d561002ac500db1b9bfa02a783a46e0d366c 0584b3d2cf6d 9 weeks ago 196.5 MB docker.io/centos sha256:2ae0d2c881c7123870114fb9cc7afabd1e31f9888dac8286884f6cf59373ed9b 980e0e4c79ec 4 months ago 196.7 MB docker.io/centos 7.2.1511 sha256:0d121fa7987c60c3f7ecb8d7347d8e86683018625e44f3864e69b388087a4d0b feac5e0dfdb2 4 months ago 194.6 MB docker.io/centos 7.0.1406 68c19b8863f0 6 months ago 210.2 MB docker.io/centos 7.1.1503 80d283436f62 6 months ago 212.1 MB We will now use Anchore to analyze both images. # anchore analyze --imagetype=none --image=centos:latest # anchore analyze --imagetype=none --image=0584b3d2cf6d Now that anchore has analyzed the images we can perform queries on the images. # anchore query --image=centos:latest show-pkg-diffs 0584b3d2cf6d This command will show the differences in package manifests between the two images, a portion of that output is included below: +--------------+-------------------------+------------------+--------------------------+----------------------+--------------------------+ | Image Id | Repo Tag | Compare Image Id | Package | Input Image Version | Compare Image Version | +--------------+-------------------------+------------------+--------------------------+----------------------+--------------------------+ | 67591570dd29 | docker.io/centos:latest | 0584b3d2cf6d | nss-tools | 3.21.3-2.el7_3 | 3.21.0-9.el7_2 | | 67591570dd29 | docker.io/centos:latest | 0584b3d2cf6d | python-urlgrabber | 3.10-8.el7 | 3.10-7.el7 | | 67591570dd29 | docker.io/centos:latest | 0584b3d2cf6d | iputils | 20160308-8.el7 | 20121221-7.el7 | | 67591570dd29 | docker.io/centos:latest | 0584b3d2cf6d | expat | 2.1.0-10.el7_3 | 2.1.0-8.el7 | | 67591570dd29 | docker.io/centos:latest | 0584b3d2cf6d | audit-libs | 2.6.5-3.el7 | 2.4.1-5.el7 | | 67591570dd29 | docker.io/centos:latest | 0584b3d2cf6d | gnupg2 | 2.0.22-4.el7 | 2.0.22-3.el7 | | 67591570dd29 | docker.io/centos:latest | 0584b3d2cf6d | xz | 5.2.2-1.el7 | 5.1.2-12alpha.el7 | | 67591570dd29 | docker.io/centos:latest | 0584b3d2cf6d | nss-sysinit | 3.21.3-2.el7_3 | 3.21.0-9.el7_2 | | 67591570dd29 | docker.io/centos:latest | 0584b3d2cf6d | file-libs | 5.11-33.el7 | 5.11-31.el7 | | 67591570dd29 | docker.io/centos:latest | 0584b3d2cf6d | rpm-build-libs | 4.11.3-21.el7 | 4.11.3-17.el7 | | 67591570dd29 | docker.io/centos:latest | 0584b3d2cf6d | libgcc | 4.8.5-11.el7 | 4.8.5-4.el7 | This default formatting is designed for viewing in the terminal however you can use the --json or --plain command line options to produce output more suited to automated processing. For example: # anchore --json query --image=centos:latest show-pkg-diffs 0584b3d2cf6d Anchore also includes a command to show what files have changed in an image. # anchore query --image=centos:latest show-file-diffs 0584b3d2cf6d +--------------+-------------------------+------------------+-----------------------------------+-----------------------------------+-----------------------------------+ | Image Id | Repo Tag | Compare Image Id | File | Input Image File Checksum | Compare Image Checksum | +--------------+-------------------------+------------------+-----------------------------------+-----------------------------------+-----------------------------------+ | 67591570dd29 | docker.io/centos:latest | 0584b3d2cf6d | /usr/bin/signtool | d0fd71514d28636fa0afd28f2ce8a04dc | 3094cc4c9f8b507513bd945cad92b2098 | | | | | | a9d837e45895900ce3a293adfec4adb | b8d6bf84956bbf1adec828690fc48c6 | | 67591570dd29 | docker.io/centos:latest | 0584b3d2cf6d | /var/lib/yum/yumdb/l/8b0fec58c4cb | ec25c418f1f5d51128ddbf924e633b3c5 | NOTINSTALLED | | | | | 6f239014f68fff4b4f8681694628-libb | 102649304f1c1a106afccd061f6aa35 | | | | | | lkid-2.23.2-33.el7-x86_64/checksu | | | | | | | m_data | | | | 67591570dd29 | docker.io/centos:latest | 0584b3d2cf6d | /usr/bin/sha224sum | af0e2ff0d30605159cf6d79fc59055b1a | 5c233b844571c856ce9cb7059a88e0cf6 | | | | | | 87fdff577358439844afcbc98ca1acf | 0ee372d43f1f1cc4a02599b9d3ac8d0 | | 67591570dd29 | docker.io/centos:latest | 0584b3d2cf6d | /usr/lib64/python2.7/lib- | 1506d2df911351ae57e0c498adfa3faa4 | f0c9c6f0f6b1597624c7bb4cb55d4f2d7 | | | | | dynload/_codecs_kr.so | 408ca4df07466fafa69a10613b11922 | 9d319697dff3bf6ffb27fac47afc0f7 | | 67591570dd29 | docker.io/centos:latest | 0584b3d2cf6d | /var/lib/yum/yumdb/s/c13227f13b29 | NOTINSTALLED | DIRECTORY_OR_OTHER | | | | | f6866c96d050aebd6098d7a62809-setu | | | | | | | p-2.8.71-6.el7-noarch/checksum_ty | | | | | | | pe | | | | 67591570dd29 | docker.io/centos:latest | 0584b3d2cf6d | /usr/share/licenses/device- | NOTINSTALLED | 32b1062f7da84967e7019d01ab805935c | | | | | mapper-libs-1.02.107/COPYING | | aa7ab7321a7ced0e30ebe75e5df1670 | | 67591570dd29 | docker.io/centos:latest | 0584b3d2cf6d | /usr/lib64/gconv/DEC-MCS.so | 5d098b7ce2079a621a0f99ae44f959f20 | 764b1597a91a39f799dd3f96051540864 | | | | | | 15a1d64527650f2cc47982a4d9bd3ab | 9089e7b2154541a630e92fa586c11f9 | | 67591570dd29 | docker.io/centos:latest | 0584b3d2cf6d | /var/lib/yum/yumdb/r/1f4b80c13100 | NOTINSTALLED | DIRECTORY_OR_OTHER | | | | | 951f6f606b7ee0519abe674f0168-rpm- | | | | | | | build- | | | | | | | libs-4.11.3-17.el7-x86_64/reason | | | | 67591570dd29 | docker.io/centos:latest | 0584b3d2cf6d | /usr/lib64/python2.7/symtable.pyc | 16eef0372b200028ae390b22dd1093b00 | 533e494e479e040772edfedfdc70c2923 | | | | | | 772c6011002c8cfb08e01e183a55dfd | 333ceeac3520f8ef42f170b74317425 | The challenge with interpreting the output of this command is that nearly 4,000 files have changed since 80 packages have changed so there's a lot of "noise" since these file changes are expected. We should still look for file changes since files that are not part of an operating system package may be changed, for example, configuration files or application files. To make this easier the enterprise release of Anchore contains the new command to show the files that are now owned by an operating system package. # anchore query --image=centos:latest show-non-packaged-files all / The all parameter specifies that all changes should be displayed. We can use a number such as 2 to specify the depth of directories that are analyzed, for example using 2 would show just the top-level directories that contain changes. +--------------+-------------------------+------------------------------------------------+ | Image Id | Repo Tags | File/Directory Name | +--------------+-------------------------+------------------------------------------------+ | 67591570dd29 | docker.io/centos:latest | /var/log/anaconda/storage.log | | 67591570dd29 | docker.io/centos:latest | /run/systemd/sessions | | 67591570dd29 | docker.io/centos:latest | /run/user | | 67591570dd29 | docker.io/centos:latest | /tmp/yum.log | | 67591570dd29 | docker.io/centos:latest | /usr/lib/locale | | 67591570dd29 | docker.io/centos:latest | /tmp/.X11-unix | | 67591570dd29 | docker.io/centos:latest | /etc/sysconfig/network-scripts | | 67591570dd29 | docker.io/centos:latest | /usr/lib64/p11-kit-trust.so | | 67591570dd29 | docker.io/centos:latest | /var/log/anaconda/ks-script-s0_pQV.log | | 67591570dd29 | docker.io/centos:latest | /usr/lib64/pkcs11 | | 67591570dd29 | docker.io/centos:latest | /etc/rsyslog.d | | 67591570dd29 | docker.io/centos:latest | /var/log/anaconda/ifcfg.log | | 67591570dd29 | docker.io/centos:latest | /tmp/ks-script-LRoSA2 | | 67591570dd29 | docker.io/centos:latest | /lost+found | | 67591570dd29 | docker.io/centos:latest | /etc/crypttab | | 67591570dd29 | docker.io/centos:latest | /run/systemd/machines | | 67591570dd29 | docker.io/centos:latest | /run/log | | 67591570dd29 | docker.io/centos:latest | /usr/lib/firewalld/ipsets | | 67591570dd29 | docker.io/centos:latest | /etc/alternatives/ld | | 67591570dd29 | docker.io/centos:latest | /etc/group- | | 67591570dd29 | docker.io/centos:latest | /usr/lib64/fipscheck | | 67591570dd29 | docker.io/centos:latest | /var/lib/alternatives/libnssckbi.so.x86_64 | | 67591570dd29 | docker.io/centos:latest | /etc/openldap/certs/password | | 67591570dd29 | docker.io/centos:latest | /var/lib/yum/yumdb | | 67591570dd29 | docker.io/centos:latest | /etc/systemd/system/multi-user.target.wants | | 67591570dd29 | docker.io/centos:latest | /etc/systemd/system/system-update.target.wants | And there is a similar command to compare non-packaged files between images which shows the files that are not part of operating system packages that have changed between two images. # anchore query --image=centos:latest show-non-packaged-files-diff all / 0584b3d2cf6d When performing this query on your own images you may find a lot of noise caused by temporary files or logs. For example /var/lib/yum may contain data from package installs or updates. Directories can be filtered out using the exclude= option on the command line. To summarize - you should be able to quickly produce a changelog for a container in 3 simple steps: Step 1: Analyze the images you wish to compare: # anchore analyze --imagetype=none --image=myapp:latest # anchore analyze --imagetype=none --image=myapp:old Step 2: Run a query to report on the package changes anchore query --image=centos:latest show-pkg-diffs my app:old Step 3: Run a query to report on the (non packaged) file changes # anchore query --image=centos:latest show-non-packaged-files-diff all / myapp:old These commands will produce human-readable output, complete with tables, however, you can easily add --json or --plain  to produce machine-parsable output. You can download and install the Anchore open source project now on GitHub or request a demo of Anchore Enterprise. ### Hanlon's Images Occam’s razor is a well known philosophical principle that’s entered mainstream culture. While there are many ways to describe this principle the most succinct is:      “The simplest answer is most often correct.” The lesson behind this razor is that if there are many explanations for a particular phenomenon, then out of the many and often complex alternative explanations the simplest is likely the most likely to be correct. In philosophy, a razor is a principle that helps you “shave off” unlikely explanations. I’d like to share with you another razor, one that is less well known but that I have found to be very useful in assessing situations I encounter in day to day life and especially around security. Hanlon’s Razor states:      "Never attribute to malice that which is adequately explained by stupidity” Or in other words:      "Don't assume bad intentions over neglect and misunderstanding.” Over the last 6 months, we’ve spoken to many organizations about container security and the need to apply governance within their container infrastructure. One question that has come up often is this: “If I’m only using official images or building my own images why do I need to scan?” This is a fair question and before I invoke Hanlon it’s worth a little discussion. Let’s start with the first point, Official images: Of the many thousand repositories on DockerHub there are around 140 special repositories that are classified as Official repos. These are a set of curated repos that have been created by an organization or community and submitted to Docker Inc and the community for official review. The official repos are among the most popular images on DockerHub and undergo detailed review before being classified as official including adherence to Dockerfile best practices in creating the image. Using the Official repos, especially the base operating system images, is a good best practice as it ensures that you are starting off with content from a known source. But care should still be taken in the use of these images. While some official images are updated frequently, many images (especially base OS images) are often only updated on a monthly basis or sometimes even less frequently. A quick way to get an idea of this is to look at the Anchore Navigator and sort by the “Repo Last Updated” column. You’ll notice an “Update Frequency” column on the Navigator which currently displays “Gathering Data”. Anchore’s cloud service continually monitors DockerHub for changes, pulling down and analyzing images as they are updated. We’ve gathered several months' worth of history and over the coming weeks, we’ll give a visual indication of the frequency of updates within this column. Another common problem that we’ve heard from many organizations is that while a developer may be using the image tagged latest they may not be aware that the latest image has been updated and so the ‘new latest’ image needs to be pulled down from DockerHub. Regardless of how often an image is updated it should still be scanned for vulnerabilities before deployment as many of the official images, not to mention the tens of thousands of public images, contain exploitable vulnerabilities. So whether you base your containers off an official image from DockerHub, a public image, or build an image from scratch then it’s good practice to ensure that all the latest package updates have been applied to the image. Scanning and updating the operating system packages is just the first step in ensuring that your images are secure, while this will address common issues such as known vulnerabilities in operating system packages (CVEs) we believe that this is just the tip of the iceberg. It’s possible to have all the latest operating system packages but still have an image that has security vulnerabilities or is otherwise not compliant with your operational, security or business policies. One area that is often overlooked is third party software libraries that are used within your applications such as Node.JS modules pulled from the public NPM or Ruby GEM repositories. A great example of this came at the end of December where a remote code execution vulnerability was reported in the PHPMailer library that’s widely used in many in-house PHP applications as well as common off the shelf applications such as WordPress, Drupal and SugarCRM. While a CVE has been assigned to this vulnerability a simple scan of operating system packages would likely not find this since many developers do not pull in their PHP, Ruby or Node libraries from operating system packages. Even with the latest operating system packages and with well-written applications using up to date libraries, a container image may be made insecure due to misconfiguration which may be caused by administration or debugging options that are left enabled or by misconfigured encryption or SSL certificates or through enabling unnecessary services within your container image. A great example of this was seen last year at Vine where a security researcher found source code and API keys embedded within the container image. And Here is Where Hanlon can Help      "Don't assume bad intentions over neglect and misunderstanding.” In all likelihood the security or compliance issues that you will encounter within your image won’t be due to malicious intent - where a hacker has embedded malware in a public image that you consume, most of the issues will be caused by mistakes that are made: packages that are not updated, 3rd party libraries that are vulnerable or simple application misconfigurations which is why scanning should be in place for all images no matter the source of the image even if all content was developed in house - you are looking for mistakes as well as for malice. While image scanning solutions focus on scanning the operating system image for known vulnerabilities Anchore provides a deeper level of analysis into images looking at the operating system, 3rd party libraries, configuration files, etc. With Anchore, organizations can define their own policies that describe their certification needs, covering all aspects of the images, that can be run at any time both on images that they may consume from public sources and on images that are created in house. ### Deeper Analysis with Anchore Since we announced Anchore 1.0 back in October we have spent a great deal of time talking to our community users, partners and enterprises about their compliance and governance needs. Many of these conversations followed a similar pattern: Initial excitement about Docker and container deployments, followed by concerns about security, then the challenge of balancing the desire to support agile development and innovation with the need for compliance and security. We’ve heard from these users that many have a basic system in place to perform the first level of checks on their images, which are focused on CVEs, however, they understand that this is not enough. In our conversations with these organizations, we spend a lot of time talking about the CVE scanning being the tip of the iceberg and many of our discussions then focus on how to go deeper into container inspection and analysis. At Anchore our focus has been to deliver tools and services that go below the surface to perform deep analysis on container images and allow organizations to define policies that specify rules to govern security vulnerabilities, package whitelists and blacklists, configuration file contents, presence of credentials in image, manifest changes, exposed ports or any user-defined checks. Last week we outlined a number of new features we added to the Anchore Navigator which added deeper container scanning including the ability to report on Node.JS NPM modules. Today we would like to announce the latest release of both Anchore’s open source project and Anchore’s Enterprise offering. Over the coming weeks, we will deep dive into each of the new features in this release and outline the roadmap for the coming months. We’ll highlight the 3 most significant features in the 1.0.3 release however you can get more details from the changelog in our Github repository. Node.JS NPM Support In addition to the operating system packages and all files in the image Anchore now reports on all Node.js NPMs that are installed in the image. These software libraries are often overlooked; they are not covered by security scanning tools and do not undergo the same level of scrutiny and governance than the operating system yet in many cases you’ll find more NPM packages in your image than you have operating system packages. Node.JS Data Feed The enterprise offering builds on top of the NPM reporting in the open source project to allow organizations to build policies that govern the use of NPM modules in their container images. For example allowing an organization to blacklist specific modules, specify minimum versions or even block deployment of outdated modules. Advanced Content Policies It is not enough to just look at the operating system packages and software packages such as NPM modules. It’s possible to have all of the latest operating system packages but still have an image that’s got security vulnerabilities or is otherwise not compliant with your operational, security or business policies. A great example of this was seen this summer when a security researcher found source code and secrets (API keys) within a Vine container image that was publicly accessible. In this release, we have added the ability to perform detailed checks against both the names and the contents of files. While this feature enables the ability to perform a wide variety of checks one of the most interesting use cases is to scan the image for ‘secrets’. For example, search for .CER or .PEM files that may contain private keys for certificates, look for source code or inspect the contents of specific files for saved passwords or API keys. These are just a few of the new features added in this release. We’ll cover these in more detail in the coming days. If you want to learn more please fill out the form below and our team will reach out to you. ### Anchore Joins the Open Container Initiative Today we formally announced that Anchore had joined the Open Container Initiative (OCI). The OCI was established to develop standards for containers, initially focusing on the runtime format specification but later adding the container image format specification. Container adoption is accelerating rapidly and the ecosystem is exploding with new vendors who are providing features such as orchestration, monitoring, deployment and reporting. Standards are critical to the adoption of containers, ensuring that customers can choose their cloud provider, orchestration platform or monitoring tool without worrying about interoperability between these platforms and without being locked into one particular stack or vendor. In the early days of the OCI concerns were raised about the overhead that is sometimes seen with standards bodies that can be bureaucratic and slow to come to an agreement. As such there was a real concern that the standardization process may stifle innovation in the container market which had seen rapid innovation and adoption. The incredible progress we have seen made by the OCI within its first 18 months seems to have put those concerns to rest and the OCI community is growing with nearly all of the leading players in the container market participating in this important work. The image format specification is of particular interest to Anchore. This format covers the low-level details of container images including both the filesystem image and the associated metadata required to run the image. Today Anchore‘s Container Image scanning engine understands the low-level details of the Docker image format and is able to perform detailed analysis on these images. Over the coming months, Anchore will add support for the OCI image specification to allow customers to perform analysis, compliance and certification tests on OCI images in addition to Docker images. We are looking forward to contributing to the specification, especially in the area of governance and compliance and by providing open source tools and services to allow OCI images to be analyzed and validated. ### Containers in Production, Is Security a Barrier? Fintan Ryan - Redmonk - December 1, 2016 Over the last week, we have had the opportunity to work with an interesting set of data collected by Anchore (full disclosure: Anchore is a RedMonk client). Anchore collected this data by means of a user survey ran in conjunction with DevOps.com. While the number of respondents is relatively small, at 338, there are some interesting questions asked, and a number of data points which support wider trends we are seeing around container usage. With any data set of this nature, it is important to state that survey results strictly reflect the members of the DevOps.com community. The data set covered a number of areas including container usage and plans, orchestration tools, operating system choices, CI tools and security. For this post we will be focusing on the data around containers and CI. Read the original and complete article on RedMonk. ### How Fast Can You Add Image Scanning to Jenkins? Last month we blogged about securing your Jenkins pipeline, how within 10 minutes you could add, for free, image scanning, analysis and compliance validation. Since then we’ve spoken to many organizations who’ve had the opportunity to add security to their CI/CD pipeline. And it’s also been pointed out that if you don’t read the marketing preamble the whole process takes around 3 minutes before you are ready to analyze your first build. So in this short blog, we want to see if we can set a record - how quickly can we really add image scanning to your CI/CD pipeline. This video was recorded on a virtual machine running Docker 1.11 and Jenkins 2.32. Without caching or pre-loading images our time is 2 minutes and 34 seconds - from the start of the install through to kicking off the build. Can you beat that? In less time than it takes to make a coffee you can secure your Jenkins pipeline. Please tweet us at @anchore with the hashtag #SecureWithAnchore to let us know your times. To learn more please contact us using the form below, or request a demo by clicking the button in the menu above. ### Keeping Linux Containers Safe and Secure Jason Baker - Opensource.com - October 4, 2016 Linux containers are helping to change the way that IT operates. In place of large, monolithic virtual machines, organizations are finding effective ways to deploy their applications inside Linux containers, providing for faster speeds, greater density, and increased agility in their operations. While containers can bring a number of advantages from a security perspective, they come with their own set of security challenges as well. Just as with traditional infrastructure, it is critical to ensure that the system libraries and components running within a container are regularly updated in order to avoid vulnerabilities. But how do you know what is running inside of your containers? To help manage the full set of security challenges facing container technologies, a startup named Anchore is developing an open source project of the same name to bring visibility inside of Linux containers. To learn more about Anchore, I caught up with Andrew Cathrow, Anchore's vice president of products and marketing, to learn more about the open source project and the company behind it. In a Nutshell, What is Anchore? How does the Toolset Work? Anchore's goal is to provide a toolset that allows developers, operations, and security teams to maintain full visibility of the 'chain of custody' as containers move through the development lifecycle, while providing the visibility, predictability, and control needed for production deployment. The Anchore engine is comprised of pluggable modules that can perform analysis (extraction of data and metadata from an image), queries (allowing reporting against the container), and policy evaluation (where policies can be specified that govern the deployment of images). While there are a number of scanning tools on the market, most are not open source. We believe that security and compliance products should be open source, otherwise, how could you trust them? Anchore, in addition to being open source, has two other major differentiators that set it apart from the commercial offerings in the market. First, we look beyond the operating system image. Scanning tools today concentrate on operating system packages, e.g. "Do you have any CVEs (security vulnerabilities) in your RPMs or DEB packages?" While that is certainly important, you don't want vulnerable packages in your image, the operating system packages are just the foundation on which the rest of the image is built. All layers need to be validated, including configuration files, language modules, middleware, etc. You can have all the latest packages, but with even one configuration file wrong, insecurity sets in. A second differentiator is the ability to extend the engine by adding users' own data, queries or policies. Read the original and complete article on OpenSource.com. ### Startup Nets $5 Million to X-ray & Secure Software Containers Barb Darrow - Fortune - October 4, 2016 Anchore has $5 million in seed funding to attack knotty container issues. Anchore, a startup that says it can ensure that software “containers” are safe, secure, and ready to deploy, is introducing its first product along with announcing $5 million in seed funding. For non-techies, containers are an emerging way to package up all the building blocks in software—the file system, the tools, the core runtime—into a nice bundle, or container, that can then run on any sort of infrastructure. That means, theoretically at least, the container, as exemplified by the popular Docker, can work inside a company’s data center, on Amazon Web Services, or some other shared public cloud infrastructure. That’s a lot more flexible than previously when business software was pretty much welded to the underlying hardware. Read the original and complete article on Fortune. ### Confident Production Deployment With Anchore 1.0 It has been just a little over five months since Anchore opened its doors, and we’re happy to announce the General Availability of Anchore 1.0 - combining an open source platform for community participation while addressing enterprise needs through an on-prem offering with additional feature augmentation, and Anchore Navigator, anchore.com, a free service that provides an unparalleled level of visibility into the contents of container images. As the adoption of containers continues to grow enterprises are increasingly demanding more visibility and control of their container environments. Today we see operations, security and compliance teams looking to add a level of governance to container deployments that were lacking during the early gold rush. The most common approach we have seen today is container image scanning which typically means scanning the operating system components of an image for security vulnerabilities, CVEs. While the need to scan an image for CVEs is undeniable it should only be the first step given the fact that each image typically contains hundreds of operating system packages, thousands of files along with application libraries and configuration files that are likely not part of the operating system image. Anchore 1.0 was designed to address the lack of transparency, allowing developers, operations and security teams to get visibility into the entire contents of the containers - far more than the surface CVE scans that we have seen today. Empowered with this detailed information operations, security and compliance teams can define policies that govern the deployment of containers, including rules that cover security vulnerabilities, mandatory software packages, blacklisted software packages, required versions of software libraries, validated configuration files or any one of a hundred other tests that an enterprise may require to consider an image compliant. The need for visibility and compliance extends beyond just point in time scanning of an image before deployment. In most cases application images are built from base images downloaded from public registries, these images may be updated often and in many cases without any obvious indication that a change was made let alone what was changed in these images. End-users have to struggle with the age-old choice: sticking with a known working but somewhat stale version, or use the latest, more feature-full, version and run the risk of security vulnerabilities, major bugs, and overall compliance deviation. Full transparency is no longer just a good option to have in your toolset, but a mandate for application development and operations teams alike. Using the most stable and secure baseline of an IT service should no longer translate to an antiquated version of the software. With the fast pace of innovation also comes risk, and companies, big and small, will benefit greatly from simply and easily uncovering and tracking all changes throughout the application development and production lifecycle. ### Is Docker More Secure? Over the last couple of years, much has been written about the security of Docker containers, with most of the analysis focusing on the comparison between containers and virtual machines. Given the similar use cases addressed by virtual machines and containers, this is a natural comparison to make, however, I prefer to see the two technologies as complementary. Indeed a large proportion of containers that are deployed today are run inside virtual machines, this is especially true of public cloud deployments such as Amazon’s EC2 Container Service (ECS) and Google Container Engine (GKE). While we have seen a number of significant enhancements made to container runtimes to improve isolation, containers will continue to offer less isolation than traditional virtual machines for the foreseeable future. This is due to the fact that in the container model each container shares the same host kernel so if a security exploit or some kernel-related bug is triggered from a container then the host system and all running containers on that host are potentially at risk. For use cases where absolute isolation is required, for example where an image may come from an untrusted source, virtual machines are the obvious solution. For this reason, multi-tenant systems such as public clouds and private Infrastructure as a Service (IaaS) platforms will tend to use virtual machines. In a single-tenant use case such as enterprise IT infrastructure where the deployment and production pipeline can be designed and controlled with security in mind, containers offer a lightweight and simple mechanism for isolating workloads. This is the use case where we have seen exponential growth of container deployments. We are starting to see crossover technologies such as Intel’s Clear Containers that allow containers to be run in lightweight virtual machines allowing the user to provide stronger isolation for a specific container when deemed necessary. Within the last year or so we have seen container isolation techniques improve considerably through the use of features of the Linux kernel such as Namespaces, seccomp, cgroups, SELinux and AppArmor. Recently Joerg Fritsch from Gartner published a research note and blog where he made the following statement: “Applications deployed in containers are more secure than applications deployed on the bare OS”. Following on from this note Nathan McCauley from Docker wrote a blog that dug further into this topic and referenced NCC group’s excellent white paper on Hardening Linux Containers. The high-level message here is that “you are safer if you run all your apps in containers”. More specifically the idea is to take applications that you would normally run on ‘bare metal’ and deploy them as containers on bare metal. Using this approach you would add a number of extra layers of protection around these applications reducing the attack surface, so in the case of a successful exploit against the application, the damage would be limited to the container reducing potential exposure to the other applications running on that bare metal system. While I would agree with this recommendation there are, as always, a number of caveats to consider.  The most important of which relates to the contents of the container. When you deploy a container you are not just deploying an application binary in a convenient packaging format, you are often deploying an image that contains an operating system runtime, shared libraries, and potentially some middleware that supports the application. In our experience, a large proportion of end-users build their containers based on full operating system base images that often include hundreds of packages and thousands of files. While deploying your application within a container will provide extra levels of isolation and security you must ensure that the container is both well constructed and well maintained. In the traditional deployment model, all applications use a common set of shared libraries so, for example, when the runtime C library glibc on the host is updated all the applications on that system now use the new library. However in the container model, each container will include it’s own runtime libraries which will need to be updated. In addition, you may find that these containers include more libraries and binaries that are required - for example does an nginx container need the mount binary? As always, nothing comes without a cost. Each application you containerize needs to be maintained and monitored, but it’s clear that the advantages in terms of security and agility provided by Docker and containers in general far outweigh some of the administrative overhead which can be addressed with the appropriate policies and tooling, which is where Anchore can help. Anchore provides tooling and a service that gives unparalleled insight into the contents of your containers, whether you are building your own container images or using images from third parties. Using Anchore’s tools an organization can gain deep insight into the contents of their containers and define policies that are used to validate the contents of those containers before they are deployed. Once deployed, Anchore will be able to provide proactive notification if a container that was previously certified based on your organization’s policies moves out of compliance - for example, if a security vulnerability is found in a package you have deployed. So far container scanning tools have concentrated on the operating system packages, inspecting the RPM or dpkg databases and reporting on the versions of packages installed and correlating that with known CVEs in these packages. However, the operating system packages are just one of many components in an image which may include configuration files, non-packages files on the file system, software artifacts such as PiP, Gem, NPM and Java archives. Compliance with your standards for deployment means more than just the latest packages it means the right packages (required packages, blacklisted packages) the right software artifacts, the right configuration files, etc. Our core engine has already been open sourced and our commercial offering will be available later this month. ### Future of Container Technology & Open Container Initiative Open Container Initiative - August 23, 2016 The Open Container Initiative (OCI), an open source project for creating open industry standards around container formats and runtime, today announced that Anchore, ContainerShip, EasyStack and Replicated have joined The Linux Foundation and the Open Container Initiative. Today’s enterprises demand portable, agile and interoperable developer and sysadmin tools. The OCI was launched with the express purpose of developing standards for the container format and runtime that will give everyone the ability to fully commit to container technologies today without worrying that their current choice of infrastructure, cloud provider or DevOps tool will lock them in. Their choices can instead be guided by choosing the best tools for the applications they are building. “The rapid growth and interest in container technology over the past few years has led to the emergence of a new ecosystem of startups offering container-based solutions and tools,” said Chris Aniszczyk, Executive Director of the OCI. “We are very excited to welcome these new members as we work to develop standards that will aid container portability.” The OCI currently has nearly 50 members. Anchore, ContainerShip, EasyStack and Replicated join existing members including Amazon Web Services, Apcera, Apprenda, AT&T, ClusterHQ, Cisco, CoreOS, Datera, Dell, Docker, EMC, Fujitsu Limited, Goldman Sachs, Google, Hewlett Packard Enterprise, Huawei, IBM, Infoblox, Intel, Joyent, Kismatic, Kyup, Mesosphere, Microsoft, Midokura, Nutanix, Odin, Oracle, Pivotal, Polyverse, Portworx, Rancher Labs, Red Hat, Resin.io, Scalock, Sysdig, SUSE, Twistlock, Twitter, Univa, Verizon Labs, VMware and Weaveworks. Read the complete and original announcement on Open Container Initiative. ### How are Containers Really Being Used? Our friends at ContainerJournal and Devops.com are running a survey to learn how you are using containers today and your plans for the future. We've seen a number of surveys over the last couple of years and heard some incredible statistics on the growth of Docker usage and of containers in general, for example, we learned last week that DockerHub had reached over 5 billion pulls. The ContainerJournal survey digs deeper to uncover details about the whole stack that users are running. For example, who do you get your container runtime from, where do you store your images, how do you handle orchestration? Some of the questions are especially interesting to the team here at Anchore as they cover how you create and maintain the images that you use. For example, do you pull application images straight from Docker Hub, do you just pull base operating system images and add your own application layers, or perhaps you build your own operating system images from scratch? And no matter how you initially obtain your image how do you ensure that it contains the right content starting from the lowest layer of the image with the operating system all the way up to the application tier. While it’s easy to build and pull images, the maintenance of those images is another matter, eg. how often are those images updated? Please head over to ContainerJournal and fill out the survey by clicking the button below. ### TNS Research: A Scan of the Container Vulnerability Scanner Landscape Lawrence Hecht - The New Stack - August 5, 2016 Container registries and vulnerability scanners are often bundled together, but they are not the same thing. Code scanning may occur at multiple points in a container deployment workflow. Some scanners will be bundled with existing solutions, while others are point solutions. There differences can be measured by the data sources they use, what is being checked, and the actions are automatically taken as the result of a scan. Read the original and complete article at The New Stack. ### Extending Anchore with Jenkins Jenkins is one of the most popular Continuous Integration/Continuous Delivery platforms in production today. Jenkins has over a million active users, and according to the CloudBees State of Jenkins survey last year, 95% of Jenkins users are already using or plan to start using Docker within 12 months. A CI/CD build system is a very important part of any organization’s automation toolkit, and Anchore has some clear integration points with these tools. In this blog post, I’ll describe and illustrate a simple way to manually integrate Anchore’s open source container image validation engine into a Jenkins-based CI/CD environment. It’s worth noting that this is only one possible method integration between Anchore and Jenkins, and a different approach may be more suitable for your environment. We’d love to hear from you if you find a new way to use Anchore in your CI/CD pipeline! Anchore allows you to specify “gates” -- checks that are performed on a container image before it moves to the next stage of the development. These gates range from things like required or disallowed packages, properties of the image’s Dockerfile, presence of known vulnerabilities, and so on. The gate subsystem is easily extended to add your own conditions--perhaps application configuration, versioning requirements, etc. Gates have been designed to run as part of an automated CI/CD pipeline. A popular workflow is to have an organization’s CI/CD pipeline respond to newly-committed Dockerfiles, building images, running tests, and so on. A good place to run Anchore’s Gates would be in between the build of the image and the next phase: whether it’s a battery of tests, or maybe a promotion of an application to the next stage of production. The workflow looks like this: Developer commits an updated Dockerfile to Git A Jenkins job is triggered based on that commit A new container image is built as part of the Jenkins job Anchore is invoked to analyze the image The status of that image’s gates are checked At this point, the CI pipeline can make a decision on whether to allow this newly-created and analyzed image to the next stage of development. Gates have three possible statuses: GO, WARN, STOP. They are fairly self-explanatory: an image whose gates all pass GO should be promoted to the next stage. Images with any WARN statuses may need further inspection but may be allowed to continue. An image with a gate that returns a STOP status should not move forward in the pipeline. Let’s walk through a simplified example. For clarity, I’ve got my Docker, Anchore, and Jenkins instances all on the same virtual machine. Production configurations will likely be different. (I’m running Jenkins 2.7.1, Docker 1.11.2, and the latest version of Anchore from PIP.) The first thing we need to do is create a Build Job. This is not intended to be a general-purpose Jenkins tutorial, so drop by the Jenkins Documentation if you need some help. Our Jenkins job will poll a GitHub repository containing our very simple Dockerfile, which looks like this: The relevant section of our Jenkins build job looks like this: These commands do the following: docker build -t anchore-test. This command instructs Docker to build a new image based on the Dockerfile in the directory of the cloned Git repository. The image’s name is “anchore-test”. anchore analyze --image anchore-test --dockerfile Dockerfile This command calls Anchore to analyze the newly-created image. anchore gate --image anchore-test This command runs through the Anchore “gates” to determine if the newly-generated image is suitable for use in our environment. Let’s look at the output from this build: Whoops! Our build failed. Looks like we triggered a couple of gates here. The first one, “PKGDIFF”, is reporting an action of “STOP”. If you look at the “CheckOutput” column, it says: “Package version in container is different from baseline for pkg - tzdata”. This means that along the way the package version of tzdata has changed; probably because our Dockerfile does a “yum update -y”. Let’s try removing that command--maybe we should instead stick to the baseline image that our container team has provided. So let’s edit the Dockerfile, remove that line, commit the change, and re-run the build. Here’s the output from the new build: Success! We’ve passed all of the gates. You can change which gates apply to which images and how they are configured by running: anchore gate --image anchore-test --editpolicy (You’ll be dropped into the editor specified by the VISUAL or EDITOR environment variables, usually vim.) Our policy currently looks like this: DOCKERFILECHECK:NOTAG:STOP DOCKERFILECHECK:SUDO:GO DOCKERFILECHECK:EXPOSE:STOP:ALLOWEDPORTS=22 DOCKERFILECHECK:NOFROM:STOP SUIDDIFF:SUIDFILEDEL:GO SUIDDIFF:SUIDMODEDIFF:STOP SUIDDIFF:SUIDFILEADD:STOP PKGDIFF:PKGVERSIONDIFF:STOP PKGDIFF:PKGADD:WARN PKGDIFF:PKGDEL:WARN ANCHORESEC:VULNHIGH:STOP ANCHORESEC:VULNLOW:GO ANCHORESEC:VULNCRITICAL:STOP ANCHORESEC:VULNMEDIUM:WARN ANCHORESEC:VULNUNKNOWN:GO You can read all about gates and policies in our documentation. Let’s try one more thing: let’s change the “PKGDIFF:PKGVERSIONDIFF” policy to “WARN” instead of “STOP”, and re-enable our yum update command in the Dockerfile. In the policy editor, we’ll change these lines: PKGDIFF:PKGVERSIONDIFF:STOP PKGDIFF:PKGADD:WARN To this: PKGDIFF:PKGVERSIONDIFF:GO PKGDIFF:PKGADD:GO And save and exit. We’ll also edit the Dockerfile, re-add the “RUN yum update -y” line, and commit and push the change. Then let’s run the Jenkins job again and see what happens. Now you can see that although Anchore still detects an added package and a changed version, because we’ve reconfigured those gates, it’s not a fatal error and the build completes successfully. This is just a very simple example of what can be done with Anchore gates in a CI/CD environment. We are planning on implementing a full Jenkins plugin for a more streamlined integration, so stay tuned for that. There are also more gates to explore, and you can extend the system to add your own. If you have questions, comments, or want to share how you’re using Anchore, let us know! ### Signed, Sealed, Deployed Red Hat recently blogged about their progress in adding support for container image signing, a particularly interesting and most welcome aspect of the design is the way that the binary signature file can be decoupled from the registry and distributed separately. The blog makes interesting reading and I’d strongly recommend reading through it, I’m sure you’ll appreciate the design. And of course, code is available online. Red Hat is, along with the other Linux distributors, well versed in the practice of signing software components to allow end-users to verify that they are running authentic code and is in the process of extending this support to container images. The approach described is different from that taken previously by Docker Inc. however rather than comparing the two approaches I wanted to talk at a high level about the benefits of image signing along with some commentary about trust. In the physical world, we are all used to using our signature to confirm our identity. Probably the most common example is when we are signing a paper check or using an electronic signature pad during a sales transaction. How many times have you signed your signature so quickly that you do not even recognize it yourself? How many times in recent memory has a cashier or server compared the signature written with that on the back of your credit card? In my experience that check is likely to happen one out of every ten times and even in those cases that check is little more than a token gesture and the two signatures may not have matched. That leads me to the first important observation: a signature mechanism is only useful if it is checked.  Obviously, when vendors such as Docker Inc, Red Hat, and others implement an image signing and validation system, the enforcement will be built into to all layers, so that in one example a Red Hat delivered image will be validated by a Red Hat provided Docker runtime to ensure it's signed by a valid source. However it's more likely that the images that you deploy in your enterprise won't just be the images downloaded from a registry, but instead, images built on top of these images or perhaps even built from scratch, so for image signing to provide the required level of security all images created within your enterprise should also be signed and have those signatures validated before the image is deployed. Some early users of image signing that we have talked to have used image signing less as a way of tracking the provenance of images but instead as a method to show that an image has not been modified between leaving the CI/CD pipeline and being deployed on their container host. Before we dig into the topic of image signing it's worth discussing what a signature actually represents. The most common example of signatures that we see in our day to day life is in our web browsers where we look for the little green padlock in the address bar that indicates that the connection to the webserver from our browser is encrypted but most importantly it confirms that you are talking to the expected website. The use of TLS/SSL certificates allows your browser to validate that when you connect to https://www.example.com the content displayed actually came from example.com. So in this example, the signature was used to confirm the source of the (web) content. Over many years we have been trained NOT to type our credit card details into a site that is NOT delivered through HTTPS. But that does not mean that you would trust your credit card details to any site that uses HTTPS. The same principle applies to the use of image signatures. If you download an image signed by Red Hat, Docker Inc, or any other vendor, you can be assured that the image did come from this vendor. The level of confidence you have in the contents of the image is based on the level of trust you already have with the vendor. For example, you are likely not to run an image signed by l33thackerz even though it may include a valid signature. As enterprises move to a DevOps model with containers we're seeing a new software supply chain, which often begins with a base image pulled from DockerHub or a vendor registry. This base image may be modified by the operations team to include extra packages or to customize specific configuration files. The resulting image is then published in the local registry to be used by the development team as the base image for their application container. In many organizations, we are starting to see other participants in this supply chain, for example, a middleware team may publish an image containing an application server that is in turn used by an application team. For the promise of image signing to be fulfilled, at each stage of this supply chain, each team must sign the image to ensure that the 'chain of custody' can be validated throughout the software development lifecycle. As we covered previously those signatures only serve to prove the source of an image, during any point in the supply chain from the original vendor of the base image all the way through the development process the images may be modified. At any step in the supply chain a mistake may be made, an outdated package that contains known bugs of vulnerabilities may be used, an insecure configuration option in an application's configuration file or perhaps secrets such as passwords or API keys may be stored in the image. Signing an image will not prevent insecure or otherwise non-compliant images from being deployed, however, as part of a post mortem, it will provide a way of tracking down when the vulnerability or bug was introduced. During each stage of the supply chain, detailed checks should be performed on the image to ensure that the image complies with your site-specific policies. These policies could cover security, starting with the ubiquitous CVE scan but then going further to analyze the configuration of key security components. For example, you could have the latest version of the apache web server but have configured the wrong set of TLS Ciphers suites leading to insecure communication. In addition to security, your policies could cover application-specific configurations to comply with best practices or to enable consistency and predictability. Anchore's goal is to provide a toolset that allows developers, operations, and security teams to maintain full visibility of the 'chain of custody' as containers move through the development lifecycle while providing the visibility, predictability, and control needed for production deployment. With Anchore’s tools, the analysis and policy evaluation could be run during each stage of the supply chain allowing the signatures to attest to both the source of the image and also the compliance of the image’s contents. In summary, we believe that image signing is an important part of the security and integrity of your software supply chain however signatures alone will not ensure the integrity of your systems. ### Webinar - Introduction to the Anchore Project Today we delivered Anchore's first webinar where we gave an introduction into Anchore's open source project and discussed how we can democratize certification through the use of open source. A primary concern for enterprises adopting Docker is security most notably, in the governance and compliance of the containers that they are deploying. In the past, as we moved from physical server deployments to virtual machines we saw similar issues and we spoke about "VM sprawl" but containers are set to exponentially outgrow VM deployments. It's almost too easy to pull an application image from a public registry and run it, within seconds you can deploy an application in production without even knowing what's under the covers. Organizations want to have confidence in their deployments, to know that when they deploy an application it will work, it will be secure, it can be maintained and it will be performant. In the past, this confidence came through certification. Commercial Linux distributions such as Red Hat, SuSE and others set the standard and worked with hardware and software vendors on certification programs to give a level of assurance to end-users that the operating system would run reliably on their hardware and also offer insurance in the form of enterprise-grade commercial support if they encountered issues. Today the problem is more complex and there can no longer be just a single certification. For example, the requirements of a financial services company are different from the requirements of a healthcare company handling medical records and these are different from the needs of a federal institution and so on. Even the needs of individual departments within any given organization may be different. What is needed now is the ability for IT operations and security to be able to define their own certification requirements which may differ even from application to application, allowing them to define these policies and evaluate them before applications are deployed into production. What we are talking about is the democratization of certification Rather than having certification in the hands of a small number of vendors or standards bodies, we want to allow organizations to define what certification means to them. Anchore's goal is to provide a toolset that allows developers, operations, and security teams to maintain full visibility of the 'chain of custody' as containers move through the development lifecycle while providing the visibility, predictability, and control needed for production deployment. Please tune into the webinar where we go a level deeper to discuss the challenges around container certification, how an open source, democratized approach can help end-users and introduce our open source tooling. ### Extending Anchore with Lynis Add Lynis Scanning to Anchore Image Analysis Note: You will need the latest Anchore code from GitHub to follow this procedure: Install it here In this post, we focus on solving a common problem that is faced when building out a container-based deployment environment - take an existing tool/practice for deciding whether or not application code is ready to be deployed, and apply it to the steady stream of container images that are flowing in from developers on their way to production. With Anchore, we show that we can apply many existing tools/techniques to container images easily, in a way that leads to a ‘fail fast’ property where things can be checked early on in the CI/CD pipeline (pre-execution). To illustrate this idea, we walk through the the process of adding a new analyzer/gate to Anchore - specifically I would like to include the scanning of all container images using the 'Lynis' open-source Linux Distro scanning utility, and then be able to use the Anchore policy system to make decisions based on the result of the Lynis scan.  Once complete, every container image that is analyzed by Anchore in the future will include a lynis report, and every analyzed image will be subject to the Lynis gate checker. The process is broken down into two parts - first, we write an 'analyzer' that is responsible for running the Lynis scan whenever any container is analyzed with Anchore, and second we write a 'gate' which can take as input the result of the Lynis scan and emits triggers based on what it finds.  From there, we can then use the normal Anchore policy strings to make STOP/WARN/GO suggestions based on what triggers the gate emits. Writing the Lynis Analyzer Module First, I use the anchore tool to set up a module development environment. Note the output where it shows the exact paths on your system.  I run the exact command just to make sure everything is sane: # /tmp/3355618.anchoretmp/anchore-modules/analyzers/analyzer-example.sh 0f192147631d72486538039c51ef9557be11865030be2951a0fbe94ef66db618 /tmp/3355618.anchoretmp/data /tmp/3355618.anchoretmp/data/0f192147631d72486538039c51ef9557be11865030be2951a0fbe94ef66db618 /tmp/3355618.anchoretmp RESULT: pfiles found in image, review key/val data stored in: /tmp/3355618.anchoretmp/data/0f192147631d72486538039c51ef9557be11865030be2951a0fbe94ef66db618/analyzer_output/analyzer-example/pfiles Since I want to write a python module (instead of the included example shell script), I'll start with an existing anchore python analyzer script and call it '10_lynis_report.py' # cp /usr/lib/python2.7/site-packages/anchore/anchore-modules/analyzers/10_package_list.py /tmp/3355618.anchoretmp/anchore-modules/analyzers/10_lynis_report.py I'll trim most of the code out, and change the 'analyzer_name' to a new name for this module - I've chosen 'lynis_report'. Next, I'll add my code which first downloads the lynis scanner from a URL and creates a tarball that contains lynis.  Then, the code uses an anchore utility routine that takes an input tarball and the input container image, and runs an instance of the container with the input tarball stages and available, executing the lynis scanner. Finally, the routine returns the stdout/stderr output of the executed container along with the contents of a specified file from within the container (in this case, the lynis report data itself). The last thing the analyzer does is write the lynis report data to the anchore output directory for later use. While writing this code, we use the follow command each time to iterate and get the analyzer working the way we would like (i.e. when the lynis.report output file contains the lynis report data itself, we know the analyzer is working properly) # /tmp/3355618.anchoretmp/anchore-modules/analyzers/10_lynis_report.py 0f192147631d72486538039c51ef9557be11865030be2951a0fbe94ef66db618 /tmp/3355618.anchoretmp/data /tmp/3355618.anchoretmp/data/0f192147631d72486538039c51ef9557be11865030be2951a0fbe94ef66db618 /tmp/3355618.anchoretmp # cat /tmp/3355618.anchoretmp/data/0f192147631d72486538039c51ef9557be11865030be2951a0fbe94ef66db618/analyzer_output/lynis_report/lynis.report The finished module is here: #!/usr/bin/env python import sys import os import shutil import re import json import time import rpm import subprocess import requests import tarfile import anchore.anchore_utils analyzer_name = "lynis_report" try: config = anchore.anchore_utils.init_analyzer_cmdline(sys.argv, analyzer_name) except Exception as err: print str(err) sys.exit(1) imgname = config outputdir = config unpackdir = config if not os.path.exists(outputdir): os.makedirs(outputdir) try: #datafile_dir = '/'.join(, 'datafiles']) datafile_dir = '/tmp/' url = 'https://cisofy.com/files/lynis-2.2.0.tar.gz' r = requests.get(url) TFH=open('/'.join(), 'w'); TFH.write(r.content) TFH.close() lynis_data_tarfile = '/'.join() tar = tarfile.open(lynis_data_tarfile, mode='w', format=tarfile.PAX_FORMAT) tar.add('/'.join(), arcname='/lynis.tgz') tar.close() except Exception as err: print "ERROR: cannot locate datafile directory for lynis staging: " + str(err) sys.exit(1) FH=open(outputdir + "/lynis.report", 'w') try: fileput = lynis_data_tarfile (o, f) = anchore.anchore_utils.run_command_in_container(image=imgname, cmd="tar zxvf /lynis.tgz && cd /lynis && sh lynis audit system --quick", fileget="/var/log/lynis-report.dat", fileput=fileput) FH.write(' '.join(["LYNIS-REPORT-JSON", json.dumps(f)])) except Exception as err: print str(err) FH.close() NOTE: this module is the basic code only meant as a demonstration, it does not include any checking for errors/faults as this would add a bit of code unrelated to the purpose of this posting. Writing the Lynis Gate Module The process of writing a gate is very similar to writing an analyzer - there are a few input differences and output file expectations, but the general process is the same.  I will start with an existing anchore gate modules and trim the functional code: # cp /usr/lib/python2.7/site-packages/anchore/anchore-modules/gates/20_check_pkgs.py /tmp/3355618.anchoretmp/anchore-modules/gates/10_lynis_gate.py Here is the module with the functional code trimmed out: #!/usr/bin/env python import sys import os import re import anchore.anchore_utils try: config = anchore.anchore_utils.init_gate_cmdline(sys.argv, "LYNIS report checker") except Exception as err: print str(err) sys.exit(1) if not config: sys.exit(0) imgid = config imgdir = config analyzerdir = config comparedir = config outputdir = config try: params = config except: params = None if not os.path.exists(imgdir): sys.exit(0) # code will go here sys.exit(0) Next, we need to set up the input by putting the imageId that we're testing against into an input file for the gate, and then we can run the module manually and check the output iteratively until we're happy. # echo 0f192147631d72486538039c51ef9557be11865030be2951a0fbe94ef66db618 > /tmp/3355618.anchoretmp/querytmp/inputimages # /tmp/3355618.anchoretmp/anchore-modules/gates/10_lynis_gate.py /tmp/3355618.anchoretmp/querytmp/inputimages /tmp/3355618.anchoretmp/data/ /tmp/3355618.anchoretmp/data/0f192147631d72486538039c51ef9557be11865030be2951a0fbe94ef66db618/gates_output/ PARAM=True # cat /tmp/3355618.anchoretmp/data/0f192147631d72486538039c51ef9557be11865030be2951a0fbe94ef66db618/gates_output/LYNISCHECK The finished module is here: #!/usr/bin/env python import sys import os import re import json import traceback import anchore.anchore_utils try: config = anchore.anchore_utils.init_gate_cmdline(sys.argv, "LYNIS report checker") except Exception as err: traceback.print_exc() print "ERROR: " + str(err) sys.exit(1) if not config: sys.exit(0) imgid = config imgdir = config analyzerdir = config comparedir = config outputdir = config try: params = config except: params = None if not os.path.exists(imgdir): sys.exit(0) # code will go here output = '/'.join() OFH=open(output, 'w') try: FH=open('/'.join(), 'r') lynis_report = False for l in FH.readlines(): l = l.strip() (k, v) = re.match('(S*)s*(.*)', l).group(1, 2) lynis_report = json.loads(v) FH.close() if lynis_report: for l in lynis_report.splitlines(): l = l.strip() if l and not re.match("^s*#.*", l) and re.match(".*=.*", l): (k, v) = re.match('(S*)=(.*)', l).group(1, 2) if str(k) == 'warning[]': # output a trigger OFH.write('LYNISWARN ' + str(v) + 'n') elif str(k) == 'suggestion[]': OFH.write('LYNISSUGGEST ' + str(v) + 'n') elif str(k) == 'vulnerable_package[]': OFH.write('LYNISPKGVULN ' + str(v) + 'n') except Exception as err: traceback.print_exc() print "ERROR: " + str(err) OFH.close() sys.exit(0) NOTE: this module is the basic code only meant as a demonstration, it does not include any checking for errors/faults as this would add a bit of code unrelated to the purpose of this posting. Tie the Two Together Now that we're finished writing and testing the module, we can drop the new analyzer/gate modules into anchore and use the anchore CLI as normal.  First we copy the new modules into a location where anchore can use them: cp /tmp/3355618.anchoretmp/anchore-modules/analyzers/10_lynis_report.py ~/.anchore/user-scripts/analyzers/ cp /tmp/3355618.anchoretmp/anchore-modules/gates/10_lynis_gate.py ~/.anchore/user-scripts/gates/ Next, we run the normal analyze operation which will now include the lynis analyzer: anchore analyze --force --image ubuntu --imagetype none Then, we can add new lines to the image's policy that describe what actions to output if the new gate emits its triggers: anchore gate --image ubuntu --editpolicy # opens an editor, where you can add the following lines to the existing image's policy LYNISCHECK:LYNISPKGVULN:STOP LYNISCHECK:LYNISWARN:WARN LYNISCHECK:LYNISSUGGEST:GO Finally, we can run the normal anchore gate, and see the resulting triggers showing up alongside the other anchore gates: anchore gate --image ubuntu 0f192147631d: evaluating policies ... 0f192147631d: evaluated. +--------------+---------------+------------+--------------+---------------------------------+------------+ | ImageID | Repo/Tag | Gate | Trigger | CheckOutput | GateAction | +--------------+---------------+------------+--------------+---------------------------------+------------+ | 0f192147631d | ubuntu:latest | LYNISCHECK | LYNISSUGGEST | BOOT-5180|Determine runlevel | GO | | | | | | and services at startup|-|-| | | | 0f192147631d | ubuntu:latest | LYNISCHECK | LYNISSUGGEST | KRNL-5788|Check the output of | GO | | | | | | apt-cache policy manually to | | | | | | | determine why output is | | | | | | | empty|-|-| | | | 0f192147631d | ubuntu:latest | LYNISCHECK | LYNISSUGGEST | AUTH-9262|Install a PAM module | GO | | | | | | for password strength testing | | | | | | | like pam_cracklib or | | | | | | | pam_passwdqc|-|-| | | | 0f192147631d | ubuntu:latest | LYNISCHECK | LYNISSUGGEST | AUTH-9286|Configure minimum | GO | | | | | | password age in | | | | | | | /etc/login.defs|-|-| | | | 0f192147631d | ubuntu:latest | LYNISCHECK | LYNISSUGGEST | AUTH-9286|Configure maximum | GO | | | | | | password age in | | | | | | | /etc/login.defs|-|-| | | | 0f192147631d | ubuntu:latest | LYNISCHECK | LYNISSUGGEST | AUTH-9328|Default umask in | GO | | | | | | /etc/login.defs could be more | | | | | | | strict like 027|-|-| | | | 0f192147631d | ubuntu:latest | LYNISCHECK | LYNISSUGGEST | AUTH-9328|Default umask in | GO | | | | | | /etc/init.d/rc could be more | | | | | | | strict like 027|-|-| | | | 0f192147631d | ubuntu:latest | LYNISCHECK | LYNISSUGGEST | FILE-6310|To decrease the | GO | | | | | | impact of a full /home file | | | | | | | system, place /home on a | | | | | | | separated partition|-|-| | | | 0f192147631d | ubuntu:latest | LYNISCHECK | LYNISSUGGEST | FILE-6310|To decrease the | GO | | | | | | impact of a full /tmp file | | | | | | | system, place /tmp on a | | | | | | | separated partition|-|-| | | | 0f192147631d | ubuntu:latest | LYNISCHECK | LYNISSUGGEST | FILE-6310|To decrease the | GO | | | | | | impact of a full /var file | | | | | | | system, place /var on a | | | | | | | separated partition|-|-| | | | 0f192147631d | ubuntu:latest | LYNISCHECK | LYNISSUGGEST | FILE-6336|Check your /etc/fstab | GO | | | | | | file for swap partition mount | | | | | | | options|-|-| | | | 0f192147631d | ubuntu:latest | LYNISCHECK | LYNISSUGGEST | STRG-1840|Disable drivers like | GO | | | | | | USB storage when not used, to | | | | | | | prevent unauthorized storage or | | | | | | | data theft|-|-| | | | 0f192147631d | ubuntu:latest | LYNISCHECK | LYNISSUGGEST | STRG-1846|Disable drivers like | GO | | | | | | firewire storage when not used, | | | | | | | to prevent unauthorized storage | | | | | | | or data theft|-|-| | | | 0f192147631d | ubuntu:latest | LYNISCHECK | LYNISSUGGEST | PKGS-7370|Install debsums | GO | | | | | | utility for the verification of | | | | | | | packages with known good | | | | | | | database.|-|-| | | | 0f192147631d | ubuntu:latest | LYNISCHECK | LYNISPKGVULN | tzdata | STOP | | 0f192147631d | ubuntu:latest | LYNISCHECK | LYNISWARN | PKGS-7392|Found one or more | WARN | | | | | | vulnerable packages.|M|-| | | | 0f192147631d | ubuntu:latest | LYNISCHECK | LYNISSUGGEST | PKGS-7392|Update your system | GO | | | | | | with apt-get update, apt-get | | | | | | | upgrade, apt-get dist-upgrade | | | | | | | and/or unattended-upgrades|-|-| | | | 0f192147631d | ubuntu:latest | LYNISCHECK | LYNISSUGGEST | PKGS-7394|Install package apt- | GO | | | | | | show-versions for patch | | | | | | | management purposes|-|-| | | | 0f192147631d | ubuntu:latest | LYNISCHECK | LYNISSUGGEST | NETW-3032|Install ARP | GO | | | | | | monitoring software like | | | | | | | arpwatch|-|-| | | | 0f192147631d | ubuntu:latest | LYNISCHECK | LYNISSUGGEST | FIRE-4590|Configure a | GO | | | | | | firewall/packet filter to | | | | | | | filter incoming and outgoing | | | | | | | traffic|-|-| | | | 0f192147631d | ubuntu:latest | LYNISCHECK | LYNISSUGGEST | LOGG-2130|Check if any syslog | GO | | | | | | daemon is running and correctly | | | | | | | configured.|-|-| | | | 0f192147631d | ubuntu:latest | LYNISCHECK | LYNISWARN | LOGG-2130|No syslog daemon | WARN | | | | | | found|H|-| | | | 0f192147631d | ubuntu:latest | LYNISCHECK | LYNISWARN | LOGG-2138|klogd is not running, | WARN | | | | | | which could lead to missing | | | | | | | kernel messages in log | | | | | | | files|L|-| | | | 0f192147631d | ubuntu:latest | LYNISCHECK | LYNISSUGGEST | BANN-7126|Add a legal banner to | GO | | | | | | /etc/issue, to warn | | | | | | | unauthorized users|-|-| | | | 0f192147631d | ubuntu:latest | LYNISCHECK | LYNISSUGGEST | BANN-7130|Add legal banner to | GO | | | | | | /etc/issue.net, to warn | | | | | | | unauthorized users|-|-| | | | 0f192147631d | ubuntu:latest | LYNISCHECK | LYNISSUGGEST | ACCT-9622|Enable process | GO | | | | | | accounting|-|-| | | | 0f192147631d | ubuntu:latest | LYNISCHECK | LYNISSUGGEST | ACCT-9626|Enable sysstat to | GO | | | | | | collect accounting (no | | | | | | | results)|-|-| | | | 0f192147631d | ubuntu:latest | LYNISCHECK | LYNISSUGGEST | ACCT-9628|Enable auditd to | GO | | | | | | collect audit information|-|-| | | | 0f192147631d | ubuntu:latest | LYNISCHECK | LYNISSUGGEST | TIME-3104|Use NTP daemon or NTP | GO | | | | | | client to prevent time | | | | | | | issues.|-|-| | | | 0f192147631d | ubuntu:latest | LYNISCHECK | LYNISSUGGEST | FINT-4350|Install a file | GO | | | | | | integrity tool to monitor | | | | | | | changes to critical and | | | | | | | sensitive files|-|-| | | | 0f192147631d | ubuntu:latest | LYNISCHECK | LYNISSUGGEST | TOOL-5002|Determine if | GO | | | | | | automation tools are present | | | | | | | for system management|-|-| | | | 0f192147631d | ubuntu:latest | LYNISCHECK | LYNISSUGGEST | KRNL-6000|One or more sysctl | GO | | | | | | values differ from the scan | | | | | | | profile and could be | | | | | | | tweaked|-|-| | | | 0f192147631d | ubuntu:latest | LYNISCHECK | LYNISSUGGEST | HRDN-7230|Harden the system by | GO | | | | | | installing at least one malware | | | | | | | scanner, to perform periodic | | | | | | | file system scans|-|-| | | | 0f192147631d | ubuntu:latest | ANCHORESEC | VULNLOW | Low Vulnerability found in | GO | | | | | | package - glibc (CVE-2015-5180 | | | | | | | - http://people.ubuntu.com | | | | | | | /~ubuntu- | | | | | | | security/cve/CVE-2015-5180) | | | 0f192147631d | ubuntu:latest | ANCHORESEC | VULNMEDIUM | Medium Vulnerability found in | WARN | | | | | | package - coreutils | | | | | | | (CVE-2016-2781 - | | | | | | | http://people.ubuntu.com | | | | | | | /~ubuntu- | | | | | | | security/cve/CVE-2016-2781) | | | 0f192147631d | ubuntu:latest | ANCHORESEC | VULNLOW | Low Vulnerability found in | GO | | | | | | package - shadow (CVE-2013-4235 | | | | | | | - http://people.ubuntu.com | | | | | | | /~ubuntu- | | | | | | | security/cve/CVE-2013-4235) | | | 0f192147631d | ubuntu:latest | ANCHORESEC | VULNMEDIUM | Medium Vulnerability found in | WARN | | | | | | package - glibc (CVE-2016-3706 | | | | | | | - http://people.ubuntu.com | | | | | | | /~ubuntu- | | | | | | | security/cve/CVE-2016-3706) | | | 0f192147631d | ubuntu:latest | ANCHORESEC | VULNLOW | Low Vulnerability found in | GO | | | | | | package - glibc (CVE-2016-1234 | | | | | | | - http://people.ubuntu.com | | | | | | | /~ubuntu- | | | | | | | security/cve/CVE-2016-1234) | | | 0f192147631d | ubuntu:latest | ANCHORESEC | VULNMEDIUM | Medium Vulnerability found in | WARN | | | | | | package - bzip2 (CVE-2016-3189 | | | | | | | - http://people.ubuntu.com | | | | | | | /~ubuntu- | | | | | | | security/cve/CVE-2016-3189) | | | 0f192147631d | ubuntu:latest | ANCHORESEC | VULNMEDIUM | Medium Vulnerability found in | WARN | | | | | | package - util-linux | | | | | | | (CVE-2016-2779 - | | | | | | | http://people.ubuntu.com | | | | | | | /~ubuntu- | | | | | | | security/cve/CVE-2016-2779) | | | 0f192147631d | ubuntu:latest | FINAL | FINAL | | STOP | +--------------+---------------+------------+--------------+---------------------------------+------------+ ### Peek Into Your Containers With 3 Simple Commands If you are just looking to run a common Linux application such as Tomcat or WordPress it's far simpler to download a pre-packaged image from DockerHub than to install the application from scratch. But with tens of thousands of images on DockerHub you are likely to find many variations of the application in question, even with official repositories you may find multiple different versions of an application. In previous blog posts, we have introduced the Anchore open source project which provides a rich toolset to allow developers, operations, and security teams to maintain full visibility of the 'chain of custody' as containers move through the development lifecycle. In our last blog, we covered a couple of simple use cases, allowing a user to dig into the contents of a container looking at specific files or packages. In this blog post, I wanted to introduce you to three interesting features within Anchore. There are seven top-level commands within the Anchore command-line tools. These can be seen by running the anchore command with no other options: Command  Description analyze  Perform analysis on specified image IDs explore  Search, report and query specified image IDs gate  Perform and view gate evaluation on selected images subscriptions  Manage local subscriptions sync  Synchronize images and metadata system  Anchore system-level operations toolbox  Useful tools and operations on images and containers In previous blog posts, we have presented the analyze, explore and gate commands, but in this blog post, we wanted to highlight a couple of the lesser-known features in the toolbox that we found very useful in our day to day use of containers. Running anchore toolbox will show the sub-commands available: Command  Description setup-module-dev  Setup a module development environment show  Show image summary information show-dockerfile  Generate (or display actual) image Dockerfile show-familytre  Show image family tree image IDs show-layers  Show image layer IDs show-taghistory  Show history of all known repo/tags for image unpack  Unpack and Squash image to local filesystem While Docker allows applications to be packaged as easily distributed containers, transparently providing both the underlying operating system and the application, you often need to know exactly what operating system this application is built upon. This information may be required to fulfill compliance or audit requirements in your organization or to ensure that you are only deploying operating systems for which you have commercial support agreements. If you are lucky then the full description of the container on the DockerHub portal contains details about the operating system used. But in many cases, this information isn't presented. One way to ascertain what operating system is used is to download and run the image and inspect the file system however that’s a manual and time-consuming process. The show command presents a simple way to retrieve this information. Taking a look at nginx, the most popular image on DockerHub: IMAGEID='0d409d33b27e47423b049f7f863faa08655a8c901749c2b25b93ca67d01a470d' REPOTAGS='docker.io/nginx:latest' DISTRO='debian' DISTROVERS='8' SHORTID='0d409d33b27e' PARENTID='' BASEID='0d409d33b27e47423b049f7f863faa08655a8c901749c2b25b93ca67d01a470d' Here we see the latest image is built on Debian version 8 (Jessie). Using another useful toolbox function is show-tag history, which shows the known tags for a given image. Here we can see that the latest image is also tagged as 1.11 and 1.11.1: +--------------+---------------------+-------------------------+ | ImageId | Date | KnownTags | +--------------+---------------------+-------------------------+ | 0d409d33b27e | Wed Jun 15 14:37:03 | nginx:1.11,nginx:1.11.1 | | | 2016 | ,nginx:latest | | 0d409d33b27e | Wed Jul 13 15:57:51 | nginx:1.11,nginx:1.11.1 | | | 2016 | ,nginx:latest | | 0d409d33b27e | Wed Jul 13 16:35:14 | docker.io/nginx:latest | | | 2016 | | +--------------+---------------------+-------------------------+ The final toolbox feature I want to highlight is a feature that many users do not know is available, that is the ability to retrieve the dockerfile for a given image. The show-dockerfile command will either display the dockerfile, if it was available during the image analysis phase, or will generate the dockerfile from the image. This information may be useful if you wish to look under the covers to understand how the container was created or to check for any potential issues with the container content. The contents of the dockerfile may also be used within our ‘gates’ feature, for example allowing you to specify that specific ports may not be exposed. # anchore toolbox --image=nginx:latest show-dockerfile --- ImageId --- 0d409d33b27e --- Mode --- Guessed Here the mode Guessed indicates that the dockerfile was generated by the tool during image analysis. There are other toolbox commands that include the ability to show the family tree of an image, display the image layers, or unpack the image to the local filesystem. If you haven't already installed Anchore and begun scanning your container images, take a look at our installation and quick-start guides at our wiki below or by going to https://github.com/anchore/anchore/wiki. ### Anchore Use Cases We just released the first version of the open-source Anchore command-line tools and we’re excited for the container community to take a look at what we’ve done and provide feedback. This blog post will outline a couple of basic use cases for some of the queries you can run using the tools, and hopefully, give you some ideas for integrating Anchore into your container image management workflow. Anchore scans container images and records a great deal of information about them: package and file lists, image hierarchies and family trees to track provenance and changes, and maps known security vulnerabilities to the packages installed on your container images. The command-line tools provide a number of ways to query this data. If you haven’t already installed Anchore and begun scanning your container images, take a look at our installation and quick-start guides. Once you’re set-up, let’s run a couple of basic package queries. Maybe you want to confirm that a certain library of a specific version is installed across all of your images, for consistency–there’s nothing worse than the dependency hell of a couple of mismatched libraries causing issues throughout your infrastructure. Or maybe your organizational policies require that a certain monitoring package be installed consistently on all of your production containers. These are questions that Anchore can quickly and easily answer. Here’s an example command that searches a file containing a list of image ids for the “curl” package, and reports the version found: +--------------+-----------------------+------------+---------+----------------------+ | ImageID | Repo/Tag | QueryParam | Package | Version | +--------------+-----------------------+------------+---------+----------------------+ | 6a77ab6655b9 | centos:6 | curl | curl | 7.19.7-52.el6 | | 20c80ee30a09 | ryguyrg/neo4j-panama- | curl | curl | 7.38.0-4+deb8u3 | | | papers:latest | | | | | 8fe6580be3ef | slackbridge:latest | curl | curl | 7.43.0-1ubuntu2.1 | | db688f102aeb | devbad:latest | curl | curl | 7.29.0-25.el7.centos | +--------------+-----------------------+------------+---------+----------------------+ We just released the first version of the open-source Anchore command-line tools and we’re excited for the container community to take a look at what we’ve done and provide feedback. This blog post will outline a couple of basic use cases for that's pretty simple. How about something a little bit more interesting? Since Anchore has the ability to correlate information about all of your container images together, it can make useful suggestions based on not just the contents of one image, but on all of your images. For example, the “base-image” query will show you if a particular image is up to date relative to its base image: # anchore explore --imagefile ~/myimages.txt query base-status all +--------------+-----------------------+---------------+-----------------------+------------+--------------+--------------------+ | InputImageId | InputRepo/Tag | CurrentBaseId | CurrentBaseRepo/Tag | Status | LatestBaseId | LatestBaseRepo/Tag | +--------------+-----------------------+---------------+-----------------------+------------+--------------+--------------------+ | db688f102aeb | devbad:latest | db688f102aeb | devbad:latest | up-to-date | N/A | N/A | | 20c80ee30a09 | ryguyrg/neo4j-panama- | 20c80ee30a09 | ryguyrg/neo4j-panama- | up-to-date | N/A | N/A | | | papers:latest | | papers:latest | | | | | 8fe6580be3ef | slackbridge:latest | 0b4516a442e7 | ubuntu:wily | up-to-date | N/A | N/A | | 89fbcb00e7a2 | devgood:latest | 2fa927b5cdd3 | ubuntu:latest | up-to-date | N/A | N/A | | 6a77ab6655b9 | centos:6 | 6a77ab6655b9 | centos:6 | up-to-date | N/A | N/A | +--------------+-----------------------+---------------+-----------------------+------------+--------------+--------------------+ If the status is ‘up-to-date’, it means that the container image the input image was initially built from (e.g. what was specified in the input image’s FROM line in its Dockerfile) is the same currently as it was when originally built. The status is ‘out-of-date’, meaning that if you were to rebuild the input image with the same Dockerfile, it would result in a different final image since the base has since been updated (indicated by the LatestBaseId column). This query can be used to determine how ‘fresh’ the analyzed container images are with respect to their base images and could trigger an action to rebuild and redeploy the application containers if they are getting too far out of date from their bases. Anchore’s query and analysis infrastructure are pluggable, so you can write your own! Stay tuned for more interesting and useful ways to use the data that we collect: with Anchore’s help, your container infrastructure will be slim, up-to-date, and secure. ### Anchore Open Source Release is Live Whether it’s security, orchestration, management or monitoring, there are many projects, products and companies vying to provide users a way to successfully deploy their apps at scale, with a minimum amount of friction. All of these projects are trying to solve a runtime problem with containers or performing simple security vulnerability scanning, but the big question of what happens in the pre-production cycle remains a period I’ll call the “Dark Ages of the Container Lifecycle”. With traditional IT models this problem was largely addressed by standardizing on commercial Linux distributions such as Red Hat’s Enterprise Linux, now the gold standard within Fortune 1000 companies. This helped aggregate and certify the Linux distribution with thousands of ISVs, providing a production-ready “golden image,” and ensuring enterprise-grade support. Today, that certification process for containers is mostly self-driven and highly unpredictable, with many stakeholders and no single “throat to choke.” Anchore Open Source Release This week’s Anchore open source release addresses a major challenge in today’s container technology space and provides a platform for the open source community to participate and share ideas. Our open source release will give users the ability to pick from a vetted list of containers, analyze new containers, and inspect existing ones -- either in the public domain or behind a firewall. In the past, these tasks were left to the user, creating an even bigger challenge and the gap between developers and operations. Anchore bridges the gap between Dev. and Ops. Data Analytics meets Container Compute An unprecedented amount of churn (more than any other one technology in the past, and over a billion downloads), illustrates the tremendous amount of information exchange at stake and at risk for container sprawl. Managing all this data -- today and over the coming years -- becomes a challenging geometric problem, to say the least. Container dependencies and relationships, security checks, functional dependencies, versioning, and so on, all become incredibly hard to manage. This will widen the gap between Dev. and Ops, and in turn make transparency and predictability paramount for operations and security teams. Pre-production data for production readiness Tens of gigabytes of information are now at the fingertips of Anchore users. Today, our open source release provides this data for the top 10 most downloaded application containers, including Ubuntu, NginX, Redis and MySQL, with new ones to follow as the need arises. Our hosted service is continuously tracking and analyzing every update and upgrade while keeping track of earlier versions for completeness. This data can then be used as a baseline to set and enforce policies, coupled with a proactive notification mechanism that lets users see potential vulnerabilities and critical bugs in a timely fashion. Anchore will provide operations and security teams the confidence necessary to deploy in production. Anchore longer term We are still in the first inning of a very long game in IT. Security, orchestration and management challenges are incrementally being addressed by small and large companies alike. The transformational effect containerization will have on IT will bring about new and interesting challenges. Future releases of Anchore, starting with our beta release next month, will address the data aspects of containers, provide actionable advice based on that data, and bring about more transparency. Most importantly, Anchore promises the predictability and control needed for mission-critical production deployments. ### Introducing Anchore for Docker Technology Demo & System Today, we are going to show how Anchore technology fits into a Docker-based container workflow to provide trust, insight, and validation to your container ecosystem without inhibiting the flexibility, agility, and speed of development that makes container-based deployment platforms so valuable. This post will walk through using Anchore in a deployment scenario for a container-based application. And we’ll also discuss the container registry, curation, and management capabilities of Anchore as well as analysis, control, inspection, and review of containers. The rest of this document is organized around a container-based application deployment workflow composed of the following basic phases: Creation of trusted well-known base containers Creation and validation of application containers built by developers or a CI/CD system Analysis of containers to determine acceptance for production use prior to deployment This post will present both an operations and a developer perspective on each phase, and describes how Anchore operates in each one. Setup and Creating Anchore Curated Containers Starting with the operations perspective, the first step is to create a registry that hosts trusted containers, and exposes them to development teams for use as the base containers from which application containers are built. This is the job of the Anchore registry management tool. The tool creates a local registry and orchestrates the images pulled fromDocker Hub (or another public-facing registry) with the image analysis metadata provided by the Anchore service. So, let’s first create a local registry and sync it to Anchore. Starting with an installed registry tool, run the initcommand to initialize the registry and do an initial sync: [root@tele ~]# anchore-registry init Creating new anchore anchore-reg at /root/.local/ [root@tele ~]# After the command is run, the registry is now initialized and contains some metadata about the base subscribed images as well as vulnerability data. You can view the set of subscribed containers by running the subscriptions command [root@tele ~]# anchore-registry subscriptions [] [root@tele ~]# To subscribe to a few more containers, for example mongo and redis, run the subscribe command. This command will not pull any data, only change the subscription values: [root@tele ~][root@tele ~]# anchore-registry subscribe centos ubuntu mysql redis Subscribing to containers [u’centos’, u’ubuntu’, u’mysql’, u’redis’] Checking sources: [u’ubuntu’, u’centos’, u’busybox’, u’postgres’, u’mysql’, u’registry’, u’redis’, u’mongo’, u’couchbase’, u’couchdb’] [root@tele ~]# [root@tele ~]# anchore-registry subscriptions [u’centos’, u’ubuntu’, u’mysql’, u’redis’] [root@tele ~]# To pull those containers and metadata from Anchore, run the sync command: [root@tele ~]# anchore-registry sync Synchronizing anchore registry with remote [root@tele ~]# By synchronizing with Anchore, we now have the ability to inspect the container to see what kind of analysis and information you get from a curated Anchore container. Let’s search those containers for specific packages. We now have the ability to “navigate” the information that Anchore gathers about the subscribed containers. For example, you can find all of the containers that have a particular package installed: [root@tele ~]# anchore --allanchore navigate --search --has-package ‘ssl*’ +--------------+--------------------+----------------------+-------------------+---------------------+ | ImageId | Current Repo/Tags | Past Repo/Tags | Package | Version | +--------------+--------------------+----------------------+-------------------+---------------------+ | 778a53015523 | centos:latest | centos:latest | openssl-libs | 1.0.1e-51.el7_2.4 | | f48f462dde2f | devone:apr15 | devone:latest | openssl-libs | 1.0.1e-51.el7_2.4 | | | devone:latest | devone:apr15 | | | | 0f0e96f1f267 | redis:latest | redis:latest | libssl1.0.0:amd64 | 1.0.1k-3+deb8u4 | | b72889fa879c | | ubuntu:latest | libssl1.0.0:amd64 | 1.0.1f-1ubuntu2.18 | | b72889fa879c | | ubuntu:latest | libgnutls- | 2.12.23-12ubuntu2.5 | | | | | openssl27:amd64 | | +--------------+--------------------+----------------------+-------------------+---------------------+ [root@tele ~]# That output shows us which images in the local docker repo contain the ssl* package. Analyzing Changed Containers Now, assume that a developer has built an application container using one of the curated Anchore images and has pushed that container back into the local docker repo. In order to determine if this developer container is okay to push into production, it’s helpful to see how the container changed from its parent image (in the FROM clause of the dockerfile). Anchore provides a specific report for this that gives insight into exactly what has changed at a file, package, and checksum level. If, for example, the developer built the container with the following steps: [root@tele ~]# cat Dockerfile FROM centos:latest RUN yum -y install wget CMD ["/bin/echo", "HELLO WORLD FROM DEVONE"] [root@tele ~]# [root@tele ~]# docker build --no-cache=True -t devone . ... ... Successfully built f48f462dde2f [root@tele ~]# First, we need to run the analysis tools on the image. For convenience we can just specify all local images (those already processed are skipped). The result of this command is locally stored analysis data for the images that have not been analyzed yet: [root@tele ~]# anchore --image devone analyze --dockerfile ./DockerfileRunning analyzers: 2791834d4281 ...SUCCESS Running analyzers: f48f462dde2f ...SUCCESS Running analyzers: 778a53015523 ...SUCCESS Running differs: f48f462dde2f to 778a53015523...SUCCESS Running differs: 778a53015523 to f48f462dde2f...SUCCESS [root@tele ~]# Now, we can view the reports and metadata that resulted from the analysis pass: [root@tele ~]# anchore --image devone analyze --dockerfile ./DockerfileRunning analyzers: 2791834d4281 ...SUCCESS Running analyzers: f48f462dde2f ...SUCCESS Running analyzers: 778a53015523 ...SUCCESS Running differs: f48f462dde2f to 778a53015523...SUCCESS Running differs: 778a53015523 to f48f462dde2f...SUCCESS [root@tele ~]# With this report, we can see exactly the delta between an image and its parent: [[root@tele ~]# anchore --image devone navigate -- report CI/CD Gates The next step is to determine if the image is acceptable to put into production. Anchore provides mechanisms to describe gating policies that are run against each image and can be used to gate an image’s entry into production (e.g., as a step in a continuous integration pipeline). Gate policies can include things like file content changes, properties of Dockerfiles, and presence of known vulnerabilities. To check an image against the gates, run the control —gate command. The output will show all of the gate evaluations against the image: [root@tele ~]# anchore --image devone control --gate +--------------+-----------------+-------------+ | f48f462dde2f | ANCHORECHECK | GO | | f48f462dde2f | PKGDIFF | GO | | f48f462dde2f | DOCKERFILECHECK | GO | | f48f462dde2f | SUIDDIFF | GO | | f48f462dde2f | USERIMAGECHECK | GO | | f48f462dde2f | NETPORTS | GO | | f48f462dde2f | FINALACTION | GO | +--------------+-----------------+-------------+ [root@tele ~]# If these statuses are all GO, then that container has passed all gates and is ready for production or further functional testing in a CI/CD system. Aggregate Container Introspection and Search After some time has passed and your Docker environment has accrued more developer container images, Anchore tools can be used to perform a variety of exploration, introspection and search actions over the entire set of analyzed container images. We can search the container image space for packages, files, common packages that have been added, and various types of differences between the application containers and their Anchore curated base images. Some example queries are illustrated below. This query shows us all images that have an installed /etc/passwd file that is different from its base image (i.e., has been modified either directly or indirectly): [root@tele ~]# anchore --alldocker navigate --search --show-file-diffs /etc/ passwd +--------------+-------------------+----------------+--------------+--------------+----------------------+----------------------+ | ImageId | Current Repo/Tags | Past Repo/Tags | BaseId | File | Image MD5 | Base MD5 | +--------------+-------------------+----------------+--------------+--------------+----------------------+----------------------+ | 3ceace5b73b0 | devfive:latest | devfive:latest | 778a53015523 | ./etc/passwd | 7073ff817bcd08c9b9c8 | 60c2b408a06eda681ced | | | | | | | cee4b0dc7dea | a05b0cad8f8a | | c67409e321d6 | devfive:apr15 | devfive:apr15 | 778a53015523 | ./etc/passwd | 7073ff817bcd08c9b9c8 | 60c2b408a06eda681ced | | | | devfive:latest | | | cee4b0dc7dea | a05b0cad8f8a | +--------------+-------------------+----------------+--------------+--------------+----------------------+----------------------+ [root@tele ~]# The next query shows all images that are currently in a STOP Anchore gate state: [root@tele ~]# anchore --alldocker navigate --search --has-gateaction STOP +--------------+--------------------+--------------------+-------------+ | ImageId | Current Repo/Tags | Past Repo/Tags | Gate Action | +--------------+--------------------+--------------------+-------------+ | 3ceace5b73b0 | devfive:latest | devfive:latest | STOP | | 55c843b5c7a3 | devthirteen:apr15 | devthirteen:apr15 | STOP | | | devthirteen:latest | devthirteen:latest | | | 2785fa3ab761 | devfifteen:apr15 | devfifteen:apr15 | STOP | | | devfifteen:latest | devfifteen:latest | | | 4e02de1e5ca5 | devtwelve:apr15 | devtwelve:apr15 | STOP | | | devtwelve:latest | devtwelve:latest | | | dd490a4ef2b3 | devsix:apr15 | devsix:apr15 | STOP | | | devsix:latest | devsix:latest | | | a7f1bb64c477 | develeven:apr15 | develeven:apr15 | STOP | | | develeven:latest | develeven:latest | | | b33f58798470 | devseven:apr15 | devseven:apr15 | STOP | | | devseven:latest | devseven:latest | | | c67409e321d6 | devfive:apr15 | devfive:apr15 | STOP | | | | devfive:latest | | | f48f462dde2f | devone:apr15 | devone:latest | STOP | | | devone:latest | devone:apr15 | | | 0f0e96f1f267 | redis:latest | redis:latest | STOP | | 63a92d0c131d | mysql:latest | mysql:latest | STOP | +--------------+--------------------+--------------------+-------------+ [root@tele ~]# This last query shows us a count of common packages that have been installed in applications containers, which can be used to determine how popular certain package installations are amongst those building containers from base images: [root@tele ~]# anchore --alldocker navigate --search --common-packages +--------------+-------------------+----------------+-------------------+--------------------+ | BaseId | Current Repo/Tags | Past Repo/Tags | Package | Child Images w Pkg | +--------------+-------------------+----------------+-------------------+--------------------+ | 778a53015523 | centos:latest | centos:latest | wget | 2 | | 778a53015523 | centos:latest | centos:latest | sudo | 2 | | 778a53015523 | centos:latest | centos:latest | gpg-pubkey | 4 | | 44776f55294a | ubuntu:latest | ubuntu:latest | wget | 9 | | 44776f55294a | ubuntu:latest | ubuntu:latest | ca-certificates | 9 | | 44776f55294a | ubuntu:latest | ubuntu:latest | libssl1.0.0:amd64 | 9 | | 44776f55294a | ubuntu:latest | ubuntu:latest | libidn11:amd64 | 9 | | 44776f55294a | ubuntu:latest | ubuntu:latest | openssl | 9 | +--------------+-------------------+----------------+-------------------+--------------------+ [root@tele ~]# Container Image Visualizations Anchore CLI tools can be used to view, inspect, search, and perform specific queries in individual container images and sets, but it is also often helpful to be able to view a container image collection graphically and to also apply coloring to indicate certain qualities of images in the visual representation. Anchore has a number of visualizations that can be generated from analysis data. As an example, we have a visual representation of container images in a system with just 15 total application containers, with each node being colored either green, yellow or red (indicating the level of severity of a present CVE vulnerability within the container image). This visualization can be performed at any time against the list of static container images, or against a list of images that has been derived from the set of deployed containers. ### Enterprise Networking Planet, Container Networking Challenges for Enterprises Arthur Cole - Enterprise Networking Planet - April 28, 2016 Establishing connectivity between containers in a network fabric is one challenge; coordinating their activities is yet another. According to Computer Weekly’s Adrian Bridgwater, a key issue is predictability, which is largely a function of the enterprise’s ability to inspect, certify and synchronize container contents. A start-up called Anchore Inc. targets this process through a common portal that application developers can use to select verified containers from established registries. In this way, they receive containers that have been pre-screened for compatibility, vulnerability and other aspects that are crucial for deploying tightly orchestrated container environments quickly and easily. Read the original and complete article on Enterprise Networking Planet. ### The Cloudcast Podcast: Trouble Inside Your Containers Last week, our very own Tim Gerla, VP of Product, and Dan Nermi, CTO and Co-Founder, were interviewed in an episode of Cloudcast. Hosts Aaron Delp and Brian Gracely spoke with Tim and Dan about a number of issues including container security, how to avoid slowing down developers, and the challenges that Anchore is attempting to solve. You can listen to the podcast now at The Cloudcast's website for free.  The Cloudcast is an award-winning podcast on all things cloud computing, AWS Ecosystem, open source, DevOps, AppDev, SaaS, and SDN. ### Computer Weekly: Anchore, A New Name for Container Predictability Adrian Bridgewater - Computer Weekly - April 8, 2016 As a newly formed operational entity, Anchore Inc. has announced the formation of the company itself and (in literally the same mouthful) the firm has launched its beta program for users working with containers. Users can sign up for the Anchore beta program now with expected availability in Q2 of 2016. But what is Anchore and how do we achieve container predictability? Read the original and complete article on ComputerWeekly.com. ### Fortune: Stealthy Startup Says It Can Build Safer Software Barb Darrow - Fortune - April 6, 2016 Anchore to certify software containers as ready for prime time. Saïd Ziouani, one of the forces behind Ansible, the tool that helps automate software development and deployment, is back with a new company. Anchore, based in Santa Barbara, Calif., is making its debut Wednesday with $2.5 million in seed money and what it says is a new way to inspect, track, and secure software containers. “We’re opening up the box,” Ziouani noted. “We can tell exactly where it came from, who touched it, and if it’s ready for mission-critical production environment or not.” Read the original and complete article on Fortune.com. ### Anchore’s Official Launch: How Did We Get Here? If you spend any time in the technology industry, you’ll probably be struck by how quickly the world changes. A lot of promising technological trends disappear as quickly as they appear, but some have staying power. Most are familiar with the technology adoption life cycle, originally published in 1957. Its premise holds true, and we can see it in action every day. I’ve spent most of my career in infrastructure technology, starting with rPath, where we pioneered the concept of “software appliances”—all-in-one software units containing all of the required dependencies all the way up to a minimal version of the base operating system. rPath was around for the introduction of cloud computing in 2006 when Amazon launched the first version of its Simple Storage Service (S3). Public cloud computing has outlasted the hype and become dominant throughout many industries because of its low barrier to entry, effectively limitless scale, and aggressive pricing. Private cloud computing, however, has not been as successful. I spent five years at Eucalyptus Systems building and selling an on-premise implementation of Amazon’s cloud platform. OpenStack was founded during that time, and we struggled to gain community and market adoption. An amazing number of platform companies spawned during that time, including Cloud.com, Nebula, and Piston Cloud. And several older infrastructure service projects moved into the private cloud market—OpenQRM, OpenNebula, and Abiquo. Still, large-scale adoption of private cloud platforms was elusive. Amazon’s EC2 was a major competitor, and despite the hype from OpenStack, Eucalyptus, and others, the advantages of public cloud computing didn’t always translate well into on-premise environments. Container Origins and Adoption Unless you’ve been living in a cave (No offense to cave-dwellers! I’m envious sometimes), you’ve heard of these new things like “Docker” and “containers.” Containers are actually not new. Linux has supported containers since 2001, but only lately has container-based systems management become popular. There are a lot of advantages to running apps in their own containers; advantages we were trying to exploit at rPath by bundling all of the required dependencies into a single, minimal computing environment. Containers promise unified environments between development, test, and production, with happier and more productive developers, greater ease of troubleshooting, fewer side effects when different system components are changed, and overall, more stable and more frequently updated applications. I spent most of 2014 skeptical of container promises thinking, “Isn’t this just virtualization again?” and, “This is more hyped than OpenStack, and look at how few production deployments of THAT exist?” But as I speak to more and more container users, I realize that adoption in production is occurring at a much faster rate than any other technological change I’ve experienced in my career. This rapid adoption is good news for a lot of people, including container management companies, developers frustrated by slow test/release cycles, and anyone responsible for managing large-scale systems with lots of dependencies and moving parts. All of this comes with risks, however. One of the problems we struggled with at rPath was handling out-of-band changes to “appliancized” systems. There was still a long modify-test-deploy cycle. This duration sometimes led to software appliances being modified in ways that were unmanageable, taking us right back to the inflexible and expensive “golden image” model, where the carefully hand-crafted golden image was the source of truth for how an environment should be constructed. If you lost that golden image, or if you needed to make major changes, you had a lot of work to do. Problems and Solutions Containers face many of the same problems today, including the hand-crafted, “artisan” containers, and there are few tools to manage provenance, examine container contents, and track changes over time. While this issue may not be a burden for the developers, it will rapidly become a headache for those responsible for production operations and the security of the applications. At Anchore, launched today, we are building tools to manage contents of the containers themselves, how they change over time, where they come from, and what’s inside, giving dev, test, and ops the visibility they need for reliable and secure application deployments. While early in our journey, we see the rapid and widespread adoption of container technology and are excited to watch what the container ecosystem has in store, and how we can help improve the agility, safety, and productivity of application developers throughout the industry. ### Deploying Containers with Confidence Container technology brings about a compute model that has been long been sought after, the ability to allow for agile application development and portability across heterogeneous environments while allowing development and operations teams to align in ways never before possible. Well, that’s the promise for now at least. The industry backing by the likes of Google, Red Hat, Intel, IBM, VMWare, to name a few, clearly shows strength and staying power of containerized apps for years to come. Google, in fact, has been using container technology since long before the buzz. Docker has helped containers cross over to the mainstream where developers can now extract value easier and faster. But in reality, container technology has also brought about new challenges that have made deploying in production a near-impossible task. The new compute paradigm, which forces existing infrastructures to be replatformed in most cases, is creating a shift in IT thinking. While a bare-metal to virtualization transition proved a substantial density-added value and fairly easy migration, containers are different. Today, new projects make up the majority of deployments while the migration of existing infrastructure continues to lag way behind. DockerHub, the largest container repository out there today, has seen close to 1B downloads so far. Spanning operating systems, databases, web services and many other technologies, the sheer download volume alone can intimidate anyone trying to deploy in mission-critical environments (think Linux circa 2000). With the understanding that new features are being added at an unprecedented pace, just keeping up with the latest ones is hard enough, let alone the most stable features. Having spoken to hundreds of users over the past year, it is clear to us now that transparency and predictability are key to bridging this gap for future production deployments of containers. A billion downloads do not necessarily equate to a stable platform and could instead point to an enormous amount of potential risk. For peace of mind, users today that need a stable platform tend to pivot towards creating their own repositories as a way to mitigate the risk. These repositories will most likely become stale over time while the baseline source continues to evolve and mature. This proves, once again, that the agility of app development and deployment using containers clearly overcomes the need to keep up with the latest and greatest technology in the public repositories. This is where Anchore comes in. Our goal is to connect these lines by creating a model of transparency and predictability, that allows users, whether in development, operations or security, to all have the tools necessary to effectively capitalize on the container compute model. Anchore is a tool that allows everyone to not only pick a collection of container-based apps that clearly show the origin and entire history but also apps that have been vetted for security, vulnerability, and functionality completeness. A set of containers that have been “Anchore certified” through collaboration with both internal and community users and tagged as production-ready. Allowing users to not only have stable repository but one that includes the most up-to-date container functionally, security checks, and bug fixes. ## Pages ### Partners ### SBOM Sprawl Software Bill of Materials (SBOM) has emerged as a pivotal technology to scale product innovation while taming the inevitable growth of complexity of modern software development. SBOMs are typically thought of as a comprehensive inventory of all software components—both open source and proprietary—within an application. But they are more than just a simple list of "ingredients". They offer deeper insights that enable organizations to unlock enterprise-wide value. From automating security and compliance audits to assessing legal risks and scaling continuous regulatory compliance, SBOMs are central to the software development lifecycle. However, as organizations begin to mature their SBOM initiative, the rapid growth in SBOM documents can quickly become overwhelming—a phenomenon known as SBOM sprawl. Below, we’ll outline how SBOM sprawl happens, why it’s a natural byproduct of a maturing SBOM program, and the best practices for wrangling the complexity to extract real value. Learn about the role that SBOMs for the security of your organization in this white paper. Download Now How does SBOM Sprawl Happen? SBOM adoption typically begins ad hoc when a Software Engineer starts self-scanning their source code to look for vulnerabilities or a DevOps Engineer integrating an open source SBOM generator into a non-critical CI/CD pipeline as a favor to a friendly Security Engineer. SBOMs begin to pile up niches across the organization and adoption continues to grow through casual conversation.  It’s only a matter of time before you accumulate a flood of SBOMs. As ad hoc adoption reaches scale, the volume of SBOM data balloons. We're not all running at Google's scale but their SBOM growth chart still illustrates the story of how new SBOM programs can quickly get out of hand. We call this SBOM sprawl. It is the overabundance of unmanaged and unorganized SBOM documents. When left unchecked, SBOM sprawl prevents SBOMs from delivering the value of its use-cases like real-time vulnerability discovery, automated compliance checks, or supply chain insights. So, how do we regain control as our SBOM initiative grows? The answer lies in a centralized data store. Instead of letting SBOMs scatter, we bring them together in a robust SBOM management system that can index, analyze, and make these insights actionable. Think of it like any large data management problem. The same best practices used for enterprise data management—ETL pipelines, centralized storage, robust queries—apply to SBOMs as well. What is SBOM Management (SBOMOps)? SBOM management—or SBOMOps—is defined as: A data pipeline, centralized repository and query engine purpose-built to manage and extract actionable software supply chain insights from software component metadata (i.e., SBOMs). In practical terms, SBOM management focuses on: Reliably generating SBOMs at key points in the development lifecycle Ingesting and converting 3rd-party supplier SBOMs Storing the SBOM documents in a centralized repository Enriching SBOMs from additional data sources (e.g., security, compliance, licensing, etc.) Generating the use-case specific queries and reports that drive results When done right, SBOMOps reduces chaos, making SBOMs instantly available for everything from zero-day vulnerability checks to open source license tracking—without forcing teams to manually search scattered locations for relevant files. SBOM Management Best Practices 1. Store and manage SBOMs in a central repository A single, central repository for SBOMs is the antidote to sprawl. Even if developer teams keep SBOM artifacts near their code repositories for local reference, the security organization should maintain a comprehensive SBOM inventory across all applications. Why it matters: Rapid incident response: When a new zero-day hits, you need a quick way to identify which applications are affected. That’s nearly impossible if your SBOM data is scattered or nonexistent. Time savings: Instead of rescanning every application from scratch, you can consult the repository for an instant snapshot of dependencies. 2. Support SBOM standards—but don’t stop there SPDX and CycloneDX are the two primary SBOM standards today, each with their own unique strengths. Any modern SBOM management system should be able to ingest and produce both. However, the story doesn’t end there. Tooling differences: Not all SBOM generation tools are created equal. For instance, Syft (OSS) and AnchoreCTL can produce a more comprehensive intermediate SBOM format containing additional metadata beyond what SPDX or CycloneDX alone might capture. This extra data can lead to: More precise vulnerability detection More granular policy enforcement Fewer false positives 3. Require SBOMs from all 3rd-party software suppliers It’s not just about your own code—any 3rd-party software you include is part of your software supply chain. SBOM best practice demands obtaining an SBOM from your suppliers, whether that software is open source or proprietary. Challenges: OSS: Open source libraries can be scanned relatively easily using software composition analysis (SCA) tools because source code is public. Remember, you are ultimately responsible for patching OSS vulnerabilities—not the maintainers. Proprietary: Commercial vendors may be wary of sharing SBOM data (IP or confidentiality concerns). If they won’t provide the SBOM, at least require them to maintain an SBOM-driven vulnerability management workflow and to notify you of relevant incidents. 4. Generate SBOMs at each step in the development process and for each build Yes, generating an SBOM with every build inflates your data management and storage needs. However, if you have an SBOM management system in place then storing these extra files is a non-issue—and the benefits are massive. SBOM drift detection:By generating SBOMs multiple times along the DevSecOps pipeline, you can detect any unexpected changes (drift) in your supply chain—whether accidental or malicious. This approach can thwart adversaries (e.g., APTs) that compromise upstream supplier code. An SBOM audit trail lets you pinpoint exactly when and where an unexpected code injection occurred. 5. Pay it forward >> Create an SBOM for your releases If you expect third parties to provide you SBOMs, it’s only fair to provide your own to downstream users. This transparency fosters trust and positions you for future SBOM-related regulatory or compliance requirements. If SBOM compliance becomes mandatory (we think the industry is trending that direction), you’ll already be prepared. How to Architect an SBOM Management System The reference architecture below outlines the major components needed for a reliable SBOM management solution: Integrate SBOM Generation into CI/CD Pipeline: Embed a SBOM generator in every relevant DevSecOps pipeline stage to automate software composition analysis and SBOM generation. Ingest 3rd-party supplier SBOMs: Ingest and normalize external SBOMs from all 3rd-party software component suppliers. Send All SBOM Artifacts to Repository: Once generated, ensure each SBOM is automatically shipped to the central repository to serve as your source-of-truth for software supply chain data. Enrich SBOMs with critical business data: Enrich SBOMs from additional data sources (e.g., security, compliance, licensing, etc.) Stand Up Data Analysis & Visualization: Build or adopt dashboards and query tooling to generate the software supply chain insights desired from the scoped SBOM use-cases. Profit! (Figuratively): Gain comprehensive software supply chain visibility, faster incident response, and the potential to unlock advanced use-cases like automated policy-as-code enforcement. You can roll your own SBOM management platform or opt for a turnkey solution 👇. SBOM Management Using Anchore SBOM and Anchore Enterprise Anchore offers a comprehensive SBOM management platform that help you centralize and operationalize SBOM data—unlocking the full strategic value of your software bills of materials: Anchore Enterprise Out-of-the-box SBOM generation: Combined SCA scanning, SBOM generation and SBOM format support for full development environment coverage. Purpose-built SBOM Inventory: Eliminates SBOM sprawl with a centralized SBOM repository to power SBOM use-cases like rapid incident response, license risk management and automated compliance. DevSecOps Integrations: Drop-in plugins for standard DevOps tooling; CI/CD pipelines, container registries, ticketing systems, and more. SBOM Enrichment Data Pipeline: Fully automated data enrichment pipeline for security, compliance, licensing, etc. data. Pre-built Data Analysis & Visualization: Delivers immediate insights on the health of your software supply chain with visualization dashboards for vulnerabilities, compliance, and policy checks. Policy-as-Code Enforcement: Customizable policy rules guarantee continuous compliance, preventing high-risk or non-compliant components from entering production and reducing manual intervention. Ready to get serious about securing your software supply chain?Request a demo to learn how Anchore Enterprise can help you implement a scalable SBOM management solution. ### SBOMs: The Missing Piece in Your ConMon Strategy Two cybersecurity buzzwords are rapidly shaping how organizations manage risk and streamline operations: Continuous Monitoring (ConMon) and Software Bill of Materials (SBOMs). ConMon, rooted in the traditional security principle—“trust but verify”—has evolved into an iterative process where organizations measure, analyze, design, and implement improvements based on real-time data. Meanwhile, SBOMs offer a snapshot of an application's composition (i.e., 3rd-party dependency supply chain) at any given point in the DevSecOps lifecycle.  Understanding these concepts is crucial because together they unlock significant enterprise value—ranging from rapid zero-day response to scalable vulnerability management and even automated compliance enforcement. By integrating SBOMs into a robust ConMon strategy, organizations can not only mitigate supply chain risks but also ensure that every stage of software development adheres to stringent security and compliance standards. A Brief Introduction to Continuous Monitoring (ConMon) Continuous Monitoring is a wide ranging topic applied across various contexts such as application performance, error tracking, and security oversight. In the most general sense, ConMon is an iterative cycle of: Measure: Collect relevant data. Analyze: Analyze raw data and generate actionable insights. Design: Develop solution(s) based on the insights. Implement: Execute solution to resolve issue(s) or improve performance. Repeat ConMon is underpinned by the well-known management theory maxim, "You can’t manage what you don’t measure." Historically, the term has its origins in the federal compliance world—think FedRAMP and cATO—where continuous monitoring was initially embraced as an evolution of traditional point-in-time security compliance audits. So, where do SBOMs fit into this picture? A Brief Introduction to SBOMs (in the Context of ConMon) In the world of ConMon, SBOMs are a source of data that can be measured and analyzed to extract actionable insights. SBOMs are specifically a structured store of software supply chain metadata. They track the evolution of a software artifacts supply chain as it develops throughout the software development lifecycle. An SBOM catalogs information like software supply chain dependencies, security vulnerabilities and licensing contracts. In this way SBOMs act as the source of truth for the state of an application's software supply chain during the development process. The ConMon process utilizes the supply chain data stored in the SBOMs to generate actionable insights like:  uncovering critical supply chain vulnerabilities, identifying legally risky open source licenses, or  catching new software dependencies that break key compliance frameworks like FedRAMP. SBOMs are the key data source that allows ConMon to apply its goal of continuously monitoring and improving an organization's software development environment—specifically, the software supply chain. Benefits of using SBOMs as the central component of ConMon As the cornerstone of the software supply chain, SBOMs play a central role in supply chain security which falls under the purview of the continuous monitoring workflow. Given this, it shouldn't be a surprise that there are cross-over use-cases between the two domains. Leveraging the standardized data structure of SBOMs unlocks a wealth of opportunities for automating supply chain security use-cases and scaling the principles of ConMon. Key use-cases and benefits include: 1. Rapid incident response to zero-day disclosure Reduced exploitation risk: SBOMs reduce the risk of supply chain exploitation by dramatically reducing the time to identify if vulnerable components are present in an organization's software environment and how to prioritize remediation efforts. Prevent wasted organizational resources: A centralized SBOM repository enables organizations to automate manual dependency audits into a single search query. This prevents the need to re-task software engineers away from development work to deal with incident response. 2. Software dependency drift detection Reduced exploitation risk: When SBOM generation is integrated natively into the DevSecOps pipeline a historical record of the development of an application becomes available. Each development stage is compared against the previous to identify dependency injection in real-time. Catching and remediating malicious injections as early as possible significantly reduces the risk of exploitation by threat actors. 3. Proactive and scalable vulnerability management Reduced security risk: SBOMs empower organizations to decouple software composition scanning from vulnerability scanning, enabling a scalable vulnerability management approach that meets cloud-native expectations. By generating an SBOM early in the DevSecOps pipeline, teams can continuously cross-reference software components against known vulnerability databases, proactively detecting risks before they reach production. Reduced time on vulnerability management: This streamlined process reduces the manual tasks associated with legacy vulnerability management. Teams are now enabled to focus their efforts on higher-level issues rather than be bogged down with tedious manual tasks. 4. Automated non-compliance alerting and enforcement Reduced risk of non-compliance violations: Proactive monitoring of SBOMs for compliance policy violations identifies issues early and prevents compliance fees from being assessed—or worse certification revocation. 5. Automated compliance report generation Reduce time spent generating compliance audit evidence: Manual generation of compliance audit reports to prove security best practices are in place is a time consuming process. SBOMs unlock the power to automate the generation of audit evidence for the software supply chain. This protects organizational resources for higher-value tasks. 6. Automated OSS license management Reduced legal risk: An adversarial OSS license accidentally entering a commercial application opens up an enterprise to significant legal risk. SBOMs enable organizations to automate the process of scanning for OSS licenses and assessing the legal risk of the entire software supply chain. Having real-time visibility into the licenses of an organization's entire supply chain dramatically reduces the risk of legal penalties. In essence, SBOMs serve as the heart of a robust ConMon strategy, providing the critical data needed to scale automation and ensure that the software supply chain remains secure and compliant. Interested to learn about all of the software supply chain use-cases that SBOMs enable? Read our new white paper and start unlocking enterprise value. Download Now SBOMs and ConMon applied to the DevSecOps lifecycle Integrating SBOMs within the DevSecOps lifecycle enables organizations to realize security outcomes efficiently through a cyclical process of measurement, analysis, design and implementation. We'll go through each step of the process. 1. Measure Measurement is the most obvious stage of ConMon given its synonym "monitoring" is in the name. The measurement step is primarily concerned with collecting as much data as possible that will later power the analysis stage. ConMon traditionally focuses on collecting security specific data like: Observability Telemetry: Application logs, metrics, and traces Audit Logs: Records of application administration: access and modifications Supply Chain Metadata: Point-in-time scans of the composition of a software artifacts supply chain of 3rd-party dependencies Software composition analysis (SCA) scanners and SBOM generation tools create an additional dimension of information about software that can then be analyzed. The supply chain metadata that is generated powers the insights that feeds the ConMon flywheel and increases transparency into software supply chain issues. External measurements (i.e., data sources) Additionally, external databases (e.g., NVD or VEX) can be referenced to correlate valuable information aggregated by public interest organizations like NIST (National Institute of Standards and Measures) and CISA (Cybersecurity and Infrastructure Security Agency). These databases act as comprehensive stores of the collective work of security researchers worldwide.  As software components are analyzed and tested for vulnerabilities and exploits, researchers submit their findings to these public goods databases. The security findings are tied to the specific software components (i.e., the same component identifier stored in an SBOM). After collecting all of this information, we are ready to move to the next phase of the ConMon lifecycle: analysis. 2. Analyze The foundational premise of ConMon is to monitor continuously in order to uncover security threats before they can cause damage. The analysis step is what transforms raw data into actionable security insights that reduce the risk of a breach.  Queries over Software Supply Chain Data: As the central data format for the software supply chain, SBOMs act as the data source that queries are crafted to extract insight from Actionable Insights: Highlight known vulnerabilities by cross-referencing the entire 3rd-party software supply chain against vulnerability databases like NVD Compare SBOMs from one stage of the pipeline to a later stage in order to uncover dependency injections (both unintentional and malicious) Codify software supply chain security or regulatory compliance policies into policy-as-code that can alert on policy drift in real-time 3. Design After generating insights from analysis of the raw data, the next step is to design a solution based on the analysis from the previous step. The goal of the designed solution is to reduce the risk of a security incident. Example Solutions Based on Analysis Vulnerability Remediation Workflow: After analysis has uncovered known vulnerabilities, designing a system to remediate the vulnerabilities comes into focus. Utilizing the existing engineering task management process is ideal. To live up to the promise of ConMon, the analysis to remediation process should be an automated system that pushes supply chain data from the analysis platform directly into the remediation queue. Dependency Injection Detection via SBOM Drift Analysis: SBOMs can be scanned at each stage of the DevSecOps pipeline, when anomalous dependencies are flagged as not coming from a known good source this analysis can be used to prompt an investigation. These types of investigations are generally too complex to be automated but the investigation process still requires design. Automated Compliance Enforcement via Policy-as-Code: By codifying software supply chain best practices or regulatory compliance controls into policy-as-code, organizations can be alerted to policy violations in real-time. The solution design includes a mapping of policies into code, scans against containers in the DevSecOps pipeline and a notification system that can act on the analysis. 4. Implement The final step of ConMon involves implementing the design from the previous step. This also sets up the entire process to restart from the beginning. After the design is implemented it is ready to be monitored again to assess effectiveness of the implemented design. Execution of Solution Design Vulnerability Remediation Workflow: Configure the analysis platform to push a report of identified vulnerabilities to the engineering organization's existing ticketing system. Prioritize the vulnerabilities based on their severity score to increase signal-to-noise ratio for the assigned developer or gate the analysis platform to only push reports if a vulnerability is classified as high or critical. Dependency Injection Detection via SBOM Drift Analysis: Integrate SBOM generation into two or more stages of the DevSecOps pipeline to enable diff analysis of software supply chain analysis over time. Allowlists and denylists can fine tune which types of dependency injections are expected and which are anomalous. Investigations into suspected dependency injection can be triggered based on anomaly detection. Automated Compliance Enforcement via Policy-as-Code: Security policies and/or compliance controls will need to be translated from english into code but this is a one-time, upfront investment to enable scalable, automated policy scanning. A scanner will need to be integrated into one or more places in the CI/CD build pipeline in order to detect policy violations. As violations are identified, the analysis platform can push notifications to the appropriate team. 5. Repeat Step 5 isn't actually a different step of ConMon, it is just a reminder to return to Step 1 for another turn of the ConMon cycle. The 'continuous' in ConMon means that we continue to repeat the process indefinitely. As security of a system is measured and evaluated, new security issues are discovered that then require a solution design and design implementation. This is the flywheel cycle of ConMon that endlessly improves the security of the system that is monitored. Real-world Scenario SBOMs and ConMon aren't just a theoretical framework, there are a number of SBOM use-cases in production that are delivering value to enterprises. The most prominent of these is the security incident response use-case. This use-case moved into the limelight in the wake of the string of infamous software supply chain attacks of the past decade: Solarwinds, Log4j, XZ Utils, etc. The biggest takeaway from these high-profile incidents is that enterprises were caught unprepared and experienced pain as a result of not having the tools to measure, analyze, design and implement solutions to these supply chain attacks. Large enterprises like Google responded to this deficit by deploying an SBOM-powered software supply chain solution that generates over 100 million SBOMs a year! As a result of having this system in place Google was able to rapidly respond to the XZ Utils incident without having to utilize any manual processes that typically extend supply chain attacks like these from minutes into days or weeks. Brandon Lum, Google’s SBOM lead, recounts that “within 10 minutes of the XZ [Utils] announcement, the entire Google organization was able to rule out that anything was impacted.” This outcome was only possible due to Google's foresight and willingness to instrument their DevSecOps pipeline with tools like SCAs and SBOM generators and continuously monitor their software supply chain. Ready to Reap the Rewards of SBOM-powered ConMon? Integrating SBOMs as a central element of your ConMon strategy transforms how organizations manage software supply chain security. By aligning continuous monitoring with the principles of DevSecOps, security and engineering leaders can ensure that their organizations are well-prepared to face the evolving threat landscape—keeping operations secure, compliant, and efficient. If you're interested in embracing the power of SBOMs and ConMon but your team doesn't want to take on this side question themselves, Anchore offers a turnkey platform to unlock the benefits without the headache of building and managing a solution from scratch. Anchore Enterprise is a complete SBOM-powered, supply chain security solution that extends ConMon into your organization's software supply chain. Reach out to our team to learn more or start a free trial to kick the tires yourself. ### DORA + SBOM At Anchore, we frequently discuss the steady drum beat of regulatory bodies mandating SBOMs (Software Bills of Materials) as the central element of modern software supply chain security. The Digital Operational Resilience Act (DORA) is the most recent framework responding to the accelerating growth of software supply chain attacks—by requiring, in all but name, the kind of structured software inventory that SBOMs provide. In this post, we provide an educational overview of DORA, explain its software supply chain implications, and outline how SBOMs factor into DORA compliance. We’ll also share how to achieve compliance—and how Anchore Enterprise can serve as your DORA compliance "easy button.” What is DORA? The Digital Operational Resilience Act (DORA)—formally Regulation (EU) 2022/2554—is an EU regulatory framework designed to ensure the digital operational resilience of financial entities. Key points include: Effective Date: January 17, 2025 TL;DR: It is already being enforced. Scope: Applies to a wide range of EU financial entities, including: Banks Payment service providers Investment firms Crypto-asset service providers, and more Core Topics Proactive Risk Management: For both 1st- and 3rd-party software. Incident Response and Recovery: Mandating robust strategies to handle ICT (Information and Communication Technology) disruptions. Resilience Testing: Regular, thorough testing of incident response and risk management systems. Industry Threat Information Sharing: Collaboration across the sector to share threat intelligence. 3rd-party Software Supplier Oversight: Continuous monitoring of 3rd-party software supply chain. DORA is organized into a high-level cybersecurity and risk management framework document and a separate technical control document—referred to as the "Regulatory Standards Technical Document"—that outlines in detail how to achieve compliance. If you're familiar with NIST’s RMF (NIST 800-37) and its "Control Catalog" (NIST 800-53) DORA follows this pattern. What challenge does DORA solve? In part driven by a 2020 study that highlighted “systemic cyber risk” due to the “high level of interconnectedness” among the technologies used by financial organizations, DORA aims to mitigate the risk that a vulnerability in one component could lead to widespread sector disruption. Two critical factors underline this need: The Structure of Modern Software Development: With extensive 3rd-party and open source dependencies, any gap in security can have cascading consequences. The Rise of Software Supply Chain Attacks: Now that open source software "constitutes 70-90% of any given piece of modern software" threat actors have embraced this attack vector. Software supply chain attacks have not only become a primary cybersecurity target but are seeing accelerating growth. DORA is designed to fortify the financial sector's digital resilience by addressing vulnerabilities in modern software development and countering the rapid rise of software supply chain attacks. What are the consequences of DORA non-compliance? Compliance is not optional. The European Supervisory Authorities (ESAs) have been given broad powers to: Access Documents and Data: Assessing an organization’s compliance status through comprehensive audits. Conduct On-Site Investigations: Ensuring that all software supply chain controls are in place and functioning. Enforce Steep Penalties: For instance, DORA Article 35 notes that critical ICT third-party service providers could face fines of up to “1% of the average daily worldwide turnover… in the preceding business year.” For financial entities—and their technology suppliers—the cost of non-compliance is too high to ignore. Does DORA Require an SBOM? DORA does not explicitly mention “SBOMs” by name. Instead, it mandates organizations track "third-party libraries, including open-source libraries". SBOMs are the industry standard method for achieving this result in an automated and scalable manner.  Specifically, financial entities are required to track: Third-Party Libraries: Including open-source libraries used by ICT services that support critical or important functions. In-House or Custom Software: ICT services developed internally or specifically customized by an ICT third-party service provider. These "general" requirements without specifically naming a specific technology (like an SBOM) is a common pattern for other global regulatory compliance frameworks (e.g., SSDF). Another reason to adopt SBOMs for DORA compliance is that the EU Cyber Resilience Act (CRA) compliance specifically names SBOMs as a required compliance artifact. SBOMs knock out two birds with one stone. DORA and Software Supply Chain Security  DORA Regulation 56 underscores the necessity of open source analysis (or Software Composition Analysis, SCA) as a fundamental component for achieving operational resilience. SCA's are software supply chain security tools that are typically tightly coupled with SBOM generators. Standalone SCA's and SBOM generation are fantastic tools to create simple point-in-time inventories for generating the necessary compliance artifacts to pass an initial audit. Unfortunately, DORA demands that financial entities continuously monitor their software supply chain: Ongoing Monitoring: Article 10 of DORA requires that financial entities, in collaboration with their ICT third-party service providers, not only maintain an inventory but also track version updates and monitor third-party libraries on an ongoing basis. Continuous Software Supply Chain Risk Management: It’s not enough to have an SBOM at one moment in time; you must continuously scan and update the inventory to ensure that vulnerabilities are promptly identified and remediated. This level of supply chain security requires organizations to directly integrate SBOM generation into their DevSecOps pipeline and utilize an SBOM management platform. How to Fulfill DORA’s Software Supply Chain Requirements 1. Software Composition Analysis (SCA) and SBOM Generation Automate SBOM Creation: Integrate SBOM generation into your CI/CD pipelines to ensure that every release is accompanied by an up-to-date, machine-readable software inventory. Adopt Standard Formats: Use accepted SBOM standards (e.g., CycloneDX or SPDX) to maintain interoperability and ease of analysis. 2. Ingest SBOMs from Third-Party Suppliers Collaborative Supply Chain Management: Ensure that you receive and maintain SBOM data from all your third-party suppliers to achieve full visibility into the software components you rely on. 3. Continuous Monitoring in Production Regular Scanning: Implement continuous monitoring to detect any unexpected changes or vulnerabilities in production environments. Key Features to Look For: Alerts for unexpected software components A centralized repository to store and manage SBOMs Revision history tracking to monitor changes over time DORA Compliance Easy Button: Anchore Enterprise Anchore Enterprise is engineered to satisfy all of DORA’s software supply chain requirements, acting as your DORA compliance easy button. Here’s how Anchore Enterprise can help: Automated Software Supply Chain Risk Management End-to-End SBOM Lifecycle Management (Anchore SBOM): Automatically generate and update SBOMs throughout your software development lifecycle. Programmatic Vulnerability Scanning & Risk Assessment (Anchore Secure): Continuously scan software components and assess risk based on real-time data. Policy-as-Code Enforcement (Anchore Enforce): Automate risk management policies to ensure adherence to DORA’s requirements. Software Supply Chain Incident Response Automation Continuous SCA and SBOM Generation (Anchore SBOM): Keep an updated view of your production software environment. Surgical Zero-Day Vulnerability Identification (Anchore Secure): Quickly identify and remediate vulnerabilities, reducing the potential blast radius of an attack. Google resolved the XZ Utils zero-day incident in less than 10 minutes by utilizing SBOMs and an SBOM management platform. Anchore Enterprise can help your organization achieve similar results >> SBOM management solutions. Continuous Compliance Monitoring Real-Time Dashboards (Anchore Enforce): Monitor compliance status with customizable, real-time dashboards. Automated Compliance Reports (Anchore Enforce): Generate and share compliance reports with stakeholders effortlessly. Policy-as-Code Compliance Automation (Anchore Enforce): Enforce compliance at every stage of the software development lifecycle. If you're interested in trying any of these features for yourself, Anchore Enterprise offers a 15-day free trial or reach out to our team for a demo of the platform. Wrap-Up DORA is redefining software supply chain security in the financial sector by demanding transparency, proactive risk management, and continuous monitoring of 3rd-party suppliers. For technology providers, this shift represents both a challenge and an opportunity: by embracing SBOMs and comprehensive supply chain security practices, you not only help your customers achieve regulatory compliance but also strengthen your own security posture. At Anchore, we’re committed to helping you navigate this evolving landscape with solutions designed for the modern world of software supply chain security. Ready to meet DORA head-on? Contact us today or visit our blog for more insights and resources. ### What is Software Composition Analysis (SCA)? What is Software Composition Analysis (SCA)? Software composition analysis (SCA) is an automated security process that identifies and inventories open-source and third-party components within software applications. SCA tools scan codebases to generate detailed reports of all dependencies, their versions, known vulnerabilities, license compliance issues, and potential security risks.  By providing visibility into the complex web of components that make up modern applications, software composition analysis enables organizations to proactively manage security risks, maintain compliance, and make informed decisions about the software they develop and deploy. What is SCA in practical terms? SCA has become increasingly critical as modern software development relies heavily on pre-existing components. With up to 90% of most applications consisting of open-source and third-party code, organizations need robust SCA tools to track, manage, and secure these building blocks throughout the software development lifecycle. Learn why legacy software composition analysis (SCA) scanners are no longer viable in the cloud native era and how modern SCA's solve these deficiencies. Watch Now The Importance of SCA for Cybersecurity and Open-Source Software Software composition analysis has emerged as a critical component of modern software supply chain cybersecurity strategies, particularly because open source software fundamentally shifts security responsibility. Unlike proprietary software with dedicated vendors who provide security guarantees, patches, and compliance documentation, OSS has no traditional vendor standing behind it. The OSS developers are essentially "a volunteer workforce that allows you to re-use their work but it is a take it or leave it agreement. You have no recourse if it doesn't work as expected, or worse, has vulnerabilities in it." This reality creates a profound security challenge: when your organization incorporates open source components, you become the de facto supplier for that software. The security burden shifts entirely to you. Without comprehensive SCA implementation, organizations remain vulnerable to exploits targeting known SCA vulnerabilities in outdated dependencies that no vendor is obligated to patch or even notify you about. High-profile security incidents like Log4j, XZ Utils, and CUPS vulnerabilities have demonstrated how quickly attackers can exploit these weaknesses across thousands of organizations simultaneously. By integrating robust software composition analysis into security practices, teams can fulfill their supplier responsibilities for OSS components by identifying vulnerabilities early, prioritizing remediation efforts based on actual risk, and maintaining compliance documentation that would typically come from a traditional vendor. SCA effectively becomes your organization's defense mechanism against the "take it or leave it" nature of open source software—allowing you to leverage OSS innovation while managing the unique security challenges that come with being your own supplier for these critical components. Key SCA Benefits for Development Teams Implementing software composition analysis provides numerous SCA benefits throughout the development lifecycle: Early vulnerability detection: Identify security issues before they become deeply embedded in your codebase, reducing remediation costs and complexity. License compliance management: Avoid legal risks by ensuring all components adhere to license requirements and organizational policies. Reduced development costs: Decrease the need for costly emergency fixes by addressing SCA vulnerabilities during development rather than in production. Enhanced software quality: Improve overall code quality by identifying outdated, deprecated, or poorly maintained dependencies through continuous SCA scanning. Accelerated development: Safely leverage open-source components while maintaining security, enabling faster time-to-market. Comprehensive visibility: Gain a complete inventory of all components, their origins, versions, and potential risks through automated SCA tools. Regulatory compliance: Meet industry and government requirements for software transparency and security with robust SCA testing procedures. How Does SCA Scanning Work? 1. Component Discovery and Identification Software composition analysis begins by scanning source code, build files, and package managers to identify all open-source and third-party components. This includes direct dependencies as well as transitive dependencies (dependencies of dependencies) that might otherwise remain hidden. Helpful SCA tools: Anchore's open-source SBOM generator, Syft creates detailed software bills of materials (SBOMs) in standard formats like CycloneDX and SPDX, providing comprehensive component inventories through automated SCA scanning. 2. SCA Vulnerability Detection and Assessment Once components are identified, SCA tools check them against multiple vulnerability databases such as the National Vulnerability Database (NVD), GitHub Security Advisories, and vendor-specific advisories. This process reveals known SCA vulnerabilities that could impact your application. Helpful SCA tools: Anchore's open-source vulnerability scanner, Grype performs deep vulnerability scanning against multiple databases, providing accurate, up-to-date security information on all discovered components. 3. License Analysis and Compliance Verification SCA solutions identify and analyze the software licenses associated with each component, flagging potential compliance issues or conflicts with organizational policies. This helps teams manage legal risks associated with open-source use. Helpful SCA tools: Anchore's open-source licence scanner, Grant provides comprehensive license compliance management, helping teams adhere to organizational policies and legal requirements through advanced SCA testing. 4. Risk Prioritization Not all vulnerabilities represent equal risk. Advanced SCA tools help teams prioritize remediation efforts by evaluating factors like severity, exploitability, and component usage within the application. Helpful SCA tools: Anchore Secure offers risk-based prioritization to help teams focus on the most critical SCA vulnerabilities first, maximizing security impact with limited resources. 5. Continuous Monitoring and Alerts As new vulnerabilities are discovered daily, SCA tools provide ongoing monitoring of components and generate alerts when new risks emerge in previously scanned applications. Helpful SCA tools: Anchore Secure integrates continuous SCA scanning throughout your development pipeline, ensuring security remains consistent across the software lifecycle. Expert Tips for Integrating SCA in CI/CD Pipelines and Overcoming Common Challenges 1. Start with a Risk-Based Approach "Don't try to fix everything at once," advises Dan Nurmi, Anchore's CTO. "Begin by addressing critical vulnerabilities in your most important applications. This targeted approach yields faster security improvements while building team momentum." 2. Automate SCA Early in the Development Process Implement SCA scans during the commit or pull request stage to catch issues before they enter your main codebase. This "shift-left" approach reduces remediation costs and makes security a natural part of the development workflow. 3. Establish Clear Policies and Exceptions Create well-defined policies for vulnerability management, including acceptable risk levels and exception processes. Document your decision-making criteria to maintain consistency while accommodating business priorities. 4. Address the False Positive Challenge SCA tools sometimes flag vulnerabilities that don't affect your application due to how components are used. Implement a verification process to validate findings before committing resources to unnecessary fixes. 5. Build Developer Security Awareness "Security tools are only as effective as the teams using them," notes Josh Bressers, Anchore's VP of Security. "Invest in developer education about common vulnerabilities and secure coding practices to create a proactive security culture." Top SCA Vendors and Tools to Streamline Software Composition Analysis Anchore Enterprise Anchore Enterprise stands out among SCA vendors by providing comprehensive software supply chain security with advanced SCA capabilities. It seamlessly integrates with CI/CD pipelines to automate SCA scanning, license compliance, and SBOM generation. With features like policy enforcement, customizable risk scoring, and centralized management, Anchore Enterprise enables organizations to implement robust security governance across their entire software portfolio. Syft Syft is Anchore's open-source SBOM generator that creates accurate, comprehensive software bills of materials in industry-standard formats. It identifies packages and dependencies across various ecosystems including container images, filesystems, and language-specific package managers. As a foundational SCA tool, Syft provides the detailed component inventory needed for subsequent SCA security analysis. Grype Grype, Anchore's open-source vulnerability scanner, works in tandem with Syft to detect known SCA vulnerabilities in your software components. It scans against multiple vulnerability databases to provide comprehensive coverage and can be easily integrated into CI/CD workflows. With low false positive rates and regular database updates, Grype ensures teams can trust their vulnerability data when making remediation decisions. Software Composition Analysis FAQs What's the difference between SCA and SBOM? Software Composition Analysis (SCA) is the comprehensive process of identifying, analyzing, and managing third-party and open-source components in software, including SCA vulnerability detection and license compliance.  An SBOM (software bill of materials) is one output of this process—a formal, machine-readable inventory of all software components and dependencies used in an application.  Think of an SBOM as the ingredients list, while SCA testing is the entire nutritional analysis and food safety inspection process. Who needs SCA tools? Any organization that develops or maintains software applications should implement SCA tools, especially those who incorporate open-source components. If your organization would cease to function if your custom software disappeared, software composition analysis is essential for you.  While small and medium-sized businesses may rely primarily on SaaS solutions and desktop applications, they should still verify that their software suppliers take software supply chain security seriously and employ SCA scanning in their development processes. How does software composition analysis align with compliance requirements? While SCA isn't explicitly mandated by most regulations, it's effectively required to meet many compliance obligations at scale. Various industry and government regulations increasingly require organizations to maintain accurate inventories of their software supply chain components and manage associated risks.  Attempting to fulfill these requirements manually would be impractical and resource-intensive, making automated SCA tools essential for compliance in today's software-driven enterprises. Wrap-Up: The Future of Software Composition Analysis Software composition analysis has evolved from a nice-to-have security practice to an essential component of modern software development. As organizations continue to leverage open-source and third-party code to accelerate innovation, the ability to effectively manage SCA vulnerabilities becomes increasingly critical. By implementing robust SCA tools and testing processes, teams can build secure, compliant applications without sacrificing development velocity. Ready to strengthen your software supply chain security with advanced SCA capabilities? Explore Anchore Enterprise's comprehensive SCA scanning solutions or get started with our open-source SCA tools today. If you’d like to learn more about the Anchore Enterprise platform or speak with a member of our team, feel free to book a time to speak with one of our specialists. ### FedRAMP Overview There’s a whole lot to know about FedRAMP, and while there are countless resources available that ensure information on the subject is in no short supply, it can be daunting to sift through, especially when what you really need are quick, straightforward answers. FedRAMP also continues to evolve, meaning organizations should keep a consistent pulse on the shifting process and requirements for achieving authorization. In 2024, the program began a major modernization initiative dubbed "FedRAMP 20x." Its goal? Transform the program "into a streamlined, automation-driven compliance framework that accelerates secure cloud adoption across federal agencies while leveraging modern technologies to minimize bureaucracy and maximize efficiency," according to a 2025 post from FedRAMP.gov. To make it easier to understand key FedRAMP compliance requirements and keep up with all of these changes, our team at Anchore put together this comprehensive list of FedRAMP FAQs, complete with real-world perspectives and examples where you need them most. Simply find your question in the table of contents on the left, jump down to find the answer, and bookmark this page for when you have future FedRAMP questions and need an answer in a pinch. Some Background on FedRAMP What is FedRAMP?  FedRAMP, which stands for the Federal Risk and Authorization Management Program, is a US Federal compliance program. It provides a standardized approach to cloud security assessment, authorization, and continuous monitoring for cloud products and services.  Essentially, it enables federal agencies to take advantage of the latest SaaS/Cloud offerings. The last 15 years have seen the software industry transition from a perpetual license business model to a subscription business model. What this means is that the most innovative software with the highest productivity gains are only available via a SaaS/Cloud deployment model. This effectively barred federal agencies from access to an entire generation of software vendors. FedRAMP was created in order to address this gap. What are the goals of FedRAMP? Ensuring security: It establishes a set of standardized security requirements for cloud service providers (CSPs) who want to work with federal agencies. Promoting efficiency: By creating a "do once, use many times" framework, FedRAMP reduces the time and cost associated with security assessments for both government agencies and CSPs. Enhancing consistency: It provides a uniform process for assessing and authorizing cloud services across different federal agencies. Increasing confidence: FedRAMP helps federal agencies feel more confident in adopting cloud technologies by ensuring that approved services meet rigorous security standards. Supporting modernization: By streamlining the adoption of secure cloud services, FedRAMP aids in the federal government's IT modernization efforts. What are the governing bodies of FedRAMP?  FedRAMP has several key governing bodies that oversee its operations and ensure its effectiveness. FedRAMP Program Management Office (PMO) The FedRAMP PMO serves as the operational hub of the FedRAMP program with several key responsibilities: Reviewing and auditing FedRAMP documents/deliverables Updating CSP FedRAMP status on the FedRAMP Marketplace Developing and maintaining FedRAMP processes, templates, and guidance Coordinating between agencies, cloud providers, and 3rd-party assessment organizations (3PAOs) Office of Management and Budget (OMB): OMB provides the policy guidance for FedRAMP It issued the original policy memo that created FedRAMP and continues to provide oversight National Institute of Standards and Technology (NIST): While not a direct governing body, NIST plays a crucial role by providing the risk framework and security controls that FedRAMP is based on (i.e., Risk Management Framework (RMF), NIST 800-37 and the Control Catalog, NIST 800-53) These bodies work together to ensure that FedRAMP remains effective, up-to-date, and aligned with federal cybersecurity needs. Their collaborative efforts help maintain the program's integrity and its ability to serve federal agencies and cloud service providers effectively. What’s the difference between FedRAMP & FISMA?  The Federal Information Security Management Act of 2002 (FISMA) is a federal law that requires all federal agencies to implement an information security program to protect the agency's data. FedRAMP is a compliance program that proves a cloud service provider is in compliance with FISMA and can be adopted by federal agencies. Here are the key differences: 1. Purpose: FISMA: Establishes a comprehensive framework to protect government information, operations, and assets against natural or man-made threats. FedRAMP: Provides a standardized approach specifically for assessing, authorizing, and continuously monitoring cloud products and services. 2. Scope: FISMA: Applies to all federal agencies and their information systems, including both cloud and non-cloud systems. FedRAMP: Focuses exclusively on cloud service providers (CSP) used by federal agencies. 3. Authorization Approach: FISMA: Each agency is responsible for authorizing its own systems (self-authorization). FedRAMP: CSPs must go through a formal authorization process managed by the FedRAMP PMO (third-party). After achieving FedRAMP authorization a CSPs service can be easily deployed for any other federal agency. 4. Historical Context: FISMA: Enacted in 2002 (updated in 2014 as FISMA Reform Act) to address overall federal information security. FedRAMP: Established in 2011 specifically to support the government's cloud-first initiative. Making the Decision to Pursue FedRAMP ATO Who needs to be FedRAMP certified?  FedRAMP certification is primarily required for: Cloud Service Provider (CSP) Any company offering cloud-based products or services that wants to do business with US federal government agencies needs to be FedRAMP certified. This includes: Software-as-a-Service (SaaS) providers: e.g., Salesforce, Atlassian, Zoom, etc. Infrastructure-as-a-Service (IaaS) providers: e.g., Amazon Web Services, Microsoft Azure, Google Cloud, etc. Platform-as-a-Service (PaaS) providers: e.g., Cloudflare Workers developer platform, Vercel, DigitalOcean App Platform, etc. As of June 2025, there are 430 FedRAMP authorized cloud service offerings (CSOs) listed on the FedRAMP marketplace. Sponsoring Federal Agency A US federal agency acts as the "sponsor" for CSPs pursuing their initial FedRAMP authorization. While agencies don't get FedRAMP-authorized themselves, they are required to use FedRAMP-authorized cloud services for their deployments that involve controlled—but not classified—data. This includes agencies like: Department of Commerce (DoC) Centers for Disease Control and Prevention (CDC) Food and Drug Administration (FDA) United States Secret Service (USSS) It's important to note that non-cloud software products and services used by federal agencies fall under different security frameworks (e.g., FISMA, SSDF, etc.) and don't require FedRAMP authorization. This primarily refers to software that runs "on-premise" in an agency's cloud environment. 3rd-Party Assessment Organizations (3PAOs) 3PAOs are independent entities that perform the initial and periodic security assessments for CSPs seeking FedRAMP authorization. To serve in this capacity, these organizations must themselves be accredited by the FedRAMP PMO. A current list of authorized 3PAOs is available on the FedRAMP Marketplace website. What are the benefits?  The decision to pursue FedRAMP certification can be significant for a company. Here are the key benefits and considerations to help determine if it's worth it: Access to Federal Market: Opens up a large market of federal agencies as potential customers. The US government spends billions annually on cloud services, with federal IT budgets for cloud computing reaching $8.3bn in FY 2025. Competitive Advantage: Differentiates your company in the marketplace; can be attractive to non-federal customers who value high security standards. Improved Security Posture: The rigorous process often leads to overall improvements in a company's security practices. Reusability: Once certified, the authorization can be leveraged across multiple federal agencies. In fact, FedRAMP authorized cloud products were reused more than 4,500 times across the federal government in FY22. Streamlined Compliance: Jump starts progress towards other compliance certifications (e.g., HIPAA, SOC 2) due to overlapping controls. Watch Now What are the drawbacks? Cost: The certification process can be expensive, potentially costing hundreds of thousands to millions of dollars. Time & Resource Investment: The authorization process is lengthy, often taking 12-18 months or more. Additionally, ongoing maintenance requires continuous monitoring and regular assessments. Altogether, this demands significant staff time and may require hiring specialized personnel. Complexity: The process is rigorous and complex, requiring a deep understanding of security practices. Is it worth it? Whether or not FedRAMP authorization is worthwhile depends on your organization and goals. In addition to the above-listed benefits and drawbacks, consider... Your target market (how important federal customers are to your business strategy) Available resources (both financial and personnel) Long-term business goals Current security posture (how much work is needed to meet FedRAMP requirements) For companies with a strong focus on serving federal agencies or those in industries where security is paramount, the benefits often outweigh the costs. However, for smaller companies or those not targeting federal customers, the investment may not be justified. How long does it take to get FedRAMP certified? The FedRAMP certification process can be lengthy and complex. While the duration can vary depending on several factors, here's a general timeline: Typical Duration On average, the full FedRAMP certification process takes about 12-18 months. Some organizations may complete it in as little as 6-9 months, while others might take 2 years or more. Factors Affecting Timeline Readiness of the Cloud Service Provider (CSP) Complexity of the system Level of security authorization required (Low, Moderate, or High) Chosen authorization path (Agency Authorization or JAB Provisional Authorization) Responsiveness of the CSP to assessment findings Current workload of the reviewing bodies Key Phases and Approximate Durations Preparation and Readiness Assessment: 1-3 months Documentation Development: 3-6 months Third-Party Assessment: 2-4 months Agency Review and Authorization: 3-6 months Continuous Monitoring (ConMon) After initial authorization, continuous monitoring is ongoing Considerations It's important to note that this timeline assumes a relatively smooth process. Delays can occur if: The system has significant security gaps that need addressing Documentation is incomplete or inadequate There are delays in remediation of identified issues The reviewing agency has a backlog To expedite the process, CSPs are advised to: Thoroughly prepare before starting the formal process Engage with a FedRAMP consultant or experienced advisor Ensure all documentation is complete and accurate from the start Be responsive to inquiries and quick to address any identified issues Remember, while the initial certification is a significant milestone, FedRAMP compliance is an ongoing process requiring continuous monitoring and periodic reassessments. What is the cost of achieving FedRAMP ATO?  The cost of achieving FedRAMP Authorization to Operate (ATO) can vary significantly depending on several factors. Here's a breakdown of the typical costs and considerations: Overall Cost Range Generally, costs can range from $500,000 to $2 million or more. Some organizations report spending up to $5 million for complex systems or high-impact level authorizations. Key Cost Factors    Size and complexity of the cloud system    Current security posture and how much work is needed to meet FedRAMP requirements    Level of authorization sought (Low, Moderate, or High impact)    Whether using internal resources or external consultants Specific Cost Areas Internal Labor Costs: Often the largest expense, typically ranging from $400,000 to $1 million+ Includes time for security team, developers, management, etc. Third-Party Assessment Organization (3PAO) Fees: Usually between $150,000 to $300,000 for initial assessment Ongoing annual assessments can cost $50,000 to $150,000 Consulting Fees (if used): Can range from $100,000 to $500,000 or more Helps with readiness, documentation, and guidance through the process Technology and Tools: $50,000 to $200,000 for security tools, monitoring systems, etc. Documentation and Preparation: Can cost $100,000 to $300,000 if outsourced Ongoing Costs Annual continuous monitoring and maintenance can cost 30-50% of the initial authorization cost Hidden Costs Potential system upgrades or redesigns to meet security requirements Opportunity costs of dedicating resources to FedRAMP instead of other projects Cost-Saving Strategies Thorough preparation before starting the formal process Leveraging existing security controls and documentation Using FedRAMP-compliant cloud infrastructure providers, like AWS GovCloud It's important to note that while these costs are significant, they should be weighed against the potential return on investment from accessing the federal market and the overall improvement in security posture. Companies considering FedRAMP authorization should conduct a thorough cost-benefit analysis and potentially consult with FedRAMP advisors to get a more accurate estimate based on their specific situation. The FedRAMP Certification Process  What are the FedRAMP impact levels?  FedRAMP categorizes cloud systems into three impact levels based on the potential impact of a security breach. These levels are directly aligned with the Federal Information Processing Standard (FIPS) 199. Here are the three FedRAMP impact levels: LI-SaaS Specifically designed for Low Impact Software-as-a-Service (SaaS) applications that process only limited types of data (e.g., no PII beyond username, password and email address) Features streamlined documentation requirements and fewer security controls compared to standard Low baseline Enables faster authorization path for low-risk cloud services Low Impact For systems where the loss of confidentiality, integrity, and availability would have a limited adverse effect on an agency's operations, assets, or individuals. Typically involves publicly available information or non-sensitive data. Requires implementation of the FedRAMP Low baseline security controls. Moderate Impact For systems where a loss would have a serious adverse effect on an agency's operations, assets, or individuals. This is the most common level for federal systems. Covers a wide range of sensitive but unclassified data. Requires implementation of the FedRAMP Moderate baseline security controls. High Impact For systems where a loss could have a severe or catastrophic adverse effect on organizational operations, assets, or individuals. Involves highly sensitive information, including certain types of law enforcement and emergency services data, financial data, health records, and other critical assets. Requires implementation of the FedRAMP High baseline security controls, which are the most rigorous. Key points The impact levels are a pyramid, each higher level incorporates all the controls from the lower levels—plus additional ones. The number of security controls increases significantly with each level (LI-SaaS: at least 37, Low: 125, Moderate: 325, High: 421 controls). Agencies determine the appropriate impact level based on the type of data they plan to store or process in the cloud system. Cloud Service Providers (CSPs) can choose which impact level(s) to pursue certification for, based on their target market and capabilities. The impact level determines the depth and breadth of the security assessment, influencing both the cost and time required for FedRAMP authorization. Higher impact levels generally require more extensive security measures and more rigorous assessments. What are the FedRAMP requirements for each impact level?  The FedRAMP requirements for each impact level are inherited from NIST 800-53, which serves as the authoritative reference for security controls for many federal compliance programs (e.g., SSDF, ATO/cATO, CMMC, etc).  Watch Now Here's an overview of the requirements for each impact level: Low Impact SaaS Total Controls: 37 controls (may expand to ~50–60 if the service touches PII, supports mobile apps, etc.) Key Requirements: Focus areaRepresentative requirementsAccess & authMFA for privileged accounts and all remote administrative sessionsLeast-privilege RBAC documented in an ACL matrixEncryptionFIPS 140-2/140-3-compliant encryption in transit (TLS 1.2+ preferred)Audit & monitoringCentral log retention: 30-day online; 12-month cold storageMonthly vulnerability scansAnnual penetration testIncident response (IR) & continuityIR plan with 1 business-day reporting window to FedRAMP PMOBackup plan that meets a 24-hour RPO/RTODocumentationFedRAMP SSP “lite,” POA&M, and customer-facing SLA with security provisions Low Impact Total Controls: 125 Key Requirements: everything in LI-SaaS, plus… Boundary protection (SC-7): basic firewalling/segmentation between CSP internal zones and the FedRAMP-authorized service boundary System hardening (CM-6) using DISA STIGs/CIS benchmarks; configuration drift scans at least quarterly Contingency Planning (CP) with annual tabletop exercise Identification & Authentication (IA) for all users (MFA for privileged, strong passwords for others) Continuous Monitoring strategy aligned to FedRAMP ConMon (monthly scanning, quarterly SAR updates) Moderate Impact Total Controls: 325 Key Additional Requirements: all Low requirements, plus key upgrades such as… Encryption at rest for all customer data; keys managed in a FIPS 140-validated module or HSM MFA for every user (privileged and non-privileged) when accessing via the public Internet Vulnerability scanning frequency increased to weekly (internally) and monthly (externally); 72-hr remediation of critical findings Event logging depth increased (full packet/header data, administrator commands, security-relevant API calls); 90-day hot / 12-month cold retention Incident response testing (functional exercise) at least quarterly, with results fed into POA&M Personnel security: Tier 2 background checks; annual security & privacy training refreshers System interconnection agreements (ISA/MOU) required for every external interface High Impact Total Controls: 421 Key Additional Requirements: all Moderate controls, plus stricter safeguards, including… Segmentation & isolation down to subnet / VLAN or container namespace; internal traffic inspection (east-west IDS) Hardware-backed crypto controls (FIPS 140-3 Level 3+) for key storage; two-person rule for key operations Near-real-time continuous monitoring: automated event correlation & alerting within 60 minutes; daily manual log review Supply-chain & code-integrity: code-signing, SBOM, tamper-evident build pipeline, and third-party component vetting Advanced vulnerability management: authenticated scans of all hosts daily; web-app scans daily; quarterly red-team exercise Enhanced personnel vetting: Tier 3 (or higher) background investigations; insider-threat and privileged-user monitoring program Physical security comparable to NIST High: mantraps, 24×7 guards, CCTV retention ≥ 90 days Recovery time objectives tightened (e.g., RTO ≤ 8 hours, RPO ≤ 1 hour) and annual operational fail-over test Common themes Focus areaRepresentative requirementsMulti-factor authenticationAlways for admins; increasingly for all users as impact risesEncryptionMandatory for data in transit (all levels) and at rest (Moderate/High)Vulnerability managementAuthenticated scanning, penetration testing, defined remediation windowsConfiguration & change management (CM)Hardened baselines, documented change control, and routine drift detectionAudit & monitoring (AU)Centralized logging, time-sync (NTP), role separation for log review, retention ≥ 12 monthsIncident response (IR)Formal IR plan, 1-hour to 24-hour notification to US-CERT/FedRAMP depending on severityContingency planning & backupsTested backups, defined RTO/RPO, alt site or cloud-native replicationPersonnel & trainingBackground checks, annual security & privacy training, role-based training for adminsDocumentation & third-party assessmentSSP, SAP, SAR, POA&M, customer-facing system description, and a 3PAO assessmentContinuous monitoring (ConMon)Ongoing scanning, monthly POA&M updates, annual security control assessment, and real-time defect reporting via FedRAMP’s Dashboard It's important to note that these requirements are regularly updated to address evolving security threats and technologies. CSPs must stay current with the latest FedRAMP requirements and continuously monitor and maintain their systems to ensure ongoing compliance. How do I determine my organization's impact level? To determine your organization’s FedRAMP impact level, first understand that the vast majority of cloud service providers end up in the Moderate category—about 80 percent of all FedRAMP Authorizations to Operate (ATOs), according to FedRAMP itself. Impact levels are assigned according to the risk posed by the federal data your service processes or stores.  If you believe your system could qualify for a lower or higher tier, first walk through the NIST FIPS 199 rating process, which FedRAMP inherits for impact categorization. Under FIPS 199, the highest confidentiality-integrity-availability (CIA) rating observed anywhere in your environment sets the bar for the entire system. In practice, handling Controlled Unclassified Information (CUI) or other sensitive personally identifiable information (PII) typically elevates you to at least Moderate. Ultimately, the sponsoring agency’s AO (Authorizing Official) has final say, so validate your proposed impact level with them early to avoid rework. What are the steps to getting FedRAMP certified?  The process of obtaining FedRAMP certification involves several key steps. Here's a high-level overview of the typical path to FedRAMP authorization: Learn how to navigate FedRAMP authorization while avoiding all of the most common pitfalls. Download Now Step 0: Project Scoping and Business Analysis Before formally beginning the FedRAMP authorization process, organizations should engage and prepare all of the initiative stakeholders. FedRAMP is a massive undertaking in the best of circumstances and requires effort from almost every department of an enterprise. Without full alignment there is a non-trivial risk of the initiative failing. Alignment is formed by conducting thorough project scoping and business analysis. Tasks Determine the Cloud Service Offering(s) (CSO) in scope Determine categorization of the agency data that will be stored and processed by CSO Determine the impact level you're targeting (LI-SaaS, Low, Moderate, High) Conduct a gap analysis between your current security posture and FedRAMP requirements Identify a specific agency to sponsor your organization Note: The previous JAB Authorization path (aka P-ATO) has been discontinued. Step 1: Readiness Assessment (Optional but Recommended) While it is optional, the Readiness Assessment step is a powerful preparatory exercise. If your organization is uncertain about their own gap analysis assessment, engaging with an experienced 3PAO is a shortcut to creating confidence that later steps and stages will go smoothly. Note: This stage is only available to organizations targeting Moderate and High impact levels. Tasks CSP develops a System Security Plan (SSP) CSP selects an accredited 3PAO from FedRAMP Marketplace to perform assessment CSP performs security review and Readiness Assessment Report with 3PAO CSP develops a plan to address any identified security gaps FedRAMP Marketplace Status: FedRAMP-Ready Watch Now Step 2: Pre-Authorization The pre-authorization step is either the first or second official step of the FedRAMP process depending on if your organization opted-out or were disqualified from the Readiness Assessment step. This step is primarily documentation and initial engagement with the FedRAMP PMO and sponsoring agency. Tasks (If you skipped Step 1) CSP develops a System Security Plan (SSP) CSP submits a CSP Information Form CSP completes In Process Request (IPR) and Work Breakdown Structure (WBS) with sponsoring agency CSP conducts formal FedRAMP Kickoff Meeting with the sponsoring agency, the FedRAMP PMO and the 3PAO (if applicable) FedRAMP Marketplace Status: FedRAMP-In Process Step 3: Full Security Assessment The Authorization stage begins the formal FedRAMP security and compliance process. This step requires a formal security assessment performed by a 3PAO and a formal remediation plan that will be presented to your sponsoring agency in the next step. Tasks 3PAO performs an independent security assessment of the CSO system 3PAO delivers a Security Assessment Report (SAR) to CSP CSP develops a Plan of Action and Milestones (POA&M) for remediation Step 4: Agency Authorization Process The Agency Authorization Process is the final step for a CSP to achieve their initial authority to operate (ATO). This step focuses on making sure that your sponsoring agency is satisfied with your organization's performance during Step 3 and that the audit evidence collected during the preceding steps meets the FedRAMP PMO's requirements. Tasks Sponsoring agency reviews CSP's Security Assessment Plan (SAP) Agency issues Authority to Operate (ATO) to CSP CSP submits FedRAMP Authorization Package to FedRAMP PMO FedRAMP Marketplace Status: FedRAMP-Authorized Step 5: Post Authorization (Continuous Monitoring) Achieving FedRAMP ATO is not the end of your compliance journey—it's merely the starting line. While organizations typically approach FedRAMP authorization as a marathon with a photo finish, the reality is that the DevSecOps movement has transformed US government compliance. Under the name of continuous monitoring (ConMon), the one-time marathon that was FedRAMP compliance has morphed into a never-ending treadmill of security and compliance activities. Tasks CSP uploads monthly security documentation Annual 3PAO administered security assessment Remember, FedRAMP authorization is a complex and time-consuming process that typically takes 12-18 months or more. Each step may involve multiple sub-steps and iterations. It is a marathon not a sprint—plan accordingly. What tools or solutions can help me achieve FedRAMP compliance?  Several tools and solutions can assist in achieving and maintaining FedRAMP compliance. Here's an overview of key categories and some examples: Compliance Management Platforms Automated tools to track controls, manage documentation, and monitor compliance Examples: Coalfire FedRAMP Assurance, A-LIGN's A-SCEND, Schellman Comply Security Information and Event Management (SIEM) Centralized logging and security event monitoring Examples: Splunk, Panther, LogRhythm Software Supply Chain Vulnerability Scanning and Management Identify and track vulnerabilities in your systems Examples: Anchore Enterprise Watch Now Configuration Management Ensure systems are configured according to FedRAMP requirements Examples: Chef, Puppet, Ansible Identity and Access Management (IAM) Manage user access and implement multi-factor authentication Examples: Okta, Microsoft Azure Active Directory, AWS IAM Encryption Tools Protect data at rest and in transit Examples: Hashicorp Vault, AWS Key Management Service Continuous Monitoring (ConMon)  Automate ongoing security assessments Examples: Anchore Enterprise Document Management Systems Organize and maintain required documentation Examples: Drata, AuditBoard, Archer Insight Incident Response and Management Tools to help detect, respond to, and manage security incidents Examples: PagerDuty, ServiceNow Security Operations Cloud Access Security Brokers (CASBs) Visibility and control over cloud service usage Examples: Microsoft Defender for Cloud Apps, Cloudflare CASB Network Security Tools Firewalls, intrusion detection/prevention systems Examples: Cloudflare, Palo Alto Networks, F5 Data Loss Prevention (DLP) Prevent unauthorized data exfiltration Examples: Zscaler, Cloudflare DLP When selecting tools: Ensure they meet FedRAMP requirements for their respective functions Consider solutions that integrate well with your existing infrastructure Look for tools that can generate reports in FedRAMP-required formats Prioritize solutions that can help automate compliance processes Remember, while these tools can significantly aid in achieving and maintaining FedRAMP compliance, they're not a substitute for a comprehensive security program and expert guidance. Many organizations use a combination of these tools along with consulting services to navigate the FedRAMP process effectively. Other FedRAMP FAQs What’s the difference between ATO and P-ATO?  A P-ATO (Provisional Authority to Operate) is a legacy designation for the Joint Authorization Board (JAB) Authorization path that was discontinued in 2024. Have there been any changes to FedRAMP? Yes, FedRAMP has undergone several changes and updates since its inception in 2011. Here are the most significant changes and ongoing initiatives: ThemeDetailsBaseline Alignment & ModernizationFedRAMP adopted each new revision of NIST SP 800-53 (Rev 3 → Rev 4 → Rev 5) and folded in newer privacy, crypto (FIPS 140-3), and zero-trust logging requirements as they appeared, keeping the control set current with technology and threats.Speed & ScalabilityWhat began as year-long, paperwork-heavy authorizations gained time-cutting programs—FedRAMP Accelerated (2016), the light-weight Tailored LI-SaaS path (2017), and now the automation-centric FedRAMP 20x initiative (2025)—all aimed at shrinking cost and cycle time.Automation & Machine-Readable PackagesStarting with OSCAL templates in 2020, FedRAMP has pushed for machine-readable SSPs, scans, and POA&Ms. The FedRAMP 20x roadmap makes “automation-first” processing the default, enabling continuous assurance rather than annual re-assessment.Risk-Based, Threat-Informed FocusGuidance shifted from compliance-checkbox reviews to threat-based prioritization (2021 white paper, 2022 update), letting agencies weight controls by real-world adversary tactics and system mission criticality.Institutionalization & Legal AuthorityAn OMB memo program in 2011 became permanent law via the FedRAMP Authorization Act (Dec 2022), creating an advisory committee and a “presumption of adequacy” for reused authorizations—cementing FedRAMP’s role in federal cloud procurement. FedRAMP has continuously tightened technical baselines, codified itself in law, and layered in automation and risk-driven methods—all to authorize secure cloud services faster while staying aligned with an evolving threat landscape. As FedRAMP continues to evolve, cloud service providers and federal agencies should stay informed about the latest updates and requirements. Next Steps FedRAMP is an exhaustive topic as evidenced by the length of this article. The important thing to remember when beginning this journey to achieving FedRAMP compliance is that it is a journey. This is a process that takes time. If you're looking for shortcuts to get to the punchline as quick as possible, be sure to read our case study on how Cisco Umbrella utilized Anchore Enterprise to achieve FedRAMP compliance in weeks versus months or reach out to our team directly and we can walk you through how we can help your organization achieve similar results. ### NIS2 Compliance with SBOMs: a Scalable, Secure Supply Chain Solution Software supply chain attacks have emerged as one of the most acute cybersecurity threats in the last decade. The European Union's (EU) Network and Information Security 2 (NIS2) Directive represents a significant up-leveling of cybersecurity requirements for EU businesses to address this rising threat. NIS2 is, also, a piece of the evolution of a larger, global regulatory puzzle focused on modernizing cybersecurity by codifying supply chain security—with special emphasis on SBOMs—into law. The NIS2 Directive: A New Era for EU Cybersecurity NIS2 expands the scope and requirements of its predecessor (NIS1), with software supply chain security playing a starring role in this update. EU member states had until October 17, 2024, to transpose it into national law, with NIS2 superseding the original NIS Directive as of October 18, 2024. The most notable change to NIS2 is the shift of liability from corporation to personal. This means the executive team and board of directors are now personally liable for compliance and the consequences of non-compliance. A significant deterrent to corporate executives who would rather prioritize growth and neglect cybersecurity. This expanded directive applies to "essential" services, though the definition is broad. It includes the usual suspects like energy, transportation, healthcare, financial services, but also encompasses "digital service providers" including public cloud platforms, online marketplaces, and search engines. If you're headquartered outside the EU, NIS2 may still apply to your organization if you have over €10 million in revenue in a given EU member nation or over 50 employees, regardless of your headquarters location. The Broader Landscape: SBOMs, Supply Chain Security and NIS2 in Context NIS2 is one step in a broader regulatory reformation to make supply chain security a first-class citizen of cybersecurity compliance: EU Cybersecurity Act (2019): Established ENISA (the EU cybersecurity agency) as a permanent agency and created a voluntary cybersecurity certification framework for Information and Communication Technology (ICT) products. SBOMs were not required, but third-party supplier component management was specified as best practice. ETSI Standards (2020): ETSI (European Telecommunications Standards Institute) first published standards for consumer IoT security in June 2020. These recommended maintaining a list of third-party software and managing known vulnerabilities, which aligns with SBOM principles, even though "SBOM" did not explicitly appear in the standards. NIS2 Directive: Proposed in December 2020 and adopted as law January 2023, emphasizes supply chain security and third-party supplier component management. TR-03183 Part 2: SBOMs become mandatory (October 2024) for third-party supplier component management. EU Cyber Resilience Act (CRA): Adopts the mandatory SBOM requirement from TR-03183 Part 2 when it is adopted as law in November 2024, though not fully enforced until December 2027. Digital Operational Resilience Act (DORA): Couldn't wait for EU CRA enforcement and requires SBOMs now. Proposed January 2023 and enforced as of January 2025 for financial services including traditional banking, fintech, and crypto services. How NIS2 Up-levels Software Supply Chain Security Requirements Beyond the shift of liability highlighted above, NIS2 represents a substantial evolution in the EU's approach to cybersecurity, with several key changes that directly impact software supply chain security: Expanded Sector Coverage NIS2 covers significantly more sectors than the original NIS Directive, introducing categories of "Highly Critical Sectors" and "Critical Sectors." This broader scope reflects the EU's recognition that nearly all industries now rely heavily on digital infrastructure and face similar threat landscapes. Rigorous Size-Based Requirements The directive applies to medium and large entities based on specific size criteria, ensuring that organizations with significant digital footprints meet appropriate security standards regardless of their industry classification. Enhanced Supply Chain Security Focus NIS2 places particular emphasis on supply chain security as a key focus area, acknowledging that modern cyberattacks increasingly target the weakest links in interconnected digital ecosystems. How SBOMs Address NIS2 Requirements SBOMs serve as the foundation for meeting several critical NIS2 requirements. They enable organizations to: Enable scalable risk management for complex, modern software development patterns Meet incident reporting deadlines (24-hour early warning, 72-hour assessment) Automate supply chain security and third-party supplier risk management Manage corporate and personal liability under NIS2 compliance requirements Here's how SBOMs specifically address key aspects of the directive: 1. Automated and Scalable Vulnerability Management NIS2 requires proactive risk management as outlined in Article 21(2)(d), which mandates that entities protect their networks and IT system from security incidents by implementing "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers". SBOMs enable automated vulnerability identification and management by providing a comprehensive inventory of all software components in use including the relationships between each entity and its direct suppliers or service providers. With this inventory, organizations can automatically cross-reference their components against vulnerability databases, prioritize patches based on severity, and address issues before they can be exploited. This proactive approach significantly reduces the risk of breaches due to unpatched vulnerabilities—a common attack vector that NIS2 specifically targets in its risk management framework. 2. Rapid Zero-Day Incident Response Article 23 of NIS2 requires rapid incident notification, with "essential and important entities [submitting] an early warning without undue delay and in any event within 24 hours" of becoming aware of a significant incident. SBOMs accelerate identification of affected components during incidents by providing immediate visibility into where vulnerable components exist across the organization. When a new zero-day vulnerability is announced (as with Log4j), companies with SBOMs can quickly search their inventory to determine exposure and prioritize remediation efforts. This capability is crucial for meeting NIS2's strict reporting timeline requirements, as organizations must know what's affected to report accurately and respond effectively. Learn how SBOMs enable organizations to react to zero-day disclosures in minutes rather than days or weeks. Watch Now 3. Automated Compliance Evidence Generation Article 21 of NIS2 emphasizes accountability and documentation, requiring entities to "maintain documentation that is sufficient to demonstrate compliance" with its risk management measures. SBOMs serve as evidence of due diligence in security practices by documenting the components used in software systems and demonstrating an organization's proactive approach to supply chain security. They provide auditable records of software components and their security status, which can be crucial during regulatory inspections. This documentation capability aligns directly with NIS2's emphasis on accountability and transparency, providing tangible evidence of compliance efforts. Learn about all of the SBOM use-cases for extract enterprise value from your software supply chain >> Practical Implementation Roadmap with Timelines Implementing SBOM-based compliance for NIS2 requires a systematic approach. Here's a practical roadmap to help organizations prepare: 1. Conduct a Risk Assessment of Current Software Assets Start by generating SBOMs for all software components. Integrate software composition analysis (SCA) scans and SBOM generation directly into your DevSecOps pipeline to ensure comprehensive coverage. Then, integrate these SBOMs into your vulnerability management processes by connecting SBOM data with vulnerability scanners in your pipeline. Finally, establish incident response plans that incorporate SBOM data by creating automated alerts based on this information that feed directly into your incident response system. 2. Automate Risk Assessment To maintain compliance over time, regularly update and audit SBOMs to ensure ongoing accuracy and completeness. Implement a policy-as-code approach for automated NIS2 compliance checking, allowing for continuous validation against regulatory requirements. How Anchore Enterprise Automates NIS2 Compliance Anchore's comprehensive SBOM-powered platform provides the tools necessary to meet NIS2 requirements efficiently: Automate software composition analysis (SCA) and SBOM generation with AnchoreCTL, making it easy to inventory all software components Implement automated vulnerability scanning and management with Anchore Secure, ensuring rapid identification and remediation of security issues Generate automated NIS2 compliance evidence with Anchore Enforce, streamlining documentation requirements Achieve supply chain transparency, tracking, and management with Anchore SBOM, providing visibility throughout your software ecosystem Future-Proofing Compliance with Robust SBOM Practices As the October 2024 deadline for NIS2 implementation has passed, organizations must act quickly to ensure compliance if they haven't already done so. By implementing a comprehensive SBOM strategy, businesses can not only meet NIS2 requirements but also position themselves advantageously for future regulatory frameworks. SBOMs provide the foundation for a secure software supply chain, enabling the transparency, vulnerability management, and rapid incident response capabilities that NIS2 demands. With potential penalties including significant fines and personal liability for executives, the stakes for compliance have never been higher. By adopting SBOM-based practices now, organizations can transform their approach to software security, moving from reactive firefighting to proactive risk management—a shift that aligns perfectly with NIS2's objectives and the broader evolution of global cybersecurity standards. Learn about the role that SBOMs for the security of your organization in this white paper. Download Now ### Homepage - New ### SBOM ### Plans & Pricing - New ### Platform ### EU CRA SBOM Requirements: Overview & Compliance Tips A Quick History of SBOM Requirements in the EU Before the EU Cyber Resilience Act (CRA), there were no specific, EU-wide legal requirements mandating the use of software bills of materials (SBOMs). However, there were related frameworks and industry guidance that touched on software supply chain transparency or product cybersecurity. Here’s a brief overview of what came before: EU Cybersecurity Act (2019): Established ENISA (the EU cybersecurity agency) as a permanent agency and created a voluntary cybersecurity certification framework for ICT products. SBOMs were not required, but some certification schemes encouraged component transparency as a best practice. ETSI Standards: ETSI (European Telecommunications Standards Institute) first published standards for consumer IoT security in June 2020. These recommended maintaining a list of third-party software and managing known vulnerabilities, which aligns with SBOM principles, but “SBOM” did not explicitly appear in the standards. NIS Directive (2016) and NIS2 (2022 update): Focused on network and information system security, particularly for essential services. While NIS2 raised expectations for software supply chain security, it still did not mandate SBOMs. TR-03183 Part 2 (2024): SBOMs became mandatory in the 2.0 updated release. The EU CRA adopts the mandatory SBOM requirement from this document when it is adopted later in 2024. What Is the EU Cyber Resilience Act? The EU Cyber Resilience Act (CRA) is a landmark regulation introduced by the European Commission to strengthen cybersecurity requirements for digital products sold in the EU. It applies to manufacturers, importers, and distributors of hardware and software with software components—ranging from smart devices to enterprise software—and requires them to build cybersecurity into their products from design through the entire lifecycle. The CRA’s goal is to reduce vulnerabilities, improve transparency around known risks, and ensure companies are accountable for maintaining product security, including after a product is released on the market. By enforcing baseline security requirements and mandatory incident reporting, the CRA represents a shift from voluntary guidelines to legally binding obligations, positioning the EU as a global leader in regulating software and device security. EU CRA Timeline Proposal Submission: September 15, 2022​ Political Agreement Reached: December 1, 2023​ European Parliament Approval: March 12, 2024​ Council Adoption: October 10, 2024​ Entry into Force: December 10, 2024​ Main Obligations Applicable From: December 11, 2027​ An Overview of What the EU CRA Says About SBOMs ​The European Union's Cyber Resilience Act (CRA) mandates that manufacturers of products with software components create and maintain a software bill of materials (SBOM). This SBOM must be in a commonly used, machine-readable format and include, at a minimum, the top-level dependencies of the product. While the CRA does not require manufacturers to make the SBOM publicly available, they must include it in the product's technical documentation and provide it to market surveillance authorities upon request. The European Commission is empowered to specify the exact format and elements of the SBOM, potentially aligning with international standards. ​ An Introduction to SBOMs A software bill of materials (SBOM) is a detailed inventory of all the components that make up a software application, including libraries, packages, and dependencies. Much like an ingredient list for packaged food, an SBOM provides transparency into what’s inside a piece of software—critical for identifying and managing security vulnerabilities, especially in third-party or open-source code. Learn about the role that SBOMs for the security of your organization in this white paper. Download Now Steps to Prepare for the CRA SBOM Requirements Generate SBOMs for all software products: Create a software bill of materials for every digital product you manufacture or distribute in the EU. The SBOM should list all top-level software components and be formatted in a commonly used, machine-readable standard (e.g., SPDX, CycloneDX, or SWID). Ensure it's included in your product’s technical documentation. Learn how to generate an SBOM with free open source tools Learn about SBOM formats and standards Explore solutions for automating SBOM generation and management Automate vulnerability scanning: Use automated tools to continuously scan components listed in your SBOMs for known vulnerabilities. Integrate scanning into your CI/CD pipeline to detect issues early and maintain a real-time view of software risks. Discover enterprise tools to automate vulnerability scanning See how DreamFactory saves 75% more time with automated vulnerability management Maintain a secure software development lifecycle (SSDLC): Embed security best practices throughout the product development process—from design and coding to testing and deployment. This includes threat modeling, code reviews, dependency management, and secure update mechanisms. Learn how to use SBOMs and security policy-as-code to automate secure development practices Document security policies and remediation processes: Maintain clear internal documentation outlining your approach to identifying, assessing, and remediating vulnerabilities. This documentation may be requested by market surveillance authorities under the CRA. Don't just document—automate compliance policy enforcement with Anchore Enforce's policy engine and policy-as-code language (i.e., DSL) Collaborate with suppliers and partners on SBOM exchange: Ensure you can access and verify SBOMs from upstream software vendors and third-party suppliers. Establish trusted, standardized channels to receive, share, and validate SBOM data across your software supply chain. Learn how Anchore SBOM automates SBOM ingest (in all standard formats) and SBOM export to downstream customers of your product/service (in the vendors preferred format) CRA SBOM Compliance Checklist for Manufacturers (by December 2027) Generate a software bill of materials (SBOM) for each product Include top-level software components Use a commonly used, machine-readable format (e.g., SPDX, CycloneDX) Include the SBOM in the product’s technical documentation Make documentation available to EU market surveillance authorities upon request Keep SBOMs up to date throughout the product lifecycle with regular or automated SBOM management Reflect changes due to patches, component updates, or software modifications Request SBOMs or component lists from third-party suppliers for supply chain coordination Ensure third-party software components are accounted for in your own SBOM Monitor developments from the European Commission regarding specific SBOM format requirements Be prepared to align with additional formatting or content specifications as they are released Final Thoughts The Cyber Resilience Act reinforces the global movement toward greater transparency in the software supply chain. By proactively integrating SBOMs into your development and documentation processes now, your organization can stay ahead of compliance requirements and reduce risk. Taking early action not only streamlines future audits and reporting but also helps avoid costly remediation efforts and potential non-compliance penalties down the line. Interested to learn about all of the software supply chain use-cases that SBOMs enable? Read our new white paper and start unlocking enterprise value. Download Now ### SCA vs. SBOM: How They Differ & Why They Work Best as a Team Data breaches cost organizations an average of $4.88 million globally—with U.S. companies facing even higher costs at $9.36 million per incident. But the real concern is the explosive growth in supply chain attacks, which saw a staggering 540% year-over-year growth from 2019 to 2022 and doubled again in 2024. Yet most organizations struggle with a fundamental question: Should we invest in software composition analysis (SCA) tools, software bill of materials (SBOM) management, or both? This article breaks down how SCA and SBOM differ and why they are most effective when used as complementary tools. SCA vs SBOM TL;DR SCA == Automated software scanning tool that analyzes all components/dependencies and structure of your applications SBOM == Standardized and interoperable application component inventory that acts as source-of-truth for numerous supply chain use-cases   Business Impact: Together, SCA + SBOM: Reduces zero-day vulnerability disclosure response time from days to minutes Saves developers time by automating security, compliance, legal, etc. feedback Meets compliance requirements of frameworks like FedRAMP, EU CRA, etc. Bottom Line: You need both—SCA generates the deep structural raw data, SBOMs create actionable insights across your organization SCA vs. SBOM: Basic Definitions What is Software Composition Analysis (SCA)? SCA automatically identifies and profiles all software components (both direct and transitive dependencies) in your applications—like running your codebase through a CT scan that reveals the internal structure of your software. It automates the previously manual codebase review and documentation process or reverse-engineering a compiled binary to determine its composition. For a deeper dive on SCA, check out our Introduction to SCA. Note: Often SCAs definitions include the ability to identify and track vulnerabilities but this isn't precisely true. The SCA process detects individual components and a separate vulnerability scanning process matches the software components against publicly disclosed vulnerabilities (e.g., CVEs). What is a Software Bill of Materials (SBOM)? An SBOM is a document that stores metadata about an application. It includes data, such as, dependencies, supply chain relationships, known vulnerabilities, OSS/proprietary licenses, compliance requirements— really anything you might want to track about a software artifact.  Beyond acting as documents, SBOMs are also an interoperable data standard. Two primary organizations manage the SBOM standard, OWASP (CycloneDX format) and the Linux Foundation (SPDX format). By standardizing on common data fields and types (e.g., JSON/XML), the software ecosystem is able to use an SBOM generated by any supplier to power a number of diverse use-cases (see below). Has your interest been piqued? Get into the nitty-gritty with our Introduction to SBOMs. SCA vs. SBOM: Key Differences Outside of these basic definitions, SCA and SBOMs differ a few key ways: Purpose & Benefits: Saving time for developers & operations vs. generating actionable insights for entire software supply chain Use-cases: How they are applied in real-world supply chain use-cases like security and compliance scenarios SCA vs. SBOM: Purpose & Benefits Understanding these tools starts with their core purposes, but the real value emerges in how they complement each other. SCA Key purposes and benefits: Saves developer and DevSecOps team time from manual dependency review by automating software decomposition process Enables scaling of software composition scanning—SCA can automatically be run at multiple stages of DevSecOps lifecycle (e.g., development, build, stage, production) to detect supply chain drift or malicious injection Creates deep transparency (direct and transitive dependencies) into software supply chain of individual artifacts SBOM Key purposes and benefits: Allow seamless supply chain ecosystem integration by utilizing standards-based, interoperable data format Enables real-time insights into software supply chain through centralized inventory and automated analysis Used as scalable source-of-truth for software supply chain use-cases, including: Security Compliance Licensing Etc. (see below for specific use-cases) Use-cases SCA Use-cases Continuous monitoring: SCA integrates into multiple stages of CI/CD pipelines to create a record of how composition of a software artifact changes over time. Deep transparency: Define direct dependencies as well as transitive dependencies (dependencies of dependencies) to recursively map the supply chain of an artifact. License discovery: Identify software licenses explicitly attached to a supply chain component. SBOM Use-cases Regulatory compliance: SBOMs help organizations automate software security compliance with standards like FedRAMP, cATO, SSDF and PCI DSS. Incident response: Security teams use SBOMs to quickly determine whether software is affected by newly discovered vulnerabilities. Proactive, shift left development: Developers generate SBOMs to get automated and incremental feedback from other stakeholder departments like security, compliance, legal, etc. Shared Use-cases Risk management: Both tools help organizations reduce security risks by increasing software transparency and risk analysis. Regulatory audits: Companies use SCA and SBOM together to meet compliance standards. Vulnerability tracking: SCAs identify components, SBOMs document the components and vulnerability scanners match the components to known vulnerabilities. Legal exposure management: SCAs identify components and licenses, SBOMs are analyzed to determine if any dependencies expose the organization to legal consequences. Here is an easy reference table with the key differentiators: SCASBOMTypeApplication component scanning toolApplication supply chain document & interoperable standardPurposeDecompose and report on software components and structureStore software metadata (e.g., components/structure) in scalable and interoperable formatUse-cases• Continuous software monitoring• Deep supply chain transparency• Automates component license discovery• Automates regulatory compliance audits• Zero-day disclosure incident response• Proactive, shift left development practices• Cybersecurity risk management• Regulatory compliance audits• Vulnerability management• Legal exposure managementCompliance• Not explicitly named but effectively required by all modern compliance standards (e.g., FedRAMP, cATO, PCI DSS, etc.)• Explicitly required by EU CRA, US EO 14028, etc.• Not explicitly named but effectively required by all other modern compliance standards (e.g., FedRAMP, cATO, PCI DSS, etc.) Interested to learn about all of the software supply chain use-cases that SBOMs enable? Read our new white paper and start unlocking enterprise value. Download Now Strengthening Security & Compliance: Why SCA & SBOM Work Better Together SCA and SBOM serve different but complementary roles in a risk management strategy. When used together, they provide: Deep supply chain transparency and large enterprise use-case breath: SCA provides deep analysis of software supply chains while SBOMs serve as the source-of-truth for numerous supply chain use-cases that generate enterprise value for departments across the organization. Regulatory compliance support: All modern cybersecurity regulatory frameworks require both proactive vulnerability detection (SCA + vulnerability scanning) and software component tracking (SCA + SBOM). Enhanced supply chain security: Using SCA’s real-time scanning alongside SBOM’s dynamic inventory analysis and reporting ensures organizations maintain a secure software supply chain even during a crisis like a zero-day disclosure. How SCAs help generate SBOMs When an SCA tool scans a software artifact, it executes deep dependency resolution and component enumeration: extracting package manifests,  analyzing binary signatures, and  constructing complete dependency graphs—including transitive relationships. This metadata extraction process generates structured component inventories containing: precise package identifiers (CPE, PURL),  version specifications,  cryptographic hashes, and  hierarchical dependency mappings.  The SCA scan result is then inserted into a standardized SBOM format—typically either SPDX or CycloneDX—creating machine-readable documents. An SBOM can then be enriched by utilizing a vulnerability scanner to run a match function comparing the component version inventory against one or more publicly available vulnerability databases like National Vulnerability Database (NVD), GitHub Security Advisories, and vendor-specific databases. To help illustrate these relationships, see the diagram below. Tips & Tools for Combining SCA & SBOM in Your DevOps Lifecycle 1. Automate SCA & SBOM Integration in CI/CD Security best practices start with automation. Integrate SCA into your CI/CD pipeline to scan for vulnerabilities before deployment and configure SBOMs to generate automatically with every build. Automating both ensures continuous security checks while maintaining development velocity. Tools to try: Anchore Secure enables automated composition scanning, vulnerability scanning and policy enforcement directly in CI/CD workflows while Anchore SBOM centrally stores, manages, and analyzes them. 2. Align SCA & SBOM with Risk Management & Compliance Policies Define clear security policies for detecting and mitigating vulnerabilities flagged by SCA. SBOMs should serve as the source of truth for software composition, ensuring compliance with licensing requirements, regulatory frameworks, and internal security policies. Tools to try: Anchore Enforce automates compliance checks by applying customizable policy packs that evaluate security, license risks, and regulatory requirements in your SBOMs. 3. Monitor SBOMs for Newly Discovered Vulnerabilities A deployed SBOM is not static—security teams must continuously monitor it for newly disclosed vulnerabilities. By cross-referencing SBOM data against the latest vulnerability intelligence, organizations can proactively mitigate risks before they become exploits. Tools to try: Use Syft to generate SBOMs and Grype to scan SBOMs for vulnerabilities in real-time. For enterprise-grade continuous monitoring and vulnerability remediation, Anchore SBOM combined with Anchore Secure provides deep insights, runtime context, and secret/malware scanning. 4. Ensure Development Teams Use Both Tools Effectively Security is most effective when seamlessly integrated into development workflows. Teams should be trained on how to interpret SBOM data and vulnerability reports, ensuring they can act on security findings early in the development lifecycle. Tools to try: Anchore Enterprise combines SCA, SBOM management, vulnerability scanning, and policy enforcement into one unified platform, making it easier for development and security teams to collaborate. Learn about the future of SBOMs and how the evolution is impact all things software supply chain—including security! Watch Now ### NIST SP 800-190 The National Institute of Standards and Technology (NIST) published Special Publication (SP) 800-190, or the Application Container Security Guide, in September 2017 to address security concerns associated with containerized technologies.  Clocking in at a total of 51 pages, the special publication outlines: common threats to containerized applications,  guidelines for enhancing container security, and  operational considerations.  To start you on your journey to NIST 800-190 compliance, we’ll summarize the key insights and action items from the special publication here, plus additional tips for achieving and maintaining compliance. What is NIST 800-190?: A Brief Overview NIST 800-190, also known as the Application Container Security Guide, provides security best practices for containerized applications, focusing on threats, risks, and mitigation strategies across the container ecosystem. The guide helps organizations implement secure containerization in DevSecOps workflows, ensuring compliance and reducing attack surfaces. It covers topics such as…  Container images Container registries Container runtimes Container orchestration Host environments The release of the special publication was prompted by the growing adoption of container technology and the security challenges that emerged alongside it. As organizations move toward DevSecOps and cloud native architectures, NIST 800-190 supports related security frameworks, including FedRAMP, DoD cATO, NIST 800-53, and CIS benchmarks. Watch the Container Security Compliance Webinar Get the Webinar On-Demand NIST 800-190 Compliance Checklist The following is a simplified checklist for tracking your organization’s compliance with the Application Container Security Guide. For automated compliance checks, software integrations, and more robust reporting, consider Anchore Enforce, a turnkey FedRAMP or DoD cATO compliance solution.  1. Image Security Vulnerability Management: Regularly scan container images for known vulnerabilities and apply necessary patches promptly. Configuration Management: Ensure images are configured securely, adhering to the principle of least privilege. Malware Protection: Implement tools to detect and prevent malware within images. Secret Management: Avoid embedding plaintext secrets (e.g., passwords, API keys) within images; utilize secure secret management. Source Authenticity: Use images from trusted sources and verify their integrity before deployment. 2. Registry Security Secure Communications: Use encrypted channels (e.g., TLS/SSL) for all communications with container registries. Access Controls: Enforce strict authentication and authorization mechanisms to control access to registries. Image Lifecycle Management: Regularly audit and remove outdated or unused images to minimize potential attack surfaces. 3. Orchestrator Security Administrative Access: Restrict administrative privileges to essential personnel and implement role-based access controls. Network Segmentation: Isolate network traffic between containers to prevent unauthorized inter-container communication. Workload Isolation: Separate workloads based on sensitivity levels to prevent data leakage and unauthorized access. Orchestrator Integrity: Regularly update and patch orchestrator components to protect against known vulnerabilities. 4. Container Security Runtime Protection: Monitor container activities to detect and prevent anomalous behaviors indicative of security breaches. Network Policies: Define and enforce network policies to control inbound and outbound traffic for each container. Resource Constraints: Set limits on container resources (CPU, memory) to prevent denial-of-service attacks. Immutable Infrastructure: Deploy containers as immutable instances; avoid in-place updates and redeploy from trusted images when changes are necessary. 5. Host Operating System Security Minimal OS: Utilize container-specific host operating systems to reduce the attack surface. Kernel Hardening: Apply security patches and harden the kernel to protect against exploits. Access Restrictions: Limit access to the host OS and monitor for unauthorized attempts. File System Protections: Ensure containers have only necessary access to the host file system, preventing unauthorized modifications. 6. Hardware Security Trusted Hardware: Deploy containers on hardware that supports security features like Trusted Platform Module (TPM) to establish a hardware root of trust. Firmware Updates: Regularly update firmware to protect against low-level vulnerabilities. Tips for Achieving and Maintaining Compliance While the guidelines provided in NIST 800-190 provide a framework for strengthening container security, implementing the best practices proactively, efficiently, and at scale is another story. Here are some expert-driven tips that aren't explicitly covered in the special publication but can significantly enhance compliance efforts: 1. Integrate SBOMs into DevSecOps pipelines NIST 800-190 compliance requires organizations to track and manage all software components in their supply chain. Integrating SBOM management tools into the DevSecOps pipeline ensures compliance from development to deployment, allowing organizations to identify and address risks early—before bad actors reach production.  SBOM-powered solutions like Anchore Enterprise streamline this process by automating SBOM generation at every stage, from source code repositories and CI/CD pipelines to container registries and runtime environments, reducing the manual burden on developers and security teams. 2. Automate Compliance with Policy-as-Code One of the most effective ways to maintain compliance in a DevSecOps environment is by implementing policy-as-code to define and enforce compliance policies at the CI/CD pipeline level. Ensure real-time validation of container images, network configurations, and access controls before deployment, and regularly update policies to align with evolving security standards and organizational requirements. 3. Shift Compliance Left Without Slowing Down Development Traditional compliance frameworks often rely on security audits at the end of the software development lifecycle, leading to costly fixes and deployment delays. Instead, compliance should be shifted left, integrating security early in the development process. This means incorporating automated compliance checks into CI/CD pipelines so developers get instant feedback on vulnerabilities, misconfigurations, and policy violations. Tools like Anchore Enterprise use vulnerability scanning and policy compliance packs to enable security teams to enforce compliance without becoming a bottleneck. 4. Prioritize Highest-Impact Compliance Controls First Trying to implement every security control at once can overwhelm teams. Instead of aiming for perfect compliance from day one, focus on high-impact controls that mitigate the most common attack vectors.  First, focus on securing CI/CD pipelines and container images (e.g., implementing signed images and scanning for vulnerabilities). Next, lock down sensitive secrets and IAM permissions before enforcing runtime security (e.g., monitoring container behavior for anomalies). By taking a phased approach, organizations can maintain compliance without disrupting operations. 5. Make Compliance Visible & Easy to Track Security and compliance often fail because they are invisible—if teams can’t see compliance issues, they won’t fix them. The best way to maintain compliance is to make security data highly visible and accessible. This can be done by: Creating dashboards that track compliance status across environments. Displaying security feedback directly in CI/CD pipelines, so developers see compliance violations before merging code. Providing clear remediation steps when compliance issues arise, so teams know exactly what to fix instead of wasting time searching for answers. Tools like Anchore Enterprise make it easy to create detailed, custom reports for security teams to assess impact and trends to help direct remediation efforts. Plus, send auditors evidence of checks being performed and pass/fail status against formal controls. 6. Reduce Alert Fatigue by Only Surfacing Actionable Compliance Issues One of the biggest challenges in compliance is alert fatigue—when security teams are bombarded with thousands of vulnerability alerts, many of which are low-risk or irrelevant. To keep compliance efficient, organizations should: Tune vulnerability scanners to prioritize exploitable vulnerabilities, rather than flagging every minor issue. Use risk-based remediation, focusing on security fixes that actually impact compliance instead of patching everything blindly. Automate false positive filtering so teams don’t waste time on non-issues. This allows compliance to be maintained without drowning security teams in unnecessary work. How does NIST 800-190 differ from other security frameworks?  NIST 800-190 vs. NIST 800-53 These two special publications differ in both scope and purpose, with SP 800-53 being much broader in nature. Here’s the difference:  NIST 800-190 Details container-specific implementations of the more general NIST 800-53 controls; specifically mitigating threats to container images, registries, orchestrators and runtime environments. Used as container security best practices guidance by any organization, cloud service provider (CSP) or agency using containers. NIST 800-53 Comprehensive security control catalog for all high-level security topics for information technology systems. Security controls are general and can be applied to development and production environments that do not utilize containers. Used by federal agencies, CSPs and software providers that need to meet federal compliance requirements, such as FedRAMP or FISMA. NIST 800-190 vs. NIST CSF Similarly, NIST 800-190 is focused on securing containerized applications, while NIST CSF (Cyber Security Framework) provides a broad, adaptable cybersecurity framework that organizations can customize based on their risk management needs. NIST CSF A flexible cybersecurity framework designed to help organizations assess and improve their overall security posture, regardless of industry or sector. Used by both public and private sector organizations to manage and reduce cybersecurity risks, with a focus on risk-based decision-making rather than specific technical implementations. Streamlining NIST 800-190 Compliance with Anchore Staying compliant with NIST 800-190 can be a challenge, but Anchore Enterprise makes it seamless by automating security checks throughout the container lifecycle. From SBOM analysis to policy enforcement and continuous monitoring, Anchore helps teams catch vulnerabilities early and enforce compliance without slowing development.With Anchore, NIST 800-190 compliance becomes efficient and repeatable—no more manual audits or last-minute fixes. Start a free trial today and take the hassle out of container security. ### FedRAMP ConMon Understanding Continuous Monitoring Beyond FedRAMP Continuous monitoring, or ConMon, isn't just a box to check on your way to achieving and maintaining FedRAMP compliance. It’s a mindset and process shift that can benefit any organization looking to take a more proactive approach to cybersecurity. Traditional security measures often relied on periodic reviews, leaving gaps between assessments. Often this meant vulnerabilities were addressed only after escalating into significant threats, resulting in higher risks, damages, and costs. ConMon, on the other hand, involves real-time observation and assessment of security postures, eliminating these gaps and enabling organizations to reduce response times and enhance threat detection.  Similar to DevSecOps and shifting security left, ConMon is as much about fostering a culture of vigilance. Teams become adept at recognizing subtle indicators of compromise, allowing them to preemptively address potential breaches. This heightened awareness not only strengthens internal defenses but also builds confidence among stakeholders and clients. Ultimately, continuous monitoring stands as a pillar of modern cybersecurity, essential for any organization aiming to safeguard its digital assets effectively. Watch Now Continuous Monitoring as part of the FedRAMP Compliance Lifecycle FedRAMP compliance demands a higher degree of vigilance than standard continuous monitoring practices, ensuring that cloud service providers (CSPs) maintain the security posture required by FedRAMP even after they have been granted an Authority to Operate (ATO).  It also requires continuous documentation and evidence of compliance for ongoing proof of adherence to specific federal guidelines. This focus on documentation ensures transparency and accountability throughout the security lifecycle. Here’s how continuous monitoring fits into the overall FedRAMP compliance lifecycle: 1. Initial Authorization (Pre-ConMon) Before a cloud service can achieve FedRAMP compliance, it must undergo a rigorous security assessment by an independent third-party assessment organization (3PAO). This assessment evaluates the system’s implementation of the required security controls. After the security assessment, the cloud service provider (CSP) is granted an ATO by either a federal agency or the FedRAMP Joint Authorization Board (JAB), signifying that the system is compliant with FedRAMP standards. 2. Transition from ATO to Continuous Monitoring Once the CSP receives the ATO, continuous monitoring becomes an ongoing, mandatory requirement to ensure the system remains secure over time and that its security posture is not degraded. Continuous monitoring ensures that any emerging security vulnerabilities, changes in the system, or threats to the cloud environment are identified and addressed in real-time. It prevents compliance from becoming a "one-time" activity and enables a dynamic, ongoing assessment of security risks. 3. ConMon Reporting to FedRAMP CSPs must submit monthly continuous monitoring reports to the federal agency or JAB. These reports include the results of vulnerability scans, security incidents, and system changes. The goal is to provide transparency into the ongoing security status of the system. In addition to monthly reports, CSPs are required to undergo annual assessments of their full set of security controls to verify ongoing compliance with FedRAMP standards. 4. Remediation and Suspension of ATO If continuous monitoring reveals significant risks or security vulnerabilities that are not promptly addressed, a cloud service’s ATO may be temporarily suspended or revoked. This can happen if a CSP fails to remediate issues identified in vulnerability scans, annual assessments, or fails to follow their continuous monitoring plan. Who Oversees FedRAMP Continuous Monitoring? The oversight of FedRAMP ConMon is managed by the Joint Authorization Board (JAB) and agency-specific Authorizing Officials (AO). These entities play a crucial role in ensuring compliance with federal standards and maintaining a strong security posture. The JAB, comprising representatives from major federal agencies, provides guidance and oversight throughout the ConMon process. By collaborating with AOs, the JAB ensures that organizations adhere to stringent security requirements, fostering a culture of compliance. Agency-specific AOs oversee individual cloud service providers (CSPs), ensuring they meet FedRAMP ConMon standards. These officials evaluate security performance, review documentation, and verify compliance with federal guidelines. By maintaining close oversight, AOs ensure CSPs uphold the highest standards of security. A Comprehensive Checklist for FedRAMP ConMon Compliance By adhering to this checklist, CSPs can systematically manage their continuous monitoring tasks and ensure they remain FedRAMP compliant. Upfront Implement continuous monitoring tools: Automate as much of the processes as possible to lighten the load on your team and reduce the risk of vulnerabilities slipping through the cracks. Popular tools include: Vulnerability Scanning and Management: Anchore Secure or other vulnerability scanning solution Endpoint Scanning and Protection: SentinelOne Singularity Endpoint, DataDog ASM (Application Security Management), Jamf Protect, Elastic Defend, etc. Security Event and Incident Management (SEIM): Datadog Cloud SIEM, Elastic Security, Splunk, Panther Cloud SIEM, RunReveal Security Data Platform, etc. Cryptographic Key Management: AWS Key Management Service, Azure Key Vault, GCP Key Management System, Hashicorp Vault, etc. FedRAMP Enforcement and POA&M Generation: Anchore Enforce or other cloud-native policy enforcement solution Develop a system for documentation: Work with your team to create a process for recording of all ConMon activities and security assessments. By setting a standard upfront, you ensure this information is always up-to-date and readily available for review by federal oversight entities. Educate your team: Promote security awareness and training among all staff members and encourage proactive reporting of potential security concerns. Monthly Vulnerability Scanning: Conduct vulnerability scans for operating systems, databases, and software containers. Remediate vulnerabilities according to severity. Looking to automate your FedRAMP container scanning? Anchore Enterprise can help.  POA&M Updates: Review the Plan of Action and Milestones (POA&M) to track the status of identified security weaknesses. Update with new vulnerabilities or security gaps discovered during scans or assessments. Log and Incident Monitoring: Continuously monitor system logs for anomalies, unauthorized access, and potential security incidents. Report any incidents to the appropriate federal agency or JAB within 24 hours of detection and provide updates on incident resolution. Configuration Management: Track and document any system configuration changes and conduct security impact analysis as needed.  Monthly ConMon Reporting: Submit vulnerability scan results, incident reports, and POA&M status updates to the federal agency or JAB. Quarterly Security Control Assessments: Assess a subset of security controls (related to access management, incident response, etc.) to ensure they remain effective.  Review Patch Management: Review the patch management process to ensure all critical patches have been applied within the required timeframes. Update Continuous Monitoring Plan: Review and update the continuous monitoring plan to reflect any changes in system architecture, configurations, or monitoring tools. Quarterly ConMon Reporting: Include summaries of security control assessments, any significant incidents, and updates on the POA&M. Annually  Full Security Control Assessment (Annual 3PAO Assessment): Engage a Third-Party Assessment Organization (3PAO) to conduct a comprehensive assessment of all security controls. Review the results and address any deficiencies identified. Review Continuous Monitoring Plan and POA&M: Perform a comprehensive review of the continuous monitoring plan and ensure it remains aligned with FedRAMP requirements. Ensure that all outstanding POA&M items from the year have been resolved or are on track for resolution. Annual ConMon Reporting: Submit the results of the annual security assessment and updates on overall system performance to the federal agency or JAB. Helpful Resources for FedRAMP ConMon Looking for more information to prepare for FedRAMP continuous monitoring? We’ve compiled some of our team’s go-to’s:  From FedRAMP FedRAMP Continuous Monitoring Performance Management Guide: Provides guidance on continuous monitoring (ConMon) and ongoing authorization in support of maintaining a security authorization that meets the FedRAMP ConMon requirements. FedRAMP ConMon Plan Template: Structured document that helps cloud service providers (CSPs) outline and implement their continuous monitoring strategy as required for FedRAMP compliance.  FedRAMP Security Controls Baseline: A detailed list of required security controls based on the National Institute of Standards and Technology (NIST) SP 800-53 standards. From Anchore FedRAMP Overview: Learn more about who can and should pursue FedRAMP ATO, what the authorization process looks like, and how long it all takes in our comprehensive guide.  FedRAMP Pre-Assessment Playbook for Containers: As your organization works toward ensuring full compliance with FedRAMP vulnerability scanning requirements for containers, this step-by-step playbook provides guidance on how to use Anchore to meet FedRAMP requirements   Webinar: How to Meet the 6 FedRAMP Container Scanning Requirements Learn how Anchore helped Cisco achieve FedRAMP compliance > ### Container Security In today’s cloud-native development landscape, the use of containers has revolutionized how applications are built, deployed, and managed. However, this convenience doesn’t come without its unique security challenges. Organizations must safeguard their containerized environments to prevent vulnerabilities, ensure compliance, and maintain operational integrity. This guide provides an in-depth look at container security—what it is, why it matters, common risks, and best practices. From foundational concepts to actionable strategies, this guide is designed to support your container security goals, whether you're starting with containerization or refining your approach. What is Container Security? Container security refers to the set of tools, policies, and practices used to protect containerized applications from threats throughout their lifecycle. It encompasses everything from the creation of a container image to its deployment and operation in production environments. Containers, by their very nature, are isolated from one another and their host systems. While this isolation improves security compared to traditional virtual machines, it’s not foolproof. Vulnerabilities in the container image, misconfigurations in orchestration tools, and gaps in runtime security can expose organizations to significant risks. Container Security: A Cornerstone of Modern Cybersecurity Container security isn’t just a concern for security teams—it’s essential for software engineers and DevSecOps teams as well. That’s because as applications become more distributed and rely on microservices, the potential attack surface grows. A single compromised container can serve as an entry point for attackers to exploit an entire system. Additionally, compliance requirements like NIST standards often mandate robust container security measures. Organizations failing to secure their containerized environments risk fines, reputational damage, and operational disruptions. Container Security Standards NIST SP 800-190 When most cybersecurity or DevOps professionals think about container security, they typically think about one specific standard: NIST SP 800-190, or the Application Container Security Guide. This comprehensive guide from the National Institute of Standards and Technology (NIST) outlines how to manage container security risks effectively, covering topics such as types of threats, how to address security at each stage of the container lifecycle, and recommendations for organizations.  Below are a few of NIST 800-190’s security container security best practices:  Maintain a private registry for container images Regularly update and patch container images to address vulnerabilities Secure Kubernetes clusters or other orchestration tools with strong authentication mechanisms and network segmentation Limit container privileges to reduce the impact of potential exploits Enforce network policies to restrict container communication to only what is necessary Use firewalls to protect containerized workloads from malicious payloads Monitor and log container activities for forensic analysis and compliance audits Automate compliance checks to streamline processes and meet regulatory requirements Learn more about cybersecurity compliance or explore NIST compliance automation solutions.  Fast Fact: Automating compliance with standards like NIST SP 800-190 can save organizations hundreds of hours annually. Anchore Enterprise simplifies this process with tools designed for seamless integration. FedRAMP The Federal Risk and Authorization Management Program (FedRAMP) provides specific guidance on container vulnerability scanning to ensure that cloud service providers (CSPs) maintain robust security postures when utilizing container technologies. Key aspects of FedRAMP's container security requirements include: Vulnerability Scanning for Container Images: CSPs must ensure that all components of container images are scanned for vulnerabilities before deployment to production. This scanning should be integrated into the CI/CD pipeline, with scans conducted at least every 30 days. Only containers from images scanned within this 30-day window are permitted in the production environment. Hardened Images: FedRAMP mandates the use of hardened container images. CSPs should utilize images that adhere to benchmarks listed in the National Checklist Program, as defined by the National Institute of Standards and Technology (NIST) Special Publication 800-70. If no benchmark is available, CSPs must create and maintain a validated benchmark for hardening purposes. Automated Build, Test, and Orchestration Pipeline: CSPs are required to implement automated tools for building, testing, and deploying containers to production. These tools must be validated to meet FedRAMP requirements, ensuring that non-compliant containers are restricted from deployment. Security Sensors: Deploying independent security sensors alongside production-deployed containers is recommended to continuously inventory and assess the security posture. These sensors should operate with sufficient privileges to avoid visibility gaps and false negatives. Registry Monitoring: Continuous monitoring of the container registry is essential to ensure that only images scanned within the 30-day vulnerability scanning window are deployed to production. This process may involve setting up alarms to inform operators or implementing control mechanisms to prevent unauthorized deployments. Asset Management and Inventory Reporting: Each class of image corresponding to production-deployed containers must have a unique asset identifier documented in the FedRAMP Integrated Inventory Workbook Template. CSPs should track these containers using an automated mechanism validated to meet baseline control requirements. Learn more about FedRAMP requirements or explore FedRAMP vulnerability scanning tools.  Other Standards Additional frameworks that outline guidelines and standards for container security include: ISO/IEC 27001: An internationally recognized standard for managing information security, this framework outlines a systematic approach to securing sensitive information, ensuring its confidentiality, integrity, and availability through implementation of a robust Information Security Management System (ISMS). CIS Benchmarks: For teams using Kubernetes or Docker, the Center for Internet Security’s benchmark provides detailed guidance on securing specific container technologies. PCI DSS and HIPAA: Industries like finance and healthcare require strict compliance with standards that extend to containerized environments. Automate FedRAMP and NIST compliance with Anchore Enterprise. Get instant access with a 15-day free trial. START FREE TRIAL Top Container Security Risks in 2025 In addition to adopting container security standards such as those listed above, understanding some of the most common sources of container vulnerabilities helps teams proactively identify threats and mitigate risks, maintain operational continuity, and build a strong culture around a security-first mindset.  Vulnerable container images: Public registries often host images with known vulnerabilities. Using unverified or outdated images increases the attack surface. Misconfigured orchestration tools: Misconfigured Kubernetes clusters or Docker files can expose containers to unauthorized access or privilege escalation. Inadequate runtime security: Threats don’t stop after deployment. Without runtime monitoring, malicious activity like crypto-jacking or data exfiltration can go unnoticed. Insufficient access control: Granting excessive permissions to users or systems can lead to unauthorized modifications or leaks. Outdated images and dependencies: Neglected updates in container images can lead to the use of outdated software with known vulnerabilities. Quick Tip: Learn how to secure your containers against the top container security vulnerabilities in our Docker Security Best Practices Guide. Effective Container Security Management: Tools & Best Practices Managing container security effectively requires a combination of cultural shifts, processes, and the right tools. Best Practices to Strengthen Container Security In addition to the standards outlined above by NIST 800-190 and FedRAMP, our team at Anchore recommends a few more overarching best practices for maintaining a strong security posture in your containerized applications:  Integrate container security directly into the DevSecOps workflow, addressing security early in the development cycle. Shift security left to reduce the risk of costly breaches or disruptions in production. By embedding security into DevSecOps pipelines, teams can maintain agility while fostering a culture of proactive risk management. Prioritize training for developers, DevSecOps, and security teams to improve awareness of container security practices and empower them to build and maintain secure applications. This awareness fosters a proactive security culture, reduces human error, and enhances the organization's overall security posture. Use tools that provide real-time visibility into container activities, helping detect and respond to threats promptly. Continuous monitoring ensures that anomalies, such as unauthorized access or resource misuse, are identified and addressed promptly, maintaining the security and reliability of containerized applications. Get the complete guide Types of Container Security Tools Maintaining a strong security posture and meeting compliance standards like NIST 800-190 and FedRAMP can be resource-intensive, often requiring detailed audits, configuration management, and constant monitoring. Luckily, there are a variety of tools available to help automate container security and compliance and protect your organization from vulnerabilities, breaches, and other security risks. Vulnerability Scanners What they do: Detect security vulnerabilities in software dependencies and infrastructure. Example: Anchore’s container vulnerability scanner integrates with CI/CD pipelines and provides automated policy enforcement for container images. Runtime Security Platforms What they do: Monitor live containers for abnormal behaviors. They protect against malware, detect and prevent intrusions, and provide real-time monitoring and response capabilities. Example: Jamf, Elastic, SentinelOne, etc. Secrets Scanning Tools What they do: Automatically detect and alert on exposed secrets in code repositories, preventing accidental leakage of sensitive information. Examples: Anchore Secure or other container security platforms Compliance Management Tools What they do: Help organizations meet and maintain compliance standards.  Examples: Anchore Enforce or other compliance management platforms Role-based Access Control Tools What they do: Provide granular permissions to minimize exposure. Examples: Permify, Styra Further Reading Securing containerized environments is no longer optional—it’s a fundamental part of operating in the cloud-native era. By understanding container security risks, implementing best practices, and leveraging the right tools, organizations can protect their applications, meet compliance requirements, and reduce overall risk. Learn more about container security with the help of Anchore’s team of cybersecurity experts:  Whitepapers Fundamentals of Container Security Best Practices for Container Security A Complete Guide to Hardening Containers with STIG Webinars How to Secure Your Kubernetes Software Supply Chain at Scale NIST 800-53: What You Need to Know 5 Insider Tips for Federal Software Compliance Case Studies Anchore + DreamFactory: 75% time savings through automated vulnerability management Anchore + Infoblox: 60% reduction in hours spent on compliance tasks Anchore + Iron Bank: Reduced false positives, enforced DoD container hardening requirements & more ### SBOM Automation The Role of SBOMs in Vulnerability Management: Securing the Software Supply Chain Software Bill of Materials (SBOMs) are essential tools for securing the software supply chain. Think of them as ingredient lists for your software, giving you a clear view of all the components and dependencies baked into your applications. They provide a detailed inventory of all software components and dependencies, making it easier to track vulnerabilities, achieve and maintain compliance, and minimize risk.  In an era where supply chain attacks are on the rise, SBOMs play a critical role in identifying and mitigating threats originating from third-party components, open-source libraries, or even compromised build tools. By enabling transparency and accountability across the software lifecycle, SBOMs empower organizations to act quickly and decisively to secure their supply chain.  The Benefits of SBOM Automation Manual SBOM management is a frustrating and error prone strategy that breaks down at scale. Automating the creation, scanning, and analysis of SBOMs is not just about efficiency; it’s about keeping your software supply chain secure and protecting the time of your DevSecOps team from monotonous, low-value work. Enhanced speed and accuracy: Automating repetitive tasks doesn’t just save time—it helps to reduce manual errors.  Improved security posture: Automatic generation and analysis creates continuous visibility into software components. This inverts your security posture from reactive to proactive. By surfacing vulnerabilities and enforcing compliance, organizations preempt threats before they become incidents. Scalability: Manage SBOMs across hundreds or thousands of software artifacts seamlessly and maintain consistent standards across diverse projects. Centralized visibility and management: Enterprise SBOM automation tools typically include dashboards and analysis tools that allow teams to extract security, compliance and risk insights across an organization's entire software portfolio. Automating SBOM Generation Generating SBOMs is easy (and cost-efficient) with the help of free, open source tools like Syft. These developer tools compile essential details such as component names, versions, and licensing information. This is ideal for startups, small teams, or companies with limited budgets that are looking for one-off SBOM generation during software development, compliance audits or an evaluation of different SBOM automation tools. But as organizations manage more and more software artifacts and increasingly complex build pipelines, processes that rely on engineers manually executing developer tools on each artifact—even simple and easy to use tools—do not scale for enterprise software factories.   Integrating SBOM generation into your CI/CD pipeline ensures that every build automatically produces an SBOM. Here’s where SBOM generation fits best: Build time: As part of the initial build process, providing a clear inventory of components as they are introduced. After containerization: Ensuring SBOMs are generated for containerized applications for both 1st- and 3rd-party applications held in artifact registries. During deployment: Validating components before deploying to production. This layered automation ensures your organization always has a detailed and up-to-date inventory of your software portfolio; this sets the stage for secure and efficient software delivery. Automating SBOM Analysis & Scanning Generating SBOMs is just the start; to truly manage risks, you need to continuously analyze SBOM. Automating this process makes it possible to identify security vulnerabilities, license conflicts, compliance violations and other risks before they snowball into bigger issues. What is SBOM Analysis and Vulnerability Scanning? SBOM analysis and vulnerability scanning involves the evaluation of an SBOM for potential security risks. By analyzing the SBOM, organizations can cross-reference the listed components against vulnerability databases to identify known security vulnerabilities, outdated versions or licensing issues that could be exploited by threat actors.  Vulnerability scanning tools automate this process, flagging components with reported vulnerabilities so organizations can prioritize remediation efforts. This practice is critical in modern DevSecOps workflows. It helps ensure software security, compliance, and resilience against cyber threats throughout the development lifecycle. How to Automatically Scan and Analyze SBOMs for Vulnerabilities Managing SBOMs at scale requires more than just generating them—you need to continuously scan and analyze their contents for vulnerabilities and risks. Tools like Anchore Secure streamline this process; providing automation, actionable insights, and centralized SBOM management to keep your software supply chain secure. Here's the short version of how you can integrate SBOM scanning and analysis into your workflows (complete guide here): Automate scanning in your CI/CD pipeline: To ensure every build is secure, set up automated SBOM scanning in your build and delivery pipeline. Integrate scanning at key stages such as post-build and pre-release, and connect your CI/CD tools (e.g., Jenkins, GitHub Actions, etc.) to Anchore Secure using pre-built plugins or APIs. Define rules to automatically trigger scans based on specific events, like a code merge or container build. Analyze results and monitor risks: Anchore Secure doesn’t just scan for vulnerabilities—it helps you understand and act on the results. View your scan results in a centralized dashboard that organizes issues by severity, package, or project. Focus on fixing high-risk issues first, while planning later remediation for medium- and low-risk items. Next create enforcement policies to block deployments with critical vulnerabilities or specific compliance violations. Automatically alert your team when a policy is violated, ensuring timely action. Schedule regular scans: SBOMs need ongoing attention. Vulnerabilities can emerge after software is deployed due to new CVEs being published or changes in dependencies. Configure Anchore Secure to perform daily, weekly, or event-based scans on critical projects. Anchore’s vulnerability database updates continuously, ensuring new threats are flagged as soon as they’re discovered. Track trends over time: Monitor trends across multiple projects to identify recurring risks or dependencies that frequently introduce vulnerabilities. Tools for SBOM automation Free and open source tools to get started on your SBOM journey: Syft (by Anchore): Lightweight and fast. Generates SBOMs in SPDX or CycloneDX format. CycloneDX Generator cdxgen (by OWASP): Built for creating CycloneDX-compliant SBOMs. SPDX SBOM Generator: Built for creating SPDX-compliant SBOMs. Tern (by VMware): Python library that generates SBOMs for container images and Dockerfiles. End-to-end SBOM automation to scale your SBOM initiatives Anchore Secure combines SBOM generation, vulnerability scanning, and security analysis into a single automated platform for complete software supply chain security. Anchore continually updates the vulnerability status of your software artifacts in response to new security advisories. By storing the SBOMs generated from your pipeline, Anchore can send instantaneous alerts when a new vulnerability is announced without needing to rescan the original software.  Next Steps Automating SBOMs—from creation to scanning and analysis—gives you the power to secure your software supply chain without adding complexity. Tools like Anchore Enterprise let you stay ahead of vulnerabilities, keep your team efficient, and maintain compliance with ease. Ready to take the next step? Dive into SBOM automation today and see the difference for yourself. Save your developers time with Anchore Enterprise. Get instant access with a 15-day free trial. START FREE TRIAL ### Events ### Enforce ### Secure ### FedRAMP & FISMA Compliance: Key Differences Explained FedRAMP… FISMA… CISA… NIST… government compliance is an alphabet soup of acronyms. Keeping them straight is a job in and of itself. It doesn't help that compliance standards like FedRAMP vs FISMA are both distinct but with overlap that blurs the lines. If you're a cloud service provider (think: SaaS or cloud infrastructure provider) then this article will help you sort through fog and come away with a clear idea of what applies to you and why. What is FedRAMP? Federal Risk and Authorization Management Program (FedRAMP) is a compliance standard and certification program. It enables federal agencies to take advantage of the latest SaaS and cloud infrastructure offerings by creating a standard security and compliance evaluation process. Established in 2011, FedRAMP is the "verify" component of the security adage "trust but verify" that enables Federal agencies to access the productivity gains of modern software services. To get the full low-down on FedRAMP, see our complete guide. What is FISMA? The Federal Information Security Management Act (FISMA) is a United States federal law. It was designed to address the risk that grew out of maturation of the internet from a curiosity to a viable market for commerce (post dot-com boom/bust) and the growth of interest in cybercrime to divert some of the new commercial gains into pockets of criminals. It was, also, a response to the fact that the most current legislation that provided guidance to federal agencies was the Computer Security Act of 1987 which was 15 years outdated by the time FISMA superseded it. FedRAMP vs FISMA: A Comparison Scope & Applications FedRAMP applies to cloud service providers (CSPs) that offer SaaS or cloud infrastructure products and services to federal agencies. If your company provides cloud solutions, you’ll need FedRAMP compliance to do business with the US government. FISMA applies to federal agencies and any external companies providing information systems or services to these agencies. This encompasses a broader range of IT systems beyond just cloud services. Model FedRAMP is founded on a “do once, use many times” ethos where cloud services can be authorized once and re-used across multiple agencies. A massive efficiency gain versus the previous method of being certified by each individual agency.  FISMA uses an agency-specific approach and prioritizes flexibility. It requires each federal agency to assess and authorize its own information systems. Agencies are responsible for implementing security controls, conducting risk assessments, and granting Authorization to Operate (ATO) for their systems. Goals FedRAMP is a specific framework for achieving secure systems in cloud environments. It aims to ensure CSPs meet the necessary protection levels for federal data while also accelerating the adoption of secure cloud services. FISMA is a general framework to guide agencies when developing their own security and compliance frameworks. FedRAMP is an example of a specific framework that meets the broad mandates of FISMA. Governing Bodies FedRAMP is managed by the Joint Authorization Board (JAB), which includes representatives from the Department of Defense (DoD), Department of Homeland Security (DHS), and the General Services Administration (GSA). FISMA is overseen by the Office of Management and Budget (OMB), with implementation guidelines published by the National Institute of Standards and Technology (NIST). Process FedRAMP involves a rigorous process of security assessment, authorization, and continuous monitoring. It begins with a readiness assessment, followed by an evaluation by an accredited third-party assessment organization (3PAO). FISMA requires agencies to achieve a number of high-level information security goals, such as, inventory systems, categorize information, conduct risk assessments, implement security controls, and continuously monitor these controls. It defers specifics to NIST which has published documents like the Risk Management Framework (RMF), NIST 800-37 and the Control Catalog, NIST 800-53. These reference documents were then incorporated into FedRAMP. Helpful Tools Tools that support automated compliance and continuous monitoring for both frameworks: Anchore Secure: Vulnerability scanning tools Anchore Enforce: Automated NIST & SSDF compliance solutions Governance, risk and compliance (GRC) platforms Security information and event management (SIEM) systems FedRAMP authorization and continuous monitoring tools include… Anchore Enforce: Automated FedRAMP compliance solutions Automation and orchestration tools Cloud security posture management (CSPM) FISMA doesn't have any purpose-built tooling because the law is purposefully general and requires that federal agencies create their own frameworks that implement the general mandates. Where FedRAMP & FISMA Overlap Goals: Both FISMA and FedRAMP are designed to protect the security and integrity of federal information systems. They aim to ensure that federal agencies and their contractors maintain adequate information security controls to protect sensitive data. Framework: Both programs utilize NIST to define specific security and compliance controls. The standards that NIST produced for both FISMA and FedRAMP are the RMF, NIST 800-37 and the Control Catalog, NIST 800-53. They outline a standardized approach to risk management, which includes categorizing IT systems, selecting and implementing security controls, and continuously monitoring those controls. Continuous monitoring: Both FISMA and FedRAMP emphasize the importance of continuous monitoring of IT systems. This involves regularly assessing the effectiveness of security controls and making adjustments as needed to address emerging threats and vulnerabilities. Choosing Between FedRAMP and FISMA This is a bit of a false choice. You don't choose between FedRAMP vs FISMA since they apply to different types of organizations. Federal agencies have to be compliant with FISMA and are required to purchase software and services from companies that are FedRAMP-compliant. CSPs on the other hand have to choose between meeting FedRAMP compliance and being able to sell to agencies or not. FedRAMP is a specific framework that meets FISMA compliance, CSPs inherit FISMA compliance through FedRAMP. Next Steps FedRAMP vs FISMA are closely related topics but with enough overlap that distinguishing between the two can be difficult at times. This article is meant to help demystify the sometimes blurry distinction. If you're ready to move beyond this high-level overview and dips your toes into the more technical aspects of FedRAMP compliance, we would recommend our: FedRAMP Pre-Assessment Strategy Playbook for Containers and;  FedRAMP Requirements Checklist for Container Vulnerability Scanning Learn about best practices for achieving FedRAMP and SSDF compliance. Watch Now ### About Us ### Join the Anchore Community on Discourse ### Automate container vulnerability scanning "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." Read Case Study Find and fix vulnerabilities in your containers Anchore Enterprise is a comprehensive solution for organizations with DevSecOps or compliance programs for software delivered in containers. It scans container images, generates an SBOM, identifies vulnerabilities and other security problems, and enables you to prioritize and remediate issues. Automate container vulnerability scanning Automate vulnerability scanning and monitoring for containerized software. Perform scans in CI/CD pipelines, registries, and Kubernetes platforms. Identify malware, secrets, and other security risks. Integrate with DevOps tools 100% API coverage and fully-documented APIs enable developers to work seamlessly in the tools they already use. Automate scanning in source code repos, CI/CD pipelines, or container registries through native integrations. Streamline remediation of issues with notifications through GitHub, JIRA, Slack, and more. See all integrations. SBOM Integrations Get an SBOM with a list of components for each container image and scan. Track changes over time to identify new or updated components. Based on your SBOM, get notified of new vulnerabilities. Learn more about SBOM management with Anchore. . Fewer false positives Optimize development velocity with an unparalleled signal-to-noise ratio. Get fewer false positives with vulnerability results that are pinpointed to a specific distro. Use flexible policies to prioritize based on severity or availability of a fix. Provide “corrections” and “hints” that improve results going forward. Add vulnerabilities to allowlists to prevent ongoing alerts. Faster, easier remediation Fix vulnerabilities more quickly with Anchore Enterprise’s remediation recommendations. Specify when issues must be fixed with time-based allowlists. Reduce manual work with workflows connected to your issue tracker or Slack. ### NIST & SSDF Compliance Satisfy compliance for NIST and SSDF attestation Companies that sell software to governments or regulated industries need robust software security programs. Software companies will also soon be required to attest to the US government that they follow secure software development practices. Anchore Enterprise provides NIST compliance tools to automate various standards and controls, including NIST 800-171, NIST 800-53, NIST 800-190, and NIST 800-218 Secure Software Development Framework. This includes: Runtime Continuous Monitoring Integrate Anchore Enterprise into your runtime environment to detect NIST & SSDF attestation compliance violations against your production clusters. Support with EKS, ECS, GKE, AKS, OpenShift, and Rancher. Reporting Use Anchore Enterprise's automated reports to generate documents on your NIST & SSDF attestation compliance status for your 3PAO. Integration with major platforms Integrate Anchore Enterprise with common DevOps platforms such as GitLab, GitHub, or Jenkins to enable shift-left security and compliance checks in CI/CD. SSDF Attestation Form Download and follow the Anchore "SSDF Attestation Form Guide and Evidence" document to guide your organization through the SSDF Attestation process. Visit Anchore Federal Learning Center: What is NIST 800-53 NIST 800-53, the “Control Catalog”, is a landmark federal compliance standard. In this webinar we distill the most important aspects of the standard. Join Anchore's VP of Security to learn about the five critical points to know about achieving compliance. Watch on-demand Prepare for SSDF attestation The US government will require SSDF attestation. Anchore provides a downloadable document that serves as an evidence attachment for the SSDF Attestation Form. Learn More Download Vulnerability scanning Automate vulnerability monitoring and scanning for containerized software. Perform scans in CI/CD pipelines, registries, and Kubernetes platforms. Identify malware, secrets, and other security risks. Learn More Continuous monitoring Automate continuous monitoring (ConMon) of production environments. Automatically inventory container images running in Kubernetes, identify vulnerabilities, analyze NIST controls, and alert on violations. Track software provenance with SBOMs Discover software components and generate a software bill of materials (SBOM). Ingest SBOMs from 3rd parties. Store and manage SBOMs for an audit trail. Generate an application SBOM to share with customers. This webinar will explain what SSDF is and why it's more of a journey than a simple checking of the box. Get a real-world perspective on secure software development. An understanding of what actual organizations are doing right now with SSDF and how to start your own journey towards SSDF compliance. Watch On-Demand ### FedRAMP Compliance Satisfy FedRAMP vulnerability scanning requirements Companies that sell cloud-based software to the US government must meet FedRAMP requirements, including for vulnerability scanning. When software is deployed via containers, organizations must meet additional FedRamp vulnerability scanning requirements for containers. Anchore Enterprise provides out-of-the-box capabilities to help meet FedRAMP requirements: Vulnerability scanning with the latest vulnerability feeds Anchore Enterprise FedRAMP Policy Pack to validate controls  STIG checks to validate hardened images Registry monitoring for automatic image scanning Central storage of Software Bills of Materials (SBOMs) to provide asset management and inventory reporting Monthly reporting of vulnerabilities for FedRAMP ConMon Visit Anchore Federal 5 Insider Tips for Federal Software Compliance In this webinar we will draw from our experience and learnings from the Iron Bank approach to improve software visibility and supply chain security. Learn common security checks to help comply with any standard, ins and outs of SBOM creation and more. Watch on demand Vulnerability scanning for container images Automate vulnerability scans in CI/CD pipelines, registries, and Kubernetes platforms to meet the FedRAMP 30-day scanning window. Harden container images by identifying malware, secrets, and security risks in addition to vulnerabilities. Performing STIG checks for container images. Automate FedRAMP and NIST controls Speed compliance with Anchore’s out-of-the-box policy packs for FedRAMP and NIST controls. Enforce FedRAMP Rev 4 and automate checks of containers and images from build to deployment. Pinpoint the exact control ID and container image for any failures. Demonstrate compliance with controls for NIST 800-53 and 800-190 and from the Secure Software Development Framework as codified in NIST 800-218. Manage vulnerability remediation Add non-compliant findings to an allowlist with specified FedRAMP time limits. Set alerts to ensure vulnerabilities are remediated within required timelines. Evaluate exceptions and create a Plan of Action and Milestones (POAM) for remediation. Registry monitoring Automate continuous scanning of all registry images. Leverage Anchore’s admission controller to prevent unscanned or insecure images from being deployed in production. Continuous monitoring (ConMon) of production Rely on continuous monitoring (ConMon) to scan Kubernetes production environments. Automatically inventory container images running in production, identify vulnerabilities, analyze FedRAMP controls, and alert on violations. Easily create monthly reports on vulnerabilities. Streamline FedRAMP reporting Deliver pass/fail reports for FedRAMP controls to your auditor. Demonstrate the controls you have in place and show any exceptions you have identified. Automate monthly vulnerability reports. Visit Anchore Federal Request a Demo Download our checklist on how to meet FedRAMP vulnerability scanning requirements for containers today. You will learn about the new 30-day scanning window, determine the use of hardened base images and how to integrate scans across the container lifecycle. Download Now ### DoD Software Factory Secure your DoD software factory with Anchore Federal Anchore Federal is used across the US Department of Defense (DoD) to secure software factories that speed up development to aid warfighters. With Anchore Federal programs meet DoD DevSecOps requirements, apply zero-trust principles for applications and ensure cyber readiness. Platform One and Black Pearl are using Anchore to harden containers for the Iron Bank. Anchore Federal is deployed in IL4 and IL6 environments and supports a continuous feed of new vulnerabilities even in an air-gapped or high side environment. Anchore aligns with the DoD DevSecOps Reference Design and offers: Container hardening (Anchore DISA policy pack) Container policy enforcement (Anchore Federal policy packs) Container image selection (Container Hardening Scanner) Artifact storage (Anchore image registry integration) Release decision-making (Anchore Kubernetes Admission Controller) Runtime policy monitoring (Anchore Kubernetes Automated Inventory) Anchore is listed in the DoD Container Hardening Guide and the Container Image Creation and Deployment Guide as a Container Hardening scanner. Visit Anchore Federal One of the key purposes of Anchore is the mitigation of insider threat within the DevSecOps lifecycle by detecting unapproved changes to Dockerfiles. Read our latest white paper "DevSecOps for a DoD Software Factory: 6 Best Practices for Container Images" that advises on best practices for setting new standards in security and efficiency for DoD software factories. Download Now Continuous vulnerability scanning Automate vulnerability scans at each step in the development lifecycle, including source code repos, CI/CD pipelines, container registries, and Kubernetes platforms. Identify vulnerabilities, malware, secrets, and security risks. Anchore Federal integrates with common DevOps platforms such as GitLab, GitHub, or Jenkins to enable a “shift left” security posture and runs on any Kubernetes, including government clouds, on-prem OpenShift or, Rancher. Automate DoD and NIST security checks Enforce DoD standards with automated policy checks. Leverage Anchore’s out-of-the-box policy packs for NIST, DoD, DISA, and FedRAMP to speed compliance. Enforce controls for NIST 800-53 and 800-190 out of the box. Demonstrate compliance with controls from the Secure Software Development Framework as codified in NIST 800-218. Uncover issues as the software is built and avoid last-minute surprises before your compliance audit. Remediate security findings easily Reduce the manual effort to process security findings and create POA&Ms. Create action plans for developers detailing necessary remediation steps and use time-based allowlists that align POA&Ms. Fix issues faster and smarter. Provide proof of your security posture Ensure the security of your software with pass/fail reports of NIST, DoD, DISA, and FedRAMP checks. Document software contents with application-level SBOMs. Track and report on changes in your security posture and SBOMs over time. Achieve continuous ATO (cATO) Fulfill the required capabilities of cATO more easily. Use automated security checks and policy enforcement to continuously monitor and assess security controls per the Risk Management Framework (RMF).   Generate, store, and monitor SBOMs throughout the development lifecycle to ensure the security of the software supply chain. Leverage a centralized SBOM database to instantly triage the impact of zero-day vulnerabilities. Align with the DoD DevSecOps Reference Design and DoD Container Hardening Guide. Visit Anchore Federal Request a Demo The Security Technical Implementation Guide (STIG) is a Department of Defense technical guidance standard that captures the cybersecurity requirements for a specific product. Achieving STIG compliance is complex and can be daunting. Download our in depth guide on best practices. Download Now ### How to Scan Containers for Vulnerabilities Generating a vulnerability scan for your containers as part of your DevSecOps process is an essential technique to help secure your software supply chain. Vulnerability scans are critical due to the growing prominence of supply chain attacks such as Solarwinds, maintainers intentionally adding malware like node-ipc, and critical vulnerabilities like Log4Shell.  Due to the high nature of supply chain attacks in 2021, President Biden issued an Executive Order on Improving the Nation’s Cybersecurity. It details guidelines to secure software for any federal departments, agencies and contractors that do business with the government. Among the recommendations outlined in the executive order, the requirement for automated tools to uncover vulnerabilities (i.e. container vulnerability scanners) have been clearly stated to ensure safety and regulations for software supply chain security used by the federal government. Fortunately, there are a number of open source tools that can create vulnerability scans, and generating your first one takes just a few easy steps. If you're looking for the TL;DR to get up and running quickly, watch the video below. For a more comprehensive treatment keep reading. Open Source Vulnerability Scanning Tools There are many open source vulnerability scanning tools available, so the first thing you’ll need to do is pick one to use. Vulnerability scanners are often specific to a particular ecosystem such as Python or Go. Some are capable of generating scans for a number of different ecosystems and environments. Some of the more popular vulnerability scanners are: Grype by Anchore OSV Scanner Clair Dependency-Track For this example we’ll focus on Grype, since it is easy to use in many different scenarios and supports a variety of ecosystems. Grype is an open source vulnerability scanner that can run on desktop, in CI systems, as a Docker container and scan a wide variety of ecosystems from Linux distributions to many types of build dependency specifications. Learn how to automate container vulnerability scanning in Harbor registry with Anchore Enterprise. A webinar with the experts from Anchore. Watch Now Step 1: Getting Grype The first thing to do is download Grype. There are a number of ways to do this: Using curl The recommended method to get Grype for macOS and Linux is by using curl: $ curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin Homebrew For macOS, you can install Syft using Homebrew: $ brew install grype Direct Download You can directly download Grype binaries for many platforms including Windows from the GitHub releases page. Docker There is also a Grype Docker image with every release: anchore/grype, which can be run like this: $ docker run -it --rm anchore/grype Validate the Grype Installation To confirm Grype was installed correctly, simply run: $ grype version You should see output similar to: Application:          grype Version:              0.65.2 Syft Version:         v0.87.1 BuildDate:            2023-08-17T19:39:41Z GitCommit:            brew GitDescription:       [not provided] Platform:             darwin/amd64 GoVersion:            go1.21.0 Compiler:             gc Supported DB Schema:  5 Note: Grype was version 0.65.2 at the time of this writing Step 2: Generating Your First Vulnerability Scan Once you have Grype installed, creating your first vulnerability scan is simple. Grype supports multiple sources when generating an vulnerability scan; choose from using an SBOM, scanning a local filesystem directly or a container image. The advantage of scanning an SBOM over a container image or local filesystem scan is the amount of time it takes to complete the task.  An SBOM is an artifact of a filesystem or container that stores metadata about its source and all of the individual components that were used to build the original source. Think of it as a nutritional label on a can of soup but for software. By scanning the ingredients label for vulnerabilities rather than re-processing the entire container, we can save an immense amount of computing power and enable the ability to scan the container more frequently as new vulnerabilities are discovered. Scanning an SBOM To generate a vulnerability scan for an already existing SBOM: $ grype sbom: Or you can pipe an SBOM file directly into Grype, here is an example with an open source SBOM generator called, Syft. If you've never used a tool to create an SBOM, be sure to check out our guide on how to generate an SBOM: $ syft :tag -o json | grype Scanning an Image To generate a vulnerability scan for a Docker or OCI image - even without a Docker daemon, simply run: $ grype By default, output includes only software that is included in the final layer of the container. To include software from all image layers in the manifest, regardless of its presence in the final image, use the --scope all-layers option: $ grype --scope all-layers Scanning a Filesystem To generate a vulnerability scan for the local filesystem, use the dir: and file: prefixes with either absolute or relative paths. For example to scan the current directory: $ grype dir:. Or a specific file: $ grype dir:path/to/dir Grype can generate a vulnerability scan from a variety of other sources, such as Podman, tar archives, or directly from an OCI registry even when Docker is not available. Check out the full list of sources. Generate an Example Vulnerability Scan For example, to scan an example image with known vulnerabilities, simply run:  $ grype docker.io/dnurmi/testrepo:jarjar You should see output similar to this:  ✔ Vulnerability DB [no update available] ✔ Parsed image sha256:0f12f881827fc3ca2c093c75966b5080a599 ✔ Cataloged packages [218 packages] ✔ Scanned for vulnerabilities [371 vulnerabilities] ├── 122 critical, 78 high, 141 medium, 30 low, 0 negligible └── 192 fixed NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY bcel 6.0-SNAPSHOT 6.6.0 java-archive GHSA-97xg-phpr-rg8q Critical busybox 1.34.1-r3 apk CVE-2022-48174 Critical busybox 1.34.1-r3 1.34.1-r5 apk CVE-2022-28391 High commons-beanutils 1.7.0 java-archive CVE-2019-10086 High commons-beanutils 1.7.0 java-archive CVE-2014-0114 High commons-collections 3.1 3.2.2 java-archive GHSA-fjq5-5j5f-mvxh Critical commons-collections 3.1 3.2.2 java-archive GHSA-6hgm-866r-3cjv High commons-io 2.4 2.7 java-archive GHSA-gwrp-pvrq-jmwv Medium commons-io 2.4 java-archive CVE-2021-29425 Medium dom4j 1.6.1 2.0.3 java-archive GHSA-hwj3-m3p6-hj38 Critical dom4j 1.6.1 2.0.3 java-archive GHSA-6pcc-3rfx-4gpm High fastjson 1.2.9 1.2.31 java-archive GHSA-xjrr-xv9m-4pw5 Critical fastjson 1.2.9 java-archive CVE-2022-25845 Critical fastjson 1.2.9 java-archive CVE-2017-18349 Critical fastjson 1.2.9 1.2.83 java-archive GHSA-pv7h-hx5h-mgfj High fat_jar 2.14.1 java-archive CVE-2021-45046 Critical fat_jar 2.14.1 java-archive CVE-2021-44228 Critical fat_jar 2.14.1 java-archive CVE-2021-45105 Medium fat_jar 2.14.1 java-archive CVE-2021-44832 Medium … Or, generate the same vulnerability scan by first creating an SBOM from the image and then piping the JSON output to Grype to do a vulnerability scan: $ syft -o json docker.io/dnurmi/testrepo:jarjar | grype The output should look identical to the output above. 3. Choosing Your Vulnerability Scan Format Depending on your use cases, it may be important to use a particular format for the vulnerability scans produced. The most common ones are JSON, Tabular and CycloneDX, all of which Grype supports. While Grype supports these different formats, they have slightly different goals and features. It may be important to pick CycloneDX for interoperability with other tools or as a standardized format to distribute to downstream consumers. Generating a Vulnerability Scan in Tabular Format If your use case requires a spot check vulnerability scan, the default tabular format is typically the quickest and easiest for an individual human reader. No special output designation is required, the example vulnerability scan above is the tabular format. Generating a Vulnerability Scan in CycloneDX Format If your use case requires a vulnerability scan in CycloneDX format, Grype has you covered. Grype supports CycloneDX XML (cyclonedx-xml) and JSON (cyclonedx-json). For CycloneDX JSON: $ grype docker.io/dnurmi/testrepo:jarjar -o cyclonedx And you should see a result resembling this: ✔ Vulnerability DB [no update available] ✔ Parsed image sha256:0f12f881827fc3ca2c093c75966b5080a599de31f110998d09b54658ddffcd15 ✔ Cataloged packages [218 packages] ✔ Scanned for vulnerabilities [371 vulnerabilities] ├── 122 critical, 78 high, 141 medium, 30 low, 0 negligible └── 192 fixed 2023-09-01T13:54:11-04:00 anchore grype 0.65.2 docker.io/dnurmi/testrepo jarjar com.sun.xml.fastinfoset FastInfoset 1.2.16 http://www.opensource.org/licenses/apache2.0.php, http://www.eclipse.org/org/documents/edl-v10.php cpe:2.3:a:oracle-corporation:FastInfoset:1.2.16:*:*:*:*:*:*:* pkg:maven/com.sun.xml.fastinfoset/FastInfoset@1.2.16 4eb6a0adad553bf759ffe86927df6f3b848c8bea java-cataloger java JavaMetadata java-archive cpe:2.3:a:oracle_corporation:FastInfoset:1.2.16:*:*:*:*:*:*:* cpe:2.3:a:FastInfoset:FastInfoset:1.2.16:*:*:*:*:*:*:* cpe:2.3:a:fastinfoset:FastInfoset:1.2.16:*:*:*:*:*:*:* cpe:2.3:a:sun:FastInfoset:1.2.16:*:*:*:*:*:*:* cpe:2.3:a:xml:FastInfoset:1.2.16:*:*:*:*:*:*:* sha256:14bb2fde19899f762ead275eb8d5ad5d5bdf2159bed99583934792a2947303e6 /checkmarx.hpi FastInfoset com.sun.xml.fastinfoset /checkmarx.hpi:WEB-INF/lib/FastInfoset-1.2.16.jar … … … There is a lot more data than the table allows, but a different set of data than native JSON because there simply is not a one-to-one mapping of properties between the two. Generating a Vulnerability Scan in Lossless JSON Format The last format we’ll talk about is Grype’s own JSON format. If there isn’t a need to provide an SBOM to other tools and you may be using Syft to generate the SBOM, the format with the highest fidelity is the Grype JSON format. Both tabular and CycloneDX lose some amount of information from the initial Grype data model whereas the JSON lossless format does not. Although Grype works great with SPDX and CycloneDX SBOMs, there could be a situation where data was lost converting to one of these formats and Grype matching uses some of that extra data, so using the Syft JSON might make the most sense. To use the Syft JSON format, use the -o json argument. Create Your Own Format! None of the previous formats fit your use-case? You can even create your own custom format. Grype export formats can be customized utilizing the Go templating syntax. If you’re interested to learn more, our team wrote an entire blog post about how to create your own custom Grype export format. Next Steps Now that I have a vulnerability scan, what do I do with it? Each organization will have their own specific integration and deployment process. Below is a generic example of what this might look like: Create a Change Request Ticket (e.g. GitHub Issue, etc) Prioritize the Ticket Assign the Ticket Create a Draft Change (e.g. GitHub Pull Request, etc) Create a New SBOM (e.g. with Syft) Scan the New SBOM (e.g. with Grype) Merge the Change into Main Code Branch (e.g. GitHub Merge, etc) Following these steps you can create a process to systematically act on newly discovered vulnerabilities in your software and take the appropriate steps to remediate the vulnerabilities before they are exploited. Managing Vulnerability Scans at Scale This works good and well for a single developer workflow but as organizations grow and are attempting to scale the software supply chain security practice doing all of these steps manually quickly becomes untenable.  A purpose-built software system to manage vulnerability scans and their associated SBOMs becomes imperative. An automated system that collects and stores all of this metadata enables additional features such as automated alerting for new vulnerabilities and automated policy enforcement to prevent vulnerable applications from moving through the CI (build) or CD (deployment) process. ### How to Generate an SBOM with Free Open Source Tools Generating a software bill of materials (SBOM) as part of your DevSecOps process is an essential step to secure your software supply chain. SBOMs are becoming critical due to the growing prominence of catastrophic supply chain attacks like XZ Utils, Log4j and CUPS. SBOMs are a comprehensive record of every software component in an application—along with critical metadata such as supplier, licensing, and security details. SBOMs serve as the foundational data structure for security, OSS licensing compliance, risk management use-cases—and many more across a DevSecOps organization. Importantly, SBOMs are needed to comply with the White House Executive Order (EO) 14028 and the recently ratified Cyber Resilience Act in the European Union. Fortunately, there are a number of free, open source tools that generate SBOMs. Generating your first one only takes a few simple steps: Choose your SBOM generation tool—we’ll use Syft Download and install Syft Determine the SBOM output format you need Run Syft against the desired source code or container: syft -o Take your SBOM to the bank (or centralized SBOM storage)! If you need instant gratification, check out our one minute tutorial. It covers generating an SBOM and scanning it for vulnerabilities: https://www.youtube.com/watch?v=ZUpUiG3Q6J8 Understand, Implement & Leverage SBOMs for Stronger Security & Risk Management Download Now Choosing an SBOM generation tool There are many tools available for generating SBOMs, so the first thing you’ll need to do is pick one to use. Below is a TL;DR of the most impactful evaluation criteria: Understanding Your Use-Cases: Aligning the tool with your specific goals. Ecosystem Compatibility: Ensuring support for your programming languages, operating systems, and build artifacts. Data Accuracy: Evaluating the tool's ability to provide comprehensive and precise SBOMs. DevSecOps Integration: Assessing how well the tool fits into your existing DevSecOps tooling. Proprietary vs. Open Source: Weighing the long-term implications of your choice. A full-length discussion of each of these points can be found at the end of this article. 4 Popular Open Source Tools for SBOM Generation Some of the most popular SBOM tools are: Syft by Anchore SBOM Tool by Microsoft CycloneDX Generator (cdxgen) by OWASP Tern by VMware If you are looking for a comprehensive list of open source SBOM generation tools in the wild, we track the complete list in our open source SBOM eBook. For this article, we’ll focus on Syft. It is easy to use in many different scenarios and supports a variety of ecosystems. Syft can run on your desktop, in CI systems, as a Docker container and scan a wide variety of ecosystems from Linux distributions to many types of build dependency specifications. Additionally, Syft is the recommended software composition analysis (SCA) tool for generating SBOMs in NVIDIA's AI Blueprint for Vulnerability Analysis. How to generate an SBOM (using Syft) Enough with the prelude! Let's get into the meat of how to generate an SBOM. We'll walk you through the process below: Step 1: Install Syft The first thing to do is install Syft. There are a number of ways to do this: curl The recommended method to get Syft for macOS and Linux is by using curl: curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bincurl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin Homebrew For macOS, Syft is available to install from Homebrew: brew install syftbrew install syft Direct Download You can directly download Syft binaries for many platforms including Windows from the GitHub releases page. Docker There is also a Syft Docker image with every release: anchore/syft, which can be run like this: docker run -it --rm anchore/syft docker run -it --rm anchore/syft Step 2: Validate the Syft Installation To confirm Syft was installed correctly, simply run: syft versionsyft version Which will produce output similar to: Application: syft Version: 1.4.1 BuildDate: 2024-05-09T19:45:46Z GitCommit: c200896a9644f9b6bd4bc3785c848276c33bb53c GitDescription: v1.4.1 Platform: darwin/arm64 GoVersion: go1.21.9 Compiler: gcApplication: syft Version: 1.4.1 BuildDate: 2024-05-09T19:45:46Z GitCommit: c200896a9644f9b6bd4bc3785c848276c33bb53c GitDescription: v1.4.1 Platform: darwin/arm64 GoVersion: go1.21.9 Compiler: gc Note: Syft was version 1.4.1 at the time of this writing Step 3: Generate an SBOM Once you have Syft installed, creating your first SBOM is simple. Syft supports multiple sources to scan when generating an SBOM using both the local filesystem and container images. To generate an SBOM for a Docker or OCI image—even without a Docker daemon, simply run: syft syft Syft can generate SBOMs from a variety of other sources, such as, scanning the filesystem by directory or specific file, Podman, tar archives, or directly from an OCI registry even when Docker is not available. Check out the full list of sources. Example SBOM Generation To scan the latest Alpine image, simply run: syft alpine:latestsyft alpine:latest You should see output similar to this: ✔ Loaded image alpine:latest ✔ Parsed image sha256:ace17d5d883e9ea5a21138d0608d… ✔ Cataloged contents 064d96b7a2fc6398b4c596e2a693fcc961a… ├── ✔ Packages [15 packages] ├── ✔ File digests [80 files] ├── ✔ File metadata [80 locations] └── ✔ Executables [17 executables] NAME VERSION TYPE alpine-baselayout 3.4.3-r2 apk alpine-baselayout-data 3.4.3-r2 apk alpine-keys 2.4-r1 apk apk-tools 2.14.0-r5 apk busybox 1.36.1-r15 apk busybox-binsh 1.36.1-r15 apk ca-certificates-bundle 20230506-r0 apk libc-utils 0.7.2-r5 apk libcrypto3 3.1.4-r5 apk libssl3 3.1.4-r5 apk musl 1.2.4_git20230717-r4 apk musl-utils 1.2.4_git20230717-r4 apk scanelf 1.3.7-r2 apk ssl_client 1.36.1-r15 apk zlib 1.3.1-r0 apk ✔ Loaded image alpine:latest ✔ Parsed image sha256:ace17d5d883e9ea5a21138d0608d… ✔ Cataloged contents 064d96b7a2fc6398b4c596e2a693fcc961a… ├── ✔ Packages [15 packages] ├── ✔ File digests [80 files] ├── ✔ File metadata [80 locations] └── ✔ Executables [17 executables] NAME VERSION TYPE alpine-baselayout 3.4.3-r2 apk alpine-baselayout-data 3.4.3-r2 apk alpine-keys 2.4-r1 apk apk-tools 2.14.0-r5 apk busybox 1.36.1-r15 apk busybox-binsh 1.36.1-r15 apk ca-certificates-bundle 20230506-r0 apk libc-utils 0.7.2-r5 apk libcrypto3 3.1.4-r5 apk libssl3 3.1.4-r5 apk musl 1.2.4_git20230717-r4 apk musl-utils 1.2.4_git20230717-r4 apk scanelf 1.3.7-r2 apk ssl_client 1.36.1-r15 apk zlib 1.3.1-r0 apk By default, the SBOM you’ll see will be a nicely formatted table rather than any standardized SBOM format, which leads us to… Step 3: Choose an SBOM Format Depending on your use-cases, it may be important to use a particular SBOM format. The most popular ones are Software Package Data Exchange (SPDX) and CycloneDX, both of which Syft supports. Syft also has a lossless intermediate format which interoperates with Anchore's open source vulnerability scanner, Grype. If you're looking for more detailed information on SBOM formats, standards and examples follow the link. While Syft supports these different formats, they have slightly different goals and features. It may be important to pick SPDX or CycloneDX for interoperability with other tools or as a standardized format to distribute to downstream consumers. Generating an SBOM in SPDX format If your use-case requires an SBOM in SPDX format, Syft has you covered. SPDX has been around the longest of all the formats mentioned here. There are multiple variants of SPDX. Syft supports SPDX Tag-Value (spdx-tag-value) and SPDX JSON (spdx-json). For SPDX JSON, simply add the -o spdx-json argument. For example, run: syft alpine:latest -o spdx-jsonsyft alpine:latest -o spdx-json You’ll see there is a lot more data than the table view allows! You should see something resembling: { "spdxVersion": "SPDX-2.3", "dataLicense": "CC0-1.0", "SPDXID": "SPDXRef-DOCUMENT", "name": "alpine", "...": "...", "creationInfo": { "licenseListVersion": "3.25", "creators": [ "Organization: Anchore, Inc", "Tool: syft-1.19.0" ], "created": "2025-01-27T15:29:58Z" }, "packages": [ { "name": "alpine-baselayout", "SPDXID": "SPDXRef-Package-apk-alpine-baselayout-421bc6506abee7e4", "versionInfo": "3.6.8-r1", "supplier": "Person: Natanael Copa (ncopa@alpinelinux.org)", "...": "...", "sourceInfo": "acquired package info from APK DB: /lib/apk/db/installed", "licenseConcluded": "NOASSERTION", "licenseDeclared": "GPL-2.0-only", "copyrightText": "NOASSERTION", "description": "Alpine base dir structure and init scripts", "externalRefs": [ { "referenceCategory": "SECURITY", "referenceType": "cpe23Type", "referenceLocator": "cpe:2.3:a:alpine-baselayout:alpine-baselayout:3.6.8-r1:*:*:*:*:*:*:*" }, { "referenceCategory": "PACKAGE-MANAGER", "referenceType": "purl", "referenceLocator": "pkg:apk/alpine/alpine-baselayout@3.6.8-r1?arch=aarch64&distro=alpine-3.21.2" } ] }, ] }{ "spdxVersion": "SPDX-2.3", "dataLicense": "CC0-1.0", "SPDXID": "SPDXRef-DOCUMENT", "name": "alpine", "...": "...", "creationInfo": { "licenseListVersion": "3.25", "creators": [ "Organization: Anchore, Inc", "Tool: syft-1.19.0" ], "created": "2025-01-27T15:29:58Z" }, "packages": [ { "name": "alpine-baselayout", "SPDXID": "SPDXRef-Package-apk-alpine-baselayout-421bc6506abee7e4", "versionInfo": "3.6.8-r1", "supplier": "Person: Natanael Copa (ncopa@alpinelinux.org)", "...": "...", "sourceInfo": "acquired package info from APK DB: /lib/apk/db/installed", "licenseConcluded": "NOASSERTION", "licenseDeclared": "GPL-2.0-only", "copyrightText": "NOASSERTION", "description": "Alpine base dir structure and init scripts", "externalRefs": [ { "referenceCategory": "SECURITY", "referenceType": "cpe23Type", "referenceLocator": "cpe:2.3:a:alpine-baselayout:alpine-baselayout:3.6.8-r1:*:*:*:*:*:*:*" }, { "referenceCategory": "PACKAGE-MANAGER", "referenceType": "purl", "referenceLocator": "pkg:apk/alpine/alpine-baselayout@3.6.8-r1?arch=aarch64&distro=alpine-3.21.2" } ] }, ] } Not only does this format contain the package names, but also Package URLs, license information, and a host of additional metadata, such as, the location of associated files Syft identified within the package. Generating an SBOM in CycloneDX format Similarly, if you need to generate an SBOM in CycloneDX format use a CycloneDX format option. Syft supports CycloneDX XML (cyclonedx-xml) and JSON (cyclonedx-json). For CycloneDX XML: syft -o cyclonedx-xmlsyft -o cyclonedx-xml To run this against the same latest Alpine image, run: syft alpine:latest -o cyclonedx-xmlsyft alpine:latest -o cyclonedx-xml And you should see a result resembling this: 2025-01-27T10:49:00-05:00 anchore syft 1.19.0 alpine sha256:47badde288cf303fe43766ba3c0be01df313b84ad91480c1f21b7e907a7f2337 Natanael Copa alpine-baselayout 3.6.8-r1 Alpine base dir structure and init scripts GPL-2.0-only cpe:2.3:a:alpine-baselayout:alpine-baselayout:3.6.8-r1:*:*:*:*:*:*:* pkg:apk/alpine/alpine-baselayout@3.6.8-r1?arch=aarch64&distro=alpine-3.21.2 https://git.alpinelinux.org/cgit/aports/tree/main/alpine-baselayout apk-db-cataloger apk apk-db-entry cpe:2.3:a:alpine-baselayout:alpine_baselayout:3.6.8-r1:*:*:*:*:*:*:* ... ... 2025-01-27T10:49:00-05:00 anchore syft 1.19.0 alpine sha256:47badde288cf303fe43766ba3c0be01df313b84ad91480c1f21b7e907a7f2337 Natanael Copa alpine-baselayout 3.6.8-r1 Alpine base dir structure and init scripts GPL-2.0-only cpe:2.3:a:alpine-baselayout:alpine-baselayout:3.6.8-r1:*:*:*:*:*:*:* pkg:apk/alpine/alpine-baselayout@3.6.8-r1?arch=aarch64&distro=alpine-3.21.2 https://git.alpinelinux.org/cgit/aports/tree/main/alpine-baselayout apk-db-cataloger apk apk-db-entry cpe:2.3:a:alpine-baselayout:alpine_baselayout:3.6.8-r1:*:*:*:*:*:*:* ... ... Again, there is a lot more data than the table allows, but a different set of data than the SPDX format because there simply is not a one-to-one mapping of properties between the two. Generating an SBOM in Syft Lossless format The last format we’ll talk about is Syft’s own format. If there isn’t a need to provide an SBOM to other tools or you're using a tool that supports Syft's lossless intermediate format (e.g., Grype), then the Syft JSON format will deliver the highest fidelity data. Both SPDX and CycloneDX prune data fields from the metadata that Syft's scan generates while the Syft lossless format does not. Although Grype works great with SPDX and CycloneDX, there could be a situation where data was lost converting to one of these formats that Grype's matching uses. This impairs Grype's ability to detect vulnerabilities which is why we recommend the Syft lossless format.To use the Syft JSON format, use the -o json argument. Additional Syft Features There’s a lot more that this open source SBOM tool can do. A few features of note: Output the SBOM to a file using --file path/to/file Exclude paths from scanning using --exclude path/**/*.txt Specify configuration in a .syft.yaml file Connect to private OCI registries Cryptographically sign an SBOM See all Syft features and configuration options, in the docs. Next Steps Now that you’ve got an SBOM, what’s next? A logical next step would be to integrate with your build pipeline to have SBOMs generated automatically. In fact, there could be more than one location where it makes sense to generate SBOMs such as build time and after a container is built or during a release process. The SBOMs then could be scanned for license compliance and continuously for vulnerabilities. In fact, if you are using GitHub Actions, there are a couple actions to do just that: sbom-action to generate SBOMs using Syft and scan-action to perform vulnerability scanning. For a few repositories, it’s very simple to set these up but might be challenging when there are a lot of repositories to keep track of. Managing SBOMs at scale As we’ve talked about, using SBOMs as a central part of securing your software supply chain is increasingly important. Integrating automated SBOM generation into your DevOps process is vital. Storing, managing, and analyzing those SBOMs to inform security measures should be an important consideration for you and your organization. For more comprehensive SBOM management, an enterprise level solution like Anchore Enterprise will enable you to generate comprehensive SBOMs with every build, detect drift from one build to the next, share SBOMs internally or externally, and quickly identify risk such as vulnerabilities, secrets, malware, and misconfigurations. Detailed Discussion of Criteria for Choosing an SBOM Generator As promised at the beginning of this article, below is a detailed discussion of the criteria to choose the best SBOM generation tool for your organization. Know your use-cases When choosing from the array of SBOM generation tools in the market, it is important to frame your decision with the outcome(s) that you are trying to achieve. If your goal is to improve the response time/mean time to remediation when the next Log4j-style incident occurs—and be sure that there will be a next time—an SBOM tool that excels at correctly identifying open source licenses in a code base won't be the best solution for your use-case (even if you prefer its CLI ;-D). What to Do: Identify and prioritize the outcomes that your organization is attempting to achieve Map the outcomes to the relevant SBOM use-cases Review each SBOM generation tool to determine whether they are best suited to your use-cases It can be tempting to prioritize an SBOM generator that is best suited to our preferences and workflows; we are the ones that will be using the tool regularly—shouldn't we prioritize what makes our lives easier? If we prioritize our needs above the goal of the initiative we might end up putting ourselves into a position where our choice in tools impedes our ability to recognize the desired outcome. Using the correct framing, in this case by focusing on the use-cases, will keep us focused on delivering the best possible outcome. SBOMs can be utilized for numerous purposes: security incident response, open source license compliance, proactive vulnerability management, compliance reporting or software supply chain risk management. We won't address all use-cases/outcomes in this blog post, a more comprehensive treatment of all of the potential SBOM use-cases can be found on our website. Example SBOM Use-Cases: Security incident response: an inventory of all applications and their dependencies that can be queried quickly and easily to identify whether a newly announced zero-day impacts the organization. Proactive vulnerability management: all software and dependencies are scanned for vulnerabilities as part of the DevSecOps lifecycle and remediated based on organizational priority. Regulatory compliance reporting: compliance artifacts and reports are automatically generated by the DevSecOps pipeline to enable continuous compliance and prevent manual compliance work. Software supply chain risk management: an inventory of software components with identified vulnerabilities used to inform organizational decision making when deciding between remediating risk versus building new features. Open source license compliance: an inventory of all software components and the associated OSS license to measure potential legal exposure. Pro tip: While you will inevitably leave many SBOM use-cases out of scope for your current project, keeping secondary use-cases in the back of your mind while making a decision on the right SBOM tool will set you up for success when those secondary use-cases eventually become a priority in the future. Does the SBOM generator support your organization's ecosystem of programming languages, etc? SBOM generators aren't just tools to ingest data and re-format it into a standardized format. They are typically paired with a software composition analysis (SCA) tool that scans an application/software artifact for metadata that will populate the final SBOM. Support for the complete array of programming languages, build artifacts and operating system ecosystems is essentially an impossible task. This means that support varies significantly depending on the SBOM generator that you select. An SBOM generator's ability to help you reach your organizational goals is directly related to its support for your organization's software tooling preferences. This will likely be one of the most important qualifications when choosing between different options and will rule out many that don't meet the needs of your organization. Considerations: Programming Languages: Does the tool support all languages used by your team? Operating Systems: Can it scan the different OS environments your applications run on top of? Build Artifacts: Does the tool scan containers? Binaries? Source code repositories?  Frameworks and Libraries: Does it recognize the frameworks and libraries your applications depend on? Data accuracy This is one of the most important criteria when evaluating different SBOM tools. An SBOM generator may claim support for a particular programming language but after testing the scanner you may discover that it returns an SBOM with only direct dependencies—honestly not much better than a package.json or go.mod file that your build process spits out. Two different tools might both generate a valid SPDX SBOM document when run against the same source artifact, but the content of those documents can vary greatly. This variation depends on what the tool can inspect, understand, and translate. Being able to fully scan an application for both direct and transitive dependencies as well as navigate non-ideomatic patterns for how software can be structured end up being the true differentiators between the field of SBOM generation contenders. Imagine using two SBOM tools on a Debian package. One tool recognizes Debian packages and includes detailed information about them in the SBOM. The latter can't fully parse the Debian .deb format and omits critical information. Both produce an SBOM, but only one provides the data you need to power use-case based outcomes like security incident response or proactive vulnerability management.Let's make this example more concrete by simulating this difference with Syft, Anchore's open source SBOM generation tool: $ syft -q -o spdx-json nginx:latest > nginx_a.spdx.json $ grype -q nginx_a.spdx.json | grep Critical libaom3 3.6.0-1+deb12u1 (won't fix) deb CVE-2023-6879 Critical libssl3 3.0.14-1~deb12u2 (won't fix) deb CVE-2024-5535 Critical openssl 3.0.14-1~deb12u2 (won't fix) deb CVE-2024-5535 Critical zlib1g 1:1.2.13.dfsg-1 (won't fix) deb CVE-2023-45853 Critical$ syft -q -o spdx-json nginx:latest > nginx_a.spdx.json $ grype -q nginx_a.spdx.json | grep Critical libaom3 3.6.0-1+deb12u1 (won't fix) deb CVE-2023-6879 Critical libssl3 3.0.14-1~deb12u2 (won't fix) deb CVE-2024-5535 Critical openssl 3.0.14-1~deb12u2 (won't fix) deb CVE-2024-5535 Critical zlib1g 1:1.2.13.dfsg-1 (won't fix) deb CVE-2023-45853 Critical In this example, we first generate an SBOM using Syft then run it through Grype—our vulnerability scanning tool. Syft + Grype uncover 4 critical vulnerabilities. Now let's try the same thing but "simulate" an SBOM generator that can't fully parse the structure of the software artifact in question: $ syft -q -o spdx-json --select-catalogers "-dpkg-db-cataloger,-binary-classifier-cataloger" nginx:latest > nginx_b.spdx.json $ grype -q nginx_b.spdx.json | grep Critical $ syft -q -o spdx-json --select-catalogers "-dpkg-db-cataloger,-binary-classifier-cataloger" nginx:latest > nginx_b.spdx.json $ grype -q nginx_b.spdx.json | grep Critical In this case, we are returned none of the critical vulnerabilities found with the former tool. This highlights the importance of careful evaluation of the SBOM generator that you decide on. It could mean the difference between effective vulnerability risk management and a security incident. Can the SBOM tool integration into your DevSecOps pipeline? If the SBOM generator is packaged as a self-contained binary with a command line interface (CLI) then it should tick this box. CI/CD build tools are most amenable to this deployment model. If the SBOM generation tool in question isn't a CLI then it should at least run as a server with an API that can be called as part of the build process. Integrating with an organization's DevSecOps pipeline is key to enable a scalable SBOM generation process. By implementing SBOM creation directly into the existing build tooling, organizations can leverage existing automation tools to ensure consistency and efficiency which are necessary for achieving the desired outcomes. Proprietary vs. open source SBOM generator? Using an open source SBOM tool is considered an industry best practice. This is because it guards against the risks associated with vendor lock-in. As a bonus, the ecosystem for open source SBOM generation tooling is very healthy. OSS will always have an advantage over proprietary in regards to ecosystem coverage and data quality because it will get into the hands of more users which will create a feedback loop that closes gaps in coverage or quality. Finally, even if your organization decides to utilize a software supply chain security product that has its own proprietary SBOM generator, it is still better to create your SBOMs with an open source SBOM generator, export to a standardized format (e.g., SPDX or CycloneDX) then have your software supply chain security platform ingest these non-proprietary data structures. All platforms will be able to ingest SBOMs from one or both of these standards-based formats. Conclusion Now that you understand the many reasons to generate SBOMs (whether for compliance or vulnerability analysis) using Syft to generate SBOMs is a flexible and simple process with many options to tailor SBOMs to your specific use-cases. If you'd like to explore using Anchore Enterprise for its robust features like continuous visibility, SBOM monitoring, drift detection, and policy enforcement then access a free 15 day trial here. Save your developers time with Anchore Enterprise. Get instant access with a 15-day free trial. START FREE TRIAL ### NIST 800-218 SSDF Automated Compliance Today Anchore is releasing an update to its NIST Policy Pack that can help customers achieve NIST 800-218 SSDF compliance. This policy pack can be imported into a running Anchore Enterprise instance and checks the technical controls that apply to applications, containers, and environments. The Executive Order on Improving the Nation’s Cybersecurity sets out expectations for NIST to provide guidance on how to improve the security of software development. That order was given in early 2021 and we saw the guidance come to fruition in late 2022. The secure development recommendations in this order resulted in creation of the Secure Software Development Framework (SSDF) - a set of secure software development guidance created by NIST and formalized as NIST 800-218. The intention of this standard is anyone conducting business with the government will follow this guidance. The idea of securing the software supply chain has been gaining momentum over the past few years, but how to do this isn’t always clear. If you have been watching the supply chain space, the guidance often lacks concrete details, and can be conflicting with itself. NIST is the gold standard when it comes to clearly defining a compliance standard and making sure the various controls are easy to understand and implement. The SSDF is a great example of NIST taking a poorly defined concept and putting well defined actions behind it. We can expect many U.S. Federal agencies and regulated industries to mandate that their software and service vendors comply with the controls spelled out in the SSDF in the coming years. It’s common for new standards to take some time to catch on, SSDF will be no different. This gives the rest of us time to understand and comply with the standard. How does Anchore help with SSDF compliance Anchore Enterprise has a robust policy engine that is used today by many customers to stay in compliance with standards such as CIS and FedRAMP using predefined policy packs created by Anchore.  Anchore has updated its NIST Policy Pack to incorporate the controls recommended by the SSDF as part of NIST 800-218. The new controls include steps such as inspecting for malware and secrets, scanning for known vulnerabilities, and generating software bills of materials (SBOM). This policy pack doesn’t meet every control specified by the SSDF. Some controls cannot be automatically detected, such as training requirements and development practices. However, the controls that apply to the technical content of a project are things we detect. This new policy compliments pre-existing support for NIST 800-53 and NIST 800-190. In addition, the NIST Policy Pack includes support for detecting packages included in the CISA Known Exploited Vulnerabilities (KEV) catalog. Why use the NIST Policy Pack By using the NIST Policy Pack with controls for the SSDF, Anchore Enterprise customers can automate the enforcement of NIST’s recommendations, alerting application developers or security engineers to failures as software is being developed and built instead of during a compliance audit. Anchore’s reporting capabilities enable security teams to demonstrate their level of compliance as part of formal reporting requirements. By automating SSDF controls checks and enforcement, time needed to prove compliance can be reduced. Those interested in learning more about the NIST Policy Pack can visit our federal compliance web page here or request a demo for an interactive view of the new features.  ### SBOM GitHub Action As we expand our portfolio of open source SBOM tools, we are excited to announce the release of sbom-action, a GitHub Action for creating a software bill of materials (SBOM) using Syft. What Is It? The sbom-action is a simple way to generate a software bill of materials (SBOM) in your GitHub-based workflows and releases. Why generate an SBOM, you ask? Because that’s what all the cool kids are doing! That, and supply chain security is increasingly important for software vendors. Many developers are already aware of the Executive Order on Improving the Nation’s Cybersecurity, its emphasis on securing the software supply chain, and the requirement for SBOMs in particular. Combine that with recent, headline-making attacks like SolarWinds and Codecov and DevOps teams are taking notice, making SBOMs a required part of the development lifecycle. The first step in securing your supply chain is to create an inventory of the software and libraries being used during your build and deployment cycle. This is where the sbom-action comes into play. Under the hood, the sbom-action uses the open source tool Syft to provide container image and directory-based SBOM generation, which makes it easy to add multiple SBOM-generation steps to your workflows. Among other things, this can be used to track build-time dependencies that may not be easily determined in the final product. How do I Use It? Every software project is different, but you should be able to identify the components used during the build and deployment cycles and how they are used. It can be important to generate SBOMs at multiple stages in the development process. Security risks that are introduced in various stages of the development and build process may not be easily detectable once the container image is fully built. Take, for example, a common type of project that uses NPM packages but builds a bundle that ultimately gets distributed in a container with a minimal web server. An example of this type of project can be seen here. During build time, a malicious package could be introduced. Without a record, or SBOM, to identify and track what software was added along the way, you would have no way of knowing if that malicious code made it into the resulting container or at what stage in the cycle it was added. Using the sbom-action is as simple as just adding a step to your GitHub Actions workflow. Using the aforementioned example, let’s say your repository contains a NPM-based project that builds a React App locally and copies the files to a static web server container. You may have a workflow set up which does something like this: - run: npm install - run: npm run build - run: docker build -t my/image . In order to generate the most accurate SBOM, you would add another step after npm run install but before docker build. In this case, all you need to do is add one step that uses: anchore/sbom-action: - run: npm install - uses: anchore/sbom-action@v0 - run: npm run build - run: docker build -t my/image . The sbom-action will automatically run in the workspace root and attempt to find all dependencies based on the NPM or Yarn lockfiles, generate an SBOM and upload it as a workflow artifact, and finally, detect if the sbom-action was run during a GitHub release and automatically upload the SBOM as a release asset. Then, to scan the container, just add another step with the image parameter: - uses: anchore/sbom-action@v0 with:   image: my/image With multiple options for scanning and configuration, sbom-action can easily be used to generate SBOMs from both simple and complex scenarios. What Lies Ahead? Generating SBOMs and using them to track components through the development cycle is quickly becoming an integral part of securing the software supply chain and sbom-action provides an easy way to make this part of your GitHub Actions workflows. Future sbom-action enhancements include: Automatic diffs in dependencies with pull requests, so you can easily see changes to your dependencies - expected or unexpected Automatically sign SBOMs for container images with cosign (see this great blog on how to combine Syft and cosign using the shell) Generate SBOM badges to show that sbom-action has been run and then show SBOMs in human-readable formats Link multiple SBOMs associated with a build process to provide full visibility as software moves through your supply chain Go here to start using sbom-action today! Let us know what you think and consider giving it a star on GitHub to show your support! ### CSF 2.0 The next major update to the influential NIST Cybersecurity Framework 2.0 (CSF 2.0) is just around the corner. The development and publication of NIST CSF 2.0 re-affirms the US Federal Government's commitment to altering the narrative that the private sector innovates in cybersecurity and the public sector adopts. Originally published in 2014 with a minor version bump in 2018 (1.0 to 1.1). 2024 will mark the release of CSF 2.0. This accomplishes 3 releases in a 10 year span with a significant increase in the breadth of the audience; going from critical infrastructure only to all organizations that utilize information technology (read: all organizations). In this post, we'll delve into the key changes of CSF 2.0, including the integration of the 'Govern' function, revised implementation guidance, and its synergy with other NIST frameworks. We'll explore how these changes benefit organizations and provide a roadmap for implementing the new framework effectively. With CSF 2.0, NIST not only addresses the complex cybersecurity landscape but also ensures that the framework is adaptable and effective for diverse cybersecurity needs. Join us as we unpack the CSF 2.0, offering insights, practical advice, and answers to some of your most pressing questions. Whether you're a cybersecurity veteran or new to the field, this guide will equip you with the knowledge to effectively navigate and implement the updated framework. What's changing in CSF 2.0? Broadened Scope The framework's scope has been updated to include all organizations globally, not just those in critical infrastructure The original CSF was development under the directive of Executive Order 13636, "Improving Critical Infrastructure Cybersecurity" which focused primarily on critical infrastructure New Function - Govern Previously there were 5 functions of the CSF; Identify, Protect, Detect, Respond and Recover The addition of the sixth function Govern is aimed at integrating the CSF with the holistic organization rather than cybersecurity being a silo Implementation Guidance Implementation examples have been added to provide assistance in achieving the framework Framework Profiles have been improved to help organizations align their cybersecurity initiatives with their business objectives Integration with Other Frameworks CSF 2.0 creates connections between the web of other related frameworks These frameworks include the Privacy Framework, the Secure Software Development Framework (SSDF), Cybersecurity Supply Chain Risk Management Practices (NIST SP 800-161) and the Artificial Intelligence Risk Management Framework Cybersecurity Supply Chain Risk Management Cybersecurity supply chain risk management was previously mixed into the Identify and Protect functions of the CSF; now it is highlighted with its own sub-category under the Govern function This is an ongoing trend for all NIST publications that deal with cybersecurity; the Risk Management Framework (NIST 800-37) and the Control Catalog (NIST 800-53) both saw software supply chain security promoted to dedicated sections in the latest revisions of each Breaking Down NIST SSDF series If you're looking for a deeper understanding of these frameworks, we have published comprehensive guides on some of them on our blog. Introduction to the Secure Software Development FrameworkSpotlight on P0.1 — Prepare the OrganizationSpotlight on PW.6 — Build SystemsSpotlight on PW.6 — Compilers and Interpreter SecuritySpotlight on PS.3.2 — SBOMs What are the benefits? NIST CSF 2.0 compliance is only mandatory for federal agencies; however, if your company does business with the US government, or plans on it, CSF compliance is a clear way to demonstrate alignment with the priorities of these agencies. This was true of the original CSF and will continue to be so when the updated 2.0 framework is released. In addition to this clear business benefit for organizations, all of the changes listed in the section above were aimed at improving the CSF which means that the benefits of the latest release of the CSF will look very similar to the changes above. Here is a concise summarization: The NIST Cybersecurity Framework 2.0 offers several enhancements over version 1.1, making it a more versatile and comprehensive tool for managing cybersecurity risks. First, it is more general, meaning it applies to more than just critical infrastructure which was the target audience of the original CSF. Second, it has embedded itself into the network of NIST frameworks that constitute NIST's holistic vision for cybersecurity and privacy. Third, a sixth function was added to tie the CSF to the operational side of the organization instead of just the technical function. Fourth, implementation examples were added to make it easier to ground the framework's theoretical foundation in real-world examples. Finally, the Framework Profiles were updated to make it easier to tie technical requirements to business objectives. These updates reflect the evolving cybersecurity landscape and aim to make CSF 2.0 adaptable and effective for a broader range of cybersecurity needs. How do I implement the new framework? Research: Digest and internalize the core functions – Identify, Protect, Detect, Respond, Recover, and Govern. Gap Analysis: Assess your current cybersecurity practices against the framework to identify gaps. Prioritize: Based on your assessment, prioritize areas that need improvement. Create a Target Profile: Develop a Framework Profile that aligns with your business objectives and risk management strategy. Implement Action Plan: Develop and execute an action plan to reach your Target Profile. Monitor and Review: Regularly review and update your cybersecurity practices to match the evolving cyber landscape and your organization’s changing needs. Communicate: Ensure effective communication across all levels of your organization regarding cybersecurity policies, risks, and practices. Getting Started Since CSF 2.0 is still currently in draft, the recommended way to get started is to do research on the ways that the specific changes will impact your organization and determine if achieving CSF 2.0 compliance is a priority or not for the organization. If your organization isn't already CSF 1.1 compliant then this is a good first step in order to prepare for the release of 2.0. This will reduce the lift needed when 2.0 is finalized. NIST has a getting started guide that can be found on their website. Frequently asked questions What is NIST CSF?  The NIST Cybersecurity Framework (CSF) is a set of voluntary standards, and best practices to help organizations manage and reduce cybersecurity risk. It provides a flexible and cost-effective approach for ensuring an organization is secure, particularly critical for industries vital to national and economic security. The framework is structured around five core functions – Identify, Protect, Detect, Respond, Recover, and with the latest update, Govern – providing a strategic view of an organization's approach to managing cybersecurity risk. What is the current version of NIST CSF? The current version of the NIST Cybersecurity Framework (CSF) is 1.1, released in April 2018. However, a new version, CSF 2.0, is in the process of being finalized and is expected to be published in early 2024. When was NIST CSF 1.0 released? The NIST Cybersecurity Framework 1.0 was released in February 2014. It was followed by the release of NIST CSF 1.1 in April 2018. When was the CSF 2.0 draft released?  The public draft of CSF 2.0 was published on August 8, 2023. But was preceded by a few iterations that solicited feedback from the community on how to best improve on the original CSF from 2014 and the 1.1 revision from 2018. The CSF 2.0 concept paper was released January 2023. It was titled, “Cybersecurity Framework 2.0 Concept Paper: Potential Significant Updates to the Cybersecurity Framework”, it laid the groundwork for the upcoming changes and updates to the framework. A discussion draft of CSF 2.0 was then released in April 2023. This draft included potential Functions, Categories, and Subcategories (also called cybersecurity outcomes) of the CSF 2.0 Core. It aimed to increase transparency in the development process and to encourage discussion and feedback for further development.As with any document this information is complete up to the publish date but will become out of date over time, the most up-to-date information can be found on the official NIST CSF website. ### 7 Principles of DevSecOps Automation DevSecOps automation is one of the most significant benefits of shifting security left in your development process. The aftermath of the SolarWinds and Codecov breaches should be at the top of mind if your organization is contemplating a move to DevSecOps. In order to ensure process efficiencies, DevSecOps relies on automation, which enables developers, infrastructure, and information security teams to focus on delivering value instead of making mistakes or repeating routine tasks. Let's look at 7 DevSecOps principals that guide automation. 1. Acknowledge that DevSecOps Automation drives DevOps Transformation Pivoting your DevOps processes to DevSecOps is a transformative effort. You’re doing more than just automating some sundry manual tasks. Being strategic with automation means you can change the way that your teams work, for the better. It frees developers and sysadmins to do more strategic or billable work that was forever on the backlog because normal development and operations tasks consumed their working hours. Project managers should include the potential impact of automation in their technology and staffing plans. While automation makes business sense, such benefits may not translate to an already pandemic stressed development team nearing two years of enforced remote work. 2. Implement Orchestration for Containers Implement Kubernetes or another container orchestration solution to apply, provision, and manage repeatable security best practices through container orchestration. Approach your move to container orchestration systematically by starting small with one project, take your lessons learned, and expand orchestration throughout your cloud-native projects where it makes technology and business sense. 3. Institute an SBOM to enhance your Application Inventory The SolarWinds and Codecov breaches followed by President Biden’s Executive Order on Improving the Nation’s Cybersecurity Executive Order testifies to the growing importance of the software bill of materials (SBOM) in cybersecurity. Bringing SBOM generation into your DevSecOps pipeline using automated scanning tools gives you the best picture of proprietary and open source software (OSS) dependencies in the software your teams are developing. You can also track SBOM drift if you have the right tools and processes in place. This visibility through your development lifecycle can show where your software gains additional components and dependencies -- malicious or otherwise. 4. Build and Manage Secure Dev Environments & Toolchains To support DevSecOps automation, future development environments require integrating security standards and guidelines through an integrated development environment (IDE). Make the guidelines actionable and relevant through the use of containers or code examples. Back your policies with a developer onboarding program that trains new employees in your environments, tools, and processes. Offer a refresher course and ongoing training to your developers beyond the onboarding training. Elevate your toolchains to the same level as other endpoints in your organization’s enterprise to protect against “man in the middle” and other potential exploits. Securing your DevSecOps toolchain needs to be a continuing focus with participation from your developers, operations, and cybersecurity teams. 5. Design Efficient Code Review Processes Define the code review process to make code review more efficient and consistent saving developers and stakeholders valuable time. Be prepared to iterate with your developers, project management, and stakeholders to get to the level of efficiency they require. You do this by taking in lessons learned, documenting your code review processes, and keep a feedback mechanism in place to foster continuous improvement. An example, feedback mechanism could be a dedicated Slack channel 6. Automate Security Testing Analyze the current state of your security testing as part of your move to DevSecOps automation and look for opportunities to automate some of those tests in conjunction with your in-place functional testing as part of instituting automated regression testing. Revisit QA team roles during security testing. Then adjust your processes to place QA team members freed up via security test automation to more strategic tasks. An example of more strategic work is involving them deeper in response to QA issue remediation along with their counterparts on the development team. 7. Stick to (and Reinforce) Cloud Security Basics Tried and true solid cloud security basics are at the heart of DevSecOps automation. Your cloud security team needs to work with your development and operations teams to apply the appropriate cloud security controls to your DevSecOps environments. Some examples might include AWS Security Hub, Microsoft Azure Monitor, and Google Cloud Policy Intelligence. Conclusion Success with DevSecOps automation happens when you first acknowledge the role of automation in your digital transformation and then add automation to your existing DevSecOps processes. All the while, you want to work with your developers, system administrators, and QA team to include them in the implementation of automation moving forward. DevSecOps truly is a team sport, and when approached with intention and purpose can reap great rewards for the team. ### Syft Now Creates Attestations Using Sigstore With the recent release of Syft v0.40.0, you can now create signed SBOM attestations directly in Syft. This is made possible by Project Sigstore, which makes signing and verification of software artifacts insanely easy. Why do attestations matter for SBOMs? Attestations help users to validate that an SBOM comes from a trusted source in the software supply chain. As an example, I may use a container image without knowing all the software components or dependencies that are included in that image. However, if I trust whatever the producer of the container image says about what software is present, I can use the producer’s attestation to rely on that SBOM. This means that I can proceed to use the SBOM safely in my workflow in place of having done the analysis myself. What is an attestation? An attestation is a cryptographically signed “statement” that claims something (a “predicate”) is true about another thing (a “subject”). In the container example above, the SBOM is the predicate and the container image is the subject, which means that the “signer” is attesting that the SBOM is an accurate representation of the contents of the container image. The fact that this statement is signed means that consumers of this data can decide for themselves whether or not they trust the statement based on their trust of the identity (a public key, a person, a company, or some other entity) that did the signing. It also means that consumers can detect if the data they’re ingesting has been tampered with since the attestation was created. The “statement” concept is extremely versatile because the subject can be anything someone is interested in: a commit in a repository, an executable file, a container image, and so on. And the predicate can describe anything about the subject: a code review, information on where the subject originally came from, or what software packages compose the subject, to name just a few examples. Why was attestation added to Syft? Syft gathers data that’s used in downstream security analysis (like vulnerability scanning), so it’s important that you have ways to safely rely on SBOM data, especially when SBOMs cross organizational boundaries. Thanks to tools like Sigstore’s Cosign, it has become incredibly easy to publish trusted data for other people to use. Syft had already been able to produce SBOMs that could then be consumed in Cosign-based workflows (both Syft and Cosign support SBOMs in CycloneDX, SPDX, and Syft’s native format), but by bringing attestation closer to the point of data generation (directly in Syft’s execution), Syft enables a safer creation of trusted information because the statement (which includes the SBOM, itself) is signed before any data is exposed beyond the Syft process. This means there’s no chance for anyone to sneak changes into the SBOM before it gets sealed in the attestation. On top of that, the Syft and Cosign integration makes it easier to create SBOM attestations now that it’s just one command from a single tool. How to create SBOM attestations with Syft To create an SBOM attestation in Syft, just use the new `attest` command. Syft uses in-toto attestations, which is a particular framework and specification for creating and using attestations. In one fell swoop, Syft will generate an SBOM for the specified target and create an in-toto attestation for that SBOM, using Cosign’s library internally to generate and sign the in-toto statement. 1. If you don’t have a Cosign key pair, generate one. $ cosign generate-key-pair Note: Your private key is encrypted with a password. When you’re generating the key pair, you can store a password in the COSIGN_PASSWORD environment variable to get prompted by Cosign. Additionally, if you’ve already stored your password in COSIGN_PASSWORD, Syft will find this password and won’t need to ask you for it when signing the SBOM attestation. 2. To create the SBOM attestation and write the attestation to a file, use syft attest with a file redirect. (Note that aside from the --key argument, syft attest just uses the same syntax as syft !) $ syft attest --key ./cosign.key -o cyclonedx-json > ./my-image-sbom.att.json 3. If you want, you can use Cosign to attach the attestation to an image in a container registry. $ cosign attach attestation --attestation ./my-image-sbom.att.json Great! Now anyone who has your public key can use Cosign to verify your SBOM attestation, which means they can trust the SBOM’s representation of your container image. $ cosign verify-attestation --key ./cosign.pub SBOM formats used for attestations In-toto statements are flexible with the format of the predicate data (which is the SBOM, in this case). Statements declare the type of the predicate with a “predicateType” field. Since the statement is JSON data, the predicate data within the statement should also be JSON data. Syft can create attestations with the CycloneDX JSON format, the SPDX JSON format, and with Syft’s own lossless JSON format. If you don’t specify a format, Syft defaults to its lossless JSON format. Read more about Syft’s attestation workflow. Looking ahead with Syft, Grype, and Sigstore We plan to integrate Syft more deeply with Sigstore in the coming months, starting by adding support for Sigstore’s “keyless workflow,” which eliminates the need for users to manage their own key pairs. We also plan to extend attestation support into Grype to enable vulnerability scans based on trusted SBOM analysis and to provide attestations for vulnerability scans. We view attestations as a significant enhancement to the existing security workflows of the Syft and Grype ecosystem. Be sure to grab the latest release of Syft and try out SBOM attestation for yourself! Shout-outs <3 Big thanks to Chris Phillips for the engineering work to make this integration happen. Thanks to Santiago Torres-Arias for expert guidance on using the in-toto attestation framework. And thanks to Jake Sanders and Matt Moore for helping to make Cosign integration more accessible for other projects. ### SBOM through an Open Source Lens The software bill of materials (SBOM) and the open source software (OSS) communities have long had close ties because of their community governance models and strategies.  However, OSS projects often don't ship with SBOMs. 90% of enterprise IT leaders are using enterprise open source today, according to Red Hat’s The State of Enterprise Open Source Report. Also, the report cites 54% of enterprises are using OSS for application development. Such stats speak to the need for commercial organizations, and government agencies need to put the tools and processes in place to generate SBOMs for the OSS that serves as a foundation. SBOM Roots are in Open Source The CycloneDX specification — one of the major SBOM standards — is an open source project. However, the project doesn’t have a standards organization or committee behind it. Instead, it relies on a community approach to drive innovation at a rate that keeps pace with the technological change happening around it. There’s some merit to this approach because post-SolarWinds industries now must elevate the role of the SBOM as a foundation for security and collaboration across their software supply chain. Since its launch in 2017, the CycloneDX specification’s adoption has grown to several thousand organizations, many of which are generating SBOMs automatically during their development life cycle. Another open source link to the SBOM is the Software Package Data Exchange (SPDX) standard, which follows the meritocratic governance model that the Apache Software Foundation uses. The governance model is such that SPDX enables participants to influence a project through their contributions. An organization that’s hungry for positive change to the SPX standard has an incentive to participate actively and contribute to SPDX initiatives to ensure that their voices are heard.  Also, SPDX maintains a list of open source tools that support their SBOM standard. The National Telecommunications and Information Administration (NTIA) Software Component Transparency Initiative also factors in OSS in their investigations and research into SBOM-related standards and formats. Consider that government agencies are increasingly moving to cloud-native applications; open source plays an integral role in government cloud initiatives. Government systems integrators (SIs) and small to mid-sized consulting firms serving the public sector who want to elevate the role of the SBOM in the public sector need to speak up through the NTIA initiative, CycloneDX, and SPDX to ensure their interests are heard. These groups help face down some of the common SBOM challenges in the public sector. The OWASP Foundation has also done some thinking around SCA, OSS, and the SBOM that you can find on their website. DIY SBOMs for OSS  The stats for OSS usage in application development and digital transformation (53%) speak to the power and innovation that enterprises are finding with the open source way. If your software supply chain relies on open source just as most do today, it’s essential to take a do-it-yourself (DIY) approach to create SBOMs for the open source packages your complex applications rely on for critical features. An open source bill of materials is foundational to your security team's vulnerability scans and general understanding of what software components are entering your DevOps toolchains. There’s the formal approach to doing this with software composition analysis (SCA) which will provide you better visibility into the known vulnerable components within the software package while producing an SBOM. Yet your organization may not have the expertise or tools to bring SCA into your DevSecOps pipeline. If you aren’t ready for formal SCA, you can implement a range of tools before or during the pre-commit or commit phases of your DevSecOps pipeline to create an SBOM for the OSS components of your project. Such a step also requires some accountability and ownership over the OSS SBOM. Candidates for the owner include the developer, development team lead, or the architect.  Another option would be to assign SBOM generation to a member of your software quality assurance (SQA) team by assigning them this role in the early stages of your project. Final Thoughts The open source ethos courses through the SBOM community, bringing opportunities for the larger IT community to contribute to these standards efforts with their expertise. The SBOM is gaining renewed attention in the tech world since the SolarWinds hack. It’s time for the open source communities behind these standards to continue evangelizing the necessity of SBOMs for enterprises designing, building, securing, and deploying complex cloud-native software. It’s also time for enterprises using OSS in their applications to step up their support of these efforts. ### Cybersecurity Executive Order Requires an SBOM On May 12, 2021, President Biden signed the highly anticipated Executive Order on Improving the Nation’s Cybersecurity (EO 14028). This executive order (EO) includes a major element outlining new guidelines for how US federal government programs will interact with industry software suppliers and partners moving forward. SBOMs & The Executive Order There are many notable improvements throughout the EO, but one area our team at Anchore found particularly interesting was around emerging requirements for sharing software bill of materials (SBOM) information when software is being delivered across organizational boundaries. Following the Executive Order’s initial publication in May 2021, the NTIA and Department of Commerce released a secondary document with more information on SBOM requirements: The Minimum Elements for a Software Bill of Materials. This document goes into more detail on three categories of minimum required elements: data fields, automation support, and practices and processes. Why it Matters The cybersecurity experts her at Anchore believe that this is an important step toward defending against security incidents that use a software supply chain attack method – where an attacker infiltrates a software supplier ‘somewhere in the chain’ to either introduce or uncover an exploitable flaw, and then implements the attack against the end consumer of the software, who has deployed the compromised supplier software element in production. Presently, one area of weakness that can lead to a successful supply chain attack stems from the reality that there is often very little transparency between suppliers and consumers on exactly what software is included within a deliverable, and what software development/security practices are being performed by the supplier in the process of generating the deliverable. If this weakness were to be addressed between all participants of a given supply chain, it becomes possible for each organization to perform more comprehensive security checking and evaluation at each organizational boundary, increasing the overall security coverage of the supply chain. The foundational element that can be used for this purpose of sharing adequate information when delivering software between organization boundaries is the software bill of materials (SBOM). Understanding the SBOM An SBOM, referenced as such directly within the EO, is a document attached to a software deliverable that includes rich information about the software itself, and also importantly contains information about the software’s bundled dependencies. One thing the EO didn’t cover explicitly pertains to containers specifically, where an SBOM generated from a container image deliverable also contains additional information about the system packages inside the container itself, included in support of the application but not necessarily explicitly defined as a dependency of the application code, itself. Besides just software names and versions, each software element has important metadata that may become an SBOM requirement: The software origin/maintainers Commercial and/or open source licenses Digital signatures/hashes of executable software and/or data/configuration files Security vulnerability scanning tools and security engineering teams use SBOM data to: Perform vulnerability scans, matching SBOM elements against known/emerging software vulnerabilities Perform quality assurance checks using SBOM element versions to determine version status and other health characteristics Perform license compliance and conformance checks for OSS and commercial licenses (and combinations) for included SBOM elements  Next Steps for Integrating SBOMs into DevSecOps Pipelines Following the release of the EO, the federal government published minimum elements for an SBOM. Our recommendation is to take this time to consider where in your DevOps or DevSecOps pipelines you’ll be consuming SBOMs and using them for vulnerability, license, and compliance checks. In addition, this is the time to be considering the tools and processes that you need to put in place to produce SBOMs and how you’ll provide SBOMs to your compliance auditors and other consumers. Also important for any organization taking part in a supply chain are that some larger organizations today require suppliers to provide elements when defining contracts around software purchasing. For example, OSS licenses and the requirement for communicating security practices guidelines from supplier to consumers. We at Anchore believe it’s becoming more commonplace practice to transmit detailed information between all organizations within a given supply chain from small/medium/large OSS project maintainers and distribution vendors, to companies providing proprietary software. Bolstering software supply chain information quality requires all actors to participate, by taking these first necessary steps to integrate SBOM generation into existing development and publication practices.  FedRAMP Updates from the Executive Order 14028 Security Principles for Cloud Service Providers Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP) are increasingly providing secure platforms for the next generation of federal government applications. Case in point, federal government agencies spent $6.6 billion on cloud computing in fiscal 2020. That figure was up from $6.1 billion in fiscal 2019, according to a government spending analysis by Bloomberg Government, as reported by NextGov. Section 3 Modernizing Federal Government Cybersecurity, states: “The Secretary of Homeland Security acting through the Director of CISA, in consultation with the Administrator of General Services acting through the Federal Risk and Authorization Management Program (FedRAMP) within the General Services Administration, shall develop security principles governing Cloud Service Providers (CSPs) for incorporation into agency modernization efforts.” Federal Cloud Security Strategy in 90 Days The EO also positions FedRAMP — as part of the General Services Administration — as part of a task force to create a federal cloud security strategy in 90 days and then provide guidance to federal agencies. Here’s the quote from the EO: “Within 90 days of the date of this order, the Director of OMB, in consultation with the Secretary of Homeland Security acting through the Director of CISA, and the Administrator of General Services acting through FedRAMP, shall develop a Federal cloud-security strategy and provide guidance to agencies accordingly. Such guidance shall seek to ensure that risks to the FCEB from using cloud-based services are broadly understood and effectively addressed, and that FCEB Agencies move closer to Zero Trust Architecture” 90 Days to a Cloud Technical Reference Architecture With large government cloud initiatives such as the United States Air Force’s Platform One gaining mindshare, other parts of the Department of Defense (DoD) and civilian agencies are certain to follow suit with large scale secure cloud initiatives. The EO also mandates the creation of a cloud security technical reference architecture: “Within 90 days of the date of this order, the Secretary of Homeland Security acting through the Director of CISA, in consultation with the Director of OMB and the Administrator of General Services acting through FedRAMP, shall develop and issue, for the FCEB, cloud-security technical reference architecture documentation that illustrates recommended approaches to cloud migration and data protection for agency data collection and reporting.” Other Key Takeaways The EO mandates establishing a training program to provide agencies with training and the tools to manage FedRAMP requests. There’s no mention of training for the SI and government contractor community The EO mandates establishing a training program to provide agencies training and the tools to manage FedRAMP requests. There’s no mention for training for the SI and government contractor community Learn how Anchore helps automate FedRAMP vulnerability scans. ### DevSecOps: 6 Steps to Integrate Security Into DevOps A DevOps toolchain includes open-source and commercial tools to aid in the delivery, development, and management of applications through the software delivery process using DevOps practices. DevSecOps builds on top of your existing toolchain. If your organization is fast-forwarding straight to DevSecOps, think of it as a few more steps to securing your toolchain.  Moving to DevSecOps: The Key Challenges Moving to DevSecOps is becoming critical across industry and government to defend against new and emerging attack vectors. However, complexities, nuances, and challenges remain. Gartner’s "Integrating Security Into the DevSecOps Toolchain" report highlights some of the challenges enterprises face as they move to DevOps: DevOps adoption is increasing as an alternative to traditional waterfall and agile development methodologies, but security and compliance typically remain afterthoughts. DevOps practices encourage automation to achieve scale, but security has traditionally been manual, process-heavy and gate-driven — the antithesis of automation, transparency and speed. Most developers have no knowledge of secure coding, including those versed in agile and DevOps. Traditional application security testing approaches weren’t designed for speed and transparency. Users now demand new features and updates to all their applications, not just the ones they download from their mobile device’s app store. For some applications in specific industries, new versions need to be government re-certified after every production update, making rapid change an issue. Gartner cites the example of pharmaceutical manufacturers may need to have the FDA re-certify their production environment after certain kinds of software updates. DevSecOps Toolchain Transformation Here are some actions you can take to upgrade your DevOps toolchain into a DevSecOps toolchain: 1. Learn From Others in the DevOps and DevSecOps Communities One of the great joys of the DevOps and DevSecOps communities is the fact that practitioners will share their knowledge and experience with open source and commercial DevOps and DevSecOps tools. Look to the DevOps community to help close your critical knowledge gaps. Sites such as Opensource.com and DevOps.com cover a range of toolchain topics throughout the year. DevOps-related conferences are even easier to attend during the pandemic. All Day DevOps is an all-virtual conference that draws in a range of practitioners with coverage over many of the pressing toolchain challenges teams are facing right now. Local DevOps and DevSecOps meetups are another useful learning resource. 2. Start With Your Container Security The first step to building out the security of your DevOps toolchain starts with your container security. Here are two foundational elements of any DevSecOps container security strategy: Software bill of materials (SBOM) generator that generates a comprehensive bill of materials so you can track dependencies in your project or discover hidden files in somebody else’s project Vulnerability scanner to generate a list of known vulnerabilities quickly that exist within a container image or project directory There’s a natural split in container security shaping up in the market right now. On one side, you want a container security solution that works in your build environment. A security solution that you can run via automation when you create a build. Look for a container security solution that’s application programming interface (API) friendly with a vendor or open-source software (OSS) project that has a solid track record with API management. 3. Institute Continuous Compliance DevSecOps is a platform for continuous compliance to protect your software supply chains against vulnerable packages and vulnerable configurations. While you may have made some initial moves to dependency scanning, it will not help you (or your compliance) if your infrastructure policies leave your AWS S3 buckets wide open. Increasingly, container image scanning tools are doing double duty as compliance scanning to check for configuration issues during the development cycle before the non-compliant container enters production. Whether your team works on commercial or federal government projects, there are infrastructure security controls to follow, such as CIS Benchmarks or Secure Technical Implementation Guides (STIGs). When choosing an image scanning tool, look for one that offers security control profiles that compare profiles versus the controls in the compliance matrices your organization needs to comply with. 4. Double Down on Automation While you may have already been experimenting with automation during your DevOps phase, it only becomes more integral once you throw the switch in by going DevSecOps. Go into your DevOps to DevSecOps transformation with an automation strategy that focuses on automating common developer and sysadmin tasks. Here are some common automation steps to take: Automate orchestration for containers and virtualized environments.  Enhance application inventory by generating a software bill of materials (SBOM) automatically Automate cloud security features and controls that make sense Automate security tests that you can run in conjunction with automated regression testing tasks.  Taking these common automation steps will pay off in time savings, improved agility, and security improvements. 5. Improve Your Monitoring and Analytics Building out a DevSecOps toolchain takes your monitoring and analytics options to a new level. Consider the fact that you should already collect and publish data from your toolchain and deliver reports to your project managers, developers, QA testers, and stakeholders outside your team. Commonly, DevOps reporting is still a work in progress for organizations. Use the introduction of new security tools into your toolchain as a chance to offer more granular and real-time security reporting into all parts of your DevSecOps toolchain. 6. Implement Accessibility Assurance Depending on your organization’s definition of compliance, the option is there to add accessibility compliance or Section 508 to your DevSecOps toolchain. Accessibility compliance means your commercial application is universally inclusive of all users. Section 508 compliance is a requirement for all federal agency applications before they launch. Remediating accessibility issues in production can be costly for businesses. Federal agencies want to resolve their compliance issues in development to pass their 508 compliance check. Both scenarios benefit from continuous feedback on application changes you meet in production. While adding tools such as Pa11y and Google Lighthouse to your DevSecOps toolchain will not make your developers accessibility experts by any means but they will alert them if the application they’re building isn’t in compliance. While your accessibility experts are working on accessibility policy and law concerns, your developers can enter tickets into your project tracking software to alert them to issues that require further investigation and remediation. Final Thoughts Whether you’re starting with DevOps toolchains, the ones you already have in place and that your teams are already familiar with, or making the leap, there are security options you can integrate into most stages of your build process. Take what steps you can to ensure that your developers and security team collaborate during the build-out of security tools. It’s also a good time to get any input from your auditors about the tools and processes for impartial analysis, this important step in your DevSecOps journey. Lastly, don’t be afraid to iterate from the lessons you learn after turning on your additional security and compliance checks. ### SP 800-37 NIST Special Publication (SP) 800-37, titled “Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy” is commonly referred to by its acronym, the RMF. It is a tool for helping organizations implement a holistic approach to designing systems with security and privacy at their core. By utilizing the RMF, agencies can achieve compliance objectives, such as, a continuous Authority to Operate (cATO) or FedRAMP certification.  Anchore has developed secure software supply chain systems that have helped numerous agencies achieve these compliance objectives. Across these engagements, Anchore has developed significant expertise in how to meet the requirements of these frameworks in the least burdensome way. In this guide, we will break down the RMF to help explain its goals and show how Anchore can help meet these goals. What is NIST 800-37? NIST SP 800-37, aka the Risk Management Framework (RMF), is a methodology for building a risk management program. It isn’t a ready-made risk management program but a framework for designing a program that will custom fit a specific organization. By utilizing the framework an organization can create a highly effective information security and privacy practice. The RMF was developed by the Joint Task Force Transformation Initiative Working Group. It is specifically designed to modernize the security and privacy practices of federal agencies in response to the reality that the previous standards were falling behind. In a report by the Defense Science Board, there is a quote that drives this home, The cyber threat to U.S. critical infrastructure is outpacing efforts to reduce pervasive vulnerabilities, so that for the next decade at least the United States must lean significantly on deterrence to address the cyber threat posed by the most capable U.S. adversaries. It is clear that a more proactive and systematic approach to U.S. cyber deterrence is urgently needed… For most agencies or federal service integrators (FSIs) the most important takeaway from the RMF is that the framework will help you achieve compliance objectives faster and more efficiently than previous recommendations. NIST 800-37 Revisions NIST 800-37 has two revisions, with the first published in February 2010 and the other in December 2018. NIST 800-37 Rev 1 Summary NIST Special Publication 800-37 Revision 1, titled “Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach'' was published in 2010 with a minor update in 2014. It was meant as an evolution of a previous process called Certification and Accreditation (C&A). The 6-step Risk Management Framework (RMF) replaced the C&A process. To put this into context, the RMF was written when the majority of applications ran on mainframes in on-premise data centers and smart phones were two separate devices (a cell phone AND a PDA). The RMF was produced in order to achieve three key objectives: Modernize software security practices Improve monitoring processes Communicate key insights upwards in the organizational hierarchy If you’d like to read the entire revision in full, you can find it here. NIST 800-37 Rev 2 Summary NIST Special Publication 800-37 Revision 2 titled, Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy was published in 2018. The landscape had changed significantly since 2010 and more modern documents had been created to make recommendations on how to design secure systems. This revision was meant to align the RMF with newer frameworks like the NIST Cybersecurity Framework and NIST SP 800-160.  Two larger updates to the content of the RMF was additional guidance on how to deal with software supply chain security and privacy into the systems designed within the framework. In the time since the first draft was published, the software landscape has shifted dramatically. Open source software became huge during that time frame. As open source software grew, it became more economical for adversaries to focus their attention on breaching the software supply chain rather than an organization directly. Revision 2 of the RMF addresses this and lays out specific guidance on how to address this.  On top of this, the RMF created an entirely new section dedicated to not only how to make systems secure but also how to ensure that the security properties also guarantee privacy. The global awareness of how much data large technology companies retain on their users has gradually ticked upward and became an important enough issue that the RMF now addresses it separately from security concerns. Potentially the largest update to the RMF was the addition of one additional step in the framework. A preparatory step, aptly named, ‘PREPARE’ was added in order to help organizations know where to start when using the RMF to design a secure and private system. The purpose of these updates were to simplify RMF execution, allow for innovative approaches to risk management and increase the level of automation when carrying out specific tasks. If you’d like to read the entire revision in full, you can find it here. The 7 Steps of the Risk Management Framework (RMF) Prepare for RMF Execution: Set up a framework and establish priorities at both organizational and system levels to manage security and privacy risks. This includes understanding the context and setting clear goals. Categorize System and Information: Analyze the system and the data it processes, stores, and transmits, and categorize them based on the potential impact if a loss occurs. This will help understand what needs to be protected and how crucial it is. Select and Tailor Controls: Choose a preliminary set of security measures for the system and customize them as necessary to manage risk down to an acceptable level, based on a risk assessment. Implement Controls: Put the selected controls into action and document how they are used within the system and its operational environment. This ensures that everyone understands how and why specific security measures are being applied. Assess Controls: Evaluate the implemented controls to confirm they're set up correctly, functioning as intended, and achieving the desired outcomes in terms of meeting security and privacy needs. Authorize System or Controls: Approve the system or common controls for use based on a judgment that the remaining risk to the organization's operations and assets, as well as to individuals, other organizations, and the nation, is acceptable. Monitor System and Controls: Continually keep an eye on the system and its controls. This includes assessing how effective the controls are, documenting any changes to the system or its operating environment, conducting risk assessments and impact analyses, and reporting on the security and privacy status of the system. NIST 800-37 vs. NIST 800-53 NIST SP 800-37, or simply the RMF, is a framework for designing a risk management program. It is simplest to visualize via the graphic that accompanies it: Diagram of relationship between the 7 steps of the Risk Management Framework It is not meant to be a step-by-step guide on how to implement a system that has its risk fully managed. It is meant to be a program that guides agencies through the process of building their own risk management system. NIST 800-53, on the other hand, is essentially a spreadsheet of specific controls that will meet different requirements of the RMF. It doesn’t go so far as recommending specific software to meet the control but it is much more prescriptive than the RMF. Example of an RMF requirement Task A-3: Control Assessments Control assessments occur as early as practicable in the SDLC, preferably during the development phase. These types of assessments are referred to as developmental testing and evaluation, and validate that the controls are implemented correctly and are consistent with the established information security and privacy architectures. Developmental testing and evaluation activities include, for example, design and code reviews, regression testing, and application scanning. Deficiencies identified early in the SDLC can be resolved in a more cost-effective manner. This task is meant to identify the purpose behind the control but not make any specific recommendations on how to achieve it. They provide some examples but purposefully keep the discussion high-level. Example of NIST 800-53 control RA-05 Vulnerability Monitoring and Scanning: RA-05a.[01] Systems and hosted applications are monitored for vulnerabilities and when new vulnerabilities potentially affecting the system are identified and reported. This is an example of a specific control that requires agencies to have a system in place that monitors their internal systems, or if their applications are hosted by a third-party, for vulnerabilities. When vulnerabilities are uncovered they need to be reported. Manage & Automate NIST Compliance The RMF and the accompanying NIST 800-53 document are very comprehensive and at the same time extraordinarily intimidating. NIST 800-53 catalogs more than 1000 different controls. Understanding this framework and the accompanying controls as well as getting all of these correct is easily a full-time job. That's why automating the process with NIST compliance tools is so critical. As agencies are determining whether to accomplish meeting these technology compliances they have to make the decision whether to DIY the entire process or work with 3rd party vendors that are experts in the process. Anchore, in partnership with its many federal service integrator partners, has sheparded countless agencies through the process and provides a number of different features that not only make meeting controls simple but automate the continuous process of maintaining compliance in real-time. The Anchore Enterprise platform was specifically designed to address the software security supply chain management of federal agencies. The platform is an automated system that manages a comprehensive inventory of the entire software supply chain, automatically scans all software packages for vulnerabilities and compliance and utilizes pre-built policy packs to report and ensure compliance standards are met. If you’re interested to learn more about how Anchore can help your organization meet its compliance requirements, learn more by visiting our public sector page. ### Gartner’s 12 Things for DevSecOps By 2023, more than 70% of enterprise DevSecOps initiatives will have incorporated automated security vulnerability and configuration scanning for open-source components and commercial packages, which is a significant increase from fewer than 30% in 2019. Automated security vulnerability and configuration scanning are amongst the DevSecOps best practices that Gartner addresses in their 12 Things to Get Right for Successful DevSecOps with insightful analysis. This Gartner Report is a veritable DevSecOps guide that addresses the following topics: Adapt your security testing tools and processes to the developers Quit trying to eliminate every vulnerability during development Focus first on identifying and removing known open-source vulnerabilities Don’t expect to use traditional DAST/SAST without having to make changes Train developers on secure coding, but don’t expect them to be security experts Adopt a security champion model and implement a simple security requirements gathering tool Secure and apply operational discipline to automation scripts and infrastructure security posture Implement stronger version control on all code and components Apply secrets management Adopt an immutable infrastructure mindset Rethink how service delivery incidents are handled Use dynamic access provisioning for developers in DevSecOps Here are some notable highlights from the report: Focus First on Identifying and Removing Known Open Source Vulnerabilities Modern software is often assembled, not developed. Developers make heavy use of prebuilt components, libraries, containers and frameworks (such as Apache Struts and Swing) from publicly available sources and repositories (such as GitHub, SourceForge, Maven and Docker Hub). Custom code often represents a minority percentage of the code in a modern application. The increasing reliance on open source software (OSS) is driving changes to security scanning and large enterprises implementing pre-approved component libraries for reuse by DevOps teams across their organization. Gartner’s analysis cites that the actual code a developer writes is less than 10% of the final application. When you make such a shift to security scanning of component libraries for vulnerabilities known configuration issues you save time and preserve team productivity. Implement Strong Version Control on All Code and Components Being able to tell the difference between what code was used (versus what code is actually exercised in production) is essential. It becomes a way to harden the application in future iterations by removing unused components, or to lower the risk if these components are later found to be vulnerable, but aren’t actually used. Having mature source code version control throughout your DevSecOps lifecycle is a necessity as you work to increase your delivery velocity. Your enterprise needs to support version control using distributed version control systems (DVCS) and application lifecycle management (ALM) tools. Use Dynamic Access Provisioning for Developers in DevSecOps Although most DevOps infrastructure tools provide at least basic role-based access control (RBAC) — which should be leveraged as a minimum baseline control — the rapidly changing DevOps environment and blurring of functional borders can challenge static access controls. Because of this, consider the use of dynamic access provisioning, such as zero trust network access (ZTNA) control for developers. The recent Cybersecurity Executive Order and fallout from the SolarWinds and Codecov hacks are going to fundamentally change how enterprises secure their development tools and infrastructure. Chief Information Security Officers (CISOs) and security teams will be looking to zero trust to shore up their  security of their software supply chains, DevSecOps tool chains, and other development infrastructure. Adopt an Immutable Infrastructure Mindset For modern, microservices-based applications that are updated frequently, there is an operationally more secure way to maintain these applications. Where possible, no person should be allowed to make changes directly on production systems. The infrastructure is considered “immutable.” Using containers and microservices to improve software delivery velocity means you need to take extra steps to protect your production environment. When you make changes and updates to software, that work should now take place in your development environment, not in production. You can then deploy changes and updates from a secure repository into your development environment via automated tools in your DevOps toolchain. ### NIST SP 800-53 NIST Special Publication (SP) 800-53, titled "Security and Privacy Controls for Federal Information Systems and Organizations," is commonly referred to as the “Control Catalog”. This is because NIST 800-53 primarily provides guidelines for selecting and specifying security controls for organizations to protect their information and systems from a diverse set of threats including cyber attacks, natural disasters, privacy risks and human errors. It is the spiritual sibling to NIST 800-37, aka the Risk Management Framework (RMF); it provides the specific controls that organizations can utilize in order to fulfill the risk management program that is developed by following the RMF process.   What is NIST 800-53? NIST 800-53 is a security standard and compliance framework for all U.S. federal information systems and any enterprises that want to provide their cloud-hosted services to a federal agency that stores classified data. It is tied very closely to NIST 800-37, and both are normally considered together and not separately. It is published by the National Institute of Standards in Technology (NIST) as a catalog of specific security controls that organizations can use to evaluate their own implementation of security controls to assess compliance with the standard. It currently has 5 revisions.  This is an important standard for both federal agencies and any cloud service providers that want to do business with federal agencies. While compliance with NIST 800-53 is not directly equivalent to FedRAMP authorization, it did heavily influence FedRAMP requirements. If you are compliant with NIST 800-53, you are well on your way to FedRAMP compliance. NIST 800-53 is both comprehensive and general enough that it is a good foundation for not only federal compliance standards like FedRAMP and continuous authority to operate (cATO) but is highly transferable to health and commercial compliance standards like HIPAA and PCI DSS. Watch the NIST 800-53 Webinar Get the Webinar On-Demand NIST 800-53 Revisions: A Summary NIST 800-53 has five revisions to-date, with the most recent published in January 2022. We’ll provide an overview of each here, starting with the most recent revision:  NIST 800-53 Revision 5 NIST SP 800-53, titled "Security and Privacy Controls for Federal Information Systems and Organizations," is the 5th revision of the document and was published September 2020.  The largest changes made in this revision was the relocation of the catalog (i.e. spreadsheet) of controls to a separate document NIST SP 800-53B and the establishment of a supply chain risk management family of controls. This second major update is of particular importance since this is what Anchore specializes in and have been helping agencies accomplish for years. If you’d like to read the entire revision in full, you can find it here. NIST 800-53 Rev 4 NIST SP 800-53, titled the same as revision 5 "Security and Privacy Controls for Federal Information Systems and Organizations," is the 4th revision of the document and was published April 2013.  This revision was meant to address the substantial changes in the threat landscape since the previous revision that was published in 2009. Supply chain security was addressed in this revision, but it wasn’t broken out into its own distinct family of controls until revision 5.  The other major change to this revision was the incorporation of controls focused on privacy. This document was primarily intended as a document focused on security previously. If you’d like to read the entire revision in full, you can find it here. NIST 800-53 Revisions 1-3 NIST SP 800-53 revision 1-3 are all roughly the same document with minor updates between each. The final revision is titled, "Recommended Security Controls for Federal Information Systems and Organizations". Across the three revisions only the word “organizations” is added to the title. Revision 1 was published in December 2006, followed a year later by revision 2 in December 2007. The final revision was published in August 2009. Later revisions of NIST 800-53 (e.g. revision 4 & 5) update the document via a system of re-publishing the same revision with Errata for minor updates. The original three revisions updated the revision number even though the differences between the three can be thought of as iterative updates to the same general document. The purpose of this series of documents was to more clearly define the specific controls that would help organizations comply with the control families that were defined in Federal Information Processing Standards (FIPS) 199 and 200 which ultimately fulfill the mandate of the original Federal Information Security Management Act (FISMA) of 2002 law. NIST 800-53 Control Families: List & Descriptions NIST 800-53 contains 20 control families with a total of more than 1,000 individual controls. A control family is a group of related security controls. The term "control family" is used to organize the security controls in a manner that makes them easier to reference and manage. Each control family typically covers a particular aspect of information security, such as access control, incident response, or system and information integrity. Below is a list of each of the 20 control families as well as a short description:  Access Control (AC): Controls that limit access to information systems and the information they process and store based on the principle of least privilege. Access controls can be both technical (such as logins and passwords) and physical (such as locked doors). Awareness and Training (AT): Controls that aim to ensure that individuals within the organization are adequately trained and informed about security risks and their responsibilities towards mitigating those risks. Audit and Accountability (AU): Controls that record and examine activity in information systems to detect and respond to security incidents. Security Assessment and Authorization (CA): Controls that deal with the initial authorization to operate the system and ongoing monitoring of security controls. Configuration Management (CM): Controls that focus on establishing and maintaining the integrity of products and systems, through control of the processes for initializing, changing, and monitoring the configurations. Contingency Planning (CP): Controls that focus on planning for, responding to, and recovering from system or service interruptions. Identification and Authentication (IA): Controls that ensure the identity of an entity (a user or a system) is verified before access is granted. Incident Response (IR): Controls that establish the capability to respond to, manage, report, and learn from information system incidents. Maintenance (MA): Controls that involve the routine, periodic, or emergency maintenance of information systems, including any potential security impacts. Media Protection (MP): Controls that protect information in print or electronic format from unauthorized access, disclosure, alteration, and destruction. Physical and Environmental Protection (PE): Controls that provide measures to safeguard physical resources and support facilities of an information system. Planning (PL): Controls that involve system security plans, rules of behavior, and more to guide the implementation and operation of the information system. Personnel Security (PS): Controls that ensure trustworthiness and appropriate training for roles and responsibilities for individuals having access to the system. Risk Assessment (RA): Controls that guide the identification and assessment of risks to organizational operations, assets, or individuals. System and Services Acquisition (SA): Controls that address the life cycle of information systems, including system development, system integration, and outsourcing decisions. System and Communications Protection (SC): Controls that protect the integrity of transmissions and information flows in information systems. System and Information Integrity (SI): Controls that protect the integrity of information and information systems by protecting against malware, providing intrusion alerts, and ensuring information input and output integrity. Supply Chain Risk Management (SR): A control family added in Revision 5 that deals with reducing the risk that an adversary will exploit vulnerabilities in the system's supply chain. Program Management (PM): Controls that provide a strategic view of the organization's information security program. This family is not applicable to individual information systems. Privacy Control (PR): An additional control family introduced in Revision 5, reflecting the need for privacy considerations in systems that handle personally identifiable information. Example of a Control from NIST 800-53 Like we mentioned, there are more than 1,000 controls put forth by NIST 800-53. We won’t list them all, but we will highlight one to help turn these general ideas into more specific examples:  Let’s examine control SR-4(2) “Provenance | Track and Trace”. This control states an agency must: Establish and maintain unique identification of the following systems and critical system components for tracking through the supply chain. For software systems specifically this means that there must be a unique identification for each individual software component/framework/library that is used to build an application. The discussion uses the examples of labels or tags as a general method for achieving this control: Labels and tags can help provide better visibility into the provenance of a system or system component…[i]dentification methods are sufficient to support a forensic investigation after a supply chain compromise or event. The important point here is that the label or tag “support a forensic investigation after a supply chain compromise or event”. This can be implemented in many different ways but the open source software security industry has quickly come to the consensus that Software Bill of Materials (SBOMs) are the preferred method for satisfying this control. SBOMs allow agencies to reliably produce unique identifiers with accompanying metadata that allow for forensic analysis in the event of a supply chain compromise.  Anchore Enterprise was purpose built with this control in mind, helping agencies streamline their SBOM management. Organizations are able to complete remediation activities within hours rather than the industry standard of days. As mentioned above, there are more than 1,000 different controls. Attempting to accurately apply all of these controls is easily a full-time job and likely a multi-year project. View the full Control Catalog spreadsheet from NIST here.  NIST 800-53 Compliance Checklist You can find many NIST 800-53 compliance checklists with a quick Google Search but all of these checklists are more like cliff notes than actual checklists. This is primarily because the one-two combo of the Risk Management Framework (NIST 800-37) and the Control Catalog (NIST 800-53) are straightforward guides to achieving compliance to both standards. Take a look at the 7 primary sections of the RMF below: Prepare for RMF Execution Categorize System and Information Select and Tailor Controls Implement Controls Assess Controls Authorize System or Controls Monitor System and Controls If those titles read like a checklist for how to reach NIST 800-37/53 compliance it's because they were designed as a checklist to reach NIST 800-37/53 compliance. If you’re interested in understanding the RMF in more detail, we have written a guide to the NIST SP 800-37, the Risk Management Framework in plain english on our website. NIST 800-53 vs. Other Security Standards With so many security standards published by various groups and government organizations around the world, we’re outlining how NIST 800-53 stacks up. NIST 800-53 vs. NIST 800-171 The primary difference between NIST SP 800-171 and 800-53 is the number of control families, the number of controls, and the target audience of the standards. NIST 800-53 20 control families 1000+ controls Applies to federal agencies and FedRAMP-compliant Cloud Service Providers (CSPs) NIST 800-171  14 (soon to be 17) control families 110 controls Applies to any non-federal agency that handles CUI The security requirements in NIST 800-171 are derived from the moderate control baseline of NIST 800-53 which makes NIST 800-171 a subset of NIST 800-53 with some modifications applied to the individual controls that effectively makes them easier to achieve. The reason for this is because these organizations only handle Controlled Unclassified Information (CUI) which is not classified but still considered sensitive or private. You can think of CUI as Personally Identifiable Information (PII) with some additions like proprietary business information, law enforcement information or information that could affect national security. The control families that have been removed from NIST 800-171 are: Contingency Planning (CP) Program Management (PM) Privacy Control (PR) NIST 800-53 vs. ISO 27001 ISO 27001 is an international standard on how to manage information security. It is very similar in scope to NIST 800-53 but its scope is for any global organization rather than being US-centric. Published by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC), the standard is formally known as "ISO/IEC 27001:2013 – Information technology – Security techniques – Information security management systems – Requirements" ISO 27001 is more similar to NIST 800-37, the RMF, in that it is a framework and high-level guidance for managing information security in an organization. The detailed controls are laid out in ISO/IEC 27002 which accomplishes roughly the same objective as NIST 800-53. Manage & Automate NIST Compliance The RMF (NIST 800-37) and the Control Catalog (NIST 800-53) are very comprehensive and extraordinarily intimidating. As agencies are determining whether to accomplish meeting these compliance standards, they have to decide whether to DIY the entire process or work with 3rd party vendors that are experts in the process. Anchore, in partnership with its many federal service integrator (FSI) partners, has sheparded countless agencies through this process with its NIST compliance solutions. Anchore provides a number of different features that not only make meeting controls simple but automate the continuous process of maintaining compliance in real-time. The Anchore Enterprise platform was specifically designed to address the software security supply chain management of federal agencies. The platform is an automated system that manages a comprehensive inventory of the entire software supply chain, automatically scans all software packages for vulnerabilities and compliance and utilizes pre-built policy packs to report and ensure compliance standards are met. If you’re interested to learn more about how Anchore can help your organization meet its compliance requirements, learn more by visiting our public sector page. ### SBOM Formats, Standards & Requirements Today’s software is complex. Each modern software application typically includes a large number of open source and commercial components coming from a wide range of sources. According to the 2024 Open Source Security and Risk Analysis report, on average, 97% of codebases contain open source. That’s where an SBOM, or software bill of materials, comes in. For those new to this topic, be sure to learn the basics of SBOMs and their role in cybersecurity first. Put simply, however, an SBOM is a structured list of components, modules, and libraries that are included in a given piece of software. Think of them like a list of ingredients that evolves throughout the software development lifecycle as you add new code or components.  To ensure the security of the software you create, it is imperative that you maintain a comprehensive list of the components in each release of a software application in order to identify vulnerable and outdated code. You can also use an SBOM to monitor the security of each application post-deployment by identifying the potential impact of new security vulnerabilities on your user-facing applications. Explore how Google leveraged 100M+ SBOMs to protect their software supply chain. Register Now Are SBOMs Required? As of April 2025, SBOMs are not universally required in the U.S. or the EU. However, they are required in specific cases in the U.S. per Executive Order 14028 and they will be required for all digital products sold in the EU as of December 2027. In the U.S., the Executive Order to Improve the Nationa's Cybersecurity (2021) directs federal agencies to "publish minimum SBOM standards" and define criteria regarding "providing a purchaser a software bill of materials (SBOM) directly or publishing to a public website." This means all software suppliers that sell to U.S. federal government agencies need to provide SBOMs for the software they deliver. Since the EO's initial publication, these standards have had a ripple effect as companies in other industries began to mirror the federal requirements in their own software procurement efforts. In the EU, SBOMs were introduced as a mandatory requirement under the 2024 Cybersecurity Resilience Act (EU CRA). The act requires manufacturers selling hardware and software products with digital elements in the EU to create and maintain a Software Bill of Materials (SBOM) in machine-readable format. The requirement will go into effect as of December 2027. What is an SBOM Standard?  To facilitate this widespread adoption of SBOMs, several SBOM formats have been developed to provide a unified structure for both generating SBOMs internally and sharing them upstream with end-users and customers. An SBOM standard is a schema designed to provide a common format for describing the composition of software in a structured way that is consumable by other tools, such as vulnerability scanners. CycloneDX and Software Product Data Exchange (SPDX) are the most commonly used standards. Common SBOM Standards and Formats CycloneDX CycloneDX is a lightweight, machine-readable SBOM standard useful for application security contexts and supply chain component analysis. CycloneDX is an open source project that originated in the OWASP community and is guided by a Core Team that provides strategic direction and maintenance of the standard. The full CycloneDX specification is available online at GitHub or the CycloneDX site. SPDX The Software Package Data Exchange (SPDX) is a machine-readable international open standard (ISO/IEC 5962:2021) format for communicating the components, licenses, and copyrights associated with a software package. The SPDX standard is developed by a grassroots open source project hosted by the Linux Foundation. It draws representatives from vendors, foundations, and system integrators. A tech team and legal team do the work behind the project. SPDX holds a scheduled monthly status call about their progress. The full SPDX specification and archives are available on the SPDX site. There’s also an SPDX GitHub repo available. Other SBOM Formats SWID tags (short for Software Identification tags) were previously considered a third standard, primarily used by the U.S. federal government. Introduced in 2009 as an XML-based format, SWID tags have since lost traction and are rarely used in comparison to SPDX and CycloneDX. Choosing an SBOM format: SPDX vs CycloneDX  There are many opinions on which format – SPDX or CycloneDX – is the best format for specific use cases. Some years ago, there were arguments for using one format if your focus was open source dependencies, or the other if your focus was licensing.  Recently, we have seen the industry move away from specific focuses for SBOM and converge on SBOM formats containing complete and accurate dependency and license details. The two formats differ in how they are constructed, but the data contained within them is functionally the same for many SBOM use cases. For example, at Anchore we support both SPDX and CycloneDX because there is equally strong demand for the two formats. SBOM Quality and Minimum Elements There is a definition of the minimum elements that should be included in an SBOM. Below is a table with the minimum data fields and descriptions: NameDescriptionSupplier NameThe name of the authoritative owner of the application or software componentComponent NameHuman readable name of the softwareComponent VersionUnique version identifier to differentiate versions of the same componentUnique IdentifierGlobally unique identifier to allow lookup of component in a database (e.g.,  Common Platform Enumeration (CPE), Software Identification (SWID) tags, or Package Uniform Resource Locators (PURL))Dependency RelationshipThe relationship between the application and its dependenciesSBOM AuthorThe name of the entity that created the SBOM (sometimes the supplier and sometimes a 3rd-party)TimestampDate and time when SBOM was generated The NTIA's SBOM minimum elements document is long and is several years old now. The world of SBOMs has changed dramatically in recent years, and like any technology, the more use it gets, the more it changes to solve real problems. Rather than speaking of minimum elements, the conversation can switch to SBOM quality, but without an adequate definition of quality. The SPDX and CycloneDX standards are working to ensure future versions of the standards define minimum expectations in a way that ensures every SBOM created has the data needed to be useful to the recipient.If you are the recipient of an SBOM today, there isn’t an easy way to verify if the document contains the data you need to conduct analysis. By using an SBOM management solution, it is possible to ingest the documents then view the results to understand if the data needed exists. If it does not, changes can be requested from the supplier of the SBOM to ensure the SBOM received is correct. SBOM Examples to Help You Get Started There are a number of ways to create an SBOM, from manually creating the document to running a scanner. An SBOM scanner or generator is a tool that analyzes software packages to identify and document all the open-source and proprietary components, libraries, and dependencies used. The scanner route is much easier than trying to construct a properly formed SBOM by hand. A scanner also gives you the ability to output both SPDX and CycloneDX formats and conduct deep inspections of your software. To help you get started, we will use the Syft open source SBOM generator. Syft is very easy to use and can output both SPDX and CycloneDX formats. SBOM Example in SPDX Format Syft supports SPDX Tag-Value (spdx-tag-value) and SPDX JSON (spdx-json). For SPDX JSON, simply add the -o spdx-json argument. For example, run: syft alpine:latest -o spdx-json You’ll see there is a lot more data than the table view allows! You should see something resembling: { "spdxVersion": "SPDX-2.3", "dataLicense": "CC0-1.0", "SPDXID": "SPDXRef-DOCUMENT", "name": "alpine", "...": "...", "creationInfo": { "licenseListVersion": "3.25", "creators": [ "Organization: Anchore, Inc", "Tool: syft-1.19.0" ], "created": "2025-01-27T15:29:58Z" }, "packages": [ { "name": "alpine-baselayout", "SPDXID": "SPDXRef-Package-apk-alpine-baselayout-421bc6506abee7e4", "versionInfo": "3.6.8-r1", "supplier": "Person: Natanael Copa (ncopa@alpinelinux.org)", "...": "...", "sourceInfo": "acquired package info from APK DB: /lib/apk/db/installed", "licenseConcluded": "NOASSERTION", "licenseDeclared": "GPL-2.0-only", "copyrightText": "NOASSERTION", "description": "Alpine base dir structure and init scripts", "externalRefs": [ { "referenceCategory": "SECURITY", "referenceType": "cpe23Type", "referenceLocator": "cpe:2.3:a:alpine-baselayout:alpine-baselayout:3.6.8-r1:*:*:*:*:*:*:*" }, { "referenceCategory": "PACKAGE-MANAGER", "referenceType": "purl", "referenceLocator": "pkg:apk/alpine/alpine-baselayout@3.6.8-r1?arch=aarch64&distro=alpine-3.21.2" } ] }, ] } Not only does this format contain the package names, but also Package URLs, license information, and a host of additional metadata, such as, the location of associated files Syft identified within the package. SBOM Example in CycloneDX Format Similarly, if you need to generate an SBOM in CycloneDX format, use a CycloneDX format option. Syft supports CycloneDX XML (cyclonedx-xml) and JSON (cyclonedx-json). For CycloneDX XML: syft -o cyclonedx-xml To run this against the same latest Alpine image, run: syft alpine:latest -o cyclonedx-xml And you should see a result resembling this: 2025-01-27T10:49:00-05:00 anchore syft 1.19.0 alpine sha256:47badde288cf303fe43766ba3c0be01df313b84ad91480c1f21b7e907a7f2337 Natanael Copa alpine-baselayout 3.6.8-r1 Alpine base dir structure and init scripts GPL-2.0-only cpe:2.3:a:alpine-baselayout:alpine-baselayout:3.6.8-r1:*:*:*:*:*:*:* pkg:apk/alpine/alpine-baselayout@3.6.8-r1?arch=aarch64&distro=alpine-3.21.2 https://git.alpinelinux.org/cgit/aports/tree/main/alpine-baselayout apk-db-cataloger apk apk-db-entry cpe:2.3:a:alpine-baselayout:alpine_baselayout:3.6.8-r1:*:*:*:*:*:*:* ... ... There is a lot of additional information in the SBOM, but this example shows how easy it can be to generate an SBOM and what the output will look like. See the whole process for Generating an SBOM with Free Open Source Tools. What’s next: Generating and Managing SBOMs at Scale As SBOMs rapidly gain acceptance, industry leaders have begun to develop approaches for creating, managing, and using SBOMs. While individual development or application teams may store SBOMs in a repository alongside their code artifacts, security teams must maintain a centralized repository of SBOMs across all applications and development teams. When new vulnerabilities or security incidents arise, security teams and CISOs need the ability to quickly query the SBOMs of all of their software and instantly assess the impact instead of frantically scrambling to get individual assessments from each development team or having to waste valuable time finding and rescanning all of their applications from scratch. In addition, meeting regulatory requirements or compliance standards requires a centralized repository for reporting and other compliance activities. Anchore Enterprise makes it easy for teams to manage SBOMs for increased security and quicker incident response. The platform provides a comprehensive set of SBOM management capabilities that enable teams to collect, store, analyze, automate, and use SBOMs across the application and software development lifecycles.  Over the course of just a few short years, we have seen the role of SBOMs transition from a “nice to have” to a “need to have” for both development and security teams who have been forced to recognize in a post-Solarwinds world that the software they build is part of a bigger chain that goes beyond the confines of their containers. The use of SBOMs will continue to expand and become the foundational element in securing and managing software supply chains. Automate your SBOM management with Anchore Enterprise. Get instant access with a 15-day free trial. START FREE TRIAL ### DevSecOps Best Practices DevSecOps is a modernized agile methodology that combines the efforts of development, operation and security teams. When working together to integrate security into every step of the development process, teams can deliver applications safely, at a massive scale. 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. When you get down to the core of it, DevSecOps is built for agility and velocity.  Risk mitigation around software supply chains is going through an awakening post-SolarWinds. DevSecOps helps mitigate a range of significant security risks in application development and highlights that you must do the best you can as a security organization. Put in the right tools. Institute best practices. Train your developers and security teams in best practices. Incentivize your vendors to follow suit.   While the process of shifting to DevSecOps can be a complex one, often involving several teams and many stakeholders, executing on a few quick wins and tracking your progress along the way is critical. That’s where our DevSecOps best practices checklist comes in. We’ve broken these best practices out into three categories to make the transition a little easier for you and your team: quick wins, process improvements, and culture shifts.  What is DevSecOps? DevSecOps requires sharing the responsibility of security across development and operations teams. It involved empowering development, DevOps, and IT personnel with security information and tools to identify and eliminate threats as early as possible. DevSecOps best practices Quick win best practices Digital transformation of enterprises and public sector organizations around the world has accelerated in recent years. However, digital transformation brings with it new digital assets such as applications, websites, and databases, and this increases an enterprise’s attack surface. To prevent costly breaches, protect reputation, and maintain customer relationships, organizations need to implement a DevSecOps security approach that is built on industry-proven best practices. Here are three quick win best practices that organizations can use as a start when implementing DevSecOps: Sanitize Sensitive Data: There are several open source tools that can detect personally identifiable information (PII), secrets, access keys, etc. Run a simple check for sensitive data, because a leaked credential in a GitHub repository could mean big trouble for your data and infrastructure. Utilize IDE Extensions: Developers use integrated development environments (IDE) and text editors to create and modify code. Utilizing IDE extensions to identify vulnerabilities and security flaws as developers are writing code is an easy way to catch security issues early on. It also serves as a way to educate developers on good coding practices.  Integrate Security into CI/CD: There are many open source Continuous Integration/Continuous Delivery (CI/CD) tools available such as Jenkins, GitLab CI, Argo, etc. Your team can integrate one or more security solutions into their current and future CI/CD pipelines. A good solution would include alerts and events that allow developers to resolve the security issue before pushing anything into production. Process best practices Now is the time to review the security of your DevSecOps pipeline to ensure that the tools and workflow powering your software development are secure from attacks. Here are some key tips to consider as you evaluate your approach to integrating security at each stage of the development lifecycle: Analyze Front End Code: Cybercriminals love to target front-end code due to its high number of reported vulnerabilities and security issues. Use CI/CD pipelines to detect security flaws early and share that information with developers so they can fix the issue. Leverage Automation: It’s always a good idea to make sure that attackers haven’t injected any malicious code into software containers, especially since container security is critical for a safe software supply chain. With Anchore Enterprise, teams can automate how to identify and remediate container security risks and monitor post-deployment for new vulnerabilities. Go Cloud Native: As mentioned above, containers can be a great way to ensure immutability. Paired with a powerful orchestration tool, such as Kubernetes, containers can completely transform the way you run distributed applications. There are many benefits to “going cloud-native,” and several ways enterprises can protect their data and infrastructure by securing their cloud-native applications Implement Pre-Commit Hooks: Exposing secrets such as application programming interface (API) keys, database credentials, service tokens, and private keys to source code repositories occurs more frequently than you might think and can be costly for organizations. In 2019, security researchers discovered over 200,000 unique secrets on GitHub. Integrating pre-commit tools in code repositories can prevent your secrets from being pushed inadvertently. Utilize Secrets Management: Ensuring that sensitive information is protected is no small task. This is where secrets management comes into play. Every organization should have a set of tools and processes to protect passwords, API keys, SSH keys, and other secrets. Besides providing a secure method for storing secrets, secrets management can also facilitate other best practices such as auditing, role-based access control, and lifecycle management. Role-Based Access Controls: Modern environments have robust access control systems. Individuals should only have access to areas they need to accomplish their tasks rather than giving them access to everything. By assigning appropriate roles for development and operations the attack surface can be reduced. Culture best practices The cultural changes that DevSecOps brings to software development can almost be more important than the tooling because it brings security concerns into the development lifecycle versus making security the last stop (and the last night) before applications hit production.  Here are four culture best practices to consider for your organization, when building internal teams and working with vendors as part of the DevSecOps journey: Share Information: Transparency yields trust with sharing between the DevOps and security teams inside enterprises. Transparency along the software supply chain builds trust. Be Clear on Measurement: Shared metrics with DevOps and security teams cooperating on shared goals will help achieve compliance and security. It only works if you have clear lines of communication to set realistic expectations. Build Trust: When you build trust internally and with your vendor teams along your software supply chain, it becomes easier to share information and collaborate on security and operational challenges.  Create a Safe Environment: You also want to create an environment where your team, not to mention vendors, can feel safe asking questions and bringing up technology and business issues. Benefits of implementing DevSecOps best practices From government agencies to fast food chains, DevSecOps has enabled organizations to quickly and securely transform their services and assets. For example, the U.S. Department of Defense Enterprise DevSecOps Services Team has changed the average amount of time it takes for software to become approved for military use to days instead of years. For the first time ever, that same team managed to update the software on a spy plane that was in flight, now that is one impressive example that underscores the benefit of DevSecOps collaboration. On the commercial side of things, we witnessed firsthand how the pandemic forced many businesses to adopt new ways of doing things, especially in the food industry. For example, with restaurant seating shut down during the pandemic, Chick-fil-A had to rely heavily on its drive-thru, curbside, and delivery services. Where do those services begin? Software applications! Chick-fil-A uses GitOps, Kubernetes, and AWS and controls large amounts of sensitive data for all of its customers, making it critical that Chick-fil-A implements DevSecOps instead of just DevOps. Imagine if your favorite fast food chain was hacked and your data was stolen - that would be extremely detrimental to business.  Learn about how Anchore helped the U.S. Department of Defense with its DevSecOps pipeline here.  Measuring the impact Whether your company builds web apps or deploys mission-critical software on jets, you should be thinking about ways to minimize your attack surface and measure how much DevSecOps moves the needle for your organization. Here are three ways to measure the impact of DevSecOps in your organization: Implement Threat Modeling: Threat Modeling not only helps security teams define security requirements and assess underlying risks associated with new and existing applications; it fosters ongoing communication between security and development teams. Integrating threat modeling tools in the development lifecycle promotes collaboration between each team on the system architecture and provides a consistent method for tracking key information. Microsoft’s Threat Modeling Tool and OWASP’s Threat Dragon are popular open source tools used in DevSecOps pipelines to conduct threat modeling. Launch End-to-end Traceability: Use your organization’s goals and metrics as a driver to improve security and development tools reporting across your pipelines. This will help your team deliver additional data to management and stakeholders about project progress through your pipelines.  Standardize Security Reporting: Be proactive and work with stakeholders to understand what reporting requirements are for their management. Update your security reporting to reflect your traditional endpoints and network perimeter. Give your team the most accurate picture using data on the current state of software development and security over your projects. Streamline your transition and DevSecOps processes with Anchore 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 Anchore Enterprise platform is a frictionless DevSecOps automation tool. With deep image inspection and vulnerability scanning across all layers, your team can shift security left with our API-first DevSecOps solution for cloud-native development.  From source code to application deployment, the Anchore Enterprise platform protects your organization at every step of the way. Learn more about our DevSecOps solution here.  ### Software Supply Chain Security Best Practices Software supply chain attacks strike at the most vulnerable segment of software, the build process. It’s where software vendors, system integrators, or internal developers bring together contributions and integrations from multiple sources. A typical list of software supply chain providers includes open source software (OSS) projects, subcontractors, and third-party software vendor partners. The shift to cloud-native applications has only exacerbated this issue as the use of containers has exploded. By using containers, developers can leverage software components from outside their organization more easily, speeding development but increasing the level of risk and the due diligence required to ensure secure and compliant software. Organizations must enhance their development processes to deliver the highest levels of security for their cloud-native applications. The compromise of the SolarWinds attack and the Log4j vulnerability sent shock waves through business and government as everyone scrambled to secure their software supply chains. No organization can afford to sit still as we increasingly depend on software supply chains to support the development of cloud-native applications that serve their internal and external customers. The technical and operational complexity of a software supply chain takes security risk management to a new level. The supply chain owner’s DevSecOps teams need to work with their business and technology stakeholders to improve internal processes while also extending collaboration, communications, and security best practices out to their supply chain partners. For those looking for a complete deep dive into the topic, get a complete guide to software supply chain security here. One thing that is evident, software supply chain attacks will remain a mounting concern for business and government agencies for the foreseeable future. There are actions you can take as a software supply chain participant to improve your security infrastructure, collaboration, communication, and processes and reduce risks for your organization and its customers. The time to start implementing the best practices outlined below is now, as there is no way to know when the next Log4j worm might appear. Fast Fact: What is software supply chain security? A software supply chain is all of the individual software components that make up a software application. Software supply chain security, then, is the process of finding and mitigating  security weaknesses that exist from impacting the software applications that utilize the vulnerable components.  Learn more with Anchore’s complete overview of software supply chain security.  Biggest security threats to the software supply chain The extensive use of the Log4j vulnerability and the severity of the exploit was a serious wake-up call for many security professionals and development teams around the world. Getting immediate visibility into your software supply chain risk is imperative and the fastest way to get started.  As we get ready for the long haul, be sure to prepare for the next inevitable critical issue that surfaces. Anchore Enterprise can get you ready for a quick and full assessment of a vulnerability impact, immediate controls to prevent vulnerable software application versions from moving further toward production, and streamlined remediation processes. Here are three of the biggest security threats to be aware of today. Development toolchains Cloud-native applications are constructed using a number of software development tools, from source code management (SCM) to continuous integration and delivery (CI/CD) tools to container repositories. These tools may be SaaS applications or run internally, but in either case, these toolchains must be secured in order to prevent internal or external actors from attacking the development toolchain and ultimately compromising the software that is being produced. We tend to emphasize our open source dependencies, but those dependencies and the software we write ourselves are subject to our development toolchain. Secure dependencies are meaningless if they are running through an insecure toolchain. Insider threats Your internal systems such as your CI/CD toolchains also face compromise by insider threats that can run the range from an employee or contractor making a mistake such as a misconfiguration that opens up your supply chain to attack to a disaffected employee or contractor can also attack the supply chain using their accounts and credentials to bypass external security measures. Such attacks can affect your organization’s managed infrastructure, your SaaS applications, and even your cloud services provider (CSP). Monitor software behavior Software updates can introduce risk, especially since service desks have been advised on best practices for software updates since the dawn of IT. One piece of advice dictates that IT teams should update software to the latest version and only install signed versions of updates, patches, and software that can counter such an attack. However, in the case of SolarWinds, customers received software that was signed, but compromised. In following this best practice, you just did just what the attacker wanted by installing the compromised software on your systems. There’s also the best practice of monitoring software behavior. Unfortunately, as the SolarWinds supply chain compromise shows, the attackers were stealthy and patient so that they could wreak damage on SolarWinds customers before the discovery of the compromise by an external security vendor. The importance of best practices in securing the software supply chain We’ve become too accustomed to the news of data breaches in our news alerts, headlines, and evening news. People outside of the technology industry are even dulling to the “breach of the week” news. While industry and government cybersecurity teams face a new onslaught of attacks every day, a software supply chain attack takes emerging threats to the next level. Conventional cybersecurity strategies can’t counter an attack against an organization’s software supply chain. According to the Anchore 2022 Software Supply Chain Security Report, supply chain attacks impacted 62% of organizations. Such widespread attacks like SolarWinds, MIMECAST, and HAFNIUM as well as the more 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. There’s no one solution for reducing risk, especially supply chain risk. Every organization, product, and team has its own development methodologies. All of the best practices noted below must be customized to every environment. Just as we customize our development process we must customize our supply chain risk management. This underscores the importance of understanding your software supply chain security and implementing best practices where and when possible. 6 software supply chain security best practices For the software supply chain owner, here are six best practices that can be implemented as potential next steps for you to improve your organization’s supply chain security. Want to automate software supply chain security? Consider adopting Anchore's software supply chain security solutions. 1. Improve relationships and collaboration There’s a human angle to supply chain security that’s often ignored. Relationships with your developers, supply chain partners, and even customers are integral to building trust, collaboration, and communications. Put tools and processes in place that enable your DevSecOps team to collaborate with all involved parties. Options include a federated collaboration solution that enables you to communicate and collaborate with your vendors in real time. It’s also important to share threat intelligence and best practices amongst your supply chain participants. Pro tip from Josh Bressers, VP of Security with Anchore:The relationships between security and development have been historically underrated, but the relationships we build are one of the most important aspects of security. A development team that doesn’t trust the security team creates slowdowns and friction for the entire DevSecOps process. 2. Improve governance of software onboarding A major challenge in the software supply chain is that it’s nearly impossible to have any practical visibility or control over your third-party software vendors’ security and compliance practices or other partners in your supply chain. This is even more complicated when open source software is used. It’s imperative to have an onboarding process for software components or applications that includes collaboration, communication, and security best practices. Asking suppliers questions about their security program works with a commercial relationship, but it doesn’t with open source. Make sure however supply chain components are incorporated, a realistic vetting process exists.  Pro tip from Daniel Nurmi, CTO with Anchore:Whether your third-party software is coming from vendors who provide security reports, or from OSS projects, instituting a ‘trust but verify’ approach is good practice.  There are a wealth of tools and technologies available that provide us with a way to scan a given piece of software for security flaws, that should be added to your evaluation process during functional assessment. Pro tip from Zach Hill, Chief Architect with Anchore:The security posture of the components that comprise your supply chain is ever evolving. Initial onboarding and evaluation processes and tooling should be repeatable as well as continuous so you can update your assessments regularly and consistently for both new components and changes to existing components. 3. Harden your build environment The DevOps and DevSecOps communities are paying more attention to hardening their DevOps toolchains against external attacks. The Linux Foundation recommends hardening of build environments using tools such as Supply-chain Levels for Software Artifacts, or SLSA ("salsa"). It’s now time for supply chain owners to extend this discussion to the entire software supply chain.  Treat all build systems up and down your software supply chain as the critical systems that they are. Apply the same or higher security requirements to your build systems as your production system. While the Linux Foundation admits it’s not clear if such a step would’ve made a difference in the SolarWinds compromise specifically, omitting this step opens the door for malicious actors to achieve the same outcome by infiltrating your build system. Pro tip from Daniel Nurmi, CTO with Anchore:Attackers are always looking for the weakest / least-monitored / lowest-energy aspect of any system as an entry point for applying their influence.  Systems that have historically been considered ‘internal’ (like build pipelines, pre-GA publication registries, etc) have become targets because of these reasons, but now need to be put into the same operational category as runtime production systems from a security perspective. 4. Require an SBOM for all partners and vendors The software bill of materials (SBOM) plays a key role in defending software supply chains. Look for SBOMs to become a requirement at contract signing time for firms of all sizes aiming to join the software supply chain of a large enterprise. The SBOM by itself isn’t the end of the story, it’s the beginning. An SBOM can provide critical data that is needed to assist with your security efforts in the future. Software supply chain owners can use the SBOM provided by their supply chain partners to conduct their own vulnerability analysis and to gain a view into their risk as new threats emerge. Pro tip from Daniel Nurmi, CTO with Anchore:Most security technologies start with ‘data’ or some kind, in order to provide their value, but historically have their own bespoke methods for gathering just the data they need.  Instituting an SBOM management program brings a valuable foundation of data to your organization, which can serve as the basis for a variety of emerging security, compliance, and insight tooling that can be made part of your organization’s standard practices.  5. Implement defense in depth Defense in depth (DiD) is a security design concept where multiple security control layers are placed throughout a complex IT system. Defense in depth provides redundancy through multiple layers of security so that you are still protected in the event of a security controls failure or an attacker exploits a vulnerability. For example, if you check your source code, your container image, and your running container for vulnerabilities, you’re going to get the same report from all three checks. But if an attacker exploits just one of those software development artifacts or activities, you can miss it without a multi-layered approach. However, when you have multiple security controls with overlapping functionality at different levels or with a software supply chain at stages, you’re resilient if one of them suffers a malfunction, exploit, or compromise. Pro tip from Josh Bressers, VP of Security with Anchore:Defense in depth means there is no one solution to reducing supply chain risk. We need to look broadly across the entire process and look for those places we can add the most value while also being the least disruptive. 6. Apply a zero trust policy Originating in network security, Zero Trust is the concept that organizations shouldn’t trust anything inside or outside their networks, and instead should verify all systems before allowing access. Such principles are also applicable to the larger security issues that the software supply chain poses. Both public and private sector cybersecurity experts are identifying the need to apply zero trust principles to software supply chain security. Pro tip from Zach Hill, Chief Architect with Anchore:One of the lines between the “inside” and “outside” of a supply chain is often the approval process to introduce a new component from a 3rd party. Applying zero trust principles to that process means continuously reviewing all components in your supply chain as if each update were a new approval with the same rigor and attention as the first. Automation is critical to success in achieving such a continuous process and will enable all your components to evolve with less friction. ### Software Supply Chain Security Prevent software supply chain attacks with Anchore Anchore’s end-to-end, SBOM-powered software supply chain security management platform protects you and your customers at every step, from SBOM monitoring to policy enforcement to remediation. Anchore integrates at every stage of the software development process from source code to build to runtime. Every package, every library, every version is cataloged and stored.  This enables organizations to find out where content is, where it came from, and how it changed. Anchore’s policy engine ensures you can automate checks to detect and prevent malicious content at every step in your pipeline and ensure only the most trusted content is released to downstream users. With its flexible APIs, Anchore integrates with your existing platforms and tools to ensure that it starts delivering value without major changes to how you build and run software. End-to-end SBOM coverage Comprehensive, end-to-end SBOM management reduces risk and increases transparency in software supply chains. Anchore automatically generates and analyzes comprehensive SBOMs at each step of the development lifecycle. SBOMs are stored in a repository to provide visibility into components, dependencies, and continuous vulnerability monitoring. Enforce provenance controls Flexible policy rules ensure only approved content is allowed into your software pipeline. Create strict rules for production that only allow use of internal builds but allow developers to experiment with new open source libraries.  Use Anchore Enterprise to better understand which vendors you are using in your applications. Prevent content drift Detect SBOM drift in the build process to uncover unexpected dependencies, malicious efforts to infiltrate builds, and inadvertent errors. Alert security staff to changes in SBOMs so they can be assessed for risks or malicious activity. See a tutorial of Anchore Enterprise here.  Start Free Trial How Anchore helps secure your software supply chain Remediation Recommendations License Analysis Vulnerability Analysis Vulnerability Feeds Analyze Vulnerability Matching Policy Engine Reports & Notifications Scanner OSS & Source Code CI/CD Registries Kubernetes WORKLOAD SBOM Generation Who benefits from Anchore’s software supply chain security platform Enterprises Respond to the next Log4Shell in minutes rather than days. Enforce usage policies across your developers to ensure they are only using trusted components and avoid the reputation and financial costs of being the next high profile supply chain attack victim. Software Vendors Establish customers’ trust in your product by demonstrating best practices in software supply chain security. Provide transparency about open source dependencies in your product and their provenance. Public Sector Comply with the Secure Software Development Framework by generating and storing SBOMs across software you develop, buy, or use. Understand your dependency on open source software and its associated risks. Learn more about software supply chain security Overview of Software Supply Chain Security Software Supply Chain Security White Paper Top Four Types of Software Supply Chain Attacks Webinar Software Supply Chain Security Trends Video Mitigating Three Software Supply Chain Attacks with Anchore Blog ### NIST How Anchore streamlines NIST compliance Anchore Enterprise comes with ready-to-use rules to bring your cloud applications into compliance with relevant NIST standards. Ensure your application meets government standards by shifting compliance checks ‘left’ into your software development process and then verifying ongoing compliance in production. Anchore enables compliance proof with automated reports that can be forwarded to auditors, helping to streamline NIST compliance and keep communication lines open across teams.  Out-of-the-box controls With minimal configuration, you can start scanning your compliance status with Anchore’s ready-to-run NIST policy bundles. Anchore ensures the NIST policy bundles are kept up to date with the latest revision freeing you to focus on your software security posture. Anchore’s NIST policy bundle will report any issues by specific NIST control so you can clearly see the remediation action.  Shift left compliance Embed compliance checks into the software development process with plugins for any CI/CD platform. Speed up resolution times by alerting application developers in their native tools to compliance issues as software is being developed and built before it reaches production.  Streamline reporting Anchore includes a powerful reporting engine that enables almost any report to be generated from the data Anchore collects. Schedule daily snapshots to assist triage, weekly reports to show trends, or ad-hoc reports to demonstrate compliance to auditors. Export the data to third-party systems to unify with additional context.  See Anchore’s NIST policy enforcement inside the development pipeline in this video. Start Free Trial End-to-end NIST compliance support The idea of securing the software supply chain has been gaining momentum over the past few years, but how to do this isn’t always clear. NIST is the gold standard when it comes to clearly defining a compliance standard and making sure the various controls are easy to understand and implement. The SSDF is a great example of NIST taking a poorly defined concept and putting well-defined actions behind it. Anchore provides a downloadable document that serves as an evidence attachment for the SSDF Attestation Form. The document assumes that Anchore Enterprise is used in the organization’s environment and is configured to scan the software that is in scope for the SSDF Attestation Form. In addition, Anchore’s policy packs help organizations easily meet compliance requirements. One policy pack can be imported into a running Anchore Enterprise instance and checks the technical controls that apply to applications, containers, and environments. Why Use Anchore’s NIST compliance solutions Anchore Enterprise has a robust policy engine with a configurable default ruleset that customers can adjust to comply with the recommendations around SSDF as part of NIST 800-218. These controls include inspecting for malware and secrets, scanning for known vulnerabilities, and generating software bills of materials (SBOM). In addition, Anchore Enterprise provides support for detecting packages listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. For enterprises, this enables streamlined selling to the U.S. government by ensuring your software meets NIST standards.  For those in the public sector, Anchore’s NIST compliance solution will reduce the time to achieving Authority to Operate approval by embedding compliance checks in the software development process.  Learn more about NIST compliance Critical Software According to NIST How to Use Anchore Enterprise for NIST Policy Enforcement Anchore Policy-Based Compliance Webinar ### DevSecOps Overview What is DevSecOps? What is DevSecOps, you may ask? It stands for Development, Security, and Operations. DevSecOps by definition is the next step beyond DevOps, a cultural change that brings security into DevOps rapid release cycles. The shift left movement that DevSecOps offers can be vital to securing software build environments.  DevSecOps at its core is a term that indicates sharing the responsibility of security across development and operations teams. It involves empowering development, DevOps, and IT personnel with security information and tools to identify and eliminate threats as early as possible. In a DevSecOps environment security is viewed as a partner helping guide other teams while trusting them to implement security features and practices. DevSecOps is built for agility and velocity. It relies on a range of open source tools to automate the software build cycle. It’s also not uncommon for organizations to put their own spin on DevOps and DevSecOps to meet their unique security and compliance requirements.  DevOps vs. DevSecOps To get at the core of the two terms, let’s dive into DevOps and DevSecOps differentiators to lay the groundwork and highlight the differences between each.  First, DevOps is a journey for many in the IT industry. It takes time and investments in staffing, tools, processes, and security to move from a traditional waterfall-driven software development life cycle (SDLC) to DevOps. DevOps depends on gates between each stage. Managers, stakeholders, and even entire development organizations can justify these gates because they provide a sense of security for troubleshooting, halting delivery, or stakeholder inquiries into the project. In contrast, DevSecOps brings with it cultural changes to software development that can almost be more important than the tooling because it brings security concerns into the software development lifecycle. Instead of a DevOps approach that makes security the last stop before an application hits production, DevSecOps incorporates security across the entire development lifecycle.  With DevSecOps, transparency yields trust with sharing between the DevOps and security teams inside enterprises and federal agencies. Plus there are shared goals and metrics with DevOps and security teams cooperating to achieve the desired metrics to achieve compliance and security in software development. Benefits of DevSecOps The primary benefit of DevSecOps security is to find and fix security bugs early to keep the software development moving - this benefits the team, organization, end user, and everyone. Instead of security being a step at the end of development, security is a part of every stage in the development lifecycle There are other additional benefits for organizations or federal agencies who want to move to DevSecOps, here are a few to consider: Moving straight from a waterfall SDLC, enables teams to skip traditional DevOps, and move right to DevSecOps. Moving from DevOps to DevSecOps through upgrading the CI/CD toolchain with a range of security automation tools, shifting security left, and bringing security team members into the development cycle The ability to move from gated processes to shared responsibility. DevSecOps substitutes mutual accountability for those gates. Mutual accountability comes about through process changes and improving collaboration between your development, security, and operations teams through cross-functional teams supported by the proper technology tools and executive sponsorship. With DevSecOps it is no longer “Us vs. Them.” Today consumers and enterprise customers want rapid updates and app stores. DevSecOps dismantles the vestiges of “us vs. them” and makes security a priority in your application development from project kickoff.  Best practices for implementing a DevSecOps model There’s no “right” way to implement a DevSecOps program. Every organization has a unique development model, tools, languages, people, and technology used as part of its development program. There are countless resources available that explain some of the ways an organization can begin the DevSecOps journey. Focus on automation A useful and important aspect of DevSecOps is to put a focus on automation. While in the traditional DevOps program there will be a heavy focus on Continuous Integration and Continuous Deployment, in the DevSecOps space there is room for automating security. Technologies now exist to detect certain security errors. For example, open source dependencies can now be scanned for security vulnerabilities. You can learn more about that here. Remember the goal However, it’s decided to implement DevSecOps practices it should be remembered that the goal is to reduce friction and increase development speed. The key is to ensure the security tooling complements development, not get in the way and slow things down. The sooner security issues can be found and fixed the less trouble they can cause in the future. How to build a DevSecOps culture Culture can be the most essential but also the most misunderstood portion of DevOps transformation. As the old saying goes, “you can’t buy DevOps.” The same goes for DevSecOps. The security and compliance implications of DevSecOps make it, so you need to go further with your security outreach and communications to help push cultural transformation forward. It’s likely the developers are hesitant to embrace security due to bad experiences in the past. Security teams are not known to have been cooperative or understanding in the past. As such, you cannot expect development teams to automatically embrace security ideas. Trust must be earned, and the value of security must be shown. Concepts and ideas that worked at other organizations may not work at yours, part of the DevSecOps mindset is being able to adjust to new problems quickly. While you’ve probably made steps to strengthen your development and operations to embrace the concepts and tools that drive DevSecOps security, there’s going to be more work to do to transform your culture to embrace DevSecOps fully. Be clear with your team about the overall importance and role DevSecOps will play in software supply chain security. Be ready to answer hard questions, be prepared to be patient with teams as they grow and adjust, and be ready to change tactics to support the team. Automate DevSecOps with Anchore Enterprise Rather than require manual changes to tools or processes, Anchore Enterprise automates vulnerability scans at each step in the development lifecycle, including source code repositories, CI/CD pipelines, container registries, and Kubernetes platforms. Since it integrates with your existing environment, Anchore Enterprise can easily check the security posture of your applications and surface the most critical issues at every stage of development.  Anchore Enterprise enables a “shift left” DevSecOps software approach which ensures issues are identified as early as possible and flagged with the appropriate teams. As software moves from development to CI/CD, to runtime, Anchore Enterprise catalogs the components at every stage and ensures that insecure software is never put into production.  Whether looking for known vulnerabilities, secrets, malware, or insecure configurations, Anchore Enterprise searches continuously for issues and enables security teams to triage, remediate, and report more efficiently. ### Cybersecurity Compliance: What You Need to Know Let’s be real, cybersecurity compliance is massively complicated and really important when something goes wrong. Complying with cybersecurity laws has only become more challenging in the past few years as the U.S. federal government and the European Union have both accelerated their efforts to modernize cybersecurity legislation and regulations. This accelerated pace of influence and involvement of governments worldwide is impacting all businesses that use software to operate (which is to say, all businesses). Not only because the government is being more prescriptive with the requirements that have to be met in order to operate a business but also because of the financial penalties involved with non-compliance. This guide will help you understand how cybersecurity laws and regulations impact your businesses and how to think about cybersecurity compliance so you don’t run afoul of non-compliance fines. What is cybersecurity compliance? Cybersecurity compliance is the practice of conforming to established standards, regulations, and laws to protect digital information and systems from cybersecurity threats. By implementing specific policies, procedures, and controls, organizations meet the requirements set by various governing bodies. This enables these organizations to demonstrate their commitment to cybersecurity best practices and legal mandates. Consider the construction of a house. Just as architects and builders follow blueprints and building codes to ensure the house is safe, sturdy, and functional, cybersecurity compliance serves as the "blueprint" for organizations in the digital world. These guidelines and standards ensure that the organization's digital "structure" is secure, resilient, and trustworthy. By adhering to these blueprints, organizations not only protect their assets but also create a foundation of trust with their stakeholders, much like a well-built house stands strong and provides shelter for its inhabitants. Why is cybersecurity compliance important? At its core, the importance of cybersecurity compliance can be distilled into one critical aspect: the financial well-being of an organization. Typically when we list the benefits of cybersecurity compliance, we are forced to use imprecise ideas like "enhanced trust" or "reputational safeguarding," but the common thread connecting all these benefits is the tangible and direct impact on an organization's bottom line. In this case, it is easier to understand the benefits of cybersecurity compliance by instead looking at the consequences of non-compliance. Direct financial penalties: Regulatory bodies can impose substantial fines on organizations that neglect cybersecurity standards. According to the IBM Cost of a Data Breach Report 2023, the average company can expect to pay approximately $40,000 USD in fines due to a data breach. The emphasis of this figure is that it is the average. A black swan event can lead to a significantly different outcome. A prime example of this is the TJX Companies data breach in 2006. TJX faced a staggering fine of $40.9 million after the exposure of credit card information of more than 45 million customers for non-compliance with PCI DSS standards. Operational disruptions: Incidents like ransomware attacks can halt operations, leading to significant revenue loss. Loss of customer trust: A single data breach can result in a mass exodus of clientele, leading to decreased revenue. Reputational damage: The long-term financial effects of a tarnished reputation can be devastating, from stock price drops to reduced market share. Legal fees: Lawsuits from affected parties can result in additional financial burdens. Recovery costs: Addressing a cyber incident, from forensic investigations to public relations efforts, can be expensive. Missed opportunities: Non-compliance can lead to lost contracts and business opportunities, especially with entities that mandate cybersecurity standards. An overview of cybersecurity laws and legislation This section will give a high-level overview of cybersecurity laws, standards and the governing bodies that exert their influence on these laws and standards. Government agencies that influence cybersecurity regulations Navigating the complex terrain of cybersecurity regulations in the United States is akin to understanding a vast network of interlinked agencies, each with its own charter to protect various facets of the nation's digital and physical infrastructure. This ecosystem is a tapestry woven with the threads of policy, enforcement, and standardization, where agencies like the Cybersecurity and Infrastructure Security Agency (CISA), the National Institute of Standards and Technology (NIST), and the Department of Defense (DoD) play pivotal roles in crafting the guidelines and directives that shape the nation's defense against cyber threats. The White House and legislative bodies contribute to this web by issuing executive orders and laws that direct the course of cybersecurity policy, while international standards bodies such as the International Organization for Standardization (ISO) offer a global perspective on best practices. Together, these entities form a collaborative framework that influences the development, enforcement, and evolution of cybersecurity laws and standards, ensuring a unified approach to protecting the integrity, confidentiality, and availability of information systems and data. Cybersecurity and Infrastructure Security Agency (CISA) Branch of Department of Homeland Security (DHS) that oversees cybersecurity for critical infrastructure for the US federal government Houses critical cybersecurity services, such as, National Cybersecurity and Communications Integration Center (NCCIC), United States Computer Emergency Readiness Team (US-CERT), National Coordinating Center for Communications (NCC) and NCCIC Operations & Integration (NO&I) Issues Binding Operational Directives, such as, BOD 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities which require federal agencies to take action National Institute of Standards and Technology (NIST) Plays a key role in the implementation of the federal cybersecurity mandate established by the Federal Information Security Management Act (FISMA). Develops the Cybersecurity Framework Publishes the Special Publication (SP) series, notably, SP 800-37, the Risk Management Framework (RMF) SP 800-53, the Control Catalog SP 800-218, the Secure Software Development Framework (SSDF) SP 800-171, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations Department of Defense (DoD) Enforces the Defense Federal Acquisition Regulation Supplement (DFARS) which mandates NIST SP 800-171 compliance for defense contractors Introduced the Cybersecurity Maturity Model Certification (CMMC) for defense industrial base (DIB) which builds a certification around the security controls in NIST SP 800-171 Releases memorandums that amend other cybersecurity laws and standards specific to the DIB, such as, the Continuous Authorization To Operate (cATO) memo The White House Issues executive orders (EOs) that direct federal agencies to take specific actions related to cybersecurity (e.g., May 2021, President Biden issued “Executive Order on Improving the Nation’s Cybersecurity”) Launches policy initiatives that prioritize cybersecurity, leading to the development of new regulations or the enhancement of existing ones Release strategy documents to align agencies around a national vision for cybersecurity (e.g., National Cybersecurity Strategy) International Organization for Standardization (ISO) Develops and publishes international standards, including those related to information security Roughly equivalent to NIST but for European countries Influence extends beyond Europe in practice though not officially European Union Agency for Cybersecurity (ENISA) EU's agency dedicated to achieving a high common level of cybersecurity across member states Roughly equivalent to CISA but for European states The Federal Bureau of Investigation (FBI) Investigates cyber attacks, including those by nation-states, hacktivists, and criminals; investigations can set legal precedent Leads National Cyber Investigative Joint Task Force (NCIJTF) to coordinate interagency investigation efforts Collaborates with businesses, academic institutions, and other organizations to share threat intelligence and best practices through the InfraGard program Federal Trade Commission (FTC) Takes legal action against companies failing to protect consumer data Publishes guidance for businesses on how to protect consumer data and ensure privacy Recommends new legislation or changes to existing laws related to consumer data protection and cybersecurity U.S. Secret Service Investigates cyber crimes, specifically financial crimes; investigations can set legal precedent Manages the Electronic Crimes Task Forces (ECTFs) focusing on cyber intrusions, bank fraud, and data breaches National Security Agency (NSA) Collects and analyzes signals intelligence (SIGINT) related to cyber threats Established the Cybersecurity Directorate to unify foreign intelligence and cyber defense missions for national security systems and the defense industrial base (DIB) Conducts extensive research in cybersecurity, cryptography, and related fields. Innovations and findings from this research often influence broader cybersecurity standards and practices Department of Health and Human Services (HHS) Enforces the Health Insurance Portability and Accountability Act (HIPAA) ensuring the protection of health information Oversees the Office for Civil Rights (OCR) which enforces HIPAA's Privacy and Security Rules Food and Drug Administration (FDA) Regulates the cybersecurity of medical devices, specifically Internet of Things (IoT) medical devices Provides guidance to manufacturers on cybersecurity considerations for medical devices Securities and Exchange Commission (SEC) Requires public companies to disclose material cybersecurity risks and incidents Enforces the Sarbanes-Oxley Act (SOX) implications for cybersecurity, ensuring the integrity of financial data Federal Trade Commision (FTC) The FTC is the chief federal agency on consumer security and privacy policy and enforcement Responsible for enforcing Children’s Online Privacy Protection Act (COPPA) Enforce laws governing consumers’ privacy rights and sensitive consumer information U.S. cybersecurity laws and standards to know Navigating the complex web of U.S. cybersecurity regulations can often feel like wading through an alphabet soup of acronyms. We have tried to highlight some of the most important and give context on how the laws, standards and regulations interact, overlap or build on each other. NIST 800-53 Comprehensive collection of security controls that many other laws and standards refer to as the baseline Other compliance standards will refer to a subset of NIST 800-53, it is unlikely all controls will need to be met in many environments Federal Information Security Management Act (FISMA) Law that requires federal agencies and their contractors to implement comprehensive cybersecurity measures Many of the standards and recommendations of the NIST Special Publication series on cybersecurity are a response to the mandate of FISMA Federal Risk and Authorization Management Program (FedRAMP) Standard for assessing security of cloud/SaaS products and services used by federal agencies Certification is the manifestation of the FISMA law Defense Federal Acquisition Regulation Supplement (DFARS) Rules that require Department of Defense (DoD) contractors to protect controlled unclassified information (CUI) Specific security controls are detailed in NIST SP 800-171 Cybersecurity Maturity Model Certification (CMMC) Certification to prove that DoD contractors are in compliance with cybersecurity practices and processes required in DFARS For many years DFARS was not enforced, CMMC is certification process to close this gap SOC 2 (System and Organization Controls 2) Compliance framework for auditing and reporting on controls related to the security, availability, confidentiality, and privacy of a system Very popular certification for cloud/SaaS companies to maintain as a way to assure clients that their information is managed in a secure and compliant manner Payment Card Industry Data Security Standard (PCI DSS) Establishes security standards for organizations that handle credit cards Must comply with this security standard in order to process or store payment data Health Insurance Portability and Accountability Act (HIPAA) Protects the privacy and security of health information for consumers Must comply with this security standard in order to process or store electronic health records NIST Cybersecurity Framework Provides a policy framework to guide private sector organizations in the U.S. to assess and improve their ability to prevent, detect, and respond to cyber incidents While voluntary, many organizations adopt this framework to enhance their cybersecurity posture NIST Secure Software Development Framework Standardized, industry-agnostic set of best practices that can be integrated into any software development process to mitigate the risk of vulnerabilities and improve the security of software products More specific security controls than NIST 800-53 that still meet the controls outlined in the Control Catalog regarding secure software development practices CCPA (California Consumer Privacy Act) Statute to enhance privacy rights and consumer protection to prevent misuse of consumer data While only application to business operating in California, it is considered the most likely candidate to be adopted by other states Gramm-Leach-Bliley Act (GLBA) Protects consumers' personal financial information held by financial institutions Financial institutions must explain their information-sharing practices and safeguard sensitive data Sarbanes-Oxley Act (SOX) Addresses corporate accounting scandals and mandates accurate financial reporting Public companies must implement stringent measures to ensure the accuracy and integrity of financial data Children's Online Privacy Protection Act (COPPA) Protects the online privacy of children under 13. Websites and online services targeting children must obtain parental consent before collecting personally identifiable information (PII) EU cybersecurity laws and standards to know ISO/IEC 27001 An international standard that provides the criteria for establishing, implementing, maintaining, and continuously improving a system Roughly equivalent to NIST 800-37, the Risk Management Framework Also includes a compliance and certification component; when combined with ISO/IEC 27002 it is roughly equivalent to FedRAMP EU 881/2019 (Cybersecurity Act) The law that codifies the mandate for ENISA to assist EU member states in dealing with cybersecurity issues and promote cooperation Creates an EU-wide cybersecurity certification framework for member states to aim for when creating their own local legislation NIS2 (Revised Directive on Security of Network and Information Systems) A law that requires a high level of security for network and information systems across various sectors in the EU A more specific set of security requirements than the cybersecurity certification framework of the Cybersecurity Act ISO/IEC 27002 An international standard that provides more specific controls and best practices that assist in meeting the more general requirements outlined in ISO/IEC 27001 Roughly equivalent to NIST 800-53, the Control Catalog General Data Protection Regulation (GDPR) A comprehensive data protection and privacy law Non-compliance can result in significant fines, up to 4% of an organization's annual global turnover or €20 million (whichever is greater) How to streamline cybersecurity compliance in your organization Ensuring cybersecurity compliance is a multifaceted challenge that requires a strategic approach tailored to an organization's unique operational landscape. The first step is to identify the specific laws and regulations applicable to your organization, which can vary based on geography, industry, and business model. Whether it's adhering to financial regulations like GLBA and SOX, healthcare standards such as HIPAA, or public sector requirements like FedRAMP and CMMC, understanding your compliance obligations is crucial. While this guide can’t give prescriptive steps for any organization to meet their individual needs, we have put together a high-level set of steps to consider when developing a cybersecurity compliance program. 1. Determine which laws and regulations apply to your organization Geography US-only; if your business only operates in the United States then you only need to be focused on compliance with US laws EU-only; if your business only operates in the European Union then you only need to be focused on compliance with EU laws Global; if your business operates in both jurisdictions then you’ll need to consider compliance with both EU and US laws, as well as any other jurisdictions you operate in. Industry Financial Services; financial services firms have to comply with the GLBA and SOX laws but if they don’t process credit card payments they might not need to be concerned with PCI-DSS E-commerce; any organization that processes payments, especially via credit card will need to adhere to PCI-DSS and attaining a SOC2 audit is often common. Healthcare; any organization that processes or stores data that is defined as protected health information (PHI) will need to comply with HIPAA requirements Federal; any organization that wants to do business with a federal agency will need to be FedRAMP compliant Defense; any defense contractor that wants to do business with the DoD will need to maintain CMMC compliance B2B; there isn’t a law that mandates cybersecurity compliance for B2B relationships but many companies will only do business with other companies that maintain SOC2 compliance Business model Data storage; if your organization stores data but does not process or transmit the data then your requirements will differ. For example, if you offer a cloud-based data storage service and a customer uses your service to store PHI, they are required to be HIPAA-compliant but you are considered a Business Associate and do not need to comply with HIPAA specifically. You should consult with your legal team to determine which data processing laws apply to your business. Data processing; if your organization processes data but does not store the data then your requirements will differ. For example, if you process credit card transactions but don’t store the credit card information you will probably need to comply with PCI-DSS but possibly not GLBA and SOX Data transmission; if your organization transmits data but does not process or store the data then your requirements will differ. For example, if you run an internet service provider (ISP) credit card transactions and PHI could traverse your network, HIPAA or PCI-DSS compliance is not your responsibility. 2. Conduct a gap analysis Current State Assessment: Evaluate the current cybersecurity posture and practices against the required standards and regulations. Identify Gaps: Highlight areas where the organization does not meet required standards. These steps can either be done manually or automatically. Anchore Enterprise offers organizations an automated, policy-based approach to scanning their entire application ecosystem and identifying which software is non-compliant with a specific framework. If you’re interested to learn more check out our webinar titled, “Policy-Based Compliance for Containers: CIS, NIST, and More” 3. Prioritize compliance needs Risk-based Approach: Prioritize gaps based on risk. Address high-risk areas first. Business Impact: Consider the potential business impact of non-compliance, such as fines, reputational damage, or business disruption. 4. Develop a compliance roadmap Short-term Goals: Address immediate compliance requirements and any quick wins. Long-term Goals: Plan for ongoing compliance needs, continuous monitoring, and future regulatory changes. 5. Implement controls and solutions Technical Controls: Deploy cybersecurity solutions that align with compliance requirements, such as encryption, firewalls, intrusion detection systems, etc. Procedural Controls: Establish and document processes and procedures that support compliance, such as incident response plans or data handling procedures. Another important security solution, specifically targeting software supply chain security, is a vulnerability scanner. Anchore Enterprise is a modern, SBOM-based software composition analysis platform that combines software vulnerability scanning with a monitoring solution and a policy-based component to automate the management of software vulnerabilities and regulation compliance. If you’re interested to learn more, we have detailed our strategy in a blog, titled “A Policy Based Approach to Container Security & Compliance” and spelled out the benefits in a separate blog post called, “The Power of Policy-as-Code for the Public Sector”. 6. Monitor and audit Continuous Monitoring: Use tools and solutions to continuously monitor the IT environment for compliance. Auditing an IT environment once a year is no longer considered a best practice. Regular Audits: Conduct internal and external audits to ensure compliance and identify areas for improvement. Being able to find vulnerabilities with a scanner at a point in time or evaluate a system against specific compliance policies is a great first step for a security program. Being able to do each of these things continuously in an automated fashion and be able to know the exact state of your system at any point in time is even better. Anchore Enterprise is capable of integrating security and compliance features into a continuously updated dashboard enabling minute-by-minute insight into the security and compliance of a software system. 7. Document everything Maintain comprehensive documentation of all compliance-related activities, decisions, and justifications. This is crucial for demonstrating compliance during audits. 8. Engage with stakeholders Regularly communicate with internal stakeholders (e.g., executive team, IT, legal) and external ones (e.g., regulators, auditors) to ensure alignment and address concerns. 9. Review and adapt Stay Updated: Regulatory landscapes and cybersecurity threats evolve. Stay updated on changes to ensure continued compliance. Feedback Loop: Use insights from audits, incidents, and feedback to refine the compliance strategy. How Anchore can help Anchore is a leading software supply chain security company that has built a modern, SBOM-powered software composition analysis (SCA) platform that helps organizations meet and exceed the security standards in the above guide. As we have learned working with Fortune 100 enterprises and federal agencies, including the Department of Defense, an organization's supply chain security can only be as good as the depth of the data on their supply chain and the automation of processing the raw data into actionable insights. Anchore Enterprise provides an end-to-end software supply chain security system with total visibility, deep inspection, automated enforcement, expedited remediation, and trusted reporting to deliver actionable insights to make a software system compliant. If you’d like to learn more about the Anchore Enterprise platform or speak with a member of our team, feel free to book a time to speak with one of our specialists. ### Software Supply Chain Security Overview In recent years, the mega-trends of application containerization and the rise of open-source software components have accelerated the velocity of software delivery. This evolution, while offering significant benefits, has also introduced complexity and challenges to traditional software supply chain security.  If you’re looking to get a better understanding of how software supply chains operate, where the risks lie, and best practices on how to manage the risks, then keep reading. An overview of software supply chains Before you can understand how to secure the software supply chain, it’s important to understand what the software supply chain is in the first place. In short, a software supply chain is all of the individual software components that make up a software application. Software supply chains are similar to physical supply chains. When you purchase an iPhone, all you see is the finished product. But behind the final product is a complex web of component suppliers that are assembled to produce that iPhone. Displays and camera lenses from a Japanese company, CPUs from Arizona, modems from San Diego, lithium-ion batteries from a Canadian mine; all of these pieces come together in a Shenzhen assembly plant to create a final product that is then shipped straight to your door. In the same way that an iPhone is made up of a screen, a camera, a CPU, a modem, and a battery, modern applications are composed of individual software components (i.e., dependencies) that are bundled together to create the finished product. An increasingly complex supply chain With the rise of open source software, most of these components are open source frameworks, libraries, and operating systems. Specifically, 70-90% of modern applications are built utilizing open source software components. Before the ascent of open source software, applications were typically developed with proprietary, in-house code without a large and diverse set of software “suppliers." In this environment, company employees comprised the "supply chain." The move to Cloud Native and DevSecOps design patterns dramatically sped up the delivery of software, but at the expense of simplicity. Coordinating all of the open source software suppliers significantly increased complexity. This shift in the way that software is developed impacts essentially all modern software. This means that all businesses and government agencies are waking up to the realization that they are building a software supply chain, whether they want to or not. One of the ways this new supply chain complexity is being tamed is with the software bill of materials (SBOM). A software bill of materials (SBOM) is a structured list of software components, modules, and libraries that are included in a given piece of software. Similar to the nutrition labels on the back of the foods that you buy, SBOMs are a list of ingredients that go into the software that your applications consume. What is software supply chain security? In short, software supply chain security is the practice of identifying and preventing vulnerabilities in third-party components from compromising the applications that rely on them. Let's briefly return to our iPhone metaphor. In the same way that an attacker could target one of the iPhone suppliers to modify a component before the iPhone is assembled, a software supply chain threat actor could do the same by targeting an open source package that is then built into a commercial application. Given the size and prevalence of open source software components in modern applications, the supply chain is only as secure as its weakest link. Think of your application as a pyramid, and the open source software components as its building blocks. Your application’s supply chain is all of the open source components that your proprietary business logic is built on top of. The catch is that every component you use also has its own pyramid of dependencies. The foundation of your app might look solid, but there is always the potential that if you follow the dependency chain far enough down, you will find a vulnerability that could topple the entire structure. This gives adversaries their opening. A single compromised package allows attackers to manipulate all of the packages “downstream” of their entry point. This reality was viscerally felt by the software industry (and all industries that rely on the software industry, meaning all industries) during the Log4j incident. Common software supply chain risks Software development is a multifaceted process, encompassing various components and stages. From the initial lines of code to the final deployment in a production environment, each step throughout the software development lifecycle (SDLC) presents potential risks for vulnerabilities to creep in. As organizations increasingly integrate third-party components and open-source libraries into their applications, understanding the risks associated with the software supply chain becomes paramount. This section delves into the common risks that permeate the software supply chain, offering insights into their origins and implications. Source code Supply chain risks start with the code itself. Below are the most common risks associated with a software supply chain when generating custom first-party code: 1. Insecure first-party code Custom code is the first place to be aware of the risk in the supply chain. If the code written by your developers isn’t secure, then your application will be vulnerable at its foundation. Insecure code is any application logic that can be manipulated to perform a function that wasn’t originally intended by the developer. For example, a developer might write a function that checks whether a username and password match what's in the user database. But if an attacker can craft a payload that causes the function to delete the entire database instead, that’s a case of insecure code. 2. Source code management (SCM) compromise Source code is typically stored in a centralized code repository so that all members of your development team can collaborate on the same codebase. An SCM is software that can potentially be vulnerable, in the same way as your first-party code. If an adversary gains access to your SCM — either by exploiting software vulnerabilities, bypassing authentication mechanisms, or using social engineering — they can manipulate your source code at the foundation. 3. Developer environments Developer environments are powerful productivity tools for your engineers, but they are another potential source of risk for an organization. Most integrated developer environments come with a plug-in system so that developers can customize their workflows for maximum efficiency. These plug-in systems typically also have a marketplace associated with them. In the same way that a malicious Chrome browser plug-in can compromise a user's laptop, a malicious developer plug-in can gain access to a “trusted” engineer's development system and piggyback on this trusted access to manipulate the source code of an application. 3rd-party dependencies (open source or otherwise) Third-party software is really just first-party software written by someone else, the same way that the cloud is just servers run by someone else. Third-party software dependencies are potentially vulnerable to all of the same risks associated with your own first-party code in the above section. But since it isn’t your code, you have to deal with the risks in a different way. Below we lay out the two risks associated with this software supply chain risk: 4. Known vulnerabilities (CVEs, etc) Known vulnerabilities are insecure or malicious code that have been identified in a third-party dependency. Typically, the maintainer of a third-party dependency will fix their insecure code when they are notified and publish an update. Sometimes, if the vulnerability isn’t a priority, they won’t address it for a long time (if ever). If your developers rely on this dependency for your application, then you have to assume the risk. 5. Unknown vulnerabilities (zero-days) Unknown vulnerabilities are insecure or malicious code that hasn’t been discovered. These vulnerabilities can lie dormant in a codebase for months, years, or even decades. When they are finally uncovered and announced, there is typically a scramble across the world by any business using software (i.e., almost all businesses) to figure out whether they utilize this dependency and how to protect themselves. Attackers are in a scramble themselves to determine who is using the vulnerable software and crafting exploits to take advantage of businesses that are slow to react. Security teams must act quickly to identify affected systems and apply mitigation measures. Build pipeline & artifact repository 6. Build pipeline compromise A software build pipeline is a system that pulls the original source code from an SCM, gathers third-party dependencies from their source repositories, and then builds and optimizes the code into a binary stored in an artifact repository. Like an SCM, it’s made up of both first- and third-party code, so it carries many of the same risks related to source code and software dependencies.Organizations deal with these risks differently from the developers of the build systems because they do not control this code. Instead, the risks are around managing who has access to the build system, what permissions they have, and what they can do with their access (if you haven't already, read up on the principle of least privilege). Risks range from modifying where the build system is pulling source code from to modifying the build instructions to inject malicious or vulnerable code into previously secure sources. 7. Artifact registry compromise An artifact registry is a centralized repository of the fully built applications (typically in the form of a container or container image) that a deployment orchestrator would pull the software from to run in a production environment. It is also software similar to a build pipeline or SCM and has the same associated risks as mentioned before. Typically, the risks of registries are managed through how trust is managed between the registry and the build system or any other system/person that has access to it. Risks range from an attacker poisoning the registry with an untrusted container or an attacker gaining privileged access to the repository and modifying a container in place. Production 8. Deployment orchestrator compromises A deployment orchestrator is a system that pulls pre-built software binaries and runs the applications on servers. It is another type of software system similar to a build pipeline or SCM and has the same associated risks as mentioned before. Typically, the risks of orchestrators are managed through trust relationships between the orchestrator and the artifact registry or any other system/person that has access to it. Risks range from an attacker manipulating the orchestrator into deploying an untrusted container or an attacker gaining privileged access to the orchestrator and modifying a running container or manifest. 9. Production environment compromise The production environment is the application running on a server that was deployed by an orchestrator. It is the software system built from the original source code that fulfills users’ requests. It is the final product that is created from the software supply chain. The risks associated with this system are different from most other systems because it typically serves users outside of the organization and has different risks associated with it, because not as much is known about external users as internal users. Runtime monitoring is critical to detect threats that bypass earlier SDLC phases. Examples of software supply chain attacks As reliance on third-party components and open-source libraries grows, so does the potential for vulnerabilities in the software supply chain. Several notable incidents have exposed these risks, emphasizing the need for proactive security and a deep understanding of software dependencies. In this section, we explore significant software supply chain attacks and the lessons they impart. SolarWinds (2020) In one of the most sophisticated supply chain attacks, malicious actors compromised the update mechanism of SolarWinds' Orion software. This breach allowed the attackers to distribute malware to approximately 18,000 customers. The attack had far-reaching consequences, affecting numerous government agencies, private companies, and critical infrastructure. Lessons Learned: The SolarWinds attack underscored the importance of securing software update mechanisms and highlighted the need for continuous monitoring and validation of software components. Log4j (2021) In late 2021, a critical vulnerability was discovered in the Log4j logging library, a widely used Java-based logging utility. Dubbed "Log4Shell," this vulnerability allowed attackers to execute arbitrary code remotely, potentially gaining full control over vulnerable systems. Given the ubiquity of Log4j in various software applications, the potential impact was massive, prompting organizations worldwide to scramble for patches and mitigation strategies. Lessons Learned: The Log4j incident underscored the risks associated with ubiquitous open-source components. It highlighted the importance of proactive vulnerability management, rapid response to emerging threats, and the need for organizations to maintain an updated inventory of third-party components in their software stack. NotPetya (2017) Originating from a compromised software update mechanism of Ukrainian accounting software, NotPetya spread rapidly across the globe with disastrous consequences. Masquerading as ransomware, its primary intent was data destruction. Major corporations, including Maersk, FedEx, and Merck, faced disruptions, leading to financial losses amounting to billions. Lessons Learned: NotPetya highlighted the dangers of nation-state cyber warfare and the need for robust cybersecurity measures, even in seemingly unrelated software components. Node.js Packages coa and rc In July 2021, two widely used npm packages, coa and rc, were compromised. Malicious versions of these packages were published to the npm registry, attempting to run a script to access sensitive information from users' .npmrc files. The compromised versions were downloaded thousands of times before being identified and removed. Lessons Learned: This incident emphasized the vulnerabilities in open-source repositories and the importance of continuous monitoring of dependencies. It also highlighted the need for developers and organizations to verify the integrity of packages before installation and to be wary of unexpected package updates. JuiceStealer Malware JuiceStealer is a malware spread through a technique known as typosquatting on the PyPI (Python Package Index). Malicious packages were seeded on PyPI, intending to infect users with the JuiceStealer malware, designed to steal sensitive browser data. The attack involved a complex chain, including phishing emails to PyPI developers. Lessons Learned: JuiceStealer showcased the risks of typosquatting in package repositories and the importance of verifying package names and sources. It also underscored the need for repository maintainers to have robust security measures in place to detect and remove malicious packages promptly. Node.js Packages colors and faker In January 2022, the developer behind popular npm libraries colors and faker intentionally sabotaged both packages in an act of "protestware." This move affected thousands of applications, leading to broken builds and potential security risks. The compromised versions were swiftly removed from the npm registry. Lessons Learned: This incident highlighted the potential security issues associated with relying heavily on open-source libraries and the actions of individual developers. It underscored the importance of diversifying dependencies, having backup plans, and the need for the open-source community to address developer grievances constructively. Trends in software supply chain security Each year, Anchore releases our annual Software Supply Chain Security Report. Our latest edition found that 40% of organizations reported software supply chain attacks in the previous 12 months, down from the 62% of respondents reporting attacks in 2022 in the wake of SolarWinds. This positive trend could be a result of increased focus on risks in the software supply chain—the study also found a 200% increase in organizations making software supply chain security a top priority from 2023 to 2024. For an update on 2025 trends and beyond, follow Anchore on LinkedIn. Standards and best practices for preventing attacks There are a number of different initiatives to define best practices for software supply chain security. Organizations ranging from the National Institute of Standards and Technology (NIST) to the Cloud Native Computing Foundation (CNCF) to Open Source Security Foundation (OpenSSF) have created fantastically detailed documentation on their recommendations to achieve an optimally secure supply chain. Choosing any of the standards defined is better than choosing none or even cherry-picking from each of the standards to create a program that is best tailored to the risk profile of your organization. If you’d prefer to stick to one for simplicity's sake and need some help deciding, Anchore has detailed our thoughts on the pros and cons of each software supply chain standard here. Below is a concise summary of each of the major standards to help get you started: National Institute of Standards and Technology (NIST) NIST has a few different standards that are worth noting. We’ve ordered them from the broadest to the most specific and, coincidentally, chronologically, as well. NIST SP 800-53, “Security and Privacy Controls for Information Systems and Organizations” NIST 800-53, aka the Control Catalog, is the granddaddy of NIST security standards. It has had a long life and evolved alongside the security landscape. Typically paired with NIST 800-37, the Risk Management Framework or RMF, this pair of standards creates a one-two punch that not only produces a highly secure environment for protecting classified and confidential information but sets up organizations to more easily achieve federal compliance standards like FedRAMP. Software supply chain security (SSCS) topics first began filtering into NIST 800-53 in 2013, but it wasn’t until 2020 that the Control Catalog was updated to break out software supply chain security into its own section. If your goal is to get up and running with software supply chain security as quickly as possible, this standard will be overkill. If your goal is to build toward NIST 800-53 and FedRAMP compliance as well as build a secure software development process, then this standard is for you. If you’re looking for something more specific, consider one of the next two standards. If you need a comprehensive guide to NIST 800-53 or its spiritual sibling, NIST 800-37, we have put together both. You can find a detailed but comprehensible guide to the Control Catalog here and the same plain english, deep-dive into NIST 800-37 here. NIST SP 800-161, “Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations” NIST 800-161 is an interesting application of both the RMF and the Control Catalog for supply chain security, specifically. The controls in NIST 800-161 take the base controls from NIST 800-53 and provide guidance on how to achieve more specific outcomes for the controls. For the framework, NIST 800-161 takes the generic RMF and creates a version that is tailored to software supply chain security. NIST 800-161 is a comprehensive standard that will guide your organization to create a development process with its primary output being highly secure software and systems. NIST SP 800-218, “Secure Software Development Framework (SSDF)” NIST 800-218, the SSDF, is an even more refined standard than NIST 800-161. The SSDF targets the software developer as the audience and gives even more tailored recommendations on how to create secure software systems. If you’re a developer attempting to build secure software that complies with all of these standards, we have an ongoing blog series that breaks down the individual controls that are part of the SSDF. NIST SP 800-204D, “Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines” Focused specifically on Cloud-native architectures and Continuous Integration/Continuous Delivery (CI/CD) pipelines, NIST 800-204D is a significantly more specific standard than any of the previous standards. That being said, if the primary insertion point for software supply chain security in your organization is via the DevOps team, then this standard will have the greatest impact on your overall software supply chain security. Also, it is important to note that this standard is still a draft and will likely change as it is finalized. Open Source Security Foundation (OpenSSF) A project of the Linux Foundation, the Open Source Security Foundation is a cross-industry organization that focuses on the security of the open source ecosystem. Since most 3rd-party dependencies are open source, they carry a lot of weight in the software supply chain security domain. Supply-chain Levels for Software Artifacts (SLSA) If an SBOM is an ingredients label for a product, then the SLSA (pronounced ‘salsa’) is the food safety handling guidelines of the factory where they are produced. It focuses primarily on updating traditional DevOps workflows with signed attestations around the quality of the software that is produced. Google originally donated the framework and has been using an internal version of SLSA since 2013, which it requires for all of its production workloads. You can view the entire framework on its dedicated website here Secure Supply Chain Consumption Framework (S2C2F) The S2C2F is similar to SLSA but much broader in its scope. It gives recommendations around the security of the entire software supply chain using traditional security practices such as scanning containers for for vulnerabilities. It touches on signed attestations but not at the same level of depth as the SLSA. The S2C2F was built and donated by Microsoft, where it has been used and refined internally since 2019. You can view the entire list of recommendations on its GitHub repository. Cloud Native Computing Foundation (CNCF) The CNCF is also a project of the Linux Foundation but is focused on the entire ecosystem of open-source, cloud-native software. The Security Technical Advisory Group at the CNCF has a vested interest in supply chain security because the majority of the software that is incubated and matured at the CNCF is part of the software development lifecycle. Software Supply Chain Best Practices White Paper The Security Technical Advisory Group at CNCF created a best practices white paper that was heralded as a huge step forward for the security of software supply chains. The document creation was led by the CTO of Docker and the Chief Open Source Officer at Isovalent. It captures over 50 recommended practices to secure the software supply chain. You can view the full document here. Types of Supply Chain Compromise This document isn’t a standard or best practices, instead it is support for the best practices white paper that defines a full list of supply chain compromises. Catalog of Supply Chain Compromises This isn’t a standard or best practices document, as well. It is instead a detailed history of the significant supply chain breaches that have occurred over the years. Helpful for understanding this history that informed the best practices detailed in the accompanying white paper. For help managing and maintaining best practices, consider adopting a software supply chain management platform. How Anchore can help Anchore is a leading software supply chain security company that has built a modern, SBOM-powered software composition analysis (SCA) platform that helps organizations incorporate many of the software supply chain best practices that are defined in the above guides. It was founded on the belief that the legacy security solutions of the monolith era could be rebuilt to deliver on the promises of speed without sacrificing security. Anchore is trusted by Fortune 100 companies and the most exacting federal agencies across the globe because it has delivered on this promise.   As we have learned working with both large enterprises and federal agencies, including the Department of Defense, an organization's supply chain security can only be as good as the depth of the data on their supply chain and the automation of processing the raw data into actionable insights. Anchore Enterprise provides an end-to-end software supply chain security system with total visibility, deep inspection, automated enforcement, expedited remediation and trusted reporting to deliver actionable insights to improve your overall security posture. If you’d like to learn more about the Anchore Enterprise platform or speak with a member of our team, feel free to book a time to speak with one of our specialists. ### SBOMs for Docker Images An introduction to the 'docker sbom' command Anchore and Docker teamed up to bring Docker users the ability to create software bill of materials (SBOM) directly in the native Docker CLI. Included in Docker Desktop is an operation called ‘docker sbom’. This new operation, which is built on top of Anchore’s open source Syft project, enables Docker users to quickly generate detailed SBOM documents against container images. Why it matters SBOMs are quickly becoming foundational data sources for a variety of DevSecOps use-cases, ranging from basic software development hygiene to more complex security measures. These include tamper and drift detection, zero-day response support, and post-security-event forensic analysis. While security scanning tools need to identify software components, they often don’t make an SBOM accessible to users or include the level of detail needed to support a variety of use cases. With this collaboration between Anchore and Docker, we are giving users the ability to create and store an SBOM independently from running any higher-level function like vulnerability scanning or license detection. We believe that the availability of SBOM data is foundational when developing processes and technologies to improve software supply chain security. Learn how to automate container vulnerability scanning in Harbor registry with Anchore Enterprise. A webinar with the experts from Anchore. Watch Now The Open Source Tool for Generating Docker SBOMs Syft is an open source software bill of materials (SBOM) generator designed to scan container images and filesystems to create an inventory of their contents, including files and software packages. With a focus on speed, accuracy, and ease of integration, Syft aims to provide the best choice for developers and DevOps engineers who need to integrate container scanning into their CI/CD pipelines. While Syft excels at detecting packages handled by package managers, it also has the ability to detect binaries installed outside of package managers with the goal of bringing supply chain visibility to all applications and dependencies regardless of whether they fit a specific development pattern.If you’re interested in learning more about Syft, check out Anchore’s open source overview. Benefits of ‘docker sbom’ command for securing container images By enabling SBOM creation to be an independent operation, it can be decoupled from the multitude of individual use cases that rely on SBOM data. This approach gives users the ability to generate an SBOM once and then use it for a variety of use cases. We believe that the availability of SBOM data is foundational when developing processes and technologies to improve software supply chain security. With ‘docker sbom’, we’re excited to engage with the Docker and Anchore communities together on the topic of SBOM creation, usage, and future directions.By integrating SBOM generation directly into the Docker command line, Anchore and Docker demonstrate the importance of making SBOM generation a native user experience. We believe that SBOMs are not only a foundational element of secure software development, it is integral to Docker security best practices as well. Automate your SBOM management with Anchore Enterprise. Get instant access with a 15-day free trial. START FREE TRIAL How to generate an SBOM for a Docker image The new ‘docker sbom’ command is simple to use and leverages the power of Syft to provide rich content and data formats. In the following quick example, we show how the ‘docker sbom’ command can be used to generate a comprehensive SBOM document in a user-chosen format and then used as input for other tools that are capable of consuming an SBOM to provide higher-level functions such as vulnerability scanning.As the discussion on the best way to create and consume SBOM data continues to evolve, we’re committed to supporting standard SBOM formats like SPDX, CycloneDX, Syft-JSON, and others in order to promote the idea of creating and storing SBOMs in forms that interoperate with evolving security and DevOps infrastructure tools.Here, we show using the ‘docker sbom’ command against a test image that combines regular distro-provided packages (Alpine in this case) with multiple vulnerable versions of Log4j that are packaged in a variety of different forms ranging from simple top-level jars to many-levels-deep jars within compressed Java archives: % docker sbom dnurmi/testrepo:jarjar Syft v0.42.2 ✔ Loaded image ✔ Parsed image ✔ Cataloged packages [217 packages] NAME VERSION TYPE alpine-baselayout 3.2.0-r18 apk alpine-keys 2.4-r1 apk … … log4j-core 2.12.1 java-archive log4j-core 2.11.0 java-archive log4j-core 2.11.1 java-archive log4j-core 2.13.2 java-archive log4j-core 2.12.0 java-archive … While the default output is in human-readable form for quick review, the command supports a growing set of output formats that can be used more directly for integration into other systems and tools that can analyze SBOMs: % docker sbom --help Usage: docker sbom [OPTIONS] COMMAND … --format string report output format, options=[syft-json cyclonedx-xml cyclonedx-json github-json spdx-tag-value spdx-json table text] (default "table") … To demonstrate this flow, let’s look at a simple use case where ‘docker sbom’ is used to produce its data as SPDX JSON, which is then consumed by another tool. We’ll use Grype, Anchore’s open source vulnerability scanner, to produce a vulnerability report without needing to contact any remote scanning services: % docker sbom --format spdx-json docker.io/dnurmi/testrepo:jarjar | grype Syft v0.42.2 ✔ Loaded image ✔ Parsed image ✔ Cataloged packages [217 packages] NAME INSTALLED FIXED-IN VULNERABILITY SEVERITY … log4j-core 2.12.1 CVE-2021-45046 Critical log4j-core 2.11.0 CVE-2021-45105 Medium log4j-core 2.13.2 2.16.0 GHSA-7rjr-3q55-vv33 Critical log4j-core 2.12.1 2.12.4 GHSA-8489-44mv-ggj8 Medium log4j-core 2.13.0 CVE-2020-9488 Low log4j-core 2.12.1 2.12.3 GHSA-p6xc-xr62-6r2g High log4j-core 2.12.0 2.12.3 GHSA-p6xc-xr62-6r2g High log4j-core 2.12.0 CVE-2021-44832 Medium … Manage SBOMs and automate container scanning with Anchore Generating an SBOM is just part of the equation. Storing, analyzing, sharing, and managing SBOMs at scale is a whole other story entirely, and a process that development teams should strive to automate and integrate into their DevSecOps pipelines.Anchore provides a number of open-source and commercially available software tools for managing SBOMs and providing security/compliance insights and enforcement capabilities against those generated SBOMs: ToolTypeGood for...SyftOpen sourceGenerating a Software Bill of Materials (SBOM) from container images and filesystems.GrypeOpen sourceScan container images and filesystems for open source vulnerabilities.Anchore EnterpriseEnterpriseAutomate SBOM scanning, generation, storage, analysis, reporting, and so much more to strengthen your software supply chain and achieve compliance with federal standards like NIST, FedRAMP, and more. Our general approach to securing modern software development systems embraces the user’s automation and development flexibility objectives, handling large and dynamic software production flows. To facilitate this, the Anchore Enterprise platform effectively conforms to a pattern where:Existing software development infrastructure is instrumented with light-weight tooling that is pointed at a software element (source code checkout, container image, etc.) to generate an SBOM, and thenThe tooling imports that SBOM into a deployment of Anchore Enterprise which stores the SBOM for further processing, at which point the full capabilities of Anchore Enterprise can be applied to the software SBOM.The Anchore Enterprise client that implements the SBOM generation and import steps is named ‘anchorectl’, a lightweight CLI tool that is included with the Anchore Enterprise platform.As part of our ongoing commitment to support integration with Docker’s native tooling and approach to SBOM generation, we’ve recently released a new version of anchorectl, available to all Anchore Enterprise users, with added support for importing an SBOM directly from new ‘docker sbom’ command. With this capability, users who have access to an existing Anchore Enterprise deployment and prefer to use native ‘docker’ commands in their development environments can easily connect the two systems in a typically UNIX-like fashion. The following example shows an abstract ‘checkout, build container image, import image sbom to Anchore Enterprise’ using this new interface. … # git clone # docker build -t -f /Dockerfile / # docker sbom --format syft-json | anchorectl sbom upload - … With this simple process invoked either manually or scripted as part of an automated build, users can be assured that new container image SBOMs are being imported to their Anchore Enterprise deployment, so that the full capabilities of Anchore Enterprise - vulnerability scanning (on demand, historical), cybersecurity compliance checks using Anchore’s fully policy subsystem, SBOM drift detection, global reporting and notifications, and many others - can be applied. ### Software Bill of Materials Overview Fast Facts A software bill of materials (SBOM) is a structured list of software components, modules, and libraries that are included in an application. SBOMs help identify security vulnerabilities and risks in software, provide visibility for DevSecOps, and help streamline compliance with cybersecurity standards like NIST and EU CRA. The two most common SBOM formats are SPDX and CycloneDX. Tools like Anchore SBOM help organizations generate, manage, and analyze SBOMs at scale. In the dynamic landscape of software development, the past decade has witnessed two transformative shifts that have redefined the industry's trajectory. The first is the widespread adoption of open-source software components, providing developers with a vast repository of pre-built modules to streamline their work. The second is the embrace of DevOps principles, automating and accelerating the software build and delivery process. Together, these shifts promised unprecedented efficiency and speed. However, they also introduced a labyrinth of complexity, with software compositions becoming increasingly intricate and opaque. This complexity, coupled with the relentless pace of modern development cycles, created a pressing need for a solution that could offer clarity amidst the chaos. This is the backdrop against which the Software Bill of Materials (SBOM) emerged. This guide delves into the who, what, why, and how of SBOMs. Whether you're a developer, a security professional, or simply someone keen on understanding the backbone of modern software security, this guide offers insights that will equip you with the knowledge to navigate all of the gory details of SBOMs. Only 1 in 5 organizations have full visibility of open source - learn more about the latest trends and discoveries in our report. Download Now What is a Software Bill of Materials (SBOM)? A software bill of materials (SBOM) is a structured list of software components, modules, and libraries that are included in an application. Similar to the nutrition labels on the back of the foods that you buy, SBOMs are a list of ingredients that the software is composed of. We normally think of SBOMs as an artifact of the software development process. As a developer is building an application using different open-source components, they are also creating a list of ingredients; an SBOM is the digital artifact of this list.To fully extend the metaphor, creating a modern software application is analogous to crafting a gourmet dish. When you savor a dish at a restaurant, what you experience is the final, delicious result. Behind that dish, however, is a complex blend of ingredients sourced from various producers, each contributing to the dish's unique flavor profile. Just as a dish might have tomatoes from Italy, spices from India, olive oil from Spain, and fresh herbs from a local garden, a software application is concocted from individual software components (i.e., software dependencies). These components, like ingredients in a dish, are meticulously combined to create the final product. Similarly, while you interact with a seamless software interface, behind the scenes, it's an intricate assembly of diverse open source software components working in harmony. Benefits of SBOMs SBOMs are one of the most powerful security tools that you can use. Large-scale software supply chain attacks that affected SolarWinds, Codecov, and Log4j highlight the need for organizations to understand the software components—and the associated risk—of the software they create or use. The following are a few advantages of using SBOMs within your organization: Identify security vulnerabilities and risks in software: SBOMs provide a detailed inventory of all components in a software application, including third-party components and open-source dependencies, enabling organizations to identify vulnerabilities quickly. This helps expose and mitigate critical security risks in the software supply chain and supports faster incident response. Comply with standards: Regulations such as the U.S. Executive Order on Improving the Nation’s Cybersecurity require SBOMs for secure software delivery. Cybersecurity frameworks such as NIST 800-53 and FedRAMP also encourage the use of SBOMs. Visibility and support for DevSecOps: Ultimately, SBOMs are a source of truth. They integrate seamlessly with CI/CD pipelines to automate vulnerability scanning and compliance checks and support collaboration by acting as a shared source of truth across development, operations, and security teams. Analyze trends: Beyond identifying security risks, SBOMs enable you to spot trends in how software changes over time, potentially introducing new risks or threats. Cost savings: SBOMs support cost savings in a variety of ways. They enable faster identification of vulnerabilities to strengthen risk managment and reduce the cost of prolonged system downtime. They reduce development time and cost by exposing and remediating issues earlier in the cycle. And they provide visibility into components to prevent unintentional use of unsupported or outdated software. Knowing what’s in software is the first step to securing it. Increasingly, organizations are developing and using cloud-native software that runs in containers. Consider the complexity of these containerized applications that have hundreds—sometimes thousands—of components from commercial vendors, partners, custom-built software, and open source software (OSS). Each of these pieces is a potential source of risk and vulnerabilities.SBOM generation enables you to create a trackable inventory of these components. Yet, despite the importance of SBOMs for container security practices, only 36% of the respondents to the Anchore 2022 Software Supply Chain Report produce an SBOM for the containerized apps they build, and only 27% require an SBOM from their software suppliers. Use Cases An organization can use SBOMs for many purposes. The data inside an SBOM has internal uses such as Compliance review Security assessments License compliance Quality assurance Additionally, you can share an SBOM externally for compliance and customer audits. Within the security and development role, SBOMs serve a similar purpose as a bill of materials in other industries. For example, automotive manufacturers must track the tens of thousands of parts coming from a wide range of suppliers when manufacturing a modern car. All it takes is one faulty part to ruin the final product.Cloud-native software faces similar challenges. Modern applications use significant amounts of open source software that depends on other open source code which in turn incorporate further open source components. They also include internally developed code, commercial software, and custom software developed by partners. Combining components and code from such a wide range of sources introduces additional risks and potential for vulnerabilities at each step in the software development lifecycle. As a result, SBOMs become a critical foundation for getting a full picture of the “ingredients” in any software application over the course of the development lifecycle. Collecting SBOMs from software suppliers and generating SBOMs throughout the process to track component inventory changes and identify security issues is an integral first step to ensuring the overall security of your applications.Security and development teams can either request SBOMs from their software suppliers or generate an SBOM themselves. Having the ability to generate SBOMs internally is currently the more optimal approach. This way teams can produce multiple SBOMs throughout the development process to track component changes and search for known vulnerabilities as new issues become known in software. SBOM Formats & Standards SBOMs can be generated in a few formats or schemas that standardize the organization of the file's contents. The most common formats are… CycloneDX SPDX (Software Package Data Exchange) SWID was previously listed as a third standard and was typically used by the U.S. federal government. It launched in 2009 and has now largely lost traction. Learn more about SBOM formats and standards, including a full comparison of Cyclone DX and SPDX. A deeper dive into SBOM security benefits There are many SBOM security benefits for your organization. Any effective solution to securing your software supply chain is transparency. Let’s dive into what SBOM security means with regard to these ingredients and why transparency is so vital. Transparency = Discovering what is in there  It all starts with knowing what software is being used. You need an accurate list of “ingredients” (such as libraries, packages, and files) that are included in a piece of software. This list of “ingredients” is known as a software bill of materials. Once you have an SBOM for any piece of software you create or use, you can begin to answer critical questions about the security of our software supply chain.It’s important to note that SBOMs themselves can also serve as input to other types of analyses. A noteworthy example of this is vulnerability management and scanning. Typically, vulnerability scanning is a term for discovering known security problems with a piece of software based on previously published vulnerability reports. Detecting and mitigating vulnerabilities goes a long way toward preventing security incidents.In the case of software deployed in containers, developers can use SBOMs and vulnerability scans together to provide better transparency into container images. When performing these two types of analyses within a CI/CD pipeline, you need to realize two things: Each time you create a new container image (i.e. an image with a unique digest), you only need to generate an SBOM once. And that SBOM can be forever associated with that unique image.  Even though that unique image never changes, it’s vital to continually scan for known vulnerabilities. Many people scan for vulnerabilities once an image is built, and then move on. But new vulnerabilities are discovered and published every day (literally) — so it’s vital to periodically scan any existing images you’re already consuming or distributing to identify if they are impacted by new vulnerabilities. Using an SBOM means you can quickly and confidently scan an application for new vulnerabilities. Why SBOMs matter for software supply chain security Today’s software is complex, which is why SBOMs have become the foundation of software supply chain security. The role of an SBOM is to provide transparency about the software components of an application, providing a foundation for vulnerability analysis and other security assessments. For example, organizations that have a comprehensive SBOM for every software application they buy or build can instantly identify the impact of new zero-day vulnerabilities, such as the Log4Shell vulnerability in Log4j, and discern their exact location for faster remediation. Similarly, they can evaluate the provenance and operational risk of open source components to comply with internal policies or industry standards. These are critical capabilities when it comes to maintaining and actively managing a secure software supply chain. The importance of the SBOM was highlighted in the 2021 U.S. Executive Order to Improve the Nation’s Cybersecurity. The Executive Order directs federal agencies to “publish minimum SBOM standard” and define criteria regarding “providing a purchaser a software bill of materials (SBOM) directly or publish to a public website.” This Executive Order is having a ripple effect across the industry, as software suppliers that sell to the U.S. government will increasingly need to provide SBOMs for the software they deliver. Over time, these standards will spread as companies in other industries begin to mirror the federal requirements in their own software procurement efforts.If you’re looking for a deep dive into the world of software supply chain security, we have written a comprehensive guide to the subject. What is an SBOM made of? What’s inside? Each modern software application typically includes a large number of open source and commercial components coming from a wide range of sources. An SBOM is a structured list of components, modules, and libraries that are included in a given piece of software that provides the developer with visibility into that application. Think of an SBOM as a list of ingredients that evolves throughout the software development lifecycle as you add new code or components. Examples of items included in SBOMs are: The software packages, libraries, and modules used (open source, commercial, or proprietary) Metadata such as creation date, SBOM author, and format details (e.g., SPDX, CycloneDX) Dependencies, including direct and deeply nested Component version numbers and supplier details Associated open-source or commercial licenses The National Telecommunications and Information Administration (NTIA) defined minimum elements in July 2021 to provide a framework for organizations looking to comply with the Executive Order issued that same year. Anchore Enterprise supports SPDX, CycloneDX, and Syft formats. This is a continually evolving space with new formats introduced periodically. To learn about the latest on SBOM formats see the Anchore blog here. Who needs SBOMs? For the last several years, SBOMs have been used mainly by DevSecOps practitioners and compliance teams for audits, license monitoring, and compliance with industry-specific regulations. The rise of software supply chain attacks like the SolarWinds hack and the Log4Shell vulnerability in Log4j accelerated the adoption of SBOMs, and by 2024, nearly 50% of organizations were using the file to document software components, according to Anchore's latest Software Supply Chain Security Report. Coupled with new compliance standards like the EU CRA, SBOM use is now on the radar for both security and development teams alike. Security teams 
SBOMs play a critical role for security teams, especially when it comes to vulnerability management. It is much quicker and easier to scan a library of SBOMs than it is to scan all of your software applications, and in the event of a zero-day vulnerability, every minute counts. SBOMs can also be leveraged by security teams to prioritize issues for remediation based on their presence and location and to create policies specific to software component attributes such as vendor, version, or package type. Development teams Development teams use SBOMs to track the open source, commercial, and custom-built software components that they use across the applications they develop, manage, and operate. This assists development teams by reducing time spent on rework by helping to manage dependencies, identify security issues for remediation early, and ensure that developers are using approved code and sources.Fueling the cross-functional use of SBOMs, is the Executive Order on Improving the Nation’s Cybersecurity, where President Biden issued an SBOM requirement that plays a prominent role in securing software supply chains.  The current state of SBOMs The current state of SBOMs is complex and evolving. The risks of software supply chain attacks are real, with almost two-thirds of enterprises impacted by a software supply chain attack in the last year according to the Anchore 2022 Software Supply Chain Report. To stem these rising threats, the Executive Order outlines new requirements for SBOMs along with other security measures for software used by federal agencies. Until now, the use of SBOMs by cybersecurity teams has been limited to the largest, most advanced organizations. However, as a consequence of these two forces, the use of SBOMs is on the cusp of a rapid transformation.With governments and large enterprises leading the way, standardized SBOMs are poised to become a baseline requirement for all software as it moves through the supply chain. As a result, organizations that produce or consume software need the ability to generate, consume, manage, and leverage SBOMs as a foundational element of their cybersecurity efforts. In recent years, we have seen threat actors shift their focus to third-party software suppliers. Rather than attacking their targets directly, they aim to compromise software at the build level, introducing malicious code that can later be executed once that software has been deployed, giving the attacker access to new corporate networks. Now, instead of taking down one target, supply chain attacks can potentially create a ripple effect that could affect hundreds, even thousands, of unsuspecting targets. Open source software can also be an attack vector if it contains unremediated vulnerabilities.SBOMs are a critical foundation for securing against software supply chain attacks. By generating SBOMs into the development cycle, developers and security teams can identify and manage the software in their supply chains and catch these bad actors early before they reach runtime and wreak havoc. Additionally, SBOMs allow organizations to create a data trail that can provide an extended view of the supply chain history of a particular product. SBOMs in Your Organization 23% of enterprises reported managing and sharing SBOMs as a top supply chain security challenge and less than half report following SBOM best practices (2024 report). Luckily, partners like Anchore are here to help streamline and automate SBOM generation and management. Anchore Enterprise is an SBOM-powered SCA tool that makes it easy for teams to manage SBOMs for increased security and quicker incident response. The platform provides a comprehensive set of SBOM management capabilities that enable teams to collect, store, analyze, automate, and use SBOMs across the application and software development lifecycle (SDLC).  ### SP 800-171 NIST Special Publication (SP) 800-171 is a list of controls that define Controlled Unclassified Data (CUI) and the security standards for non-federal organizations that handle it. It is roughly similar in intent to NIST 800-53, the “Control Catalog”, but significantly less stringent and focused on non-federal organizations (e.g. federal service integrators, defense contractors, etc.) instead of Federal agencies. It is very closely related to the controls that are needed to achieve Cybersecurity Maturity Model Certification (CMMC) 2.0 framework Level 2 (Advanced) compliance. Complying with NIST 800-171 is required for any non-federal organization that handles CUI. This includes Prime contractors working for the DoD and their subcontractors, as well as universities and research institutions receiving federal grants. Compliance determines whether these organizations are eligible to do business with the DoD and reap the rewards of the associated federal funds. What is NIST SP 800-171? NIST SP 800-171 is a document that provides guidelines to secure sensitive but unclassified federal information (i.e. Controlled Unclassified Data) that resides in nonfederal systems and organizations (e.g. federal service integrators, defense contractors, etc.). You can think of CUI as Personally Identifiable Information (PII) with a few extra categories of information added in like proprietary business information, law enforcement information, or information that could affect national security. If you are a federal service integrator, defense contractor, or any other business that wants to do business with a federal agency AND will need to process or hold CUI as part of your business then you will need to comply with NIST SP 800-171. More specifically, you will need to comply with the CMMC 2.0 framework. When you meet the certification requirements for Level 2 (Advanced) of the CMMC you will be in compliance with NIST SP 800-171. Looking to learn more about how to achieve CMMC Level 2 or NIST 800-171 compliance? 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. Intro to DoD Software Factory Outline for Getting Up to Speed on the DoD Software Factory How Anchore Secures Software Factories Revisions NIST Special Publication (SP) 800-171 is titled, "Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations". It was originally published in December 2016 as revision 1 and has been updated most recently May 2023 as revision 3. NIST 800-171 has three revisions to date, with the most recent – NIST 800-171 Revision 3 Draft – published in May 2023.  We’ll provide an overview of each here, starting with the most recent revision:  NIST 800-171 Rev 3 summary NIST 800-171 revision 3 was published as a draft in May 2023 and is currently going through the formal publication process which will end with the publication of a final draft later this year.  This revision is primarily updating the document to stay in line with the other documents that it is tied to. NIST 800-171 is based on NIST SP 800-53 Revision 5 controls and SP 800-53B moderate control baseline. NIST SP 800-53 Revision 5 was published in September 2020. All of those changes have been incorporated into revision 3 of NIST 800-171 including moving from 14 control families to 17.  Revision 3 has also adopted the use of organization-defined parameters (ODP) to allow organizations to tailor specific values to their circumstances. If you’d like to read the entire revision in full, you can find it here. NIST 800-171 Rev 2 summary NIST 800-171 revision 2 did not contain any significant changes from revision 1. It was published alongside a working draft of NIST SP 800-171B which was a precursor to CMMC. If you’d like to read the entire revision in full, you can find it here. NIST 800-171 Rev 1 summary NIST 800-171 revision 1 was originally created in order to provide guidance to non-federal organizations on how to protect CUI in their IT environments. It was published December 2016. If you’d like to read the entire revision in full, you can find it here. NIST 800-171 compliance: Understand the control families Achieving and maintaining NIST 800-171 compliance requires meeting standards outlined in the special publication’s 17 control families and the 110 corresponding controls. The term "control family" is used to organize the security controls in a manner that makes them easier to reference and manage. Together the NIST 800-171 control families form a checklist of requirements for organizations to follow: Access Control (AC)Controls that limit access to information systems and the information they process and store based on the principle of least privilege. Access controls can be both technical (such as logins and passwords) and physical (such as locked doors). Awareness and Training (AT)Controls that aim to ensure that individuals within the organization are adequately trained and informed about security risks and their responsibilities towards mitigating those risks. Audit and Accountability (AU)Controls that record and examine activity in information systems to detect and respond to security incidents. Configuration Management (CM)Controls that focus on establishing and maintaining the integrity of products and systems, through control of the processes for initializing, changing, and monitoring the configurations. Identification and Authentication (IA)Controls that ensure the identity of an entity (a user or a system) is verified before access is granted. Incident Response (IR)Controls that establish the capability to respond to, manage, report, and learn from information system incidents. Maintenance (MA)Controls that involve the routine, periodic, or emergency maintenance of information systems, including any potential security impacts. Media Protection (MP)Controls that protect information in print or electronic format from unauthorized access, disclosure, alteration, and destruction. Personnel Security (PS)Controls that ensure trustworthiness and appropriate training for roles and responsibilities for individuals having access to the system. Physical Protection (PE)Controls that provide measures to safeguard physical resources and support facilities of an information system. Risk Assessment (RA)Controls that guide the identification and assessment of risks to organizational operations, assets, or individuals. Security Assessment and Authorization (CA)Controls that deal with the initial authorization to operate the system and ongoing monitoring of security controls. System and Communications Protection (SC)Controls that protect the integrity of transmissions and information flows in information systems. System and Information Integrity (SI)Controls that protect the integrity of information and information systems by protecting against malware, providing intrusion alerts, and ensuring information input and output integrity. Planning (PL)Controls that involve system security plans, rules of behavior, and more to guide the implementation and operation of the information system. System and Services Acquisition (SA)Controls that address the life cycle of information systems, including system development, system integration, and outsourcing decisions. Supply Chain Risk Management (SR)A control family added in Revision 5 that deals with reducing the risk that an adversary will exploit vulnerabilities in the system's supply chain. A full list of NIST 800-171 Revision 2 controls organized by family can be found here. This includes the soon-to-be-replaced 14 families and 110 controls. You can view the new proposed control families here. NIST 800-171 compliance checklist Compliance is hard and checklists make it easier but this is not a comprehensive checklist of everything you need to do in order to achieve NIST 800-171 compliance. There is an entire industry of businesses that offer services taking you through the steps to become NIST-171 compliant. Anchore partners with many of these companies, if you’re interested in getting a recommendation—reach out. Regardless, it is important to have a high-level understanding of what goes into achieving NIST 800-171 compliance. Below are the steps that your organization will need to complete in order to achieve this certification. Step 1: Identify CUI Begin by identifying the extent of CUI within your organization. Conduct a thorough audit spanning from individual employee devices to the end-user. Automated tools are available to assist in this task. The goal is to gather comprehensive data about the type, usage, and accessibility of your CUI. Step 2: Classify CUI Next, you should classify your CUI as per NIST 800-171, which provides 20 recognized categories, each with its unique standards. Step 3: Perform security assessment Regardless of the size of your DoD contracting office, a robust security system is crucial. Start by performing a security assessment to gauge your existing cybersecurity capabilities, pinpoint vulnerabilities, and plot the course for enhancement. Step 4: Install baseline controls Develop baseline controls to fortify your defenses against external threats, ensuring endpoint security. This forms part of your data protection strategy, designed to prevent cyber incidents. Step 5: Perform risk assessment Routine risk assessments are critical to measure the effectiveness of your security measures and devise strategies to safeguard your CUI against emerging threats. Step 6: Codify security plan NIST 800-171 compliance necessitates a documented security plan. As you carry out assessments and make changes, your plan should be updated, with each new version clearly dated and revision-numbered. Step 7: Build a response plan Your response plan should delineate your organization's actions following a cyber incident. Should such an incident occur, your response plan facilitates a swift, cost-effective return to normal operations. Step 8: Educate employees Upon the completion of the above steps, it's vital to inform your employees. A well-informed workforce is less likely to fall prey to cyber threats. Therefore, any changes in policies should be promptly communicated to all employees. While many organizations think about this checklist as a one-time operation or maybe even a once every 3 years activity, organizations at the forefront of cybersecurity understand that the world is moving to a model of continuous re-validation of their security posture. The only way to scale this sort of practice is through automation both in the process and the tools that perform the individual tasks. That's where NIST compliance solutions come in. Anchore Enterprise is purpose-built to achieve these goals and enable organizations to re-validate their compliance with standards like NIST 800-171 down to each individual software change request. If you’re interested to see how Anchore Enterprise automates compliance through software policy enforcement be sure to read our blog where we dive into all of the gory details. It is only through scalable, automated security solutions that organizations can both meet and maintain emerging standards like continuous Authority to Operate. NIST 800-171 DoD Assessment methodology What is the DoD Assessment methodology?  The DoD (Department of Defense) Assessment Methodology is the scoring rubric used to determine if an organization is protecting Controlled Unclassified Data (CUI) adequately to do business with the DoD. The DoD Assessment Methodology was created to evaluate the compliance of its contractors with the cybersecurity requirements outlined in the Defense Federal Acquisition Regulation Supplement (DFARS). The most recent update to DFARS (252.204-7102) was issued in 2016. Contractors are obliged to demonstrate their ability to securely manage CUI throughout the system development life cycle, guided by the security controls listed in NIST SP 800-171. However, the original DFARS did not establish a mechanism for ensuring contractor compliance with these NIST 800-171 requirements. Previously, contractors were only required to self-certify that they had plans to implement the necessary controls. But in 2019, the DoD began implementing more stringent, objective assessments of its contractors' security profiles. This led to the creation of the Cybersecurity Maturity Model Certification (CMMC) which allows contractors to achieve a certification to prove that they are complying with DFARS. Performing a NIST 800-171 self-assessment  The Defense Federal Acquisition Regulation Supplement (DFARS) mandates that organizations securely manage CUI, guided by the security controls listed in NIST SP 800-171. Originally the only way to demonstrate compliance was through a self-assessment. NIST has published two different documents to assist with this task. The first is NIST Special Publication 800-171A which provides a methodology for meeting each individual control that is part of the parent NIST SP 800-171 document. The second is NIST SP 800-171 DoD Assessment Methodology, Version 1.2.1 which provides a table with each control and the corresponding score associated with each. After you know which controls have been satisfied and which have not, the scores can help when building a Plan of Action & Milestones (POA&M) and prioritizing which controls to address in which order. NIST 800-171 vs. 800-53 The primary difference between NIST SP 800-171 and 800-53 is the number of control families, the number of controls and the target audience of the standards. NIST 800-53 20 control families 1000+ controls Applies to federal agencies and FedRAMP-compliant Cloud Service Providers (CSPs) NIST 800-171  14 (soon to be 17) control families 110 controls Applies to any non-federal agency that handles CUI The security requirements in NIST 800-171 are derived from the moderate control baseline of NIST 800-53 which makes NIST 800-171 a subset of NIST 800-53 with some modifications applied to the individual controls that effectively make them easier to achieve. The reason for this is because these organizations only handle Controlled Unclassified Information (CUI) which is not classified but still considered sensitive or private. You can think of CUI as Personally Identifiable Information (PII) with some additional information tacked on like proprietary business information, law enforcement information or information that could affect national security. The control families that have been removed from NIST 800-171 are: Contingency Planning (CP) Program Management (PM) Privacy Control (PR) If you’re interested in reading more, you can read a full breakdown of NIST SP 800-53 and the requirements to achieve compliance here. Manage & automate NIST compliance NIST SP 800-171 is comprehensive and extraordinarily intimidating. As agencies are determining whether to accomplish meeting these compliance standards, they have to decide whether to DIY the entire process or work with 3rd party vendors that are experts in the process. Anchore, in partnership with its many federal service integrator (FSI) partners, has shepherded countless agencies through this process. Anchore provides a number of different features that not only make meeting controls simple but automate the continuous process of maintaining compliance in real time. The Anchore Enterprise platform was specifically designed to address the software supply chain security of federal agencies. The platform is an automated system that manages a comprehensive inventory of the entire software supply chain, automatically scans all software packages for vulnerabilities and compliance, and utilizes pre-built policy packs to report and ensure compliance standards are met.If you’re interested in learning more about how Anchore can help your organization meet its compliance requirements, learn more by visiting our public sector page. ### New Author Josh Bressers ### Videos ### Reports ### Playbooks ### Datasheets ### Webinars ### White Papers ### Case Studies ### Search ### Press & News ### DevSecOps How Anchore’s DevSecOps solutions help From source to deployment, the Anchore platform protects your organization at every step of the way. Want to learn more about DevSecOps and its role in software supply chain security? Explore Anchore’s platform with a 15-day free trial. What you get with Anchore Anchore provides DevSecOps integrations for your existing toolchain. Whether looking for known vulnerabilities, secrets, malware, or insecure configurations, Anchore Enterprise searches continuously for issues and enables security teams to triage, remediate, and report more efficiently. Continuous vulnerability scanning Automate vulnerability scans at each step in the development lifecycle, including source code repositories, CI/CD pipelines, container registries, and Kubernetes platforms. Identify vulnerabilities, malware, secrets, and security risks. Explore container vulnerability scanning here.  Frictionless developer experience 100% API coverage and fully-documented APIs enable developers to work seamlessly in the tools they already use. Automate scanning in source code repos, CI/CD pipelines or container registries through native integrations. Streamline remediation of issues with notifications through GitHub, JIRA, Slack, and more. Track SBOM drift Detect SBOM drift in the build process to uncover unexpected dependencies, malicious efforts to infiltrate builds, and inadvertent errors. Alert security staff to changes in SBOMs so they can be assessed for risks or malicious activity. Discover SBOM management solutions. Fewer false positives Optimize development velocity with an unparalleled signal-to-noise ratio. Get fewer false positives with vulnerability results that are pinpointed to a specific distro. Use flexible policies to prioritize based on severity or availability of a fix. Provide "corrections" and "hints" that improve results going forward. Add vulnerabilities to allowlists to prevent ongoing alerts. Shift security left Find and fix vulnerabilities earlier to keep development moving. Start automated scanning in the development and build phases to uncover new dependencies and vulnerabilities. Continue scanning against container registries and pre-deployment to ensure components remain secure. See the product here. Start Free Trial Why Anchore Led by a team with extensive experience in automation and cloud computing, Anchore was founded to enable efficient security workflows at scale. Rather than require changes to tools or processes, Anchore Enterprise integrates with your existing environment to check the security posture of your applications and surface the most critical issues at every stage of development.  Anchore Enterprise enables a “shift left” approach which ensures issues are identified as early as possible and flagged with the appropriate teams. As software moves from CI/CD to Runtime, Anchore Enterprise catalogs the components at every stage and ensures that insecure software is never put into production.  ### Log4j Resource Hub ### 2022 Software Supply Chain Security Report ### Legal ### Careers ### Integrations ### Resources ### Blog ### Public Sector ### Enterprises ### SBOM Management Achieve supply chain security with SBOM Management & Automation High-quality SBOMs enable security teams to scale with their developers. With more visibility, it is easier to secure the open source attack surface and identify open source and third party components in your software supply chain.Explore Anchore’s approach to SBOM management with a 15 day free trial. START FREE TRIAL What you get with Anchore Anchore Enterprise is a modern, SBOM-powered software composition analysis (SCA) tool that identifies every software component in cloud native applications. It provides an end-to-end software supply chain security system with total visibility, deep inspection, automated enforcement, expedited remediation and trusted reporting. Benefit from end-to-end SBOM management Staying secure and compliant requires continuous, end-to-end insight into your software stack. By generating SBOMs in the development cycle, developers and security teams can identify and manage the software in their supply chains and mitigate issues before they reach runtime. Anchore Enterprise provides end-to-end SBOM coverage so organizations can create a data trail and extended view of the supply chain history of a particular product. Gain visibility with comprehensive SBOMs Identify all your software components present in both internally developed and third-party supplied software, including direct and transitive dependencies. Generate SBOMs at each stage in the development process from source code repositories and CI/CD pipelines to container registries and runtimes. Leverage in-depth metadata down to the file level to enforce policy rules. Respond quickly to new vulnerabilities with an SBOM repository Keep SBOMs in a centralized repository for complete visibility and ongoing monitoring, even post-deployment. Speed up incident response time for new vulnerabilities — including zero-day vulnerabilities like Log4j — by searching the SBOM repository to easily identify impacted applications. Track SBOM drift to detect suspicious activity Detect SBOM drift in the build process to uncover unexpected dependencies, malicious efforts to infiltrate builds, and inadvertent errors. Alert security staff to changes in SBOMs so they can be assessed for risks or malicious activity. Gain an application-level view of software supply chain risk Tag and group all artifacts associated with a particular application, release, or service to enable reporting on vulnerabilities and risks. For each new application release, leverage tag-based reporting to pinpoint vulnerabilities for fast remediation. Identify unsanctioned components with automated SBOM analysis Define policies based on rich SBOM metadata for packages, files, configuration data, secrets, malware, and more. Get alerted automatically when disallowed software is identified. Build trust by sharing SBOMs Produce SBOMs for individual artifacts or entire applications. Easily share SBOMs to external customers, compliance auditors, and internal security teams to build trust about the ingredients of your software. Explore Anchore SBOM Why Anchore Since its inception, Anchore has been putting SBOMs at the heart of our technology and products. Anchore is the creator and sponsor of Syft, one of the most popular open source SBOM generation tools, which has attracted hundreds of developers and thousands of users. This community has helped produce one of the most flexible and accurate SBOM tools in the market.With this open source tool at its heart, Anchore Enterprise automatically generates and stores SBOMs from every stage of the software development process from source code to runtime, then analyzes for new vulnerabilities to streamline SBOM management. Anchore Enterprise supports standards such as SPDX and CycloneDX in addition to the richer, native Syft format and enables you to group SBOMs together to accurately reflect the contents of your application. ### Vendors ### Open Source ## Popups ### Video Popup 2 ### Video Popup Secure & Enforce ### Self Guided Tour Popup Take a tour of product VIEW DEMO ### Video Popup ### Example: Auto-opening announcement popup You can see how this popup was set up in our step-by-step guide: https://wppopupmaker.com/guides/auto-opening-announcement-popups/ ## Solutions ### Federal Compliance ### Open Source Security ### Container Security Solution ### FedRAMP Vulnerability Scanning ### Container Vulnerability Scanning ### Kubernetes Images Scanning ### Container Registry Scanning ### CI/CD Security & Compliance ### Container Compliance ## Integrations ### VMWare ### Travis CI ### Slack ### Red Hat ### Rancher ### Pivotal Concourse ### Oracle Wercker ### NIST ### Microsoft Teams ### Jira ### JFrog ### JetBrains ### Jenkins ### Harbor ### Google Cloud ### GitLab ### GitHub ### Docker Hub ### CloudBees ### CircleCI ### Canonical ### Azure ### Atlassian ### AWS ### Kubernetes ## Testimonials ### Dreamfactory ### Infoblox ### Platform One - Iron Bank ### Cisco ### ebay ### GitLab ### GitHub ### Air Force ### NVIDIA 2 ### NVIDIA ### Platform One ## Partners ### Canonical ### TD SYNNEX ### AWS ### Blue Ivy Partners ### Swish Data ### Sterling Computers ### Meadowgate Technologies ### GovSmart ### FCN, Inc. ### Clearshark ### Google Cloud ### Bion ### Thundercat ### Fierce ### Dark Wolf ### Cloudfit ### Carahsoft ### Harbor ### Atlassian ### CircleCi ### Microsoft Partner ### CloudBees ### GitLab ### RedHat ### GitHub ## Press ### Experts say software’s shrug at security is over, thanks to the EU’s Cyber Resilience Act Anchore's Josh Bressers on the EU's Cyber Resilience Act and the value of enforcing mandatory cybersecurity standards. Read more. ### Anchore Extends Best-in-Class Container Security Offering with Bring Your Own SBOM Support Anchore Enterprise is a powerful, cost-effective, and compliant management, monitoring, and automation tool for understanding and securing complex software supply chains. SANTA BARBARA, CA – May 21, 2025 – Anchore, the market leader in software composition analysis for cloud native platforms, today announced the next phase of its SBOM strategy with the release of Anchore SBOM. With the addition of Anchore SBOM, Anchore Enterprise now provides a centralized platform for viewing, managing and analyzing Software Bill of Materials (SBOMs), including the capability of "Bringing Your Own SBOMs". Organizations can now gain comprehensive visibility into the software components present in both their internally developed and third-party supplied software to identify and mitigate security and compliance risks. Driven by the rise of open source software (OSS), which Gartner estimates makes up 70% to 90% of any given software application, only 15% of organizations feel confident in their management practices. Software composition analysis, policy-driven curation of packages, and SBOMs have become increasingly critical for accelerated and safe consumption of OSS, including AI LLMs. Anchore SBOM can import and process SBOMs generated by any tool adhering to the SPDX or CycloneDX standards, creating transparency and establishing a comprehensive inventory of software components and dependencies, regardless of their origin. Demand for software supply chain transparency is surging due to regulations (NIS2, US Cybersecurity Executive Orders, and CRA, EU’s Cyber Resilience Act), industry mandates (PCI DSS), and sector-specific requirements (FDA, SEC and others). This makes SBOMs essential for enterprises and government agencies seeking critical visibility. Key features and benefits of Anchore SBOM include: Bring your own SBOM: Import SBOMs in SPDX (versions 2.1-2.3), CycloneDX (versions 1.0-1.6), and Syft native formats - analyze components and vulnerabilities.  Validate SBOMs: Assess uploaded SBOM quality to ensure they meet schema standards and contain necessary data for vulnerability scanning. Manage SBOMs centrally: Store and group SBOMs to reflect logical organization structures for easier management, control, analysis, and reporting for enhanced collaboration across business and engineering functions.  Identify vulnerabilities: Identify and report vulnerabilities within uploaded SBOMs for fast and efficient remediation. Prioritize and triage with Anchore Score: A prioritized vulnerability rating based on CVSS Score and Severity, EPSS, and CISA KEV data reduces noise and drastically improves triage time. "At Anchore, we know that securing the software delivery pipeline is necessary to secure the software being delivered; that’s why we secure software during development, delivery, and post-deployment. We built Anchore Enterprise to be embedded into the CI/CD pipeline - it analyzes OSS risks, enforces policy gates throughout delivery, and scans continuously thereafter. SBOMs are at the core of how we establish trust in the delivery pipeline and therefore in the software you are delivering,” says Neil Levine, SVP of Product at Anchore. “ Our flagship customers, NVIDIA, Cisco, US Navy, and Department of Defense, have been, for years, relying on our SBOM centric approach to security to gauge their risks and meet the highest level of security standards.” Anchore Enterprise not only analyzes and stores software information for organizations, but provides a strategic platform for security, engineering, procurement, and legal teams to access, understand, and secure highly complex software supply chains. Anchore represents 10 years of implementing DevSecOps as part of an automated shift left approach to secure software development and continuously managing risks with open source software.  Additional Resources: Read the announcement blog   Sign up for the Launch Webinar About Anchore: Anchore is a leader in software supply chain security for modern cloud-native environments. Our SBOM powered software composition analysis embeds continuous security and compliance checks at every stage of the software development process for early detection.  Large enterprises and government agencies use Anchore Enterprise to create comprehensive software bills of materials, continuous visibility, vulnerability management, compliance enforcement, and trust in their software supply chain.  ### Anchore: Keeping Your Code Shipshape with SBOMs! See the full segment with Truth in IT here.   ### Anchore Survey Shows Only 1 in 5 Organizations Have Full Visibility into Their Open Source Software Components The survey highlights that 78% plan to increase their use of SBOMs. Compliance drives hardening the software supply chain as organizations must meet 4.9 government regulations and standards on average.  Santa Barbara, CA – November 7, 2024 - Anchore today released its third report of executive insights into managing software supply chain security practices. The Anchore 2024 Software Supply Chain Security Report found that 76% of respondents prioritize software supply chain security as the effects of software supply chain attacks intensify, while 21% of the victims of supply chain attacks reported a significant impact on their organization. As attacks like SolarWinds, XZ, and Log4j grow more sophisticated, the remediation expenses, risk of financial losses, and reputational damage are further heightened. Gartner predicts that by 2025, 45% of organizations worldwide will have experienced attacks on their software supply chains, a three-fold increase from 2021. Visibility into Open Source Software Remains a Challenge The survey shows that organizations need help to verify the security of open source and third party software. Only 1 in 5 respondents are confident that they fully understand all the components and dependencies in their software. As a result, 78% of organizations plan to increase their use of SBOMs in the next 18 months, with 32% planning to significantly increase SBOM use. Compliance Emerges as a Key Driver in Software Supply Chain Security Initiatives Survey respondents report compliance as a key driver of software supply chain security initiatives. With that, organizations now comply with an average of 4.9 regulations and standards, and 35% report a significant effort to comply with government regulations and standards.  Highlights of the report include:  76% say that software supply chain security is a significant or top priority. 59% of organizations have a cross-functional or dedicated team focused on software supply chain security. Only 21% are very confident they have visibility into all open source dependencies. 78% plan to increase their use of SBOMs in the next 18 months. 77% are concerned about the impact of embedded AI libraries on their software supply chain security. “Mounting software supply chain risk is driving organizations to take action. This report shows a 200% increase in organizations making software supply chain security a top priority and growing use of SBOMs,” said Josh Bressers, vice president of security at Anchore. “While we’ve seen a lot of data highlighting the threat landscape, this survey offers a different perspective into the experiences and practices of the organizations that are the targets of software supply chain attacks. We’re able to see how organizations are responding internally to those threats.” Read the executive summary of the Anchore 2024 Software Supply Chain Security Report here or download the full report and associated graphs here. About the Anchore 2024 Software Supply Chain Security Report This report provides a view of practices for securing the software supply chain as provided by 106 leaders and practitioners involved in software supply chain security. Their responses provide a unique perspective on current security practices and challenges from executives and practitioners within organizations. The survey was conducted during August and September 2024.  About Anchore Anchore is a leader in software supply chain security and enables organizations to protect  applications against attacks. Anchore technology embeds continuous security and compliance checks at every stage of the software development process.  Large enterprises and government agencies use Anchore solutions to generate a comprehensive software bill of materials, pinpoint vulnerabilities, identify malware, and discover unprotected credentials that can lead to hacks and ransomware.  With an API-centric approach, Anchore solutions integrate into the tools developers already use to detect issues earlier, saving time and lowering the cost to fix vulnerabilities. To learn more visit www.anchore.com.   Media Contact: Brandie Gerrish press@anchore.com ### NVD slowdown leaves thousands of vulnerabilities without analysis data ### NIST's Vuln Database Downshifts, Prompting Questions About Its Future ### NIST National Vulnerability Database Disruption Sees CVE Enrichment on Hold ### Anchore Reports Strong Success in Federal and Enterprise Markets, Team Growth Adoption in global defense agencies and new software releases accelerate momentum SANTA BARBARA, CALIFORNIA - November 14, 2023 - Anchore, Inc., the leading experts in software supply chain security and federal compliance, today announced strong growth and continued business momentum heading into 2024. Amidst a challenging macroeconomic environment, Anchore saw sustained demand for its SBOM-powered software composition analysis platform as organizations scramble to meet increasing government and regulatory compliance requirements. Building upon significant adoption in the U.S. defense sector, Anchore has witnessed demand for the secure software factory reference model on a global scale. This accelerated momentum has created a strong tailwind for Anchore to reach profitability in 2024. “Despite the broader economic hurdles, we're ecstatic to see continued growth in demand for Anchore's security solutions," remarked Saïd Ziouani, Anchore CEO. "And our growth beyond the U.S. underscores the robust demand and significance of Anchore's offerings worldwide. Entities like NATO and the U.K. Ministry of Defence are aligning with Anchore for a hardened security posture, just as the U.S. DoD and government agencies have for nearly five years.  Anchore has established a solid foundation for scalability, and we look forward to our next phase of expansion.” Continued Market Penetration Anchore continued its market penetration in the U.S. federal sector with new customers within the U.S. Air Force, U.S. Army, U.S. Marine Corps, U.S. Navy, and the U.S. Dept. of Homeland Security. Anchore now works to secure mission critical defense projects delivered by all prime and major federal systems integrators such as Northrop Grumman, General Dynamics, Lockheed Martin, Leidos, SAIC, Booz Allen Hamilton, Jacobs Federal, and Sierra Nevada Corporation. Additionally, Anchore added more Managed Service Providers into its partner ecosystem, including the U.S. Navy’s Black Pearl offering (in conjunction with Sigma Defense) and Second Front System’s Game Warden. Just as Anchore has quickly become recognized as the software composition analysis tool of choice in the U.S. defense sector, numerous ally countries and global entities including the U.K. Ministry of Defence, Australian Dept. of Defence and NATO have selected Anchore as their security vendor of choice for cloud native DevSecOps. In addition to strong momentum within the global public sector, Anchore welcomed more industry-leading enterprises driven by vulnerability and governmental/regulatory compliance related use cases. New Advisors Add Industry Acumen  In preparation for continued growth and advancement in 2024, Anchore added two new industry leaders to its advisory team. Kelsey Hightower is a well-known industry thought leader who co-founded KubeCon and served on the governing board of the Cloud Native Computing Foundation. Kelsey previously held the role of Distinguished Engineer at Google where he helped set industry standards and build cloud native products and services. Nic Chaillan was the first Chief Software Officer at the U.S. Air Force and U.S. Space Force and the driving force behind Platform One, the Air Force’s DevSecOps software factory that set the standard for secure software development across the Dept. of Defense. Nic also created the  DoD’s Enterprise DevSecOps Reference Architecture, now in use at multiple software factories throughout the U.S. Dept. of Defense. Open Source Community Traction Anchore’s open source projects, Syft and Grype, saw strong growth in community adoption and contributions. With over 11k GitHub stars and hundreds of contributors, Syft and Grype have become the tools of choice for SBOM creation and SBOM vulnerability scanning with open source developers. Anchore and community contributions include support for Azure Linux, Elixir, Erlang, R, NiIx, and Swift. Syft continues to support existing and emerging standards with updates for CycloneDX 1.5, SPDX 2.3 and OpenVEX. Anchore also released a new open source project, Vunnel, for use with Syft and Grype.  Vunnel was introduced in April and enables open source developers to contribute new vulnerability sources used by Grype to scan software for vulnerabilities. Additions to the Executive Bench As the company continues to advance and expand, Anchore has added two enterprise software industry veterans to its management team. Lester Wade joined Anchore as Vice President of Customer Success after leading technical teams at Amazon Web Services and Google. Jamie Wakelin has joined as Vice President of Enterprise Sales and Commercial Partnerships, having previously served in senior sales roles at ServiceNow, DXC, and Hewlett Packard Enterprise. Core Technology Advancements Anchore’s flagship product, Anchore Enterprise, reached a milestone with the release of 5.0 in November. Building on a year of development, Anchore Enterprise 5.0 includes a brand new reporting console that enables users to preview and schedule reports that indicate any non-compliant assets. In addition, 5.0 delivers new agents to support the scanning of SBOMs in Amazon ECS in addition to the existing coverage for Amazon EKS, Google GKE, and Azure AKS. Advancements also include updated policy pack controls to assist with NIST 800-218 compliance, the standard that reflects the Secure Software Development Framework (SSDF). Anchore Enterprise 5.0 now includes integrations with ServiceNow and Harness which complement its support for existing platforms such as GitLab, GitHub, and Jenkins. For more information about Anchore or to view current job openings, go to www.Anchore.com. About Anchore Anchore enables organizations to speed digital transformation and reduce risks by streamlining the development of secure and compliant cloud-native applications. Anchore’s solutions integrate with existing DevOps toolchains to automate security and compliance checks throughout the software development lifecycle. Organizations can reduce costs and accelerate time to market by remediating security and compliance issues early and continuously. Headquartered in California with offices also in Boston and the UK, Anchore’s customers include large enterprises and government agencies that require secure and compliant cloud-native applications. To learn more about Anchore’s solutions, visit www.Anchore.com. ### Anchore Expands Federal Footprint with $1.58M Tactical Funding Contract Award Recent contract, new customer installations, and marketplace listings further advance Anchore’s presence in the federal market. Santa Barbara, CA – October 27, 2022 - Today Anchore announced a $1.58M tactical funding award to extend its Small Business Innovation Research (SBIR) Phase II contract with the United States Air Force (USAF) Platform One (P1) program.  The tactical funding award is to provide 12 months of work in critical areas that build on Anchore’s deep expertise and institutional knowledge to advance P1 goals.  With the award, Anchore and P1 will deliver new innovative capabilities for securing software supply chains. “It is important now, perhaps more than ever before, to be proactive about software supply chain security in order to stay ahead of current and emerging threats.  Anchore’s role in this contract award is to continue developing technology that identifies and illuminates the constantly evolving software components that are used to compose critical infrastructure across a broad spectrum of programs,” said Dan Nurmi, CTO of Anchore.  “We’re proud to partner with the P1 team and happy to see that this contract will continue into the future to help secure our nation’s critical software systems.” “Anchore’s partnership with P1 continues to advance software security across the Department through innovative technical solutions and modern, industry standard security practices,” said Colonel Timothy Helfrich, Senior Materiel Leader, Cyber Systems Group, USAF.  “P1’s mission is to transform how the Department of Defense (DoD) delivers warfighter capability through innovative frameworks, collaborative culture, and secure software.  Adversaries attempt to compromise our national defense daily, and the software supply chain is a growing attack vector.  At P1, security is not an afterthought, it is the first thought.  Anchore’s industry standard software bill of materials (SBOM) formats help Iron Bank publish SBOMs for broad consumption and track for unexpected drift to mitigate supply chain risk for the Department of the Air Force.” In the Executive Order on Improving the Nation’s Cybersecurity, President Biden encourages federal agencies to mandate the use of SBOM as a best practice to understand software dependencies and components to prevent malicious activity.  Anchore’s software supply chain tools automate compliance checks with pre-built policy packs for U.S. government standards, including the DoD, Defense Information Systems Agency STIG, CISA, FedRAMP, NIST, and Center for Internet Security benchmarks. In addition, Anchore’s software container scanning capabilities are included in the U.S. DoD Container Hardening Guide and Container Image Creation and Deployment Guide to help federal agencies maintain a strong security posture when working with containerized applications. Federal Footprint Expansion Anchore technology is deployed across a wide number of DoD agencies and programs.  Anchore’s solutions are used specifically to identify and remediate critical vulnerabilities and malware, ensure strict adherence to government compliance standards, and improve the overall security posture of these and other critical aircraft and warships, conventional and nuclear weapons systems, and key intelligence centers and software factories. Anchore Available in the Federal Marketplace As Anchore continues to collaborate with federal agencies, its offerings are now available for purchase through the online government marketplaces of GSA Advantage and Second Generation IT Blanket Purchase Agreements (2GIT).  Anchore’s software supply chain security tools can be purchased through contract vehicles at pre-negotiated rates and terms, enabling federal agencies to easily procure solutions to institute proactive cyber hardening and software supply chain security measures. For more information about Anchore’s secure public sector solution that automates compliance with stringent government security standards, visit anchore.com. About Anchore Anchore is a leader in software supply chain security and enables organizations to protect  applications against attacks. Anchore technology embeds continuous security and compliance checks at every stage of the software development process.  Large enterprises and government agencies use Anchore solutions to generate a comprehensive software bill of materials, pinpoint vulnerabilities, identify malware, and discover unprotected credentials that can lead to hacks and ransomware.  With an API-centric approach, Anchore solutions integrate into the tools developers already use to detect issues earlier, saving time and lowering the cost to fix vulnerabilities. Anchore is recognized on the Forbes 2022 list of America’s Best Startup Employers.  To learn more visit anchore.com. Media Contact: Brandie Gerrish press@anchore.com ### Anchore Joins Docker Extension Program to Enable Deep Analysis of Container Images With this extension, Anchore is further integrating into the Docker ecosystem with tools that help improve software supply chain security Santa Barbara, Calif - May 10, 2022 - Anchore, a leader in software supply chain security, today announced that it is the newest member of the Docker Extension Program. The Anchore Docker Desktop Extension conducts a powerful analysis that proactively scans and displays the software components in each container image. With this instant analysis of container images, developers and security engineers have the information available to make informed decisions about the security of their software supply chain. The Anchore Docker Desktop Extension is unique because it seamlessly scans each container image behind the scenes, without requiring developers to request an individual scan or wait for a scan to complete. Instead, the Anchore extension instantly displays the number and type of packages along with vulnerabilities segmented by severity level, allowing users to easily search for specific packages or vulnerabilities. The extension analyzes the container images locally, keeping all data on the user’s machine. It is built on the open source Syft and Grype tools and continually monitors the set of images with unlimited, automatic scans. “Docker is obsessed with developer ergonomics and is committed to filling and improving the developer experience gap,” said Webb Stevens, Docker’s SVP of Secure Software Supply Chain. “We welcome Anchore to the Docker Extension marketplace, expanding the applications and capabilities available for millions of registered Docker developers.” This new extension further expands integration points between Anchore and the Docker ecosystem. Last month Anchore and Docker collaborated to launch the ‘docker sbom’ command that generates an SBOM for any Docker image. Anchore also recently released a new version of its AnchoreCTL tool which now can upload SBOMs generated by the ‘docker sbom’ command to Anchore Enterprise, enabling organizations to centrally store their SBOMs and continually monitor them for any new vulnerabilities that may arise. According to the Gartner® Innovation Insight for SBOMs report, “the lack of visibility and transparency into proprietary and open-source dependencies within the software supply chain exacerbates security and compliance risks.” It also states that “software engineering teams often lack the tools, practices and standards to systematically discover and share details about vulnerable software packages across the organization.” Docker Extensions demonstrates Docker’s commitment to improving the developer experience by bringing the tools developers use most to an environment where they can more easily focus on innovation, and less time on everything else. Inclusion of the Anchore Docker Desktop Extension provides a frictionless developer experience while providing transparency into the software supply chain. *Gartner, “Innovation Insight for SBOMs”, Manjunath Bhat, Dale Gardner, Mark Horvath, February 14, 2022. GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved. About Anchore Anchore is a leader in software supply chain security and enables organizations to protect cloud-native applications against software supply chain attacks. Anchore technology embeds continuous security and compliance checks at every stage of the software development process to prevent security risks from reaching production. Large enterprises and government agencies use Anchore solutions to generate a comprehensive software bill of materials, pinpoint vulnerabilities, identify malware, and discover unprotected credentials that can lead to hacks and ransomware. With an API-centric approach, Anchore solutions integrate into the tools developers already use to detect issues earlier, saving time and lowering the cost to fix vulnerabilities. Anchore is recognized on the Forbes 2022 list of America’s Best Startup Employers. To learn more visit anchore.com. Media Contact: Brandie Gerrish press@anchore.com ### Anchore Named to the Forbes 2022 List of America’s Best Startup Employers Inclusion on the annual list highlights Anchore’s focus on employees, culture, and growth Santa Barbara, Calif - March 16, 2022 - Today Anchore announced it was recognized by Forbes with inclusion on their 2022 List of America’s Best Startup Employers. Companies included on the list are rated on multiple areas, including company culture and employee engagement. Anchore was selected out of 2,500 startup companies in the United States that were founded between 2012 and 2019. “Anchore was founded on three core values of kindness, ownership, and openness. Our goal from the very beginning was to create an inclusive and supportive environment, and we’ve built on those values to create a strong foundation for creativity and innovation,” said Said Ziouani, CEO of Anchore. “We actively invest in our people, our culture, and the community. We're honored to be recognized by Forbes as one of America's best startup employers.” To be included in the fourth annual Forbes list of America’s Best Startup Employers, each company must have at least 50 employees. Judges graded each startup based on employer reputation, employee satisfaction and company growth. Each startup had to be founded organically and not created out of an existing enterprise to qualify for consideration. Anchore experienced over 150% growth in ARR from the prior year, as organizations looked to proactively secure their software supply chains against growing exploits. This momentum is supported by new product capabilities, exploding adoption of open source tools, and continued work to proactively prepare its customers for inevitable future breaches and hacks. With this, Anchore’s team has continued to expand and it currently has 80 employees in the United States. Details about the Forbes 2022 List of America’s Best Startup Employers and the full article can be found here. To learn more about Anchore and available career opportunities visit anchore.com. About Anchore Anchore is a leader in software supply chain security and enables organizations to protect cloud-native applications against software supply chain attacks. Anchore technology embeds continuous security and compliance checks at every stage of the software development process to prevent security risks from reaching production. Large enterprises and government agencies use Anchore solutions to generate a comprehensive software bill of materials, pinpoint vulnerabilities, identify malware, and discover unprotected credentials that can lead to hacks and ransomware. With an API-centric approach, Anchore solutions integrate into the tools developers already use to detect issues earlier, saving time and lowering the cost to fix vulnerabilities. To learn more visit anchore.com. Media Contact: Brandie Gerrish press@anchore.com ### Anchore Continues Expansion into Software Supply Chain Security Market New customer adoption and open source community involvement fuel expansion Santa Barbara, Calif - January 28, 2022 - Anchore today announced strong results in the software supply chain security market over the last year. With concerns about the security of the software supply chain driving demand for automated tooling and a rise in SBOM adoption across the industry, Anchore has delivered new product capabilities, seen exploding adoption of its open source tools, and continued to proactively prepare its customers and organizations for inevitable future breaches and hacks. Software Supply Chain Security Focus 2021 started with the fallout of the SolarWinds SUNBURST attack and ended with multiple exploits against the Log4j zero-day vulnerability, highlighting the critical importance of securing the software supply chain. According to the Anchore 2022 Software Supply Chain Security Report, 62 percent of organizations were affected by a software supply chain security attack last year. Software suppliers face increased risk with 73 percent impacted by an attack. The report also highlights that organizations are responding to these risks with 54 percent placing a heavy focus on securing the software they build and use. While the U.S. Executive Order on Improving the Nation’s Cybersecurity highlights the software bill of material (SBOM) as a critical foundation for supply chain security, 76 percent of organizations plan to increase use of SBOMs next year. The importance of SBOMs, combined with the need for automated tooling and continuous security checks in the development process, is driving significant growth in Anchore’s software supply chain management solutions. “Recent security breaches have catapulted the topic of software security to the forefront of business conversations everywhere. Software supply chain security does not just impact the software industry, today every organization needs to bolster their security practices to reduce risk in their cloud-native applications,” said Said Ziouani, CEO of Anchore. “Last month’s Log4j zero-day vulnerability underscores the need for organizations to use SBOMs and automated tooling to reduce the risk of successful attacks and speed remediation of the next zero-day vulnerability.” Customer Growth In 2021 Anchore saw 2.5 times growth in ARR from the prior year, as organizations looked to proactively secure their software supply chains against growing exploits. Anchore customers include the largest global enterprises as well as government agencies. In 2021 Anchore welcomed leading Fortune 100 organizations to the customer roster, joining dozens of Global 500 organizations and major software companies that use Anchore technology to secure their software supply chains. New customer NVIDIA uses Anchore to secure containers for AI, machine learning and high-performance computing on the NVIDIA NGC. Anchore more than tripled its government customers in 2021, adding the U.S. Space Force’s Kobayashi Maru program along with numerous programs across the U.S. Air Force, U.S. Department of Defense, U.S. General Services Administration, U.S. Navy, U.S. Marine Corps and the Defense Information Systems Agency (DISA). Anchore also expanded its relationship with the U.S. Air Force Platform One program with a $4.6M contract to harden its software supply chain with a focus on container scanning technology and services. Product Expansion Over the past twelve months the company advanced its software supply chain management capabilities, with multiple releases to the Anchore Enterprise platform. New capabilities include: Broadened coverage of the software supply chain by making the security status of running images visible to developers and security teams reducing the risk of insecure code being included in production applications. Expanded remediation capabilities with remediation recommendations and automated workflows. A new FedRAMP policy pack that enables software vendors and cloud service providers to identify and resolve compliance issues for containerized applications and shorten the timeline to achieve a FedRAMP authority to operate (ATO) certification. Ability to automate STIG checks for cloud-native applications and provide a unified view of both vulnerabilities and STIG compliance vulnerabilities that are required by the U.S. Department of Defence applications. A new policy pack that alerts on vulnerabilities found in the CISA catalog of Known Exploited Vulnerabilities. Rapid Adoption of Open Source Tools Anchore saw accelerating adoption of its two open source software supply chain security tools that easily integrate into development processes and toolchains. Syft, a tool that performs deep inspection of container images and filesystems to generate an SBOM, now has over 400,000 downloads, representing a 150% increase in the last 5 months. Grype, a vulnerability scanner, now has over 500,000 downloads, an 80% increase in the same time period. Together, Syft and Grype have garnered over 4,500 stars on GitHub, a tenfold increase since the beginning of 2021. Updates to Syft and Grype in 2021 include the ability to generate accurate SBOMs and vulnerability reports via plugins to popular CI/CD systems including GitHub, GitLab, and Jenkins. Syft has also added support for the Software Package Data Exchange (SPDX) standard which makes it easy to share data across systems and organizations. SPDX is an internationally recognized ISO standard for SBOMs that is sponsored by the Linux Foundation. "The ability to produce accurate SBOM and vulnerability results from a wide variety of software artifacts has led to growing adoption of Syft and Grype by both the open source community and end users, particularly as more and more project maintainers are looking to include security tooling directly into their development environments," said Daniel Nurmi, CTO and co-founder of Anchore. "During the initial and on-going response to the Log4j zero-day vulnerability, practitioners were able to quickly and easily identify the presence of Log4j across their software environments using Anchore's Syft and Grype tools, even when the library was nested several levels deep inside Java archives, which has led to a large jump in downloads and usage." “As enterprises look to accelerate their operational velocity, an increasing number of them are focusing on improving their developer experience. The challenge facing these organizations is how to offer a frictionless experience to their developers while simultaneously improving their overall security posture," said Stephen O'Grady, Principal Analyst with RedMonk. "One approach that's growing in popularity is to integrate API-driven security resources into their existing development toolchains. This is exactly the opportunity that Syft and Grype were constructed for." For more information about Anchore’s technology and software supply chain security offerings go to Anchore.com. About Anchore Anchore is a leader in software supply chain security and enables organizations to protect cloud-native applications against software supply chain attacks. Anchore technology embeds continuous security and compliance checks at every stage of the software development process to prevent security risks from reaching production. Large enterprises and government agencies use Anchore solutions to generate a comprehensive software bill of materials, pinpoint vulnerabilities, identify malware and discover unprotected credentials that can lead to hacks and ransomware. With an API-centric approach, Anchore solutions integrate into the tools developers already use to detect issues earlier, saving time and lowering the cost to fix vulnerabilities. To learn more visit anchore.com. Note to Editors: Experts available for comment upon request Press Contact: Brandie Gerrish press@anchore.com ### Anchore Welcomes Josh Bressers as Vice President of Security The industry veteran and podcaster will utilize his seasoned perspective of software supply chain security to shape new software security practices  Santa Barbara, Calif - November 16, 2021 - Anchore, a leader in software supply chain security, today announced that Josh Bressers has joined the company as vice president of security. In this new role he will bring two decades of expertise in building secure software development processes to help champion supply chain security practices, advance Anchore’s product vision, and engage with open source communities around these issues. Bressers brings a seasoned perspective from building software supply chain security practices and leading product security teams at Elastic and Red Hat.  He also has an active track record in the open-source community. Bressers helped open source projects coordinate the response to security vulnerabilities such as Shellshock and GHOST, and was one of the creators of the open source security mailing list for sharing of vulnerabilities. Bressers is a frequent blogger and speaker on security topics and an industry thought leader with two podcasts, Hacker History and Open Source Security. “Software supply chain security continues to be a critical issue that impacts nearly every industry, and big problems require bold new ideas. In joining Anchore, I hope to draw from my experience securing open source projects to help secure the world's software supply chains. Anchore is proving to be a leader in supply chain security and I’m happy to be on board to help organizations address these critical challenges,” said Josh Bressers, vice president of security at Anchore. “We’re in a pivotal time for software supply chain security, and companies need trusted solutions to proactively evaluate their software security posture and remediate supply chain risks. This is why we couldn’t be more excited to welcome Josh to Anchore. His deep experience in securing software will help guide our approach as Anchore continues to develop software supply chain solutions for organizations both small and large,” commented Said Ziouani, CEO and Cofounder of Anchore. With 64% of organizations having been impacted by a supply chain attack in the past year, according to an Anchore survey, government agencies and large enterprises are working to embed security and compliance into their development workflows to better protect their software supply chain. Anchore provides Anchore Enterprise, a platform for securing software supply chains, as well as trusted open source tools Syft, to generate a software bill of materials (SBOM), and Grype, for container image vulnerability scanning. A key element in reducing the software supply chain security risk profile is adopting new security measures throughout the software development process, this includes creating SBOMs for all software components and tracking and managing SBOMs throughout the development process to identify tampering that can indicate security threats. To learn more about Bressers’ vision on the future of software supply chain security read his debut blog here or learn more about Anchore’s technology solutions at anchore.com. About Anchore Anchore is a leader in software supply chain security and enables organizations to protect cloud-native applications against software supply chain attacks. Anchore technology embeds continuous security and compliance checks at every stage of the software development process to prevent security risks from reaching production. Large enterprises and government agencies use Anchore solutions to generate a comprehensive software bill of materials, pinpoint vulnerabilities, identify malware and discover unprotected credentials that can lead to hacks and ransomware. With an API-centric approach, Anchore solutions integrate into the tools developers already use to detect issues earlier, saving time and lowering the cost to fix vulnerabilities. To learn more visit www.anchore.com. ### Anchore Adds Support for SPDX to Syft SBOM Generator Tool New SPDX support advances continued open source collaboration for best practices in software supply chain security  Santa Barbara, Calif - October 11, 2021 - Anchore, a leader in software supply chain security, today announced that Syft, an open source tool that generates a Software Bill of Materials (SBOM), now has the ability to generate information using the Software Package Data Exchange (SPDX) standard which makes it easy to share data across systems and organizations.  Because Syft is easily integrated into a variety of build systems and development tools,  developers can now use Syft to automatically generate SBOMs in the SPDX format as part of their existing build processes. Syft users now have an interoperable format to communicate SBOM information including the software components, dependencies and versions that are embedded in software container images and file systems. “As both enterprises and the open source community continue to adopt the SPDX standard, it’s beneficial to have Syft support SPDX formats that streamline the exchange of SBOMs within and between organizations,” said Kate Stewart, Vice President of Dependable Systems at the Linux Foundation. “We want to encourage use of reliable and innovative open source tools to help secure the software supply chain and prevent breaches. Producing SBOMs in the SPDX format is an essential element of that.” SPDX, an internationally recognized ISO standard for SBOMs, is sponsored by the Linux Foundation and is an important element of software supply chain security. The recent United States Cybersecurity Executive Order defines new requirements for an SBOM as part of federal government procurement. Anchore is an active member of the Linux Foundation and supports its continued adoption of SPDX as a way to easily communicate SBOM information across the software supply chain. In a recent Anchore survey, 60% of respondents indicated that securing the software supply chain is a top or significant area of focus. “With recent software supply chain attacks infiltrating internal software build processes, organizations can leverage SBOMs during the development process to monitor changes in the SBOM and reduce the risk of successful attacks,” said Daniel Nurmi, Anchore CTO and Co-Founder. "Syft is a powerful tool that can inspect container images and source code repositories alike, reporting on dependencies and software packages, all the way down to individual file information. This type of deep inspection and insight makes it possible to identify unintentional or malicious content being installed during application builds." For more information about SPDX go to www.spdx.dev. For more information about the Syft open source SBOM generator tool go to www.Anchore.com/opensource.  About Anchore Anchore is a leader in software supply chain security and enables organizations to protect cloud-native applications against software supply chain attacks. Anchore technology embeds continuous security and compliance checks at every stage of the software development process to prevent security risks from reaching production. Large enterprises and government agencies use Anchore solutions to generate a comprehensive software bill of materials, pinpoint vulnerabilities, identify malware and discover unprotected credentials that can lead to hacks and ransomware. With an API-centric approach, Anchore solutions integrate into the tools developers already use to detect issues earlier, saving time and lowering the cost to fix vulnerabilities. To learn more visit www.anchore.com. ### Anchore Demonstrates How to Further Software Supply Chain Security with Signed SBOMs and Security Reports Demonstration workflow shows how organizations can use open source tools Syft, Grype, and Sigstore to share accurate data about the contents and security status of software  Santa Barbara, Calif - September 20, 2021 - Anchore, a leader in software supply chain security, today introduced a demonstration workflow that shows how software producers can create, sign, and share accurate software bill-of-material (SBOM) and security reports to help further the security of software supply chains. As the United States government implements the Executive Order on Improving the Nation’s Cybersecurity, federal agencies expect to require SBOMs from their software vendors. Commercial enterprises can also benefit from verifiable documents that attest to the contents and security status of the software they use. The demonstration workflow leverages open source tools Syft, Grype, and Sigstore’s Cosign to create and share signed attestations about the security of software applications delivered in containers. The workflow details how software producers can:  Use Sigstore’s Cosign to sign a software container image Use Syft to produce a comprehensive SBOM that details the contents of the container image and then use Sigstore to create a signed attestation for its validity Use Grype to produce a vulnerability report for a container image and then use Sigstore to create a signed attestation for its validity Deliver the signed container image, SBOM and vulnerability report to their software customer or user Software users can then verify the software container image, SBOM, and vulnerability report for an accurate picture of both the contents and security status of the software they are using. The demonstration workflow was developed in partnership with Sigstore and builds off the complementary capabilities of open source tools, Syft, Grype, and Sigstore’s Cosign. A detailed blog on how to implement this demonstration workflow is available here and sample code and documentation is available here.  Why Software Supply Chain Security is Important The need for a secure software supply chain increases in priority and urgency each day due to continued and persistent cyberattacks. The widespread use of DevOps processes to speed cloud-native software development has led to a concurrent rise in the use of software containers. An Anchore survey of 400+ large enterprises showed that 65% of respondents have a significant number of applications running in containers.  Containers make it easy to package software during development, but can bring in multiple open source software (OSS) dependencies as applications move through the DevOps pipeline, creating new security requirements. As a result, 63% of survey respondents plan to increase container use and 60% report improving supply chain security as a top initiative. Anchore and Sigstore Cosign engineers are working in tandem to educate the open source community and raise industry awareness of software supply chain security and available tools to proactively secure the development pipeline. More information about SBOMs and the importance of container attestation for SBOM signing is available in this blog post. About Anchore Anchore is a leader in software supply chain security and enables organizations to protect cloud-native applications against software supply chain attacks. Anchore technology embeds continuous security and compliance checks at every stage of the software development process to prevent security risks from reaching production. Large enterprises and government agencies use Anchore solutions to generate a comprehensive software bill of materials, pinpoint vulnerabilities, identify malware and discover unprotected credentials that can lead to hacks and ransomware. With an API-centric approach, Anchore solutions integrate into the tools developers already use to detect issues earlier, saving time and lowering the cost to fix vulnerabilities. To learn more visit anchore.com.    ### Anchore Awarded $4.6M Phase III SBIR Contract with U.S. Air Force Platform One Contract includes continued software innovation, application development and container hardening security  SANTA BARBARA, CALIFORNIA - September 1, 2021 - Anchore today announced a $4.6M Small Business Innovation Research (SBIR) Phase III contract from the U.S. Air Force Platform One program to deliver container scanning technology, services, and expertise over a two year period. Anchore’s deep expertise and detailed institutional knowledge will deliver experience, guidance and coordination for the implementation of Anchore solutions and DevSecOps practices to help advance Platform One program goals. The U.S. Air Force initiative is a DevSecOps enterprise service for agencies across the entire U.S. Department of Defense (DoD). Phase III of the SBIR contract award indicates a proven concept and initiates commercialization for broad use across government agencies. This contract validates Anchore’s contribution to the Platform One program as it transitions to commercial availability across the Department of Defense.  “Our engineers have been embedded with the Platform One team for years, and the collaboration has resulted in security innovations that help protect our country from new and persistent threats,” said Dan Nurmi, CTO of Anchore. “We’re happy to see that this contract extension confirms broader adoption of DevSecOps practices and methodology across federal agencies. This continued working partnership is confirmation that small businesses, such as Anchore, can provide important contributions to the security of our nation’s critical software systems.” Anchore provides the container security technology needed to harden new software and application builds to meet DoD security and compliance regulations. As part of the contract Anchore will create and maintain container security infrastructure and provide container security subscriptions to support technological innovation at scale. This includes the build and management of end-to-end container hardening pipelines, improved security for software applications, and intake and analysis of OSS components. “Teaming with Anchore to shape the container hardening process for Platform One has been highly successful. Anchore’s strong understanding of our goals has translated into strong support for adoption of modern DevSecOps practices. We expect our continued partnership through this new contract will support broader adoption of the Platform One offerings across the DoD,” said Lt. Col. Brian Viola, Materiel Leader for Platform One.  For more information about Anchore go to anchore.com.  About Anchore Anchore accelerates the development of secure and compliant cloud-native applications. Anchore’s container security solutions seamlessly embed continuous security and compliance checks throughout the software development process. From sourcing to CI/CD pipelines to production, Anchore’s solutions protect the software supply chain and prevent container security risks from reaching production. Using Anchore as part of the DevSecOps toolchain creates a reliable way to detect issues earlier, save developers time, and lower the cost to fix vulnerabilities. Built with an open source foundation, Anchore solutions provide transparency into source code and leverage the benefit of peer reviews.  Headquartered in California with offices in Virginia and the UK, Anchore customers include large enterprises and government agencies that require secure and compliant cloud-native applications. To learn more about Anchore’s solutions, visit anchore.com.     # # #  Media Contact:  Brandie Gerrish press@anchore.com  ### Anchore Vulnerability Scanning Tools Integrated with GitLab 14 New integration of open source tool Grype with GitLab 14 provides deep container inspection to aid in securing the software supply chain Santa Barbara, Calif - August 2, 2021 - Anchore today announced that its open source Grype vulnerability scanner tool is now available in GitLab 14’s container scanning feature. Grype, leveraging Syft libraries, performs a deep inspection of container image contents to create an accurate software bill-of-materials (SBOM) and then produces high-fidelity vulnerability data that can be used to harden the software. This data can be used natively within GitLab workflows and interfaces. The focus of the GitLab 14 release is to deliver a modern DevOps platform with increased velocity, trust and visibility. The integration of Grype enables security-minded engineers and developers to investigate and remediate vulnerability findings with analysis of the software package. “We are excited to embed these robust container scanning features of Grype within GitLab’s complete DevOps platform. Our built-in security enables DevOps velocity with confidence and these added features from Anchore bring even greater security for cloud native applications,” said Sam White, Senior Product Manager at GitLab.  “Grype was selected for this integration based on its ease of use and accuracy of results. This is especially important as we see increased demand from software developers and engineers to protect against rising software supply chain attacks by embedding security early in the development process,” said Neil Levine, Vice President of Product at Anchore. “Organizations who want to gain end-to-end visibility and control over container security can use Grype and Syft in conjunction with Anchore Enterprise.”     Grype provides the transparency and detail necessary to investigate why the image vulnerability is being reported. As part of the integration with GitLab 14, users gain valuable information about the vulnerabilities discovered in order to empower users to triage and remediate them with available patches.  Get more information on how to get started with GitLab’s integration with Grype in this blog post.  About Anchore Anchore accelerates the development of secure and compliant cloud-native applications with solutions that enable software supply chain security, from vulnerability scans to generating a software bill of material. Anchore’s container security solutions seamlessly embed into the DevOps toolchain with continuous security and compliance checks early in the software development process. From sourcing to CI/CD pipelines to production, Anchore’s solutions protect the software supply chain and prevent container security risks from reaching production. Using Anchore as part of the DevSecOps toolchain creates a reliable way to detect issues earlier, save developers time and lower the cost to fix vulnerabilities. Built with an open source foundation, Anchore solutions provide transparency into source code and the benefit of peer reviews.  Anchore customers include large enterprises and government agencies that require secure and compliant cloud-native applications. To learn more about Anchore’s solutions, visit www.Anchore.com.   # # #  ### Anchore Enterprise 3.1 Simplifies STIG Compliance for U.S. Federal Agencies New capabilities automate STIG checks for cloud-native applications and provide security teams with a unified view of STIG compliance and vulnerabilities Santa Barbara, Calif - July 1, 2021 - Anchore today announced the release of Anchore Enterprise 3.1 that includes simplified STIG compliance for U.S. federal agencies. New capabilities in the federal edition automate STIG checks for cloud-native applications and provide security teams with a unified view on STIG compliance, vulnerabilities and other security issues.  The federal edition of Anchore Enterprise 3.1 simplifies the process of DISA STIG checks for containers running in a Kubernetes cluster. Federal agencies that need to comply with STIGs can automate a typically time intensive process. The resulting STIG checks are aggregated and correlated to provide security teams with a unified view on compliance issues and vulnerabilities. Anchore’s approach to STIG validation is based on deep experience working with the U.S. Department of Defense and branches of the U.S. Armed Forces. The new STIG compliance capability performs the checks on running container instances using a lightweight agent which passes the result back to the Anchore Enterprise. The results are queried programmatically through an API that can be used to prove the compliance of an image for auditors or used as part of a policy to warn or fail a deployment.   “This new capability is based on collaboration with multiple agencies in the federal government and addresses the pain points they identified in automating the STIG process in a containerized environment,” said Neil Levine, Vice President of Product for Anchore. “Now, federal agencies can streamline DevSecOps for cloud-native applications by combining automated STIG checks and other security controls for a unified view of compliance.”    STIGs are configuration standards for information systems across the U.S. Department of Defense to ensure software security and decrease vulnerabilities. More information can be found at the DoD Cyber Exchange website. Learn more about Anchore Enterprise 3.1 and the federal edition with automated STIG compliance checks here.  About Anchore Anchore accelerates the development of secure and compliant cloud-native applications with solutions that enable software supply chain security, from vulnerability scans to generating a software bill of material. Anchore’s container security solutions seamlessly embed into the DevOps toolchain with continuous security and compliance checks early in the software development process. From sourcing to CI/CD pipelines to production, Anchore’s solutions protect the software supply chain and prevent container security risks from reaching production. Using Anchore as part of the DevSecOps toolchain creates a reliable way to detect issues earlier, save developers time and lower the cost to fix vulnerabilities. Built with an open source foundation, Anchore solutions provide transparency into source code and the benefit of peer reviews.  Anchore customers include large enterprises and government agencies that require secure and compliant cloud-native applications. To learn more about Anchore’s solutions, visit www.Anchore.com.     ### Survey of Large Enterprises Shows 64 Percent Affected by a Software Supply Chain Attack in the Last Year Debut survey of security and development leaders identifies trends in securing the software supply chain as containers become the common delivery model  Santa Barbara, CA - June 17, 2021 - Today Anchore released its findings in the first report of executive insights into enterprise software supply chain practices, called the Anchore 2021 Software Supply Chain Security Report. As the leader in continuous security and compliance for cloud-native applications, Anchore is spearheading the enterprise-focused viewpoint of how to secure the software supply chain. The report includes insights gathered from large enterprises with at least 1,000 employees on supply chain attacks, container security, DevOps toolchains and the most popular container platforms.  The report shows that containers are becoming a preferred delivery model, with 65% of respondents reporting a significant number of applications running in containers. While technology-focused industries lead the way in container adoption, traditional industries, such as healthcare and financial services, also report significant container use. Containers make it easy to package software during development, but they commonly bring in multiple open source (OSS) or third-party dependencies as applications move through the DevOps pipeline, creating new software supply chain risks. In the survey, 38 percent of advanced container users indicated that they see containerized applications as more risky than traditional applications. As a result, technical leaders ranked open source security and gaining a full understanding of the software bill-of-materials as top challenges. “This report highlights that 60% of respondents have made securing the software supply chain a top initiative for 2022,” said Dan Nurmi, CTO and Co-Founder of Anchore. “This is critical as software supply chain attacks rise in frequency and intent. It’s an important reminder that now is the time for IT leaders, security executives and members of the C-suite to empower their teams to implement new practices and tools that secure the software supply chain.”  Highlights from the report include: 84% of respondents plan to increase container use and 29% will increase container use significantly  While many orgs are scanning containers, most report challenges in identifying vulnerabilities (86%), too many false positives (77%), and getting developers to spend time remediating issues (77%)  Top initiatives are increasing container use (63%) and improving supply chain security (60%) The full report with data findings and associated graphs is available here. About the Anchore 2021 Software Supply Chain Security Report This report compiles the responses of 425 IT, Security, and DevOps leaders to identify the latest trends on how large organizations are adapting to these new security challenges of the software supply chain. As enterprises increasingly move to cloud-native software, this report includes a special focus on the platforms, tools and processes used to secure the growing volume of software containers.  About Anchore Anchore accelerates the development of secure and compliant cloud-native applications with solutions that enable software supply chain security, from vulnerability scans to generating a software bill of material. Anchore’s container security solutions seamlessly embed into the DevOps toolchain with continuous security and compliance checks early in the software development process. From sourcing to CI/CD pipelines to production, Anchore’s solutions protect the software supply chain and prevent container security risks from reaching production. Using Anchore as part of the DevSecOps toolchain creates a reliable way to detect issues earlier, save developers time and lower the cost to fix vulnerabilities. Built with an open source foundation, Anchore solutions provide transparency into source code and the benefit of peer reviews.  Anchore customers include large enterprises and government agencies that require secure and compliant cloud-native applications. To learn more about Anchore’s solutions, visit www.Anchore.com.   ### Anchore Wins New U.S. Space Force SBIR Contract to Enforce Security Compliance Standards Anchore will help drive down costs of new application development and increase the overall security of the U.S. Space Force’s containerized applications SANTA BARBARA, CALIFORNIA - May 19, 2021 - Today Anchore, the leader in continuous security and compliance for software containers, announced it has been awarded a Small Business Innovation Research (SBIR) Phase II contract through AFWERX, an innovation arm of the U.S. Air Force that solves challenges and increases effectiveness through innovation. With the new contract, Anchore will develop and implement container security enhancements and compliance automation for the U.S. Space Force’s software development pipeline to modernize how the U.S. shares data and space intelligence with allies.  The U.S. Space Force’s Kobayashi Maru program will track objects in space and provide access to data on objects circling the earth, as part of a space domain awareness with ally countries. Under the new contract Anchore will partner with the Kobayashi Maru program team to shift compliance earlier into the software development cycle to drive down the cost of new application development and increase the security of the U.S. Space Force’s containerized applications. “Our team is excited to be working with Anchore to provide the best container security in the industry for all of our Kobayashi Maru customers,” said Col. Jennifer Krolikowski, senior materiel leader for the U.S. Space Force Kobayashi Maru Program. In addition, Anchore will research and develop software enhancements to implement the Security Technical Implementation Guide (STIG) checks into the software development pipeline. STIG is a standard for enforcing cybersecurity requirements for applications and operating systems. The automation of these checks will be enabled through the development of software capabilities within Anchore. “With a program of this magnitude, it is critical that the software handling space data continues to be secure and protected, using the latest technology and techniques available in cybersecurity. Adding enforcement of security compliance standards earlier into the software development cycle means that violations can be detected and addressed as they arise and are resolved quickly, resulting in more efficient and comprehensive security enforcement across the development lifecycle,” said Dan Nurmi, CTO at Anchore. For more information about Anchore go to www.anchore.com.  About Anchore Anchore accelerates the development of secure and compliant cloud-native applications. Anchore’s container security solutions seamlessly embed continuous security and compliance checks throughout the software development process. From sourcing to CI/CD pipelines to production, Anchore’s solutions protect the software supply chain and prevent container security risks from reaching production. Using Anchore as part of the DevSecOps toolchain creates a reliable way to detect issues earlier, save developers time and lower the cost to fix vulnerabilities. Built with an open source foundation, Anchore solutions provide transparency into source code and the benefit of peer reviews.  Headquartered in California with offices in Virginia and the UK, Anchore customers include large enterprises and government agencies that require secure and compliant cloud-native applications. To learn more about Anchore’s solutions, visit www.Anchore.com.     ### Anchore Secures Containers for AI, Machine Learning and HPC on NVIDIA NGC Anchore advances marketplace container security momentum with growing enterprise demand for container scanning technology SANTA BARBARA, CALIFORNIA - May 13, 2021 - Today Anchore, the leader in continuous security and compliance for software containers, announced an expanded collaboration with NVIDIA for container scanning to ensure the security of software hosted on NVIDIA’s NGC catalog. NVIDIA has used Anchore container scanning technology since 2019 and the expanded partnership will include vetting third-party software available on NGC. NGC  is a curated collection of GPU-optimized artificial intelligence (AI), machine learning (ML), and high-performance computing (HPC) container images that simplify and accelerate end-to-end workflows. The catalog will now integrate Anchore Enterprise container and policy scanning technology to perform automated security checks before containers are published. This integration will rely on Anchore technology to perform security scans for detecting:  Software vulnerabilities (CVEs, RHSAs, GHSAs, and others) Container image metadata violations (Dockerfile instructions, layer history) Credential leaks (passwords, tokens, access keys) Permissive service network exposures (open ports) “Anchore is working with organizations across a variety of industries to secure their container build pipeline by embedding automated security checks and policy controls during the development process,” said Saïd Ziouani, CEO of Anchore. “NVIDIA’s use of Anchore’s enterprise solution gives developers and data scientists access to NGC software that has been vetted for security risks.” “Developers rely on NVIDIA’s NGC catalog for a wide variety of GPU-accelerated software,” said Adel Hallak, director of product management for NGC at NVIDIA. “Our use of Anchore’s scanning technology can help reassure them that the containers on NGC have been evaluated for critical security risks before they’ve been put into production.” Growing Demand for Securing Container Marketplaces  Anchore is used to secure both free and paid container marketplaces across a variety of industries and public sector organizations. The U.S. Department of Defense uses Anchore to secure and harden software containers for its Iron Bank repository as part of the Platform One initiative for DevSecOps. Enterprises in telecommunications, manufacturing, and technology industries also deploy Anchore to ensure the security of container images in marketplaces and catalogs that they provide to customers or partners. “Incorporating Anchore’s container scanning technology to harden images in the Platform One Iron Bank repository has allowed us to drastically increase our security and understanding of the Bill of Materials of third party containers. The Anchore technology is an essential element to how we approach secure software development,” said Nic Chaillan, Chief Software Officer, U.S. Air Force. For more information about Anchore go to www.anchore.com.  About Anchore Anchore accelerates the development of secure and compliant cloud-native applications. Anchore’s container security solutions seamlessly embed continuous security and compliance checks throughout the software development process. From sourcing to CI/CD pipelines to production, Anchore’s solutions protect the software supply chain and prevent container security risks from reaching production. Using Anchore as part of the DevSecOps toolchain creates a reliable way to detect issues earlier, save developers time and lower the cost to fix vulnerabilities. Built with an open source foundation, Anchore solutions provide transparency into source code and the benefit of peer reviews.  Headquartered in California with offices in Virginia and the UK, Anchore customers include large enterprises and government agencies that require secure and compliant cloud-native applications. To learn more about Anchore’s solutions, visit www.Anchore.com.  ### Anchore Delivers New Automated Policies that Accelerate FedRAMP Compliance for Containerized Applications Offering will help organizations meet new FedRAMP vulnerability scanning requirements for containers SANTA BARBARA, CALIFORNIA - March 31, 2021 - Today Anchore, the leader in continuous security and compliance for containers, announced the release of a new FedRAMP policy pack. This proprietary policy scanning pack will help software vendors and cloud service providers identify and resolve compliance issues for containerized applications and shorten the timeline to achieve a FedRAMP authority to operate (ATO) certification. The new policy pack provides pre-built checks for FedRAMP controls that apply to containers. It will help organizations meet the supplemental requirements within the 6-month deadline specified in the Vulnerability Scanning Requirements for Containers document released by FedRAMP in March 2021. Use of Anchore and the FedRAMP policy pack will: Scan and assess images to identify which FedRAMP controls are failing and provide the specific changes needed to remediate the issue; Harden container images to meet FedRAMP scanning requirements; Embed the needed security and compliance checks into the container build, test, and orchestration pipeline; Monitor containers in the registry and running in production and ensure they have been scanned within the required 30-day scanning window; Generate a container workload artifact report for use with federal assessors and third-party assessor organizations (3PAO). “It is critical that enterprises remediate issues and identify vulnerabilities within containers and open source components, especially with the rise of software supply chain attacks,” said Daniel Nurmi, CTO and Co-Founder of Anchore. “By applying FedRAMP policies and mapping back to specific checks within the NIST 800 compliance control set, we’re helping companies expedite the time to reach FedRAMP authorization and reduce their costs to maintain compliance.” Learn how to expedite FedRAMP authorization of containerized applications in a free webinar on Thursday, April 8, 2021. Join Anchore engineers as they discuss the necessary steps to meet requirements of the FedRAMP vulnerability scanning requirements for containers: https://get.anchore.com/tips-to-accelerate-fedramp-for-containers/. For information on how Anchore can assist in the FedRAMP qualification process or to request a demo go to https://get.anchore.com/demo-request/. About Anchore Anchore accelerates the development of secure and compliant cloud-native applications. Our suite of container security solutions seamlessly embeds in the DevOps lifecycle with continuous security and compliance checks early in the software development process. From sourcing to CI/CD pipelines to production, Anchore’s solutions protect the software supply chain and prevent container security risks from reaching production. Using Anchore as part of the DevSecOps toolchain creates a reliable way to detect issues earlier, save developers time and lower the cost to fix vulnerabilities. Built with an open source foundation, Anchore solutions provide transparency into source code and the benefit of peer reviews. Headquartered in California with offices in Virginia and the UK, Anchore customers include large enterprises and government agencies that require secure and compliant cloud-native applications. To learn more about Anchore’s solutions, visit www.Anchore.com. # # #   ### New Anchore Enterprise 3.0 Release Delivers Major Upgrade to Secure the Software Supply Chain Added capabilities expand protection to all stages of the DevSecOps lifecycle, preventing security problems from reaching production applications  SANTA BARBARA, CALIFORNIA - February 2, 2021 - Today Anchore, Inc., the leading experts in continuous security and compliance for containers, announced release of a new major upgrade of its container security and compliance platform, Anchore Enterprise 3.0.  Modern cloud-native software applications include software components from internal and external sources that can introduce security risks at numerous points in the software development lifecycle. With the release of Anchore Enterprise 3.0 organizations can now protect against software supply chain threats from development to production and accelerate the delivery of secure,container-based software. New capabilities in this release include:  End-to-end container security from development to Kubernetes Anchore Enterprise 3.0 broadens coverage of the software supply chain by making the security status of running images visible to developers and security teams. This provides added layers of security and reduces the risk of security breaches caused by insecure code being included in production applications. Distributed scanning that integrates seamlessly with developer workflows Anchore Enterprise can now perform automated security checks locally on developer systems and within the CI/CD pipeline. This release includes new, lightweight tools that can be deployed at various points in the software development lifecycle and feed results back to the central Anchore Enterprise system to be processed based on organizational policies. Reduced false positives making developers more productive    Anchore Enterprise 3.0 provides new features that reduce false positives,  enabling developers to focus on the critical security issues that must be fixed. Users can now easily correct any misidentifications to ensure that future checks have fewer false positives. Security teams can leverage time-based allowlists that enforce SLAs for developers to address security while avoiding repeated alerts. Remediation recommendations that reduce time and cost to fix security issues  This release provides automated remediation suggestions for vulnerable containers and enables security teams to triage policy violations, select remediation options, and issue notifications through tools like Jira, Slack, Teams, Gitlab, GitHub, traditional email and more. As a result, security issues are fixed earlier in the development lifecycle, resulting in lower costs and fewer delays. “Digital transformation is driving companies and government agencies to improve their cybersecurity posture,” said Saïd Ziouani, CEO of Anchore. “With Anchore Enterprise 3.0 we’re expanding DevSecOps protections and reducing security risks by providing multiple layers of protection across the software supply chain. As organizations adopt ‘defense in depth’ strategies, they are seeking to significantly decrease the number of security issues that make it through to staging or production, where risks are higher and fixes are more costly. With this release we’re making it easier to automate security checks from the earliest stages of the software development lifecycle all the way through production.” Anchore will host a webinar “How to Secure Containers Across the SDLC with Anchore 3.0” on  March 9, 2021 at 1 pm ET. During the webinar experts will discuss how to automate security checks from development to Kubernetes deployment, implement distributed scanning that fits seamlessly in developer workflows, and more. Inquiries about Anchore Enterprise 3.0 can be sent to sales@anchore.com or visit www.anchore.com for more information.  About Anchore Anchore enables organizations to speed digital transformation and reduce risks by streamlining the development of secure and compliant cloud-native applications. Anchore’s solutions integrate with the DevOps toolchain to automate security and compliance checks throughout the software development lifecycle. Organizations can reduce costs and accelerate time to market by remediating security and compliance issues early and continuously. Headquartered in California with offices in Virginia and the UK, Anchore’s customers include large enterprises and government agencies that require secure and compliant cloud-native applications. To learn more about Anchore’s solutions, visit www.Anchore.com.    # # #  Note to press: Images and captions available for publication Executive interviews available upon request Media Contact:  Brandie Gerrish press@anchore.com  ### Anchore and GitLab Announce New Integration to Automate Container Security and Compliance Processes and Speed Application Delivery The ongoing partnership between Anchore and GitLab streamlines DevSecOps processes and reduces re-work for developers SANTA BARBARA, CALIFORNIA -- January 28, 2021 --  Today Anchore, the leading providers of continuous security and compliance for containers, has announced an integration with GitLab, the complete DevSecOps platform, delivered as a single application. With this integration, organizations will be able to automate security and compliance checks from the early stages of the development cycle, speeding software development and reducing risks. Anchore also announces it has joined the GitLab partner program. Anchore now integrates seamlessly with GitLab to simplify security and compliance workflows for developers and to enable DevSecOps practices. Anchore performs deep container image scanning that identifies vulnerabilities and surfaces a wide range of security and policy infractions, including vulnerabilities and other risks during development. Together, the Anchore and GitLab security integrations will: Display vulnerability results of container scans directly in GitLab security dashboards Surface these findings in merge requests that identify changes needed to remediate issues Enable updating of merge requests with a package version to resolve vulnerabilities Seamlessly manage the risk profile in one place through GitLab’s Risk Management Framework (RMF), reducing the friction of typical software security scanning  “Digital transformation has changed software development practices as organizations seek to deliver applications more quickly and update them more frequently. This shift, combined with increasing cybersecurity threats, requires developers to implement security and compliance checks throughout the DevSecOps life cycle. The integration between Anchore and GitLab helps to automate these DevSecOps best practices for enterprises, government agencies, and open source communities,” said Saïd Ziouani, Anchore CEO and Cofounder. ”Strengthening the software development security and compliance postures of enterprises and public sector organizations is paramount to the missions of both GitLab and Anchore. We are pleased to partner through this integration to help our joint customers to increase their speed to mission delivery and to reduce the risks associated with software development,” said GitLab Vice-President of Global Channels, Michelle Hodges. The U.S. Department of Defense (DoD) uses both Anchore and GitLab as part of their Platform One Initiative to speed the development of secure and compliant software. Anchore is used to develop hardened containers for Iron Bank (DoD’s software repository for containers) based on DoD best practices.  ”Today, more than ever before, security is the most essential aspect of software development for government and critical infrastructure—and is the core of the DoD DevSecOps Initiative and Platform One. Now developers have the ability to push validated code into production on an ongoing basis, resulting in shorter development cycles, less debugging, and more rapid feature development,” said Major Robert Slaughter, Director of DoD Platform One. GitLab and Anchore will continue to explore how this integration enables those in the public sector to achieve digital transformation during the upcoming “A Day in the Life of a Developer:  Accelerating Software Delivery without Compromising Security” webinar on March 4, 2021 at 2 pm ET.  Enterprise organizations seeking to implement security and compliance checks throughout the DevOps lifecycle can learn more in the Anchore whitepaper, “Fundamentals of Container Security.” Related links: DoD DevSecOps Initiative Platform One About Anchore Anchore enables organizations to speed digital transformation and reduce risks by streamlining the development of secure and compliant cloud-native applications. Anchore’s solutions integrate with the DevOps toolchain to automate security and compliance checks throughout the software development lifecycle. Organizations can reduce costs and accelerate time to market by remediating security and compliance issues early and continuously. Headquartered in California with offices in Virginia and the UK, Anchore’s customers include large enterprises and government agencies that require secure and compliant cloud-native applications. To learn more about Anchore’s solutions, visit www.Anchore.com.   About GitLab GitLab is a DevOps platform built from the ground up as a single application for all stages of the DevOps lifecycle enabling Product, Development, QA, Security, and Operations teams to work concurrently on the same project. GitLab provides a single data store, one user interface, and one permission model across the DevOps lifecycle. This allows teams to significantly reduce cycle times through more efficient collaboration and enhanced focus. Built on Open Source, GitLab works alongside its growing community, which is composed of thousands of developers and millions of users, to continuously deliver new DevOps innovations. More than 100,000 organizations from startups to global enterprises, including Ticketmaster, Jaguar Land Rover, NASDAQ, Dish Network, and Comcast trust GitLab to deliver great software faster. All-remote since 2014, GitLab has nearly 1,300 team members in 69 countries. To learn more about GitLab’s solutions, visit https://about.gitlab.com.  # # #  Media contact: Brandie Gerrish press@anchore.com ### Anchore Continues Remarkable Growth and Business Momentum Strong revenue growth, market expansion, and technology advancements accelerate growth  SANTA BARBARA, CALIFORNIA - January 14, 2021 - Anchore, Inc., the leading experts in continuous security and compliance for containers, today announced strong growth and continued business momentum heading into 2021.  Anchore began the 2020 calendar year by raising $20 million in Series A funding. Following that, Anchore experienced 500% revenue growth year-over-year and quadrupled its number of employees. The company has also fielded remarkable customer growth, supported federal security innovation, launched a partner program, and issued several new product advancements.  “As we pause to reflect on 2020, it was a year of sustained growth for Anchore,” said Saïd Ziouani, CEO of Anchore. “Digital transformation is accelerating the adoption of container security, and as we welcome new customers to the Anchore family, we’ve scaled our business to deliver on product innovation and capitalize on the market opportunity.” Customer Growth Throughout 2020 Anchore secured new Fortune 1000 companies across Information Technology, Finance, Aerospace and Defense, and Communication verticals. Increasing market demand in Europe prompted a new Anchore UK office to expand its global footprint and proximity to its growing European customer base.  Federal Innovation In the public sector, the Anchore Federal solution is being used to develop hardened containers for Iron Bank, the U.S. Department of Defense software repository for containers, and Platform One, the DoD Enterprise DevSecOps service. Anchore Federal is an approved container hardening tool in the Department of Defense Container Hardening Process Guide.  Anchore Federal helps government agencies certify their containers to the NIST 800-190 certification. Achieving a NIST 800-190 certification is a government-wide security standard that containerized applications must comply with before they go live in production. In addition, Anchore Federal’s end-to-end security and compliance help achieve FedRAMP guidelines, the United States government standard for security assessment, authorization, and continuous monitoring for cloud products and services. Anchore also won an AFWERX Small Business Innovation Research (SBIR) Phase II contract with the U.S. Air Force to advance capabilities by enabling innovators to simplify technology transfer and accelerate results. Partner Ecosystem Anchore launched a partner program to speed customers’ digital transformation and reduce risks by automating security and compliance checks early in the software development lifecycle.   The program brings Anchore and partners together to help companies and government agencies build DevSecOps toolchains and processes to meet business and mission objectives. Existing partners include GitHub, GitLab, Atlassian, CloudBees, Red Hat, Microsoft, and Carahsoft. Technology Advancements Anchore demonstrated significant technology advances by expanding Anchore Enterprise 2.4  to focus directly on scanning, security, vulnerabilities, and operations. In the open-source space, Anchore introduced Syft and Grype open-source tools for security integration and agile performance. The tools analyze and scan container images and filesystems, allowing developers to enhance best practices within existing workflows and systems. For more information about Anchore or to view current job openings, go to www.Anchore.com.  About Anchore Anchore enables organizations to speed digital transformation and reduce risks by streamlining the development of secure and compliant cloud-native applications. Anchore’s solutions integrate with the DevOps toolchain to automate security and compliance checks throughout the software development lifecycle. Organizations can reduce costs and accelerate time to market by remediating security and compliance issues early and continuously. Headquartered in California with offices in Virginia and the UK, Anchore’s customers include large enterprises and government agencies that require secure and compliant cloud-native applications. To learn more about Anchore’s solutions, visit www.Anchore.com.   # # #  Media Contact:  Brandie Gerrish press@anchore.com ### Anchore Announces New Partner Program to Meet Growing Demand for DevSecOps The program provides solutions to help organizations develop secure and compliant cloud-native applications SANTA BARBARA, CALIFORNIA - December 16, 2020 -- Today Anchore, Inc., the leading experts in continuous security and compliance for containers, announced the launch of a new partner program to speed customers’ digital transformation and reduce risks by automating security and compliance checks earlier in the development lifecycle.  The program launches worldwide with existing partners such as GitHub, GitLab, Atlassian, CloudBees, Red Hat, Microsoft, Carahsoft, and many others. The program will bring together Anchore and partners to help companies and government agencies build DevSecOps toolchains and processes to meet their business and mission objectives. “As software delivery increasingly moves to containers and cloud-native technologies, organizations must fundamentally change their approach to security and compliance.  They can’t wait to fix security and compliance until the end of the software development lifecycle, but instead must shift left by continually checking the software applications and remediating issues earlier in the process,” remarked Saïd Ziouani, Anchore CEO and Cofounder. “With this new partner program, we’re formalizing our strategic relationships to create the flexible and integrated DevSecOps solutions that enterprises and government agencies have been requesting.” Anchore’s new partner program has three categories: Solution Providers, such as systems integrators, managed services providers, and security/compliance firms who provide clients with a complete end-to-end solution for continuous security and compliance across the software development lifecycle through to production environments. Channel Partners, such as value added resellers (VARs), who interact with clients and Anchore to scope deployment and enable the procurement of technologies needed for a complete continuous security and compliance solution. Technology Partners who integrate with Anchore to create compelling DevSecOps technologies to fuel innovative solutions for customers.    Supporting Partner Quotes: "As GitHub continues to focus on building the best experience for developers, it's critical to embed security into their workflow. With the Anchore GitHub Action, developers are able to surface container security findings directly through the GitHub code scanning UI. This empowers teams to ship more secure code, faster, and all within the native GitHub user experience,” said John Leon, VP of Business Development, GitHub. "Red Hat’s joint work with Anchore at the US Department of Defense has driven technology and services innovation such as hardened Red Hat UBI images, Anchore's Red Hat OpenShift Operator Certification, and joint DevSecOps services expertise,” said Lars Herrmann, Senior Director of Technology Partnerships, Red Hat. “With Red Hat Marketplace, we are making it easier for customers to find and purchase tools like Anchore that are tested, certified and supported on Red Hat OpenShift, and we've removed operational barriers to deploying and managing these technologies on Kubernetes-native infrastructure.” “We are excited to be included in Anchore’s new partner program,” said Natalie Gregory, Vice President of the team that manages Anchore at Carahsoft, which serves as Anchore’s Master Government Aggregator®. “Our Carahsoft team is committed to providing the public sector with the leading solutions to build out their DevSecOps pipelines, and we look forward to strengthening our partnership with Anchore under this program to better serve our government customers and reseller partners seeking to integrate security and compliance into their development processes.” New inquiries to join the partner program can be sent to partners@anchore.com or visit anchore.com/partners for more information. About Anchore Anchore enables organizations to speed digital transformation and reduce risks by streamlining the development of secure and compliant cloud-native applications. Anchore’s solutions integrate with the DevOps toolchain to automate security and compliance checks throughout the software development lifecycle. Organizations can reduce costs and accelerate time to market by remediating security and compliance issues early and continuously. Headquartered in California with offices in Virginia and the UK, Anchore’s customers include large enterprises and government agencies that require secure and compliant cloud-native applications. To learn more about Anchore’s solutions, visit www.Anchore.com.  # # # Media Contact: Brandie Gerrish press@anchore.com ### Anchore Unveils New Open Source Tools For Automated DevSecOps Pipeline Security Syft And Grype Integrate With Modern DevOps Environments For Security And Speed SANTA BARBARA, CALIF., OCTOBER 6, 2020 — Anchore, Inc., the leading experts in policy-based workflow and compliance, is launching a collection of new open source tools for automating DevSecOps pipeline security and analysis. Syft and Grype are the first in a collection of tools designed for integration and performance. The tools analyze and scan container images and filesystems, allowing developers to enhance best practices within existing workflows and systems. As cybersecurity breaches become more numerous and costly, traditional safeguarding tactics grow less effective. Incident response teams are often overwhelmed by having to constantly investigate the cause of previous breaches while developing new preventative measures as the pace of software delivery quickens. With Anchore developers have a unique opportunity to address problems before software is ever deployed and before an incident can occur.   “Our mission at Anchore is to give developers the tools they need to build security into their everyday tasks,” said Anchore CTO Daniel Nurmi. “That means they need to work seamlessly with a large collection of other tools and systems, providing instant results so developers can act immediately. Syft and Grype were designed for exactly that purpose, and are the first of many tools to come.” Syft analyzes container images and filesystems to create a Software Bill of Materials (SBOM), a comprehensive record of operating system packages and language artifacts. Using Syft, developers can inspect the contents of new software components before deciding to use them and maintain a comprehensive record of the third-party software included in their projects. Syft generates SBOMs that conform to the CycloneDX specification, providing interoperability with a range of software supply chain management tools. Grype scans container images and filesystems for known vulnerabilities, matching contents against Anchore Feed Service data compiled from multiple public data sources.  Developers can use Grype to discover vulnerable components quickly inside projects as they are created and take the appropriate steps for remediation. The Visual Studio Code extension for Grype brings vulnerability scanning directly into the developer’s environment, rescanning projects regularly to watch for emerging vulnerabilities. Developers can easily trigger a Grype vulnerability scan of GitHub projects using the Anchore Container Scan GitHub Action. “As an open source company, we do research and development in the open,” shared Anchore VP of Product Management Neil Levine. “In recent surveys, customers and community members agreed that security scanning can never be too fast and integration can never be too easy. We are looking forward to seeing how developers and DevOps teams use the tools while we focus on enhancing them with the policy features of our continuous compliance platform, Anchore Enterprise.” Syft and Grype are available immediately at toolbox.anchore.io. The Visual Studio Code extension can be found in the Visual Studio Marketplace, and the GitHub Action can be found in the GitHub Marketplace. Contributions, feature requests, and issue reports are welcome at the GitHub projects for each tool. ### Anchore Announces Availability of Anchore Enterprise 2.4 on Red Hat Marketplace Discover And Purchase Enterprise Applications And Deploy Across Any Cloud Or On-Premise With Red Hat Marketplace SANTA BARBARA, CALIF., SEPTEMBER 10, 2020 — Anchore today announced that Anchore Enterprise version 2.4 is now available through Red Hat Marketplace. Red Hat Marketplace is an open cloud marketplace for enterprise customers to discover, try, purchase, deploy and manage certified container-based software across environments—public and private, cloud and on-premises. Through the marketplace, customers can take advantage of responsive support, streamlined billing and contracting, simplified governance and single-dashboard visibility across clouds. To ensure continuous security and compliance as software containers are deployed, Anchore delivers a policy-based container security workflow and compliance platform for federal and enterprise DevOps and security teams. New features in Anchore Enterprise 2.4 focus on scanning, security, vulnerabilities and operations:   Support for virus scanning of containers, allowing customers to look for malware as part of their CI/CD workflow or before deployment from a registry.  Security reports have been expanded to allow users to compare two different container images, enabling developers to more easily spot issues in their applications from issues in the base operating system.   Vulnerability detection has been improved with support for a “hint” file which can prompt for detection of security issues in explicitly declared libraries, useful for language types like Go which don’t support a formal package management system.  Several operational improvements for larger deployments, such as better resource allocation among processes and automated ways to delete large sets of images from the system. “With the addition of Anchore to the Red Hat Marketplace, we are positioned to improve the way teams and organizations improve security across the SDLC and provide complete container security and compliance solutions to an even greater audience,” remarked Anchore CEO and Co-Founder Saïd Ziouani. “We’re excited to partner with Red Hat and accelerate the growing demand for Anchore’s container security workflow capabilities.” Built-in collaboration with Red Hat and IBM, Red Hat Marketplace delivers a hybrid multicloud trifecta for organizations moving into the next era of computing: a robust ecosystem of partners, an industry-leading Kubernetes container platform, and award-winning commercial support—all on a highly scalable backend powered by IBM. A private, personalized marketplace is also available through Red Hat Marketplace Select, enabling clients to provide their teams with easier access to curated software their organizations have pre-approved. “We believe Red Hat Marketplace is an essential destination to unlock the value of cloud investments,” said Lars Herrmann, senior director of technology partnerships, Red Hat. “With the marketplace, we are making it as fast and easy as possible for companies to implement the tools and technologies that can help them succeed in this hybrid multicloud world. We've simplified the steps to find and purchase tools like Anchore Enterprise version 2.4 that are tested, certified and supported on Red Hat OpenShift, and we've removed operational barriers to deploying and managing these technologies on Kubernetes-native infrastructure.” Red Hat Marketplace is designed to meet the unique needs of developers, procurement teams and IT leaders through simplified and streamlined access to popular enterprise software. All solutions available through the marketplace have been tested and certified for Red Hat OpenShift, allowing them to run anywhere OpenShift runs. A containers-based approach helps ensure that applications can be run and managed the exact same way, regardless of the underlying cloud infrastructure. This gives companies the flexibility to run their workloads on-premise or in any public or private cloud with improved portability and confidence that their applications and data are protected against vendor lock-in. Moreover, by combining Anchore Enterprise with Red Hat Openshift, agencies and enterprises are further protected by ensuring security best practices are applied from “code to cloud.”    ### Anchore Unveils Enterprise 2.4 With Expanded & Updated Capabilities U.S. Department of Defense Usage Drives Improvement On Private Sector Features SANTA BARBARA, CALIF., SEPTEMBER 1, 2020 — Anchore, whose policy-based container security workflow and compliance solutions platform enables federal and enterprise DevOps and security teams to deploy containers with confidence, today announced several updated product features for its users and customers in Anchore Enterprise 2.4. New feature upgrades in Anchore Enterprise 2.4 focus on scanning, security, vulnerabilities and operations:   Support for virus scanning of containers, allowing customers to look for malware as part of their CI/CD workflow or before deployment from a registry.  Security reports have been expanded to allow users to compare two different container images, enabling developers to more easily spot issues in their applications from issues in the base operating system.   Vulnerability detection has been improved with support for a “hint” file which can prompt for detection of security issues in explicitly declared libraries, useful for language types like Go which don’t support a formal package management system.  Several operational improvements for larger deployments, such as better resource allocation among processes and automated ways to delete large sets of images from the system. “Containers continue to be the driving force behind the adoption of agile and secure software development practices,” shared Anchore CEO and Co-Founder Saïd Ziouani. “By delivering actionable information through Anchore’s products in this latest release enables us to  further close the gap between feature velocity and security.” Currently used by the U.S. Department of Defense (DoD) with its Iron Bank — a  repository of digitally signed, binary container images that have been hardened —Anchore Enterprise 2.4 features have been driven by the DoD’s input and feedback. Recently, Anchore won an AFWERX Small Business Innovation Research (SBIR) Phase II contract with the U.S. Airforce to advance capabilities by connecting innovators to simplify technology transfer and accelerate results. The contract is focused on securing and hardening software containers through automated, policy-based DevSecOps workflows. For more information, visit Anchore.  About Anchore Anchore, Inc., based in Santa Barbara, CA, was founded in 2016 by Saïd Ziouani and Daniel Nurmi to help organizations implement secure container-based workflows using Anchore Engine and Anchore Enterprise. With Anchore, DevSecOps teams establish policy-based approaches to container compliance without compromising velocity. Customers range from Fortune 100 companies to small- and mid-sized customers. Anchore is trusted by modern software development companies across the globe.  Follow Anchore on Twitter or connect with Anchore on LinkedIn. ### Anchore Announces International Expansion To Meet Growing Demand Opens Location In United Kingdom, Plans For Additional Hires SANTA BARBARA, CALIF., JULY 29, 2020 — Today, Anchore, an industry leader in policy-based container security and compliance solutions for small businesses, major enterprises and federal and government agencies, announced it's increasing its global footprint by expanding with an office in the United Kingdom for the organization’s sales and customer support teams.  The new office is part of Anchore’s strategic growth plan fueled by customer demand and will provide value to new and existing businesses to include: Advanced container security solutions that span the entire lifecycle of containers from development to production for seamless application delivery and execution. Full visibility into the operational status of container-based software development for increased security across enterprise and private sector DevOps teams. Enforced security requirements in cloud-native environments to improve overall container security posture without sacrificing velocity. Anchore CEO and Cofounder Saïd Ziouani shared, “Our expansion into the UK increases our geographic reach, but more importantly, enables us to deliver superior customer support and solution enablement for our rapidly growing base of customers outside North America. Anchore’s UK-based office allows our company to create personalized experiences for new customers and drive container security adoption for modern DevSecOps teams large and small.” Anchore’s international growth is an integral part of its mission to transform the methodologies of developer operations by implementing container security as a shared responsibility across development, security and operations. For more information, visit Anchore.  About Anchore Anchore, Inc., based in Santa Barbara, CA, was founded in 2016 by Saïd Ziouani and Daniel Nurmi to help organizations implement secure container-based workflows using Anchore Engine and Anchore Enterprise. With Anchore, DevSecOps teams establish policy-based approaches to container compliance without compromising velocity. Customers range from Fortune 100 companies to small- and mid-sized customers. Anchore is trusted by modern software development companies across the globe.  To follow Anchore on Twitter, please visit www.twitter.com/anchore or Linkedin, visit www.linkedin.com/company/anchore. ### Anchore and Carahsoft Partner to Provide Container-Based Security to the Public Sector Anchore Solutions Now Available on Carahsoft SEWP, U.S. Air Force and Maryland COTS Contracts SANTA BARBARA, Ca. and RESTON, Va., July 01, 2020 (GLOBE NEWSWIRE) -- Anchore, experts in container workflow, analysis and security, and Carahsoft Technology Corp., The Trusted Government IT Solutions Provider®, today announced a partnership. Under the agreement, Carahsoft will serve as Anchore’s Master Government Aggregator™, making Anchore’s container security inspection platform available to the public sector through Carahsoft’s NASA Solutions for Enterprise-Wide Procurement (SEWP) V and Maryland Commercial Off the Shelf Software (COTS) contracts and the company’s reseller partners. In addition, Anchore is available under Carahsoft’s U.S. Air Force DevSecOps BOA, which is established to support the U.S. Air Force LevelUP mission as well as the DevSecOps goals of the greater Department of Defense (DoD) and related agencies. “We chose Carahsoft as our Master Government Aggregator based on their ability to effectively address the broad and complex public sector market,” said Craig Bowman, Vice President of Public Sector at Anchore. “Organizations building and deploying cloud-native technologies – including the DoD and civilian agencies such as the DHS, VA, and HHS – need Anchore to manage an increasingly fragmented and dynamic software supply chain. With this partnership, we can use policy-based compliance to secure workflows across the public sector.” Anchore’s container inspection and analytics platform provides deep container image inspection, analysis, scanning, reporting and verification to ensure that DevSecOps workflows run efficiently without compromise. This offering is comprised of three comprehensive solutions: Anchore Enterprise – A complete container security workflow solution that allows developers to perform detailed comprehensive image analysis to expose risks, unsafe configurations and other vulnerabilities. Enterprise can be implemented through an API or CLI, allowing seamless integration and full access to all of Enterprise’s capabilities. Anchore Engine – An open source tool that provides a centralized service for deep inspection on container images and vulnerability analysis to generate a software bill of materials. This highly customizable tool seamlessly integrates into CI/CD systems and continuously monitors policies when images are updated. Anchore Federal – A policy first container security tool suited for Federal agencies that meet security requirements ranging from DOD-IL-2 to DOD-IL-6. Anchore Federal’s image scanning and analysis provides end-to-end security and compliance that meets TIG and NIST standards and FedRAMP guidelines. As application modernization and complexity increases, developers are in need of tools that address and analyze container security without compromising momentum. Anchore’s container workflow, analysis and security platform mitigates risks and prevents vulnerabilities to containers while defining and enforcing security policies. “As container use in agencies’ DevSecOps pipelines continues to rise, the need to protect those containers from threats also increases,” said Natalie Gregory, Vice President of Sales at Carahsoft. “Anchore’s mission to help users create and deploy trusted software quickly and efficiently alleviates those risks. We look forward to working with Anchore and our reseller partners to bring security-first solutions to the public sector.” The Anchore container-based security platform is available through Carahsoft’s SEWP V contracts NNG15SC03B and NNG15SC27B, U.S. Air Force BOA FA8307-20-G-0004, and Maryland COTS contract 060B2490021. For more information, contact the Anchore team at Carahsoft at (703)-871-8570 or Anchore@Carahsoft.com; or register for “Red Hat and Anchore Discuss DevSecOps in the DoD” on Wednesday, July 15, 2020 at 3:00 p.m. EST. About Anchore Anchore, Inc., based in Santa Barbara, CA, was founded in 2016 by Saïd Ziouani and Daniel Nurmi to help organizations implement secure container-based workflows using Anchore Engine and Anchore Enterprise. With Anchore, DevSecOps teams establish policy-based approaches to container compliance without compromising velocity. Customers range from Fortune 100 companies to small- and mid-sized customers. Anchore is trusted by modern software development companies across the globe. For more information, visit anchore.com. About Carahsoft Carahsoft Technology Corp. is The Trusted Government IT Solutions Provider®. As a top-performing GSA Schedule and SEWP contract holder, Carahsoft serves as the Master Government Aggregator™ for many of its best-of-breed technology vendors, supporting an extensive ecosystem of manufacturers, value-added resellers, system integrators and consulting partners committed to helping government agencies select and implement the best solution at the best possible value. The company’s dedicated Solutions Divisions proactively market, sell and deliver Anchore, VMware, Amazon Web Services (AWS), Palo Alto Networks, Symantec, Veritas, McAfee, Dell, Adobe, F5 Networks, Google Cloud, ServiceNow, Open Source, Micro Focus Government Solutions, SAP, Salesforce, and Innovative and Intelligence products and services, among others. Carahsoft is consistently recognized by its partners as a top revenue producer and is listed annually among the industry’s fastest-growing and largest firms by CRN, Inc., Forbes, Washington Technology, The Washington Post, Washington Business Journal, and Bloomberg Government. Visit us at www.carahsoft.com or follow us on Twitter and Facebook. ### Anchore Delivers Hardened Version of Policy-Based DevSecOps Platform to the DoD RESTON, VA - June 23, 2020 – Anchore, Inc., experts in DevSecOps workflow for software containers, today announced that Anchore Federal has reached the criteria for hardened applications that adhere to the United States Department of Defense’s (DoD) security and compliance requirements, allowing the software to be used in security-sensitive DoD projects. The U.S. Air Force Platform One team, operating as the DoD Enterprise Service Provider for DevSecOps, provided the formal certification following an extensive evaluation. The hardened version of Anchore is delivered as container images that have achieved a Certificate to Field (CtF), meaning that they can be used in environments that meet requirements set forth in DISA STIGs and cybersecurity best practices defined within Platform One’s security policy for the use of containerized software. “Establishing force-wide DevSecOps capabilities as we move to Continuous Authority to Operate (ATO) remains a top priority for the US Air Force and Department of Defense,” said Nicolas Chaillan, Air Force chief software officers and co-lead for the DoD Enterprise DevSecOps initiative. “Authorizing DevSecOps vendors such as Anchore supports and enables this mission, ensuring that a wide variety of hardened software components are available to meet the needs of developers.” With Anchore, DevSecOps teams can enforce security and compliance policies against software containers. For the past 18 months, Anchore has been working with the DoD to implement DevSecOps practices to rapidly and securely deliver new software to its developers and warfighters. In fact, Anchore provides a core technology platform mandated as part of the DoD DevSecOps Reference Design. During this time the Anchore team has provided design and operational support for Platform One. “Wide-scale software application modernization is spreading across the DoD, and we’re just at the beginning,” said Craig Bowman, Vice President, US Public Sector at Anchore. “With their mission-critical, time-sensitive, and complex needs, we could not ask for a better partner to drive our roadmap forward. We are proud to see Anchore become available to DoD developers building security into their pipelines.” Today’s news follows Anchore’s announcement last week that it was awarded a $2.25 million AFWERX Small Business Innovation Research (SBIR) Phase II contract to secure and harden software containers using automated policy-based DevSecOps workflows to identify and apply security and compliance policies. For more information about Anchore and Platform One, visit anchore.com/usaf and software.af.mil/team/platformone. About Anchore Anchore, Inc., based in Santa Barbara, CA, was founded in 2016 by Saïd Ziouani and Daniel Nurmi to help organizations implement secure container-based workflows using Anchore Engine and Anchore Enterprise. With Anchore, DevSecOps teams establish policy-based approaches to container compliance without compromising velocity. Customers range from Fortune 100 companies to small- and mid-sized customers. Anchore is trusted by modern software development companies across the globe. For more information, visit anchore.com. ### Media Contact: press@anchore.com ### Anchore Wins US Air Force SBIR Phase II Contract to Accelerate Software Container Security RESTON, VA -- June 18, 2020 -- Anchore, Inc., experts in DevSecOps workflow for software containers, today announced it has been awarded a $2.25 million AFWERX Small Business Innovation Research (SBIR) Phase II contract. The core mission of AFWERX is to advance United States Air Force (USAF) capabilities by connecting innovators to simplify technology transfer and accelerate results. The contract is focused on securing and hardening software containers through automated, policy-based DevSecOps workflows. To stay ahead of growing global threats, the United States Department of Defense (DoD) is adopting modern DevSecOps practices to rapidly deliver new software to warfighters while simultaneously improving cybersecurity. These practices employ automated tools, processes and platforms to identify and remediate security vulnerabilities early in the software development process. Anchore provides a core technology platform mandated as part of the United States Department of Defense (DoD) DevSecOps Reference Design, enabling teams to enforce security and compliance policies against software containers. And for the past 12 months, the Anchore team has provided design and operational support for Platform One, the USAF DevSecOps platform. “The success of our mission depends on our ability to rapidly deliver secure software to warfighters,” said Maj. Rob Slaughter, USAF. “The Platform One software factory is designed to ensure that hardened containers are made available at every stage of the software development lifecycle. Anchore allows us to do that by working within the development process to enforce security best practices.” Under the Phase II contract, Anchore will deepen product capabilities to help the USAF secure software supply chains and prevent insider threat by using deep image inspection and policy-based compliance enforcement technology. Anchore engineers will be embedded into the Platform One team as they continue deploying secure software capabilities across the USAF. ‘We’re honored to continue the critical work we are doing with the USAF as part of their DevSecOps initiative,” said Craig Bowman, Vice President, US Public Sector at Anchore. “Since the DoD published its DevSecOps reference design, we have observed a rapid increase in the adoption of software containers. In close collaboration with the USAF, we are committed to providing the technology and practices required to apply security and compliance policies to software containers as they are adopted throughout the DoD” For more information about Anchore and Platform One, visit anchore.com/usaf. About Anchore Anchore, Inc., based in Santa Barbara, CA, was founded in 2016 by Saïd Ziouani and Daniel Nurmi to help organizations implement secure container-based workflows using Anchore Engine and Anchore Enterprise. With Anchore, DevSecOps teams establish policy-based approaches to container compliance without compromising velocity. Customers range from Fortune 100 companies to small- and mid-sized customers. Anchore is trusted by modern software development companies across the globe. For more information, visit anchore.com. About AFWERX Established in 2017 by the Secretary of the Air Force, AFWERX is a catalyst for agile Air Force engagement across industry, academia, and non-traditional contributors to create transformative opportunities. AFWERX has partnered with the Air Force Research Laboratory (AFRL), a scientific research organization operated by the U.S. Air Force Materiel Command, to streamline the SBIR process to increase the efficiency, effectiveness, and transition rate of the SBIR program.     ### Anchore Enterprise 2.3 Expands DevSecOps Solutions to the Microsoft Technology Ecosystem SANTA BARBARA, Calif. -- May 6, 2020 /PRNewswire/ -- Anchore, Inc. today announced the newest version of its transformative container compliance and security platform, Anchore Enterprise 2.3. This release follows the close of a Series A round of funding in January, fueling a new stage of product and operational growth. Announced at the GitHub Satellite conference, Anchore Enterprise 2.3 serves the needs of those in the GitHub and Microsoft technology ecosystems. Anchore Enterprise 2.3 introduces support for deep image inspection of Windows container images, allowing customers to extend container-based DevSecOps workflows beyond the Linux stack for the first time. Analysis of images has been expanded to include the discovery of NuGet packages (in tech preview) which allows for policy-based control over .NET frameworks and artifacts. Anchore Enterprise 2.3 also provides an updated reporting service that allows users to schedule and generate custom reports. The new version includes support for the GitHub Security Advisory Database, providing customers with vulnerability data from the world's largest development community. "Every day, customers improve the security posture of their Linux applications using DevSecOps practices powered by Anchore Enterprise," said Saïd Ziouani, CEO of Anchore. "But until now, those practices only provided governance for Linux applications running in Linux containers. This new release of Anchore Enterprise offers that power to teams in the Microsoft ecosystem, helping them establish even more comprehensive visibility and compliance throughout their software supply chain." While containers are indelibly part of Linux, many enterprises operate in environments where key applications are built using Microsoft ecosystem technologies. These applications can be managed within container orchestration platforms like Docker and Kubernetes, running alongside Linux applications in the hybrid cloud for greater efficiency and flexibility. Anchore Enterprise 2.3 performs deep image inspection of Windows container images, building a comprehensive software build of materials (SBOM) that can be used to establish and enforce policies. "Containers have taken hold in the IT landscape because of their flexibility," said Taylor Brown, PM Manager for Container Platform at Microsoft. "However, they present a fresh set of governance and operational security challenges. To address these challenges, Anchore now supports Windows Server containers, delivering more choice for public sector agencies and enterprises developing container-based applications, and implementing broad DevSecOps initiatives." ### Anchore Federal Streamlines Government DevSecOps Workflows Defense Agencies Use Anchore for Deep Image Inspection and Policy-Based Compliance, to Balance Security and Efficiency RESTON, VA -- February 6, 2020 -- Anchore®, Inc., experts in container workflow, analysis, and security, today announced Anchore Federal, a solution designed to validate compliance with the stringent software development security requirements of the United States Department of Defense (DoD). Anchore Federal allows agencies to perform deep inspection of software container images as they are created, validating them against a collection of policies designed in collaboration with the Department of Defense. By integrating into existing development pipelines, Anchore Federal prevents the deployment of software that does not meet the necessary security requirements. The Department of Defense is introducing modern DevSecOps practices throughout all defense agencies and projects in the form of automated software tools, services, and standards. The objective, codified into the DoD DevSecOps Reference Design, is to address security issues as early as possible in the development process. The Anchore team has been working extensively with key Air Force stakeholders to meet these challenges, resulting in the selection of Anchore as one of the few tools mandated as part of the reference design. “Anchore is honored to work hand-in-hand with federal agencies to provide them with enhanced security and efficiency,” said Saïd Ziouani, CEO at Anchore. “We understand how important it is for our warfighters to have leading-edge software, but it’s equally important for that software to be free of known vulnerabilities and follow security best practices. Our mission is to help organizations of all kinds achieve that balance.” Anchore engineering teams continue to work alongside resources from the DoD and partner organizations to secure and harden software containers held within the DoD’s Centralized Artifact Repository. Based on this expertise, Anchore also offers Anchore Federal Accelerator, an integrated program that prepares software providers to deliver their products to the DoD in a compliant manner. As requirements continue to evolve within the federal market, Anchore Federal customers will receive updated policy bundles that reflect the changing security and regulatory landscape and maintain ongoing compliance. ### Anchore Raises $20M Series A to Advance DevSecOps Workflows SANTA BARBARA, CA -- January 22, 2020 -- Anchore, Inc., experts in container workflow, analysis and security, today announced the close of $20 million in Series A funding led by SignalFire. Anchore was co-founded in 2016 by Saïd Ziouani, CEO, and Daniel Nurmi, CTO. Both technology veterans, Ziouani was founder and CEO of Ansible, Inc., and Daniel Nurmi was founder and CTO of Eucalyptus Systems, Inc. Software containers bring new flexibility and efficiency to software developers. However, container adoption has also increased the risk surface area by allowing easier introduction of vulnerabilities. With Anchore, developers can harden their software supply chain, protect against insider threats and ensure companies can audit and respond effectively. By taking a preventative approach, organizations can maintain a well-informed balance between velocity and compliance. “We believe Anchore is uniquely positioned to dominate the space around container workflow security,” said Ilya Kirnos, Managing Director and CTO at SignalFire. “With a solid open source foundation, strong customer adoption, and a seasoned executive team from Ansible and Red Hat, Anchore has all the elements of success. We’re thrilled to share in this exciting journey.” Increasingly, organizations are pursuing a shift left approach to security by introducing automated workflows early in the software development lifecycle to detect and remediate issues before they reach production. To accomplish this, Anchore has become the container security tool of choice by numerous Fortune 500 companies and is a required component of the United States Department of Defense DevSecOps Reference Architecture. The new investment will be used to expand the product’s capability to secure more stages of the container lifecycle and to provide security teams with additional insight into their risks and vulnerabilities. “We created Anchore to empower developers to build secure software quickly and more efficiently,” said Saïd Ziouani, CEO of Anchore. “Given our progress to date backed by the strong adoption this past year, we’re now ready to scale our sales, professional services, and engineering resources globally to meet the need and achieve our mission to bring the benefits of container workflow security to customers around the world.” ### Anchore Strengthens Open Source Security and Compliance for CNCF’s Harbor Container Image Registry Harbor Can Now Trigger Anchore Deep Inspection for Hosted Container Images SANTA BARBARA, CA —  December 17, 2019 — Anchore Inc., the container analysis and security experts, today announced the integration of Anchore Engine with the Cloud Native Computing Foundation’s (CNCF) Harbor container image registry project. Harbor is an open source, cloud-native container image registry that is currently an incubating project within the Cloud Native Computing Foundation. With this new integration, Harbor users can use Anchore to automatically scan container images to identify known vulnerabilities and enforce best practices before allowing them to be published. The rise of Linux containers has brought developers unprecedented flexibility and velocity. However, container adoption often results in reuse and redistribution of software containing security vulnerabilities. This is why deep image inspection is critical for organizations deploying containers, as it can uncover these vulnerabilities and notify operators of mismanaged credentials, problematic Dockerfile lines, exposed secrets, and other configuration issues that often create opportunities for bad actors. Using Anchore, organizations can maintain a well-informed balance between velocity and compliance. “Deep image inspection and policy-based compliance should be a best practice for all those who create, publish, or deploy container images,” said Saïd Ziouani, CEO of Anchore. “Our goal is to empower developers to build secure software quickly and at large scale. By integrating Anchore Engine with the Harbor container image registry, we make it easy for developers to integrate comprehensive container security into their workflows.” Anchore Engine, first released in 2017, is an open source tool for deep image inspection and vulnerability scanning. It is the only tool focused 100% on container-native scanning; it goes beyond basic source and binary scanning by probing into the configuration and contents of container images. Anchore Engine is the core of Anchore Enterprise, a fully-featured container security workflow solution for enterprises in highly-regulated industries. The integration between Anchore Engine and CNCF’s Harbor registry is now available with Harbor version 1.10. Users can experiment with the integration by following the demonstration provided in our webinar with the Harbor team. Read more about Anchore Engine. ### Anchore Enterprise 2.2 Automates DevSecOps Workflows with Support for Third-Party Integrations New Integrations Span Leading Developer and Security Tools Including GitHub, Jira, Slack and Microsoft Teams SANTA BARBARA, CA — December 16, 2019 — Anchore, Inc., experts in container workflow, analysis and security, today announced the immediate availability of Anchore Enterprise 2.2. This new release of Anchore Enterprise can notify users about policy violations and security issues immediately through email, webhooks, or integrations with Slack, Jira, GitHub Issues, and Microsoft Teams. Anchore Enterprise 2.2 is based on open source Anchore Engine 0.6.0, also available today. Anchore Enterprise 2.2 addresses a growing concern for DevSecOps teams, who need to react more quickly to emerging security issues. When an image fails a policy check, security teams will typically notify developers as soon as possible to perform remediation. With the new integrations in Anchore Enterprise 2.2, notifications can be received through familiar tools and within existing workflows. “For DevOps teams working to identify and fix security issues, time is of the essence,” said Saïd Ziouani, CEO at Anchore. “Through integrations with the most common DevOps tools, this new version of Anchore Enterprise allows teams to shorten the time between discovery and remediation. That means catching small problems before they become big ones.” For administrators, Anchore Enterprise 2.2 provides a new system dashboard that makes it easy to troubleshoot issues and understand the roles of its various feeds and services. This allows for quick diagnosis of any issues that arise, increasing the efficiency of first-time users and experienced Anchore experts alike. To learn more about Anchore Enterprise 2.2, view the detailed announcement. ### Anchore Brings Container Security to the Masses With GitHub Actions Anchore Container Scan GitHub Action Makes it Easy for Developers to Analyze Container Images for Known Vulnerabilities Before Publishing Them for Use SAN FRANCISCO, CA — November 13, 2019 — Anchore Inc., experts in container workflow, analysis and security, today announced the availability of the Anchore Container Scan action for GitHub Actions. GitHub Actions, which becomes generally available at the GitHub Universe annual conference, enable developers to create custom software development life cycle (SDLC) workflows directly in their GitHub repositories. With the Anchore Container Scan action, developers can now automatically trigger deep inspections of container images to create a full software manifest with comprehensive security findings, thereby preventing the release of software that fails to meet defined standards. Anchore Engine, first released in 2017, is an open source tool for performing deep inspection and policy-driven analysis of container images. It is the only tool focused 100% on container-native analysis and goes beyond basic source and binary scanning by probing the configuration and contents of container images. Anchore Engine is the core of Anchore Enterprise, a full-featured container security workflow solution for enterprises in highly-regulated industries. “Thanks to open source and critical platforms like GitHub, the software supply chain is moving more quickly than ever,” said Saïd Ziouani, CEO of Anchore. “Introducing security best practices as early as possible in the development process has become critical for all those who produce and consume software. The Anchore Container Scan action will allow any GitHub user to easily trigger deep image inspection and analysis, establishing a baseline of security for their projects.” Developers can activate the Anchore Container Scan Action from its page on the GitHub Actions Marketplace. Read more about Anchore GitHub Actions here. ### stackArmor and Anchore Announce Strategic Partnership for Driving Docker Container Security and Compliance on AWS Cloud stackArmor and Anchore to deploy and implement advanced container security and compliance solutions for regulated industries WASHINGTON, DC, and SANTA BARBARA, CA – April 10, 2018 – stackArmor and Anchore announced today a strategic partnership to deliver enhanced container security and compliance solutions for customers in regulated markets. Anchore provides a platform and a series of tools to certify container contents, providing a consistent set of tools for developers, operations and security to analyze images, perform queries, and define and evaluate policies. The Anchore platform provides a centralized interface for image analysis, reporting, policy scanning, compatibility verification, vulnerability scanning, and other inspection and synchronization tools to ensure that trusted containers get deployed. stackArmor is an Advanced AWS Partner focused on delivering cloud migration, management and cybersecurity & compliance services for healthcare, financial services and public sector clients. stackArmor’s cloud security and compliance engineers have been working closely with Anchore’s product team to deliver policy-based Docker container security and compliance services. stackArmor’s ThreatAlertTM  Security & Compliance-As-A-Service leverages Anchore’s deep analysis tools to inspect container images and to generate detailed manifests of the images -- a virtual ‘bill of materials’ that includes official operating system packages, unofficial packages, configuration files and language modules and artifacts such as NPM, PiP, GEM, and Java archives. “Cyber security compliance and vulnerability management is critical for highly regulated customers in public sector, healthcare and financial services,” said Anchore Cofounder and CEO, Saïd Ziouani. “Given the rapid adoption of Docker containers, our policy-driven approach to container security and compliance is crucial. We are excited to partner with stackArmor and bring the Anchore solution to public sector customers concerned about container security and compliance.” stackArmor assists organizations in meeting compliance and cybersecurity requirements for cloud-hosted workloads. stackArmor has developed a comprehensive set of cloud security and compliance solutions that meet NIST SP 800-171, FedRAMP, FFIEC, HIPAA and ISO 27001 requirements. stackArmor’s ThreatAlertTM Compliance-As-A-Service is designed to help organizations and key stakeholders quickly and easily understand risks and act on improving their cybersecurity posture. stackArmor ThreatAlertTM is a unique service that combines expert human intelligence and automated scanning to provide a set of actionable results that address cloud security controls relevant to the customers’ business and industry. The methodology and security controls assessed are drawn from NIST Special Publication 800-53, Center for Internet Security (CIS) 20 Security Controls and ISO/IEC 27001/27002 standards. “Anchore’s policy-based container security and compliance solution helps us get a better handle on vulnerabilities in Docker container-based micro-services,” said Terry Grogan, Director of stackArmor’s Security and Compliance practice. “Based on our experience in engineering full-stack cloud solutions for healthcare, financial services, government and security-focused commercial clients, Anchore provides critical capabilities for our SecDevOps pipeline architecture and practices.” stackArmor’s certified Cyber security Subject Matter Experts and certified AWS Solution Architects worked closely with the Anchore team to develop a deployment model optimal for highly regulated customers. “Cloud-based applications are rapidly being containerized and the speed of deployment automation increases the risk of vulnerabilities being introduced into the system and compromising the security posture, which is unacceptable,” said Gaurav “GP” Pal, stackArmor Founder and CEO. “I am impressed by Anchore’s leadership and open standards model to drive container security and compliance best practices. They have demonstrated great understanding of the paramount need for security on cloud-based containers on both IaaS and PaaS environments.” About stackArmor stackArmor is a full-stack cloud solutions provider and advanced AWS partner with a focus on security and compliance. stackArmor’s engineers are certified and trained in cloud architecture & design, systems engineering, networking and routing, and security design & compliance. Our customers include Software-As-A-Service (SaaS) providers, Non-Profit, Financial, Healthcare and Global Public Sector clients with strong security and compliance requirements including ISO 27001, NIST, 800-171, HIPAA, FFIEC, FISMA, FedRAMP, and DISA standards. About Anchore, Inc. Anchore, Inc. provides visibility, transparency, and control of container environments. Anchore users can analyze, inspect, and perform security scans and apply custom policies to container images within any CI/CD build system, both on-premises and in the cloud.  Anchore is available as a Software-as-a-Service (SaaS) and an on-premises enterprise offering. Anchore was founded in April 2016 and is headquartered in Santa Barbara, CA. ### Anchore 2.0 Releases Open Container Certification Platform Anchore Delivers the Power of Certification Directly to End Users SANTA BARBARA, CA – October 11, 2017 - Anchore, Inc., today announced Anchore Cloud 2.0, a suite of software tools that, via a simple User Interface (UI), provides developers, operations and security teams with a path to fully compliant container workloads both on-premise or in the cloud. Anchore Cloud is a Software-as-a-Service (SaaS) product built on a powerful, open source analysis and policy engine that allows users to search for container images on public and private registries. With Anchore Cloud users can perform a detailed analysis of container images and apply user-defined policies to ensure that containers meet the organization's security requirements and operational best practices. Anchore Cloud supports integration with the open source Anchore Engine for on-premises deployments, allowing the policies defined on Anchore Cloud service to be applied to images created and stored on-premises, and ensuring proper compliance prior to production deployment. Anchore is already integrated with popular open source tools including Jenkins and Kubernetes today. Key Anchore Cloud 2.0 features include: Deep inspection of container images including operating system packages and software libraries; Graphical policy editor to allow creation and management of custom policies; Notifications service providing email notifications for image updates, policy evaluations, and security vulnerabilities; Powerful search interface including historic tag and image data; Access to both private and public images on Dockerhub and Amazon EC2 Container Registry; Integration with on-premises CI/CD plugin and local Anchore Engine service. “As new development-to-production workflows are introduced with containers at their core, there is a growing need for developers, operations, and security professionals to be able to deeply inspect and control the fast and highly variable flow of software within containers,” said Daniel Nurmi, CTO and Co-founder at Anchore. “With the addition of an easy-to-use policy editor, an expanded set of notifications, and support for public and private registries including Amazon's EC2 Container registry, Anchore Cloud 2.0 gives users the tools necessary to achieve a controllable containerized software flow in a way that can be certified by the user for their specific needs. Coupled with our open source on-premise engine, Anchore Cloud 2.0 provides users the ability to quickly and easily integrate powerful inspection, reporting, and security and compliance checks into their existing or new container build environments.” “With the Rancher container management platform, our goal is to make container security as easy to implement as containers,” said Nick Stinemates, VP of Business Development at Rancher Labs. “By partnering with Anchore, we’re able to ensure that our users' container workloads are both secure and compliant.” About Anchore Container adoption is accelerating, but with speed comes risk. With Anchore, users can create a trusted standard for containers that is predictable and protectable, with development, production, and security teams on the same page from the start. Anchore democratizes certification and empowers users to secure their containers, so they can deploy them with confidence. Anchore, Inc. was founded in April 2016 and is headquartered in Santa Barbara, CA. ### Anchore Expands Container Image Discovery, Deep Inspection and Analysis With Enhanced Navigator Service New Functionality Gives Navigator Users Power to Independently Verify Certification Status, Define Certification Policies for all Container Images Santa Barbara, CA – February 7, 2017 - Anchore, Inc., announced today new functionality for its free Navigator service, a simple and powerful user interface that allows application developers and data center operations teams to search for and inspect container images across multiple registries, including DockerHub. Additional public and third party private registries will be added in the first quarter of 2017. Using Anchore Navigator, users can perform deep inspections of container images, including package manifest, software libraries, configuration files and security policies. Finding the right container image and keeping track of updates is becoming increasingly complicated with nearly 500,000 images on DockerHub and thousands more hosted by cloud providers such as Amazon and Google, as well as a growing number of private registries hosted by independent software vendors. With Navigator, users can quickly search for images that meet their requirements including detailed content, security and compliance status. In addition to current content, a detailed analysis of historic images is maintained including the frequency of updates made to images, ensuring they are well maintained and allow for a user to subscribe to notifications when an image has been updated. "While end-users welcome the simplicity containers bring to deploying off-the-shelf applications, software vendors face a number of adoption challenges," said Saïd Ziouani, CEO and Cofounder of Anchore. "Many enterprises are reluctant to deploy a third-party container without knowing what is inside the container or if the container has introduced new risks into their organization in terms of security, compliance and overall best practices." With Anchore's Navigator software vendors and service providers can enable their customers to verify the compliance of container images without needing to download and analyze the images themselves. This validation by an independent third party, using open source tools with a published certification policy allows enterprises to deploy third party containers with confidence. "Shipping Scality's applications as containers greatly simplifies deployment and maintenance for our customers,” said Giorgio Regni, Founder and CTO at Scality. "However, enterprise customers want to be sure that the containers they are deploying are secure and well maintained. Using Anchore's tools we can define strict policies for security and compliance that ensure only images that meet our stringent security requirements are released. Anchore's Navigator allows our customers to independently verify the certification status of all their images at any time, as well as define their own specific certification policies.” "When it comes to deploying containers in the enterprise, trust is an enormously important factor. Container users must trust their ability to scan containers at scale with the ability to deeply inspect them," said Stephen O'Grady, Principal Analyst at RedMonk. "One of the better mechanisms to earn this trust is open source, where not only can the performance be validated, but so can the quality of the code itself. This is the approach Anchore has taken with Navigator." The Anchore Navigator is available immediately at https://anchore.io with access to all public DockerHub images with other public and private registries coming online in the first quarter of 2017. About Anchore Container adoption is accelerating, but with speed comes risk. With Anchore, users can create a trusted standard for containers that is predictable and protectable, with development, production, and security teams on the same page from the start. Anchore democratizes certification and empowers users to secure their containers, so they can deploy them with confidence. Anchore, Inc. was founded by enterprise veterans, Saïd Ziouani, Dan Nurmi. The company is headquartered in Santa Barbara, CA. ### Anchore, Inc. Joins Open Container Initiative to Help Guide the Future of Container Technology MarketWired - December 6, 2016 -- Anchore, Inc. announced today that it has joined the Open Container Initiative (OCI), an open source Collaborative Project hosted by the Linux Foundation for creating open industry standards around container formats and runtime. With Anchore, software developers, operations and security teams are on the same page from the start, with unparalleled visibility into their containers and the chain of custody at every stage of the development lifecycle. Anchore democratizes certification by giving users the data and tools required to define policies that cover both the provenance and contents of their containers, ensuring that only images that meet the strict requirements of their organization are deployed. Anchore’s governance and policy controls go further than traditional image scanning solutions which focus on simple operating system CVE scanning. Anchore delivers complete visibility and control. With Anchore, policies can cover all aspects of an image including operating system packages, configuration files, user-supplied binaries, third-party software libraries from public repositories including Node.JS modules, Ruby GEMs, Python modules and Java archives. The OCI was launched in mid-2015 to develop standards for container formats and runtimes that will give organizations the confidence to commit to container technologies guided by choosing the best tools for the applications they are creating. without vendor lock-in. Anchore will add support for the upcoming OCI Image specification to allow users to run certification tests against OCI format images in addition to Docker images. “We are very excited to join the OCI to help further the development of open industry standards for container formats and runtimes that encourage innovation,” said Saïd Ziouani, chief executive officer and founder of Anchore. “Formalized specifications ensure that the containers our customers have certified using Anchore’s tools are interoperable and compatible across multiple platforms and container runtimes.” “We are pleased to welcome Anchore to the Open Container Initiative,” said Chris Aniszczyk, executive director of the Open Container Initiative. “Having visibility and control in container deployments is extremely important, and their expertise in certification and security for containers will be instrumental in furthering open industry standards.” To learn more about the Open Container Initiative and how to join the community, visit here. Details on projects associated with the Open Container Initiative can be found here. ### Anchore 1.0 Delivers Container-based Compliance and Certification Seed Round Nets Close to $5 Million in First Five Months Santa Barbara, CA - October 4, 2016 – Anchore, Inc., announced today the commercial release of its flagship product. Anchore gives developers, operations and security teams unparalleled visibility into their containers and the chain of custody at every stage in the development lifecycle. Anchore also announced today that it raised close to $5 million in venture capital funding. Seed round investors include Andreas von Blottnitz and Menlo Ventures’ managing director Doug Carlisle. Anchore works seamlessly with an enterprise's IT infrastructure whether deployed on-premises or in the cloud, regardless of the image registry, container runtime or orchestration platforms. With Anchore’s on-premise offering organizations can easily integrate container inspection and analysis into the CI/CD pipeline to ensure that corporate policies are enforced. Anchore’s SaaS offering lets users conduct container inspections and visualizations and will include tools to vet, certify, inspect and synchronize container images to ensure that they comply with standards policies defined by the organization. These policies cover more than basic operating system vulnerabilities and can be customized to include operating system packages, third party packages, software artifacts and configuration files. "Container-based deployments require speed and agility, making transparency and control a critical aspect of application production deployment," Said Saïd Ziouani, Anchore CEO and cofounder. "Anchore 1.0 marks a major milestone in delivering a full end-to-end container visibility toolset that spans security vulnerability to configuration, and packaging to provenance, across both public and private registries." Using plug-ins for CI/CD platforms such as Jenkins organizations can ensure that container images are inspected during each stage of the software development pipeline. Compatible with public container registries such as DockerHub, Anchore will interact with container platforms, including Kubernetes, Mesos, CoreOS, ECS, and Google Container Engine. "As containers are adopted at an accelerating rate by businesses of all shapes and sizes and deployed into production, it's critical to know with precision what is running in a given container and where it came from," said Stephen O'Grady, Principal Analyst with RedMonk. "Anchore is built to add just these kinds of capabilities to container infrastructure, regardless of what it's made up of." Anchore, Inc. was co-founded in April by open source veterans Saïd Ziouani, CEO, and Dan Nurmi, CTO. Anchore’s management team is headed up by Sean Doherty, SVP Business Development and Andrew Cathrow, VP Products and Marketing, both Red Hat veterans About Anchore Anchore gives development, production, and security teams complete visibility into their containers at every stage in the development lifecycle to ensure a trusted standard for containers that is predictable and protectable, with everyone on the same page from the start. Anchore democratizes certification and empowers users to secure their containers so they can deploy them with confidence. Headquartered in Santa Barbara, California, Anchore was founded in April 2016 by Saïd Ziouani, CEO and Dan Nurmi, CTO. ### Anchore, Inc. Brings Transparency and Predictability to Containers SANTA BARBARA, CA—(Marketwired - April 06, 2016) - Anchore, Inc., based in Santa Barbara, CA, announced today the launch of the company and its beta program for users working with containers at every stage of the application lifecycle. Users can sign up for the Anchore beta program now with anexpected availability in Q2 of 2016. The Anchore software-as-a-service platform (SaaS) provides tools to vet, certify, inspect, and synchronize container contents. Through a common portal, application developers can select verified containers from a curated registry and ensure the right containers get deployed in the right places. This centralized interface will be used for compatibility verification, vulnerability scanning, and other inspection and synchronization tasks. Anchore is the brainchild of co-founders Saïd Ziouani, CEO, Dan Nurmi, CTO, and Tim Gerla, Head of Products. Nurmi was a co-founder of Eucalyptus Systems, Inc., the popular open source private cloud platform. Saïd and Tim were founders of Ansible, Inc., the popular enterprise IT automation solution that opened its doors in 2013 and was acquired by Red Hat in Oct. 2015. “Containers give developers a way to quickly and efficiently test and deliver applications,” said Saïd Ziouani. “Once containers begin moving through QA, acceptance and deployment processes, it becomes easy to lose track of provenance and compatibility information. Anchore gives users tools and resources to have full visibility of the ‘chain of custody’ as containers move through the development lifecycle, while providing the visibility, predictability, and assurance needed for production deployment.” The company starts up with over $2M in seed funding from Doug Carlisle, managing director of Menlo Ventures and Andreas von Blottnitz, managing director of e-Ventures. Both are Anchore board members and were also Ansible Inc. investors. “There is an incredible opportunity in the container technology space, underscored by the broad industry backing we’re seeing,” said Doug Carlisle. “The right market timing combined with the unique strength of the founding team in both technology and in business, make me a strong believer in Anchore”. Compatible with public container registries such as DockerHub, Anchore will interact with container platforms, including Kubernetes, Mesos, CoreOS, ECS, and Google Container Engine. Anchore is not a “single-pane-of-glass” interface for all container management tasks, but is focused on providing certification and visibility into container contents for all stakeholders in a container-based application environment. “Anchore technology is being designed to allow users to fully realize the benefits of container-based production systems, while at the same time allowing them to choose the latest, best technology that fits their particular needs,” said Daniel Nurmi. “Our tools and infrastructure aim to provide users a high level of transparency, control, and visibility into the contents of their containers, giving organizations the confidence required to fully take advantage of containers from development to production.” About Anchore Containers adoption is accelerating, but with speed comes risk. With Anchore, users can create a trusted standard for containers that is predictable and protectable, with development, production, and security on the same page from the start. Anchore democratizes certification and empowers users to secure their containers, so they can deploy them with confidence. Anchore, Inc. was founded by enterprise veterans, Saïd Ziouani, Dan Nurmi and Tim Gerla. The company is headquartered in Santa Barbara, CA.