Welcome to our blog.

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:

1. 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
2. With Daytona, which comes with many “batteries included” for development workflows: daytona create --code
3. 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:

1. 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.
   
2. Run each scanner against each repository and branch. Even if you have a single repo and two branches—main and dev —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.
   
3. 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.
   
4. 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 try git diff --no-index file1.json file2.json for files not committed to your Git repository.
   
5. 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.
   
6. 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.
   
7. 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.
   
8. 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?
   
9. 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.

Maybe you’re considering AICPA SOC 2 certification? Aikido was recently examined to check that our system and the design of our security controls meet the AICPA’s SOC 2 requirements. Because we learned a lot about SOC 2 standards during our audit, we wanted to share some of the insights that we think might be helpful to someone starting the same process.

Read our top tips on becoming ISO 27001:2022 compliant.

Type 1 vs. Type 2

The first thing to understand is that there are two different types of SOC 2 certification: SOC 2 Type 1 and SOC Type 2. If you’re only starting to think about SOC certification, Type 1 might be a good first step. It’s faster to get and the requirements aren’t as demanding. Type 1 is also less expensive than Type 2 report.

But the difference is that it doesn’t cover monitoring over an extended period. Your cybersecurity measures are only checked at one specific time during a SOC 2 Type 1 audit. In contrast, the SOC Type 2 certification process tests your security controls over a period of time. In effect, Type 1 tests the design of your security controls, while Type 2 also tests their operating effectiveness.

Note: You might also read about the ISAE3402 Type I report. That’s the European alternative, but in practice, most industries don’t worry about it. So go for SOC 2 unless you already know you need the European one.

SOC 2 trust services criteria

An SOC auditor will typically use five trust services criteria to evaluate companies for SOC 2 compliance:

• Security: protect data and systems from unauthorized access.
• Availability: make sure customer data can be accessed when needed.
• Confidentiality: make sure that confidential information is sufficiently protected.
• Privacy: protect personal information.
• Processing integrity: ensure that systems process data accurately and reliably.

Not every business needs to include all five criteria. Part of preparing for your SOC 2 audit is deciding which criteria your customers will require.

Additional industry-specific criteria also exist. For instance, a cloud service provider will have more stringent client data encryption requirements, while healthcare providers will need to protect health information.

Our top 5 SOC 2 certification tips

1. You can’t really become SOC 2 “compliant”

Unlike ISO 27001, you can’t reach a state of SOC 2 compliance. It’s a report that a potential customer can request so that they can evaluate the company’s security posture. The customer has to make their own decision on whether that company is secure enough to do business with.

You’ll get an SOC 2 report demonstrating compliance with specified criteria, but that doesn’t mean that you go from non-compliant to compliant. That doesn’t reduce its value for your business partners. They know what they need and will often require an SOC 2 audit report.

For example, SOC 2 doesn’t necessarily require you to carry out a pentest, but it is highly recommended for ISO 27001. Vanta, one of the top SOC 2 compliance monitoring platforms, recommends treating SOC 2 as a bar that you need to get over to be seen as having reached essential security standards. But you might go the extra mile after you get over that bar, and your customers will probably appreciate the extra reassurance.

In that sense, your SOC 2 compliance report means that you’ve satisfied the auditor that your company meets the SOC 2 trust services criteria.

2. Type 2 is based on a compliance observation period

SOC 2 Type 2 reports check your security posture over an observation period called an audit window. You can select a window of between three months to a full year. This is much more thorough than SOC 2 Type 1 and it means that stakeholders and prospective customers get additional reassurance on security systems and data security.

You’ll need to consult with your auditor to choose the audit window. It can depend on factors such as regulatory requirements, customer expectations, or how recently you developed your security frameworks and controls.

3. SOC 2 vs. ISO 27001: if your potential customers are in the US, SOC 2 is for you!

Companies in the United Stated typically request SOC 2 reports more often, while European companies tend to rely more on ISO 27001. This is because SOC 2 is an American standard. If you can, get both. That’s what we did, as we also became ISO 27001 compliant in 2023. If you can’t do both, choose based on where your customers or prospects are based.

If your customers are in the US, there’s a good chance they’ll be looking for your SOC 2 report.

4. We recommend that you work with an auditor in the US

If you’re based in Europe, there are lots of SOC auditors. They’re probably very good, but if you want a US company to trust your report, it makes sense to go with a third-party SOC 2 auditor in the United States.

5. Use a secure system for customers to request your SOC 2 report

You should make it easy for customers to request your SOC 2 report, but don’t make it too easy. Hackers might use it to identify weak spots in your security.

Don’t use email and use a tool that tracks what happens to the report after it gets downloaded. You should know who is requesting it, track when it was requested, and even consider watermarking or password protection. The best approach is to use an NDA.

Aikido and ongoing SOC 2 compliance

Now that we’ve completed our own SOC 2 journey, Aikido Security fulfills all SOC 2 trust services criteria. We have also partnered with compliance monitoring platforms (such as Vanta, Drata, Secureframe, and Thoropass) to regularly sync data on current security controls and make sure that Aikido, and our customers, maintain a strong security posture.

Request our SOC 2 Type 2 report

You can request Aikido’s SOC 2 Type 2 certificate on our security trust center.

Or if you’re considering SOC 2 certification and still have questions, connect with me on LinkedIn and I’ll be happy to discuss the process with you in more detail.

You know your latest web application is inherently vulnerable to all kinds of attacks. You also know app security can never be perfect, but you can make it better tomorrow than it was yesterday.

The problem is that whether you’re using enterprise-grade (aka, expensive and complex) security tools, or have cobbled together a handful of open-source projects into a CI/CD pipeline or Git commit hooks and are hoping for the best, your toolkit can’t help you see:

• How your app could be vulnerable due to less-than-ideal programming practices, insecure dependencies, and beyond.
• Where the vulnerabilities are most likely hiding, down to single LOCs or entries in your package.json file.
• Why you should fix certain vulnerabilities immediately and why others are lower priority.

Aikido exists to make app security relevant and efficient for developers who need to apply the right security fixes fast and get back to shipping code. Just like we do in our developer-centric security platform, we’re going to reduce the noise around common vulnerabilities and focus on three essential details:

• The TL;DR, which will teach you just enough to be afraid… and the right keywords to continue your educational search.
• A concise answer to the question, “Does this affect me?” with a clear yes or no (✅ or 🙅) and brief explanation.
• Quick tips in response to “How can I fix it?” that don’t involve expensive tools or costly refactors.

#1: SQL injection && NoSQL injection

TL;DR: This classic vulnerability is made possible by unsanitized and unvalidated user input, which allows attackers to run queries directly against your database. From there, they can extract data, modify records, or delete at will, completely negating any other app security measures you’ve put into place.

Does this affect me?

• ✅ if your app interacts with a SQL or NoSQL database at any point. Injection attacks have been around for decades, and automated attacks will immediately start to probe your endpoints with common exploits.
• 🙅 if you have no dynamic content based on database records. This could be because you’re entirely client-side, using a static site generator (SSG), or doing server-side rendering with a database but never accepting input from users.

How do I fix it? First and foremost, sanitize and validate all user input to eliminate unwanted characters or strings. Leverage open-source libraries and frameworks that allow for parameterized queries, and never concatenate user input into a database query. If you’re using Node.js, consider our open-source security engine Runtime, which autonomously projects you from SQL/NoSQL injection attacks and more.

#2: Cross-site scripting (XSS)

TL;DR: XSS is another injection attack that allows an attacker to send a malicious script to another, potentially gathering their authentication credentials or confidential data.

Does this affect me?

• ✅ if your app accept user input and outputs it elsewhere as dynamic content.
• 🙅 if you don’t accept user input at all.

How do I fix it? As with SQL/NoSQL injection attacks, you should validate user input when you include said input inside the href attribute of anchor tags to ensure the protocol isn’t javascript. Take care when using JavaScript methods like innerHTML or React’s dangerouslySetInnerHTML, which can arbitrarily execute any code embedded into the string during output. Regardless of your approach, sanitize HTML output with open-source sanitizers like DOMPurify to send only clean, non-executable HTML to your users.

#3: Server-side request forgery (SSRF)

TL;DR: SSRF attacks happen when a malicious actor abuses your app to interact with its underlying network, operating it like a proxy to jump to potentially more vulnerable or lucrative services.

Does this affect me?

• ✅ if your app interfaces with another service or API that performs a specific operation with user data—even if you’ve used allowlists to restrict traffic between only known and trusted endpoints.
• 🙅 if you’re truly static.

How do I fix it? While a regex to validate IP addresses or hostnames is an okay start, it’s usually prone to bypasses like octal encoding. Two more reliable solutions are to use an allowlist and your platform’s native URL parser to restrict input to only safe and known hosts, and disabling redirects in the fetch requests. Depending on your framework, you can also freely leverage open-source projects—like ssrf-req-filter for Node.js—to properly refuse any requests to internal hosts.

#4: Path traversal

TL;DR: This security flaw lets attackers access files and directories on your web server by reference files using ../ sequences or even absolute paths. Using sneaky tactics like double encoding, attackers can use framework-specific folder-file hierarchies or common filenames to find valuable information.

Does this affect me?

• ✅. Your app runs on a web server and includes references to the filesystem—no skirting around this one.

How do I fix it? Your first step is to remove any sensitive files, like any containing environment variables or secrets, from your web server’s root directory, and establish a process to prevent further slip-ups.

be to never store sensitive files, like those containing environment variables or secrets, in your web server’s root directory. Also, don’t store these files in any folder meant to be publicly accessible, like the /static and /public folders of a Next.js project. Finally, strip ../ path separators and their encoded variants from user input.

Runtime also works fantastically well for path traversal… just saying.

#5: XML eXternal Entity (XXE) injection

TL;DR: XXE attacks leverage a weakness in XML parsers that allows external entities, referenced by a document type definition (DTD), to be fetched and processed without validation or sanitization. The type and severity of the attack are limited mostly by the attacker’s skills and any OS-level security/permissions from your infrastructure provider.

Does this affect me?

• ✅ if you parse XML for any reason, including single sign-on authentication flows using SAML.
• 🙅 if you don’t have to deal with XML in your app!

How do I fix it? Disable external DTD resolving in your XML parser. You likely can’t refuse DTDs entirely, as it’s normal for some XML payloads to contain them—just don’t let your XML parser do anything with them.

#6: Deserialization

TL;DR: Attackers can send malicious data through a deserialization function built into your app (like unserialize() from node-serialize) to execute code remotely, run a denial-of-service, or even create a reverse shell.

Does this affect me?

• ✅ if your app deserializes data directly from user interaction or through background functions/services like cookies, HTML forms, third-party APIs, caching, and more.
• 🙅 if you’re running a fully-static app with none of the above.

How do I fix it? In general, avoid deserializing user input (aka untrusted) data. If you must, only accept said data from authenticated and authorized users based on trusted signatures, certificates, and identity providers.

#7: Shell injection/command injection

TL;DR: Your app passes user input directly to the underlying shell of the OS on which your web server and app executes, allowing attackers to execute arbitrary commands or traverse the filesystem, often with sufficient privileges to extract data or pivot to another system.

Does this affect me?

• ✅ if your app interacts with the filesystem or shell directly, such as a UNIX command like cat.
• 🙅 if you already use a framework API or method to safely pass arguments to the command you need to execute, or don’t need to interact with the filesystem/shell, such as in an SSG.

How do I fix it? Avoid accepting user input directly into commands or calling them directly. Instead, use your framework’s API/method, like child_process.execFile() in Node.js, which lets you pass arguments in a list of strings. Even with that protection, always run your apps with the least privileges necessary for the required business logic to prevent an attacker from “escaping” the web server and accessing root-only folders and files.

And yes, we’re back for one more friendly reminder to add Runtime to any Node.js project with one command (npm add @aikidosec/runtime || yarn install @aikidosec/runtime) to instantly protect your app against common shell/command injection attacks.

#8: Local file inclusion (LFI)

TL;DR: LFI attacks involve tricking your app into exposing or running files on the system running your web server, which allows attackers to extract information or execute code remotely. While path traversal only allows attackers to read files, LFI attacks execute those files within your app, opening you up to a laundry list of app security vulnerabilities like remote code execution (RCE).

Does this affect me?

• ✅ if your app uses the path to a file as user input.
• 🙅 if your app doesn’t require users to supply paths to complete any action.

How do I fix it? Always sanitize user input to prevent the path traversal methods discussed above. If you must include files on the local filesystem beyond those typically found in “safe” /public or /static folders, use an allowlist file names and locations that your app is permitted to read and execute.

#9: Prototype pollution

TL;DR: This JavaScript-specific vulnerability lets an attacker manipulate your app’s global objects using __proto__. The new object is then inherited across your app, potentially giving them access to confidential data or further escalating their privileges.

Does this affect me?

• ✅ if you’re using JavaScript.
• 🙅 if you’re using anything but JavaScript!

How do I fix it? Start by sanitizing keys from user input using allowlists or an open-source helper library. You can extend your protection by using Object.freeze() to prevent changes to a prototype, or even using the --disable-proto=delete flag offered with Node.js.

#10: Open redirects

TL;DR: In this common vector for phishing, attackers craft a custom URL like https://www.example.com/abc/def?&success=true&redirectURL=https://example.phishing.com to trick your app into redirecting unsuspecting users to a malicious website. In addition, attackers can chain redirects together with other vulnerabilities for even more impact, leading to account takeovers and more.

Does this affect me?

• ✅ if your app redirects users to another page/view after completing an action, like sending them to example.app/dashboard after successful authentication.
• 🙅 if you’re still living that static-generated life.

How do I fix it? First, remove parameter-based redirects from your app and replace them with fixed redirects based on an allowlist of trusted domains and paths to which you can redirect users after they take specific actions. This might slightly degrade the user experience, but it’s a meaningful compromise for better app security, not one that leaves them blaming you for the strange expenses on their credit card statement.

What’s next for your app security?

If you’re feeling overwhelmed by the scope of attacks and all the work required to protect against them, know you’re not alone.

No one expects you to solve all these security problems and possible vulnerabilities yourself. SQL injection attacks alone have existed for decades, and folks are still finding CVEs in sophisticated apps, frameworks, and libraries all the time. That’s not to say you should also take these security problems with a grain of salt—if your project meets the ✅ for any of these top 10 app security problems, you should start taking action.

First, sign up for Aikido to start focusing on the genuine threats to your app security. In two minutes, and for free, you can scan repositories and get relevant details plus guided remediations for the most critical vulnerabilities based on specific architecture of your app and what features, functions, and helper libraries you’ve implemented. With Aikido, you’ll reduce scope to what matters and implement smart fixes faster, and get informed instantly of new security problems introduced in your latest commits.

Next, add Runtime, our open-source embedded security engine, to your Node.js apps. Runtime instantly and autonomously protects your apps against various injection, prototype pollution, and path traversal attacks by blocking them at the server-level, but without the cost and complexity of web application firewalls or Agent-based application security management platforms. Runtime gives you confidence your app and users are safe from these common security problems, but can also feed real-time data back to Aikido to give you visibility into current attack vectors to help you prioritize fixes.

Now you’re off on the right foot, with a clearer picture as to:

• How your app is vulnerable in more ways than you might have once thought.
• Where you should focus your time and attention to fix the most critical issues first.
• Why app security and vulnerability scanning isn’t a one-time effort, but a continuous process—one made a whole lot easier with Aikido.
  

TL;DR we raised a lot of money and we’re ready to go big.

We've raised $17M to bring “no BS” security to devs. We’re happy to welcome Henri Tilloy from Singular.vc on board, who is again joined by Notion Capital and Connect Ventures. This round comes just 6 months after we raised $5.3M in seed funding. That’s fast.

We founded Aikido because developers have a problem. Security and compliance requirements are no longer just for large enterprises - they are now a growing necessity for companies of all sizes, especially SMEs looking to win customers and scale up. Compliance standards like SOC2, ISO 27001, CIS, HIPAA, and the upcoming European NIS 2 Directive are becoming baseline requirements for software companies, especially those selling to enterprises or handling sensitive data, like in HealthTech or Fintech.

But this growing compliance burden often falls on the shoulders of developers, who are now expected to function as security experts. That's why we built Aikido - the all-in-one platform that brings together all the necessary code and cloud security scanners in one simple, easy-to-use interface, leveraging the best open source has to offer. We’re freemium, self-service, and open about what is under the hood and how much it’ll cost you.

We're an outsider challenger in the established, tight-knit security industry, which has long been dominated by US and Israeli enterprises led by industry veterans. Yes, there have been security tools for three decades, but we’re starting from a very different position. We are building a security platform where the buyer is the user. As it so often is, the CISO is the buyer, but then some poor developer is the user.

We’ve been that poor developer before. We have felt the frustration of working with clunky, legacy security tools that waste our time and our money. We wasted hundreds of hours on irrelevant security alerts as CTOs ourselves. We know how these tools look like the inside of an F-16’s cockpit. We know how they make you feel dumb, how you get so swamped with complexity and false alerts, that people stop checking them all together. We understand that a developer just wants to fix problems and move on with building fun features.

We’re excited to work with Henri and Singular. He’s one of the first investors we felt actually understood the product, and didn’t just see us as a spreadsheet. He believes that we have “an incredibly unique approach to security” as we are “simple, leverage open-source, and easy to set up and use, yet Aikido ticks off the boxes of company compliance and security requirements in one go." (We like him for his nice quotes and compliments too).

In less than a year since our launch, we are already used by over 3,000 organizations and 6,000 individual developers. Visma choosing us to secure all of its portfolio of 175+ companies was major and confirmed we’re on the right track (not that we doubted it ;)) We have 30% of our customers in the US and we're now aiming for further international expansion to help developers and SMEs get security done.

This new $17M Series A funding will allow us to deepen our platform and push Aikido onto the global stage, making security simple for SMEs and doable for developers without the industry jargon, red tape, and frankly, BS.

Want to join us?

Why are you here?

Let’s not waste time. You’re here because you’re building a webhook feature in your app. Unfortunately, there are quite a few things that can go wrong from a security perspective. This article aims to ensure that you’re not making any well-known mistakes while building webhooks.

How do webhooks work?

As a quick recap, webhooks are HTTP(S) requests to third parties to inform them about something that happened in your app. For example, if you offer an application that generates invoices, you might offer your customers the opportunity to set up webhook functionality that is triggered when a new invoice is created. This means that when the invoice is created, your application will send a HTTP(S) request to a location that is determined by the user. The user can use this to set up their own custom workflows that are triggered by the webhook, such as scheduling reminder emails, or sending the customer a message on Slack.

Checklist: securing webhook implementations

1. Defeating SSRF-type attacks

In this type of attack, the attacker tries to get information (e.g. instance metadata in a cloud) by exploiting the webhook feature. To counter it, you should take the following measures.

✅ Validate user input

• Basic: Perform simple URL validation.
• Better: Ensure URL starts with "https://", disallow "file://" and other non-HTTPS schemes.

✅ Restrict Local Addresses

• Block typical local IPs: 127.0.x, 192.168.x, 172.x.
• Prohibit "localhost" and "http://"

✅ Limit Log Exposure

• Show only HTTP status codes in user-facing logs.
• Avoid displaying headers or body content.

✅ Advanced: Enhanced URL Validation

• Require a specific response header for POST requests, unique to the customer.
• Maintain this verification continuously, even after initial setup, to counter DNS changes..

2. Allow your users to verify data authenticity

Your webhook consumer must have a way to know the data really comes from your app. You can use any of the following methods.

✅ Test Message Verification

First, enable users to trigger a test message to test security mechanisms.

✅ HMAC Verification Hash

One of the most effective security mechanisms for webhooks functionalities is implementing HMAC for data integrity and authenticity.

The basic process can be summarized as follows:

• Generate a hash of the payload using SHA-256 and a secret key.
• Send the HMAC with the payload.
• Recipients recreate the hash to verify payload authenticity and integrity.

✅ Timestamp Inclusion

This is more of an advanced security mitigation. Add a timestamp to the payload to prevent replay attacks. Ensures messages are not reused or altered.

✅ Client-Side TLS Certificates

Authenticate HTTP calls with client-side TLS certificates. This is particularly appealing for enterprise-level consumers.

3. Rate limit and avoid data overexposure

For webhook security, sending too little data is more secure than attaching too much. Although webhook callbacks should be encrypted using HTTPS, you can never know who might be in control of a domain name after a few years.

✅ Minimize Data Exposure

• Avoid sending Personally Identifiable Information (PII) or sensitive data.
• Instead of sending multiple data points (like contact_id, email, name), just send the contact_id. Let users fetch additional data through your public API if needed.

✅ Retry Policy Communication

• Clearly communicate the retry policy and rate limits to users.
• Inform them that due to retries, messages may arrive out of order.
• Define that any 2xx response is a success; other responses should trigger a retry.

✅ Use a Queue System for Delivery

Implement a queue system to manage webhook delivery and throttle output. This approach helps prevent accidentally overwhelming your users' servers in edge cases, like a large CSV import triggering excessive webhook calls and retries.

4. Bonus: Anomaly alerting

This is more for developer convenience than security, but it's a good thing to implement nonetheless.

• Alert users when 4xx and 5xx responses are encountered
• Send notifications to inform users of any failures

This addition enhances transparency and responsiveness in your webhook system.

Conclusion

And there you have it! We've covered some steps to make your webhooks not just functional, but also secure and user-friendly. Implementing these steps will safeguard your app and also enhance the overall user experience. Happy coding! 🚀🔒👨‍💻

Aikido Security is a developer-centric software security platform. We help keep your product secure, so that you can focus on writing code. You don’t need to talk to a sales team - just connect your GitHub, GitLab, Bitbucket or Azure DevOps account to start scanning your repos for free.

Visma selects Aikido security, entrusting them to deliver software security to their portfolio of 170+ companies. Securing software is vitally important to Visma, whose operations deliver software to dynamic SMEs, powerhouse corporations, and key public institutions worldwide.

Together, Visma and Aikido are not just participating in the future of application security; they are creating it.

Software Composition Analysis (SCA) and an all-in-one approach

Why did Visma zero in on Aikido Security? Why go with a startup that is just over a year old? It's all about Aikido's powerhouse Software Composition Analysis (SCA) – the ultimate tool for dependency scanning. Visma's companies will be able to continuously monitor their code, find the vulnerabilities that matter, and fix them in a heartbeat.

But that's just the start. Visma isn't just cherry-picking features; they're thrilled with Aikido’s all-in-one approach that gives Visma and its network a complete security arsenal. Aikido’s 10-in-1 package is an industry game-changer, and Visma sees this clearly. That’s a 10-in-1 security package giving Visma’s security warriors the proactive and reactive tools to win. Besides the SCA tool, another highlight is Aikido’s SAST solution, which brings together best in class open-source solutions for Ruby, Python, Golang and PHP.

Noise reduction

Visma wasn't messing around – they wanted a security platform that's top-notch quality, yet simple to use. Enter Aikido, laser-focused on eliminating false positives. Aikido’s practical approach to security lets Visma’s companies zero in on real threats, without the distractions from white noise.

Nicolai Brogaard, Visma’s Service Owner of SAST & SCA, drives the point home: “Trying to reduce the noise that [other] tools actually generate – diving into the signal-to-noise ratio – is a nightmare.”

Aikido cuts through the chaos. No false positives, no noise. Visma wants results. Aikido provides them.

European businesses unite

Visma and Aikido aren't just European by location – they're European by attitude and approach! Cybersecurity tends to be a sea of non-European companies, so Visma is elated to find a Europe-based security provider with a shared vision.

Aikido closely monitors European Cybersecurity & Privacy Legislation such as GDPR, NIS2, CRA, DORA, etc. Through Aikido’s reporting feature, tracking your company’s technical security compliance becomes dead simple.

Want to see an example? Get your NIS2 report right on Aikido.

Rolling out Aikido

Visma's network is colossal and constantly growing, so they demand software that not only strengthens their security posture but comes hassle-free. In practical terms, Visma values onboarding simplicity, and Aikido delivers just that: fast, easy, and effective onboarding across Visma’s entire network.

The proof is in the pudding. According to Brogaard, “Since we launched Aikido internally with sign-up automation on the 19th of February, 55% of Visma’s portfolio has already started using Aikido.”

Aikido’s API meshes seamlessly with Visma’s inventory management juggernaut. So, with a few fiery clicks, Visma’s network can start using Aikido with lightning speed and no setup headaches.

Visma’s High Security Standards

Visma has an advanced security program, empowering companies in the group to manage their own security by providing specialised tools, capabilities and training. One of the tools they use is their “Visma Index”. A gamified security maturity index, custom-developed and crafted by Visma to score their companies on the adoption of security measures & tools. Aikido plugs directly into the “Visma Security Maturity Index” and makes it easy to monitor their security stance.

Aikido pulls it all together for Visma in its dedicated “Group Admin Portal”, which is basically a master control center for Visma’s extensive network. The portal gives Visma a crystal-clear view of the security stance across all 170+ companies, along with unprecedented insight into its collective security posture.

Visma’s security budgeting pain point

Brogaard points out, “Security tools cost way too much.”

Most similar platforms have a developer-focused pricing model, creating unpredictable costs and making budgeting an unnecessarily challenging and persistent headache. Consequently, for Visma, the pricing model becomes a high-priority security pain point. Considering Visma’s size and continual network expansion, ballooning costs and the unpredictability around budgeting become unsustainable.

Aikido Security solves Visma’s previous problematic pricing model pain with its unlimited users enterprise plan – a flat rate that is known upfront. No unknown costs = a huge advantage for budgeting.

About Visma

Visma is a leading provider of mission-critical cloud software, with revenue of € 2.06 billion in 2022, 15,000 employees, and 1.7 million customers across Europe and Latin America. By simplifying and automating the work of businesses and organizations of all sizes, Visma enables a more efficient and prosperous society. Visit Visma at visma.com.

About Aikido Security

Aikido Security is a developer-first software security platform. We scan your source code & cloud to show you which vulnerabilities are actually important to solve. Triaging is sped up by massively reducing false positives and making CVEs human-readable. Aikido makes it simple to strengthen your security posture to keep your product secure. And, it gives you back time to do what you do best: writing code.