Welcome to our blog.
SAST vs DAST: What you need to know.
So, you’re looking for SAST and DAST. Or, you’re looking to understand what SAST and DAST tools are: What are the key differences? How do you use them together? Do you need them?
You’re in the right place. Let’s dive in.
But first, the TL;DR:
- TL;DR: SAST checks your code for vulnerabilities before your app runs, while DAST tests your app while it’s running to find issues that pop up in real time.
- SAST is like an expert dev reviewing your code, DAST is like a hacker trying to break in.
- Using both together helps catch security problems from start to deployment, and ensures your app is safe.
- Shameless plug 😇 - if you’re looking for SAST & DAST, check us out. Get your SAST & DAST covered, so you can get back to building.
SAST & DAST: What you need to know
Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) are two essential methods in application security that help identify vulnerabilities in software.
What is SAST?
SAST, or Static Application Security Testing, is a testing method that analyzes an application's source code in a static or non-running state. It is a “white-box” testing technique.
SAST allows developers to identify vulnerabilities early in the development (SDLC) process, like code development or code review phases. SAST tools are easy to integrate into CI/CD pipelines and IDEs, so you can secure your code as it's written and scan your code before committing changes to the repository.
SAST can detect vulnerabilities like SQL injection, cross-site scripting (XSS), hard-coded credentials, and other OWASP Top 10 vulnerabilities. SAST tools, like Aikido SAST, scan and compare your code to databases of known security vulnerabilities like the National Vulnerability Database (NVD).
Think of it like this, SAST is like having an expert review your code with a fine tooth comb, who gives you immediate feedback on issues they discover.
That being said, SAST is limited and cannot be used to detect runtime or environment specific vulnerabilities, like configuration errors or runtime dependencies. Scanning code requires that you choose a SAST tool that supports your programming language.
Why does SAST matter?
This early detection is crucial as it allows developers to address issues before the application is deployed, making it easier and less costly to fix problems early. SAST is proactive security, it can save a lot of time - and headache - for the future.
What is DAST?
DAST, or Dynamic Application Security Testing, is a testing method that evaluates an application while it is running.
While SAST sees inside your source code, DAST does not require source code access. Instead, DAST takes an outsider approach to testing your applications security.
DAST simulates attacks on the application much like a hacker would. It is a “black-box” technique.
DAST can also be called “surface monitoring” as it tests the surface or front-end of the web app. DAST tools interact with the application via the user interface, testing various inputs and observing the outputs to identify vulnerabilities such as authentication issues, server misconfigurations, and other runtime vulnerabilities. As DAST works at runtime, that means you need a working application before DAST tests make sense, which is usually around the pre-production and production phase.
Because DAST works externally - and uses standardized protocols like HTTP to connect to your app - DAST is not tied to a specific programming language, unlike SAST.
Why does DAST matter?
This method is important for detecting issues that you cannot detect before deployment. DAST covers you for different categories of errors. DAST identifies risks that come up when the application is up and running, like server or database misconfigurations, authentication and encryption issues that allow unauthorized access, or risks from web services that your application connects to.
Using SAST and DAST Together
Using SAST and DAST together is recommended. Combining SAST and DAST gives you broad coverage across the software development lifecycle. Cover yourself early with SAST and ensure you have real-world resilience later with DAST. This combination allows teams to address vulnerabilities at multiple stages and ultimately leads to more secure applications.
Cheatsheet: SAST vs DAST
Testing Approach:
- SAST: White-box (inside-out) testing. It does not require a running application, working “like an expert developer.”
- DAST: Black-box (outside-in) testing. It requires a running application, testing “like a hacker.”
Access to Code:
- SAST: Requires access to the source code.
- DAST: No access to the source code is required.
When to Use in Software Development Lifecycle (SDLC):
- SAST: Used early in the SDLC. Integrate into your CI/CD and IDE to secure code as it is written.
- DAST: Used later in the SDLC, starting in the pre-production and production phase.
Type of Vulnerabilities Detected:
- SAST: Detects security issues in source code, such as SQL injection, cross-site scripting (XSS), and hard-coded credentials.
- DAST: Detects runtime and environment-related vulnerabilities, such as misconfigurations.
Key Advantages:
- SAST: Identifies vulnerabilities early, allowing for easier remediation that saves time and money.
- DAST: Tests application behavior as a real attacker would, covering a broader attack surface, catching different categories of errors (like configuration issues), and producing low false positives.
Key Limitations:
- SAST: Language and platform-dependent, may produce false positives, and cannot discover runtime or environment-related issues.
- DAST: Cannot pinpoint the exact source of vulnerabilities, requires a running application, and vulnerabilities are more expensive to fix at this stage.
Popular Open Source Tools:
- SAST: Semgrep, Bandit, Gosec.
- DAST: ZAP, Nuclei.
5 Snyk Alternatives and Why They Are Better
Snyk is widely recognized as one of the top security tools for developers, especially when it comes to finding vulnerabilities in open-source code, containers, and infrastructure as code. However, no tool is perfect for every scenario and access to the Snyk platform comes with a price tag. Depending on your needs, there may be Snyk alternatives that provide better integration, features, or just better value for money.
Here, we'll look at 5 Snyk alternatives and why they might be a better fit for your organization.
1. Aikido Security
- Why It’s Better: all-in-one appsec
- Overview: Aikido integrates open-source scanners into a 10-in-1 vulnerability management platform, delivering exceptional value with affordable pricing tiers.
- Advantages:
- Strong focus on noise reduction
- 10-in-1 vulnerability scanners
- Continuous scanning throughout the entire development lifecycle
- In-depth policy enforcement capabilities
- Why It Might Be Better than Snyk:
- While Snyk provides a good base of powerful security scanners, Aikido is superior for organizations that need all-around vulnerability protection, license tracking, and compliance features, especially in highly regulated industries - and all that affordably priced.
2. Dependabot
- Why It’s Better: Seamless Integration with GitHub
- Overview: Acquired by GitHub, Dependabot offers automatic dependency updates for your projects. It continuously monitors your dependencies for vulnerabilities and automatically generates pull requests with updates.
- Advantages:
- Native integration with GitHub repositories
- Automated pull requests and patches with minimal configuration
- Simple, lightweight, and easy to use
- Free for public and private repositories on GitHub
- Why It Might Be Better:
- If your codebase is hosted on GitHub, Dependabot’s native integration makes it a natural choice. It’s also fully automated, which means less manual work compared to Snyk’s more interactive approach.
3. SonarQube
- Why It’s Better: Code Quality Meets Security
- Overview: SonarQube is a code quality and security tool that scans codebases for both code smells and security vulnerabilities, making it a great option for developers looking for a tool that blends security with code health.
- Advantages:
- Combines code quality checks with security scanning
- Broad language support and community-driven plugins
- Integrates with popular CI/CD tools and DevOps pipelines
- Detailed reports on both technical debt and vulnerabilities
- Why It Might Be Better:
- Suppose you are looking for a tool that goes beyond just security vulnerabilities and provides insights into code quality. In that case, SonarQube’s ability to highlight maintainability and performance issues is a big plus.
4. Clair
- Why It’s Better: Container Security Focus
- Overview: Clair is an open-source vulnerability scanner primarily focused on Docker and OCI container images. It integrates directly into your container pipelines, analyzing vulnerabilities in images.
- Advantages:
- Strong focus on container security, especially for Kubernetes environments
- Seamless integration with container registries like Docker Hub and Quay.io
- Open-source, allowing for customization and integration with other tools
- Continuous scanning for known vulnerabilities
- Why It Might Be Better:
- While Snyk covers container security, Clair’s exclusive focus on containers allows it to offer a more fine-tuned and granular approach. For organizations deeply invested in containerized environments, Clair may provide better visibility and customization options.
5. Aqua Security
- Why It’s Better: End-to-End Cloud Native Security
- Overview: Aqua Security provides a holistic solution for securing containers, serverless functions, and other cloud-native applications. It covers a wide range of security needs, from image scanning to runtime protection.
- Advantages:
- End-to-end security solution for containers, serverless, and Kubernetes
- Strong runtime protection capabilities
- Real-time threat detection and anomaly monitoring
- Integrates with CI/CD pipelines and multiple cloud platforms
- Why It Might Be Better:
- Aqua’s depth in cloud-native security, especially its real-time threat detection and runtime protection, makes it a more powerful solution for cloud-native environments compared to Snyk, which is more focused on scanning and remediation during the development phase.
Conclusion
Snyk is a powerful tool, but these alternatives may offer better solutions depending on your specific needs. Aikido provides superior value for money with an all-in-one platform, Dependabot excels at GitHub integration and automation, SonarQube enhances code quality while ensuring security, Clair specializes in container security, and Aqua Security delivers comprehensive cloud-native security. Ultimately, the best tool for your organization will depend on your existing workflows, the complexity of your infrastructure, and the specific challenges you’re trying to solve.
110,000 sites affected by the Polyfill supply chain attack
A critical exploit just hit the scene, targeting cdn.polyfill.io
, a popular domain for polyfills. Over 110,000 websites have been compromised by this supply chain attack, which embeds malware into JavaScript assets.
TL;DR
If your website uses http://polyfill.io/, remove it IMMEDIATELY.
Who does this supply chain attack affect?
The cdn.polyfill.io
domain has been hijacked to serve malicious scripts. This means any site relying on this domain for polyfills—a method of adding new functionality to older browsers, like modern JavaScript functions—is at risk. Security researchers at Sansec were the first to identify the many instances of malware payloads, which included redirecting mobile users to a sports betting site,
This supply chain attack can compromise your users' data and the integrity of your applications, and even includes built-in protection against reverse engineering and other clever tricks to prevent you from observing how it affects your end users.
Aikido's Research Team continuously adds new advisories for dependencies which use pollyfill[.]io under the hood, which would leave your applications vulnerable to the supply chain attack. Some notable dependencies include:
- albertcht/invisible-recaptcha (Over 1m installs)
- psgganesh/anchor
- polyfill-io-loader
Since details about the attack were publicly released, Namecheap put the domain name on hold, preventing any requests to the polyfill malware. While that does prevent the spread of malware in the short term, you should still continue with a proper remediation.
How can you fix this vulnerability?
Scan your code now. Aikido’s SAST feature scans your codebase for any instances of cdn.polyfill.io
.
Create an Aikido account to get your code scanned
Any findings around this Polyfill supply chain attack will jump to the top, as they have a critical 100 score. Make sure to remove all detected instances of polyfills immediately to prevent yourself and users from this critical supply chain attack.
The good news is that according to the original author, you can likely remove cdn.polyfill.io
, or any of the affected dependency packages, without affecting the end-user experience of your application.
No website today requires any of the polyfills in the http://polyfill.io library. Most features added to the web platform are quickly adopted by all major browsers, with some exceptions that generally can't be polyfilled anyway, like Web Serial and Web Bluetooth.
If you do require Polyfill capabilities, you can tap into recently-deployed alternatives from Fastly or Cloudflare.
Cybersecurity Essentials for LegalTech Companies
According to IBM & Ponemon, the average cost of a data breach is a staggering $4.35 million! No wonder companies feel the need to invest heavily in cybersecurity. For legal tech companies, handling a large amount of sensitive client data daily, the stakes are even higher. Beyond the immediate financial impact, a data breach can cause severe reputational damage that is often much harder to repair, making cybersecurity a top priority for legal professionals. As the digital world evolves, strategies for protecting sensitive information must also adapt to increasingly sophisticated threats.
ELTA, the European Legal Tech Association, gathered some of today's leading cybersecurity experts in a digital meeting room. Roeland Delrue, Co-Founder & CRO at Aikido Security, Aidas Kavalis, Co-Founder & Head of Product at Amberlo, Wouter Van Respaille, Co-Founder & CTO at Henchman and Michiel Denis, Head of Growth at Henchman share their expertise and insights on how to install a solid cybersecurity framework for LegalTech companies.
The Growing Importance of Cybersecurity
What are the foundational cybersecurity standards every legaltech application should meet, and how have these standards evolved with emerging threats? Roeland Delrue, Co-founder & CRO at Aikido Security, emphasizes that developing a secure legaltech application starts with the code.
- Programmers are writing the app in code. The first layer of security is ensuring that the code itself is secure
- Once the code is ready, it is typically shipped in containers - which represent the second layer that must be scanned and monitored.
- The third layer is the cloud environment where the application is deployed.
Followed by the fourth layer, the domains (login.com or app.com) through which users access the application.
Compliance and Continuous Monitoring
Wouter Van Respaille, Co-Founder and CTO at Henchman, stressed the importance of compliance with industry standards such as ISO 27001 and SOC 2. These certifications are not just checkboxes; they are indicators that a vendor is serious about security. He noted that companies without these certifications might lack the necessary resources or commitment to security.
Beyond compliance, continuous monitoring and creative approaches like bug bounty programs are crucial. These programs involve ethical hackers who continually test the system, providing an additional layer of security beyond traditional scanning tools. Van Respaille shares their approach at Henchman: “Aikido continuously scans both our infrastructure and our code. Additionally, we use Intigriti for bug bounty hunting, which involves a collective of social hackers creatively probing and exploring our systems. Compared to traditional scanning tools, this approach is far more innovative. We also use Phished to send phishing simulations to all our employees, raising awareness of phishing and security while adding a touch of gamification. As a company handling a never-ending stream of sensitive data, it's important to have these partnerships rather than doing everything ourselves."
Because cybersecurity is a complex matter, Aidas Kavalis, co-founder and head of product at Amberlo, points out that it's wise to bring in a third party to evaluate vendors. "An expert in the field can help you discover things you'd never have thought of. Even if an ISO27001 or SOC 2 standard is implemented, how can you be sure that the certificate matches reality? A professional helps to ask the right questions and ensure that the right things are checked up front.”
Legal data is highly sensitive and valuable
The panelists agree that legaltech applications face unique cybersecurity challenges compared to other web applications, being a top target for hackers together with financial institutions. Legal data, much like financial data, is highly sensitive and valuable. "The difference is that financial institutions handle money, while law firms manage client information, which can sometimes cause more harm if breached. Recently, there have been several attacks where law firms were hacked, leading to individual targeting of their clients. Therefore, I believe law firms are definitely among the highest-risk sectors," says Kavalis.
Delrue urges to be mindful of the value of the data you handle, as it impacts the level of security required: "For instance, there's a significant difference between a legaltech vendor that only reviews contracts without storing them and one that holds numerous clients' actual contracts. The more sensitive data you hold, the more attractive a target you become to hackers, who aim to extort money through ransomware or by selling the data. Therefore, whether you are a legaltech vendor or consumer, you should assess the sensitivity and value of your data to potential malicious actors. If your data is highly valuable, it is crucial to implement more rigorous cybersecurity measures than the average company."
Evaluating LegalTech Security
When evaluating the security of legaltech products, law firms should also consider the sensitivity and volume of the data they handle and ensure that the applications have the necessary security measures in place.
As a legaltech provider, Kavalis is asked for three things by his customers:
- ISO or SOC 2 certifications, along with GDPR compliance questionnaires.
- External cybersecurity assessment: Larger law firms often ask for tech sessions, where they bring in external experts to dig deep into Amberlo to see if it has adequate technology and policies in place.
- And from time to time, a history of security incidents. “Fortunately, we haven't experienced any major security incidents so far, which I consider a significant achievement. Since we launched Amberlo in 2017, we have seen daily attempts to break into our systems from some well-known hacker locations,” says Kavalis.
An easy thing to check is whether a company is ISO 27001- or SOC 2-compliant. However, Delrue stresses the importance of understanding what these certifications entail. Delrue sees ISO27001 or SOC 2 as a shortcut to filling out a lengthy security questionnaire, where ⅔ of boxes can be checked off automatically. However, some things are not covered by certifications, such as malware scanning which is not covered by SOC2, for example. So in some cases, standard ISO certifications might not cut it and you might want to add some deeper questions.
On-premise vs hosted in the cloud?
With the rapid advancements brought by GPT and other AI technologies, evaluating technology in law firms has become increasingly crucial. However, there has always been an on-premises vs. cloud hosting debate. Let’s have a look at what this means first:
- On-premise software: customers have the servers physically and host their applications there
- The private cloud: customers adopt Microsoft Azure, the Google Cloud Platform or AWS where they run all the applications inside of their network
- The cloud: applications run fully on the cloud and then the customers adapt that technology
"I don't want to get hit by a car, so I'll just stay home forever. Or I could actually go somewhere, and when I cross the street, I look left and right first to make sure I’m safe.”
Van Respaille uses this analogy to compare on-premises to the cloud. In his view, staying on-premise is outdated. "It means you will be excluded from a lot of innovation. My advice to all law firms is to fully embrace the cloud but approach it thoughtfully. Be aware that there are security checklists available. These don't need to be overly complex or resource-intensive; a basic questionnaire can suffice for evaluating the tools you wish to adopt. This approach creates an initial layer of security, giving you a clear understanding of what you're actually purchasing. In summary, 'Go full cloud, but know which tools you are going to adopt!'"
If certain standards are met, Delrue sees on-premise as a legitimate option: "If you have a top-notch on-prem program with dedicated security people who know how to manage that on-prem, then it's definitely a viable option." However, he believes that high-quality on-prem security is rare. "If you're dealing with very highly professional cloud providers and you don't have the in-house resources to manage your on-prem, it's probably safer to go with the cloud version because there are a lot of security risks on-prem." So basically, it’s a risk assessment: where do you want the risk to be, and who do you want to manage that risk?
"Very often, on-premise becomes a single point of failure," Adias adds. "If one perimeter is breached, it often means that all the other systems are also quite easily accessible. I have rarely seen a layered approach to on-prem cybersecurity, where each application is isolated in a separate security zone."
From ideation to deployment
Of course, legaltech vendors should integrate security standards and measures from the start, even before the product has been built.
"It starts with the software developer's laptop. The developer writes code, and that's where you can do the first check. That's what Aikido does," says Delrue. "Whether it's code, containers, cloud, domain, in every part of the development lifecycle, Aikido can do security checks." Being too strict, however, can slow down the development process tremendously. That's why Delrue advises using the risk categorization of vulnerabilities & security issues (low, medium, high, critical) smartly. "If you start blocking them at medium, you're going to slow down development: they're going to be stopped at every step they take because of some security check that needs to be fixed. Sometimes it's a little easier to only block the ‘critical issues’ and then maybe fix the ‘highs’ later in a focused moment.”
Throughout the whole development lifecycle, you can perform different checks to have a proper security posture. In the world of security products, this is referred to as ‘shifting left’. "This means catching someone earlier in the cycle, which makes it easier to fix than when it's already live with a customer. Because at that point the damage is done." Delrue says.
In an age where data breaches can cost millions and reputations hang by a thread, it's clear that cybersecurity is no longer an option for legaltech companies, it's a necessity. So whether you're debating cloud vs. on-premises or evaluating a new tech solution, remember: in the digital age, the only thing more expensive than investing in cybersecurity is not investing in it.
Drata Integration - How to Automate Technical Vulnerability Management
Aikido Security is now live on the Drata Integration marketplace! That’s great news because navigating today’s cybersecurity regulatory landscape is a bit like walking a tightrope in a hurricane. As cyber threats evolve, so do the regulations designed to keep them in check. Businesses now find themselves grappling with a growing list of compliance requirements, each more stringent than the last.
In this blog post, we'll discuss how Aikido and Drata’s integration can help you tackle SOC 2 and ISO 27001:2022 compliance.
What do Aikido and Drata do?
First, let’s familiarize ourselves with both of these security platforms.
What does Aikido do?
Aikido is the get-it-done security platform for developers. Aikido centralizes all necessary code and cloud security scanners in one place. Created by pragmatic engineers, we put open-source solutions and the developer experience first in what we build and how we build it. We focus on finding what matters, so you aren’t bothered by what doesn’t. Win customers, grow up-market, and ace compliance.
Aikido makes security simple for SMEs and doable for developers without industry jargon, red tape, and frankly, BS.
What does Drata do?
Drata is a security and compliance automation platform that continuously monitors and collects evidence of a company’s security controls while streamlining compliance workflows end-to-end to ensure audit readiness. The Drata team excels at using automation to help companies of any size achieve and maintain compliance, e.g. preparing for SOC 2 or ISO 27001:2022.
How does the Aikido and Drata integration work?
Aikido’s Drata integration automatically pushes SOC 2 and ISO 27001:2022 evidence directly to Drata via API integration. Every day Aikido creates a PDF report and syncs this as 'external evidence' to Drata (learn how here). Aikido also creates a control with the code 'AIKIDO' and links the relevant SOC2 and ISO27001:2022 requirements. The point is, Aikido ensures that your vulnerability information is always up to date. This enables accurate risk assessment and efficient remediation.
Any Aikido package allows you to integrate with Drata. But, of course, you’ll also need a Drata license to use Drata’s audit prep services.
Where can I find the integrations?
On Aikido, the integration with Drata is right here! Meanwhile, in Drata’s integration listing you can find Aikido under “Vulnerability Scanning”, “CSPM” (Cloud Security Posture Management), and “Security Questionnaire.” You can connect Aikido as a vulnerability scanner directly from your Drata dashboard.
Covering the technical vulnerability management requirements for compliance
Whether you are on a mission to comply with SOC 2 or ISO 27001:2022, you’ll need to implement technical vulnerability management measures. What does that involve? Identifying real vulnerabilities to your code base. Then, prioritizing and addressing them.
Step 1: Conduct a risk assessment of your code base
Analyze your systems. Identify weaknesses and vulnerabilities that attackers could exploit, by letting Aikido scan your application.
Step 2: Prioritize your vulnerabilities
Rank your identified vulnerabilities considering the severity and the potential impact on your systems. Dealing with the most impacting first should be your priority.
Step 3: Tackle vulnerabilities
Implement patches. Upgrade software. Make configuration changes to your systems.
Step 4: Test for effectiveness
After addressing your vulnerabilities you’ve got to check if your solutions have worked. The best approach is to run a pentest. Back to step 3 if needed. NB: pentests are not mandatory for either SOC 2 or ISO27001:2022.
Step 5: Continual monitoring
The above steps are not one-and-done. Ongoing monitoring is essential to maintaining healthy systems and identifying emerging threats and vulnerabilities. The key to this is regularly scanning your codebase by using a vulnerability management program.
Aikido automates your vulnerability management process
Implementing the process manually is painstaking but possible. Instead, we recommend using an easy-to-use vulnerability management platform, such as Aikido. Let’s have a look at how Aikido does that for the 5 steps above.
Step 1: Check your defense – conduct a risk assessment of your code base
Aikido plugs into your code and cloud infrastructure and then automatically conducts a risk assessment. It thoroughly analyzes your systems, identifying potential vulnerabilities that could be exploited by attackers. Aikido is agentless so you can get a full overview in 30 seconds. The result is saving lots of money and time: gone are the hours wasted installing expensive software or configuring and maintaining free open-source tools.
Step 2: Identify your real threats – prioritize vulnerabilities
After completing the risk assessment, Aikido gives your brain a break by prioritizing the vulnerabilities. Getting a really long list of all the vulnerabilities in your system could be overwhelming, so that’s exactly what Aikido does not do! Instead, Aikido deduplicates and auto-triages the vulnerabilities and provides you with the vulnerabilities that truly matter and are exploitable. Now, you can focus on the most critical vulnerabilities first.
Step 3: Knock your opponents over – tackle vulnerabilities
Although addressing vulnerabilities can often be a manual task, Aikido takes the pressure off and makes it easier than ever. Want to make a PR in just one click? Now you can with Aikido’s autofix! On top of that, Aikido integrates fully with the tools you’re already using, including implementing patches, upgrading software, or making configuration changes.
Step 4: Get your black belt – test for effectiveness
Our advice is to do a pentest to ensure the effectiveness of the fixes implemented. Why is this important? It validates the effectiveness of the security measures and ensures that your systems are robust against potential attacks. Neither SOC 2 nor ISO 27001:2022 mandate a pentest, but they are recommended. Aikido works with multiple pentest agencies, but you’re free to pick any consultant you’d like.
Step 5: Stay safe – continual monitoring
How do you maintain secure systems? Aikido maintains your defense with ongoing monitoring, of course! Every 24 hours Aikido scans your environment to detect any new vulnerabilities and risks. Staying proactive in identifying and addressing any emerging vulnerabilities or threats with Aikido’s vulnerability scanning gives you peace of mind whether preparing for SOC 2 and ISO 27001:2022 or carrying out day-to-day business as usual.
Aikido's awesome capabilities enable companies to meet the technical vulnerability management requirements for SOC 2 and ISO 27001:2022 compliance. In doing so, you establish a secure environment that safeguards your data and infrastructure.
Benefits: integrating Aikido and Drata boosts efficiency and saves money
Aikido’s automates the follow-up process
Aikido is your autopilot that transforms technical vulnerability management – it continually monitors while running seamlessly in the background. When it finds a significant issue, you’ll get a notification.
Say goodbye to false positives
Traditional security platforms often overload you with every detected vulnerability. If those are sent to Drata, you still have to sort through and eliminate the false positives. However, Aikido’s mission from the beginning has been to eliminate those intruding false positives. So, Aikido’s advanced auto-triaging engine effectively filters out the noise and only sends legit vulnerabilities to Drata. This allows you to focus on genuine threats and save valuable time.
Cut costs on security expenses
The security sector often suffers from complex and aggressive pricing strategies, and companies who need security solutions suffer in turn. Some systems charge based on the number of users, which can lead to compromised security as developers might share accounts. And, this can add up very quickly with large teams! Others offer pricing based on the amount of code, which can also become costly fast.
Aikido breaks away from these norms with a clear, fixed-rate pricing model. Starting at just $314 per month per organization, Aikido’s pricing strategy can help you save about 50% compared to incumbent solutions.
Aikido + Drata = big win
Let’s look at reality in the face: to implement SOC 2 or ISO 27001:2022, you will need to do more than just technical vulnerability management. We wish it were that simple, but it is not! You’ll need a general, overall Security Compliance Software solution. A platform such as Drata automates complex and time-consuming compliance processes to ensure you are prepared for an audit.
But, with Aikido looking after your vulnerability management and feeding evidence to Drata through our integration, you are saving time! This makes all aspects of technical vulnerability management as easy as pie.
What are you waiting for? Try Aikido today for free (onboarding takes 30 seconds) and fast-track your compliance.
DIY guide: ‘Build vs buy’ your OSS code scanning and app security toolkit
You’re confident in your development chops—confident enough to know the apps you’ve built aren’t completely free of security and configuration flaws. You’ve also researched the deep ecosystem of scanning tools available and perhaps got overwhelmed by the sheer volume of choice. What’s the right “portfolio” of open-source app security tools to identify vulnerabilities in your dependencies, Infrastructure as Code (IaC) configurations, containers, and more?
To get you on the right track, we’ll cover 10 essential categories of code scanning and security tooling, and recommend 9 OSS projects, with just the essential information you need to get started:
- How that scan helps the security of your app.
- Which open-source project you can install and how to run it.
- Some alternatives (when available) you can pick from.
With that, you’ll have a no-BS path to scan your apps for critical security issues in code and cloud configurations. What’s not to love?
Well, the configuration and management part isn’t all roses—but we’ll get to that later.
What you’ll need
Just bring your local workstation, whether that’s a desktop or laptop—it doesn't matter if you’re using macOS, Windows, or Linux.
A developer environment is optional but recommended. To run this suite of open-source scanning tools, you’ll need to install a lot of software you might not want on your base OS, requiring bigger updates, polluting your autocomplete, and pinning you to specific tools that might not work across all your projects. A developer environment containerizes and isolates, to some degree, all your development-specific tooling from the rest of your OS.
Luckily, you have some great open-source tools to choose from:
- With Docker, you can spin up a new barebones container named
devenv-01
like so:docker run --name devenv-01 -it ubuntu:24.04 sh
- With Daytona, which comes with many “batteries included” for development workflows:
daytona create --code
- Or with Distrobox, which embeds any Linux distribution inside your terminal, letting you install software
The great thing about a developer environment is that once you’re done with a particular “stack,” you can safely delete the container without impacting your workstation.
#1: Cloud security posture management (CSPM)
How does CSPM help app security?
CSPM helps you enhance the security and compliance of your cloud environments. By continuously monitoring your applications and their upstream services against industry best practices and your internal policies, CSPM tools assess issues, prioritize them based on their criticality, and offer recommendations for remediation. With CSPM, you take more ownership of the baselines and guardrails that prevent yourself or others from promoting vulnerable applications to production while also rooting out misconfigurations and overly permissive user roles.
Install and run your OSS CSPM project: CloudSploit
To install CloudSploit, you’ll first need Node.js to download its dependencies and run the engine.
git clone https://github.com/aquasecurity/cloudsploit.git
cd cloudsploit
npm install
Next, you need to configure CloudSploit with read permissions to your cloud account, with support for AWS, Azure, GCP, and Oracle. Follow the directions for your cloud provider, using the repo’s config_example.js
file as your template, to create a config.js
file with all the details you’ll need to run your first complete diagnostic and get results in JSON.
./index.js --collection=file.json config.js
#2: Software composition analysis (SCA) of open-source dependencies
How does SCA help app security?
Your apps inevitably have a large tree of open-source dependencies that you now rely on, from your UI framework all the way down to helper libraries you use in a single LOC, like a validator for email addresses. SCA is like a background check on your code’s extended family, identifying security vulnerability and licensing issues not once, but continuously. Because your SCA tools notify you about new vulnerabilities and remediations, you’ll have confidence your open-source supply chain remains a helper, not a hindrance, to productivity.
Install and run your OSS SCA projects: Syft + Grype
For locally-run SCA, you’ll need Syft to create a software bill of materials (SBOM) and Grype to analyze said SBOM for known vulnerabilities. Since the same team makes Syft and Grype, they support many installation methods but recommend their respective one-liners:
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin
curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin
With Syft installed on your local workstation, you can create a SBOM for your container, replacing <YOUR-IMAGE>
with an image in a configured container registry or a local directory.
syft <YOUR-IMAGE> -o syft-json=sbom.syft.json
You’ll end up with a sbom.syft.json
in your working directory, which you can then feed into Grype.
grype sbom:path/to/syft.json -o json
Grype then prints out a vulnerability summary in the format below, including severity details and information about known fixes, which you can use to guide your prioritization and remediation process.
{
"vulnerability": {
...
},
"relatedVulnerabilities": [
...
],
"matchDetails": [
...
],
"artifact": {
...
}
}
Alternatives and caveats
Trivy is a solid OSS alternative for SCA—it won’t offer 1:1 feature parity across the board, but it will be more than enough to get you started.
#3: Secrets detection
How does secrets detection help app security?
A secrets detection tool scans your code and configurations for credentials you don’t want to expose publicly. These secrets can include API keys, access tokens to third-party providers, passwords to upstream databases, certificates, encryption keys, and more, and once they’re pushed to a public repository, you’ll have to go through a painful process to remove them from your Git history—better to detect them early and take action before you commit.
Install and run your OSS secrets detection project: Gitleaks
Gitleaks scans your repositories for the presence of hardcoded secrets, past or present, by parsing Git logs. Its detect
behavior identifies secrets that have already been committed, while the protect
behavior scans uncommitted changes to prevent you from making mistakes in the first place.
For maximum control, we recommend installing Gitleaks from source.
git clone https://github.com/gitleaks/gitleaks.git
cd gitleaks
make build
The first time you run Gitleaks, you can create a baseline report to give you results only for new secrets exposure.
gitleaks detect --report-path gitleaks-report.json
With subsequent invocations, you should reference your gitleaks-report.json
file to scan Git logs for only secrets added since you created your baseline report.
gitleaks detect --baseline-path gitleaks-report.json --report-path findings.json
Your findings.json
file will contain details about the commit hash and author of each potential leak, helping you focus on fixes.
Alternatives and caveats
Unfortunately, there aren’t many options beyond Gitleaks. Other open-source secrets detection projects have gone years since the last commit—not exactly confidence-inspiring to protect the apps you’re working on today. If you’re a service provider, you can register for the GitHub secret scanning partner program, which identifies when your users accidentally commit your secret token formats to one of their repositories.
#4: Static application security testing (SAST)
How does SAST help?
SAST is the fine-toothed comb of app security tools, analyzing your codebase line by line to check for flawed syntax, structure, or logic that could leave your app vulnerable. Think SQL injection attacks, cross-site scripting (XSS) opportunities, buffer overflows, and more. By checking against popular databases of known CVEs, a solid SAST tool will give you confidence that you’re not leaving big security flaws on the table—and some even offer autofix suggestions for quick remediation.
Install and run your OSS SAST project: Semgrep
Semgrep scans your code, finds bugs, and enforces established code standards with every invocation, with support for more than 30 languages. For the sake of simplicity, we’re focused on Semgrep CLI, which is just one part of a complex ecosystem of products.
The most universal way to install the Semgrep CLI is with Python/pip.
python3 -m pip install semgrep
Run your first scan to create a report of code-level flaws and vulnerabilities as a JSON file.
semgrep scan --json --json-output=semgrep.json
Alternatives and caveats
The SAST world is brimming with opportunity—if Semgrep doesn’t work for you, check out some language-specific alternatives like Bandit (Python), Gosec (Go), or Brakeman (Ruby on Rails) to get yourself started.
#5: Dynamic application security testing (DAST)
How does DAST help app security?
Unlike SAST, DAST simulates commonly exploited vulnerabilities against your app in a live environment. It’s less about the syntax and structure of the code you wrote and much more about replicating the approaches an attacker might take against your production deployment. DAST tools will double-check known CVEs in frameworks and libraries you use and test whether logged-in users can access sensitive data due to broken permissions or “toxic combinations” of multiple vulnerabilities that open your app to far worse consequences.
Install and run your OSS DAST project: Nuclei
Nuclei is a community-driven vulnerability scanner that uses templates to send requests to the app you want to secure running in a local environment. You can write custom templates using YAML, but the Nuclei community also has an extensive library of pre-configured templates to test against your app.
You need Go on your local workstation to install Nuclei.
go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest
From there, the simplest way to run Nuclei is by specifying a single target—your app running locally in a developer environment—and leveraging the template library, which Nuclei activates by default.
nuclei -u localhost:5678 -je nuclei-report.json
Alternatives and caveats
The Zed Attack Proxy (ZAP) is a fantastic scanner actively maintained by a global team of security experts and developers. However, unlike others in this list, ZAP is a graphical app by default. There are options for using your terminal, but they’re not exactly the most developer-friendly compared to other processes you’ve followed this far.
#6: Infrastructure as code (IaC) scanning
How does IaC scanning help app security?
Your code is just half the equation in getting to production—today, most teams use IaC tools like Terraform, CloudFormation, and “base” Kubernetes Helm charts to provision cloud services in a declarative, version-controlled, and repeatable fashion. IaC scanners identify vulnerabilities in these JSON or YAML blueprints to prevent you from ever deploying an insecure state to production.
Install and run your OSS IaC scanning project: Checkov
Checkov scans many types of IaC code—Terraform configurations, Helm charts, Dockerfiles, and more—for common misconfigurations and potential security vulnerabilities. With more than 1,000 built-in policy checks for AWS, GCP, and Azure, the tool quickly helps you understand your cloud deployments' current risks and opportunities in a few minutes.
The team recommends installing Checkov locally via Python’s package manager.
python -m pip install checkov
You can then run Checkov against your working directory (or another directory where you’ve stored IaC files) and get a JSON file as your output.
checkov --directory . -o json
#7: Container image scanning
How does container image scanning help app security?
We love containers because they abstract away so much complexity, but whenever you build a container image, it can inherit vulnerabilities from its base image or package dependencies. Container image scanners discover vulnerabilities in your base images and Dockerfiles, however deep the dependency tree goes, to prevent you from unwittingly deploying an exploitable app.
And that is also how container image vulnerabilities were born.
Install and run your OSS container image scanning project: Trivy
Trivy is a versatile security scanner capable of parsing your container images for known vulnerabilities with CVEs, IaC issues and misconfigurations, the presence of secrets, and more. The Aqua Security team, which is behind the open-source Trivy project, maintains a public database of vulnerability information, gathered from more than a dozen data sources.
In tune with the other installation mechanisms recommended so far, we recommend using Trivy’s script for installing directly from the latest GitHub release.
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin v0.51.1
By default, Trivy scans container images for vulnerabilities, misconfigurations, and secrets against any container image you specify, with results in standard JSON format.
trivy image --format json --output trivy-result.json <YOUR-IMAGE>
Alternatives and caveats
If you’ve been following along, you already have Grype installed on your local workstation from the previous section on SCA, and it works great for scanning container images with an SBOM created by Syft. If you’re on AWS, this is another place where Amazon Inspector can come in handy in a “two birds, one stone” fashion.
Amazon Inspector is also an option, but with two big caveats—first, it only works with AWS deployments, and second, it’s not open-source software like the rest of our recommendations, meaning it comes with new monthly costs.
#8: Open-source license scanning
How does open-source license scanning help app security?
The legality of using open-source software in your commercial products isn’t something you check with legal or compliance teams once and forget about. OSS projects change licenses more frequently than you might understand, requiring you to either pay for an enterprise version, seek an alternative, or open-source some of your private code. License scanners identify changes and help you sail through security audits with a ready-to-go software bill of materials (SBOM).
Install and run your OSS license scanning project: Syft
As with Grype in the last step, you already have Syft installed on your local workstation and might even have an existing SBOM from setting up your SCA integration with Grype. If you don’t yet, you can quickly create a new one by either referencing a container image from a configured registry, or a path on your local workstation.
syft <YOUR-IMAGE> -o syft-json=sbom.syft.json
syft /path/to/image -o syft-json=sbom.syft.json
Depending on the complexity of your image and the depth of dependencies, you might get an SBOM file that’s a few thousand lines long. Within all that JSON output, you’re looking within the artifacts
array for the licenses
values of each package and dependency your container image relies on.
{
"artifacts":[
{
"id":"cdd2655fffa41c69",
"name":"alpine-baselayout",
"version":"3.4.3-r2",
"type":"apk",
"foundBy":"apk-db-cataloger",
"locations":[
…
],
"licenses":[
{
"value":"GPL-2.0-only",
"spdxExpression":"GPL-2.0-only",
"Type":"declared",
…
With these details in a single SBOM, you’ll be able to scan your licensing obligations for changes you might need to make downstream or migrations you should start preparing for. You'll also have a go-to resource for the next security audit you’re subjected to.
Alternatives and caveats
Trivy, first mentioned in the previous section, has a license scanning feature that presents you with opinionated results about the risk associated with the projects in your open-source dependency tree.
#9: Malware detection
How does malware detection help app security?
Malware scanners help you identify a threat that’s taken off in recent years: malware injected into dependency packages by attackers. The recent zx backdoor attempt is a fantastic—and frightening—example. Malware scanners detect these software supply chain attacks before you even merge your code to prevent you from having to make time-sensitive and costly fixes once the CVE goes public.
Install and run your OSS malware detection project: Phylum
Phylum’s CLI tooling lets you submit your lockfiles to their API for dependency analysis, which differs slightly from the other open-source tools we’re recommending here—the analysis doesn’t happen on your local workstation. Instead, you need to register an account with Phylum for authentication with their service.
Start by installing Phylum locally.
curl https://sh.phylum.io | sh
Then register your account and run your first analysis—Phylum should identify the lockfile you’re using.
phylum auth register
phylum auth login
phylum init
phylum analyze --json
Phylum’s analysis delivers a comprehensive output, starting with a true
or false
result based on whether your project passes Phylum’s malware check. Under the rejections array for each dependency, you’ll find a detailed description of the vulnerability and remediation advice from the OSS community. This allows you to aggregate results from your SAST, DAST, and SCA tests, empowering you to understand which vulnerabilities are due to your dependencies and which are embedded directly into the code you wrote.
{
"is_failure": true,
"incomplete_packages_count": 2,
"help": "...",
"dependencies": [
{
"purl": "pkg:npm/next@13.5.6",
"registry": "npm",
"name": "next",
"version": "13.5.6",
"rejections": [
{
"title": "next@13.5.6 is vulnerable to Next.js Server-Side Request Forgery",
"source": {
"type": "Issue",
"tag": "HV00003FBE",
"domain": "vulnerability",
"severity": "high",
...
#10: End-of-life (EOL) runtime detection
How does EOL runtime detection help app security?
The more frameworks, libraries, and runtimes you include in your app, the more opportunities there are for you to be leveraged dangerously against outdated versions or unmaintained dependencies. This is especially critical for runtimes directly exposed to the public internet. EOL runtime detectors read your dependency tree through lockfiles—even those in containers—to alert you well ahead so you can prepare for updates or migrations.
Install and run your OSS project: endoflife.date
endoflife.date is a database of EOL information about more than 300 tools and platforms, many of which are integral to the operation and security of your app. Instead of you having to explore obscure documentation sites or trawling through mailing lists to discover when a specific version of your dependency becomes unmaintained, you can quickly put dates around necessary upgrades to prioritize your efforts moving forward.
The easiest way to discover EOL data is to explore the site, paying particular attention to your programming languages, databases, frameworks, deployment tooling, and CLIs for cloud services.
As a developer, you might want a more CLI-centric approach to exploring EOL data for your major runtimes and libraries—endoflife.date has a simple API that outputs JSON data, which you can also append to a local file for future reference.
curl --request GET \
--url https://endoflife.date/api/nginx.json \
--header 'Accept: application/json' \
>> eol.json
A new problem: Managing all your code scanning and app security data
If you’ve followed along this far, you’ve built a handy toolkit of open-source code and configuration scanning tools. You’re ready to start running these against your locally-stored projects and branches for far better pre-commit security guarantees. Take that, shift left!
Your future, however, isn’t instantly faultless. This new toolkit comes with a big caveat: Your tools don’t speak together, and only around your app.
You’re still on the hook to:
- Individually configure each tool. Let’s take a simple option, like an allowlist of certain directories or dependencies you don’t want to bother scanning, as they’re not relevant to the security of your production environment. You’ll need to learn the arguments for each CLI tool by reading documentation and testing, which steals away valuable time from what you actually want to do: implement fixes.
- Run each scanner against each repository and branch. Even if you have a single repo and two branches—
main
anddev
—that’s nearly 20 operations to scan for vulnerabilities. Ideally, you’re running these scanners before you ever push changes to a remote, which means plenty of repeated operations throughout your day.
There are some ways to simplify this, of course. You can write a script to chain these open-source scanners together to run manually or as a pre-commit Git hook. That saves you terminal time, but only generates JSON output faster—you’re still on the hook for understanding what’s changed and whether you can still push your changes and (finally) create your pull request. - Trawl through massive JSON arrays for insights. These tools often produce output thousands of lines long. The comprehensiveness is good, but who has time to explore dozens or hundreds of potential security issues, hoping to understand each one well enough to understand its severity?
Over time, you’ll need more intuitive way to read results than unformatted lines of JSON, like importing into Google Sheets or building a simple app for viewing results. - Understand what’s changed between runs. Security scanning has two purposes. First, to help you identify existing problems in your code and configuration. Second, to prevent you from introducing new vulnerabilities as you build. If you can’t quickly understand whether you fixed a certain vulnerability or aren’t notified upon a new one slipping into your code, this whole effort is wasted time.
One option is to increment or timestamp your output JSON files, then use CLI tools to compare them.diff file1.json file2.json
is a great standalone tool, or you can trygit diff --no-index file1.json file2.json
for files not committed to your Git repository. - Aggregate, store, and share data for long-term analysis. As we’ve said before, security scanning is a continuous operation, not a one-off item on your TODO list. Plus, the results of your scanning efforts shouldn’t be locked away on your local workstation—your peers will want to know about the vulnerabilities most relevant to what they’ve built, even if they don’t have a similar toolkit running at the moment.
You’ll need to explore data platforms that put all this information into one place—yet another piece of infrastructure to self-host or pay for. - Create tickets in Jira or GitHub. You or a peer must escalate each identified vulnerability into a relevant ticket containing all necessary context and possible remediations. That’s the only way to ensure security transparency, get your peers to collaborate, and create the audit log your compliance standards might require. None of these tools support integration with your ticket platform, so you’ll have to create these tickets manually—and there could be dozens, if not hundreds, to wade through.
- Prioritize said tickets based on severity. Flooding your repositories with tickets is a project management nightmare. It’s a different but equally painful version of alert fatigue: How does anyone know which to focus on first? If your OSS tools can’t help you with severity, you’ll have to spend time making those determinations yourself, which might involve years of security knowledge you simply can’t shortcut.
- Manage the lifecycle of each OSS tool. Whether it’s keeping your tools up-to-date, trying to build automation, or looping runs and results into your CI/CD pipeline, you’re now on the hook for the long-term efficacy of your toolkit. You might have a better security posture than ever before, but at what cost to your real-world posture?
- Worry and wonder about what happens if the project loses its maintainer. If your dependencies and runtimes can reach EOL and create problems, so can the tools and platforms your local development environment depends on. Unfortunately, open-source projects are often built upon funding and maintainer models that are not sustainable for the long haul. You can still use stagnant or abandoned projects in your CLI, but when trying to improve your app security, they won’t help you uncover new vulnerabilities or methods of attack.
The current conversation in developer tooling swirls around a single concept: developer experience (DX). The better the DX, the more likely a tool will be integrated, used, treasured, and championed. And let’s be honest—the DX of this locally-run OSS scanning toolkit isn’t particularly great. You fully own your process and data, but at exceptional costs and time commitment. How much are you willing to pay for advanced app security?
Open-source security tools are amazing—we’ve even built a web application firewall for autonomously protecting Node.js apps against common and critical attacks—but for continuous security scanning and vulnerability remediation, there has to be another way. Maybe even one that’s built on top of this fantastic OSS foundation.
A new app security solution: Aikido
Aikido integrates all those open-source projects and a whole lot more.
Instead of running 10+ tools every time you get ready to commit your latest changes, you just need to add your repositories, Docker images, and cloud providers to Aikido once for comprehensive scanning. Aikido runs automatically in the background for continuous scanning or in your CI/CD pipeline for targeted recommendations with every pull request, protecting you from new vulnerabilities while pointing out existing ones that have been lurking in your codebase for months or years.
Even better, all results, context, and possible remediations are aggregated and stored in a single place—the Aikido dashboard—so you never have to worry about parsing JSON, merging multiple data sources, or shelling out for an expensive data management platform to create a source of truth. We’ve even built custom rules and special “glue” between these open-source projects to unearth correlations and results that would otherwise require an in-house specialty security researcher.
Aikido also integrates with your task management and messaging platforms, like GitHub and Slack, to create pre-triaged and -prioritized tickets. With all the context, documentation, and suggested autofixes, anyone on your team can pick up the issue and see it through remediation quickly and comprehensively.
App security would be in a far worse place if not for these open-source tools and many others. That’s indisputable. But just because of the way developer tools operate—on your local workstation, inside your terminal—means they’re both infinitely flexible and inherently isolated. The “it worked on my machine” meme still applies here, just with different verbiage:
If you’re looking for another way, which replaces all the burden of building this open-source toolkit with a platform that’s already built on top of the same projects, consider giving Aikido a shot for free.
If you choose the OSS route, you have our props and respect… but while you’re layering new tools and dependencies into your workflows, you really should let Aikido’s Web Application Firewall autonomously and continuously protect your Node.js apps from even the most vicious of vulnerabilities. The best DX, after all, is when the tool truly does all the hard work for you.