Welcome to our blog.

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?

Application security holds significant importance as cyber threats grow more sophisticated. Developers must protect applications from vulnerabilities and attacks that threaten sensitive data and disrupt business operations.

Traditional security measures often lag behind evolving threats. These measures may fail to protect against zero-day exploits or complex attack vectors targeting application runtime environments.

Runtime Application Self-Protection (RASP) tools address these challenges. RASP tools proactively secure applications by monitoring behavior and blocking attacks in real-time, without major code changes or performance impact.

Understanding RASP (Runtime Application Self-Protection)

RASP technology protects applications by continuously monitoring behavior during runtime. Unlike traditional perimeter-based security solutions, RASP tools integrate directly with the application runtime environment, offering a defense layer from within.

By embedding security controls into the application, RASP detects and prevents various vulnerabilities and threats in real-time. This includes common attacks like SQL injection, cross-site scripting (XSS), and remote code execution, as well as sophisticated exploits that bypass other security measures.

RASP stands out for providing continuous attack protection without significant application code changes. RASP tools automatically identify and block malicious requests or behaviors based on predefined security policies and machine learning. This allows developers to focus on building features while RASP handles security seamlessly.

Why Developers Need RASP Tools in 2025

The cybersecurity landscape in 2025 presents unique challenges. As threats evolve rapidly, traditional security measures often lack the agility to address emerging vulnerabilities. This gap calls for dynamic solutions capable of offering real-time protection. RASP tools embed security controls directly within applications, allowing immediate detection and interception of malicious actions.

These tools play a vital role in safeguarding applications through active threat monitoring during runtime. By analyzing application behavior and identifying potential threats, RASP tools strengthen security frameworks and help developers meet compliance mandates. In sectors with strict data protection regulations, RASP tools are crucial for mitigating risks associated with data breaches and unauthorized access.

Incorporating RASP tools into the development lifecycle enables developers to innovate without compromising security. These tools integrate smoothly with existing development environments, ensuring security enhancements do not disrupt workflow. As a result, development teams can focus on creating advanced applications, confident that security needs are managed and maintained.

Top RASP Tools for 2025

1. Aikido Security Platform

Aikido's RASP solution - Zen - uses advanced AI technology to enhance application defense, instantly identifying and mitigating threats to ensure robust security. This tool provides deep visibility into potential vulnerabilities and attack vectors, enabling developers to strengthen security measures effectively. Integration with popular development environments is smooth, allowing developers to bolster security features without interrupting their development process.

2. Contrast Protect

Contrast Protect is a versatile RASP solution supporting a broad range of programming languages and frameworks. It uses sophisticated machine learning techniques to detect emerging threats and adjust defenses, reducing false alerts. The platform offers comprehensive analytics and reporting, equipping developers with the information to address vulnerabilities swiftly and improve application fortification.

3. Imperva RASP

Imperva RASP operates on a cloud-based infrastructure, delivering extensive protection against various vulnerabilities, including those identified by OWASP. It efficiently detects and blocks harmful traffic in real-time, ensuring applications remain protected without sacrificing performance. This tool integrates effortlessly with existing security setups, simplifying the process of enhancing application defenses against sophisticated cyber threats.

Choosing the Right RASP Tool for Your Application

Selecting the ideal RASP tool involves understanding the technical and operational needs of your development environment. First, assess the programming languages and frameworks your application uses. Different RASP tools offer varying compatibility levels, and choosing one that aligns with your tech stack streamlines integration and ensures efficient operation. Opt for a RASP solution that supports your most commonly used languages and frameworks, ensuring comprehensive application protection.

Consider how the RASP tool enhances development workflows without adding complexity. The tool should fit naturally into existing processes, complementing team methodologies. An effective RASP tool automates key security tasks and integrates with CI/CD systems, enhancing efficiency and maintaining development momentum.

The level of protection a RASP tool offers against common vulnerabilities and attack vectors is crucial. Examine the tool's ability to handle threats like buffer overflow, privilege escalation, and sophisticated exploits. Tools with advanced analytics and adaptive learning provide comprehensive defense, adjusting to new threats with precision. Additionally, consider the tool's ability to deliver detailed insights and reports that inform ongoing improvements.

Ease of deployment and management should not be overlooked. A straightforward RASP tool reduces the learning curve for development teams and minimizes operational burdens. Evaluate vendor support offerings, including documentation, customer service, and community resources. Strong vendor support is crucial, especially when navigating complex security challenges or during integration phases.

Best Practices for Implementing RASP in Your Development Process

When integrating RASP into your security strategy, embed it within your application's architecture to enhance protection. Integrating RASP at the core ensures continuous monitoring and immediate threat detection. This proactive approach allows for adaptive security measures that evolve alongside your application, providing robust defense without delaying development.

To strengthen security, implement RASP alongside real-time threat intelligence services. This combination enriches your security framework, offering insights into emerging threats and enabling preemptive actions. Real-time intelligence complements RASP by providing external perspectives on potential vulnerabilities, ensuring a comprehensive security approach.

Regularly update your RASP configuration to maintain effectiveness. Conduct thorough audits of settings and performance metrics to refine operations and address gaps. By keeping your RASP tool up-to-date with the latest threat data and security protocols, you can effectively intercept threats and maintain high application security standards.

Finally, cultivate a security-focused environment. Equip your team with the knowledge to use RASP effectively, emphasizing its role in the broader security landscape. Encourage continuous learning and adaptation to new security trends, ensuring your team remains informed and prepared for evolving cybersecurity challenges.

By adopting RASP tools and integrating them into your development process, you strengthen applications against evolving threats. As you tackle application security challenges in 2025, remember that proactive measures and continuous adaptation are vital to staying ahead of potential vulnerabilities. If you're ready to enhance your application security, start for free with Aikido - we're committed to simplifying your security journey and empowering you to build confidently.

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.

Most security tools waste developers’ time. We’re on a mission to fix this.

Application Developers aren't paid to care about security. Their performance is measured by the speed at which they can add value to the business through new features or enhancements.

This makes traditional security tools a hindrance as they're not built for developers — plus, they're not designed to be helpful. Their job is simply to show a massive list of security alerts, leaving it to the developer to figure out the rest.

At Aikido, our mission is to make securing applications as quick and painless as possible, and one of the most important ways we do this is by reducing the noise and false positives that waste developers' time and cause delays in shipping security fixes.

This post will show you what Aikido does to offer a cure for Developers suffering from Alert Fatigue Syndrome.

Reducing the Noise

In his famous song, "The Gambler," Kenny Rogers captured it pretty well:

“the secret to survivin', Is knowin' what to throw away and knowin’ what to keep.”

The most significant impact you can have on the signal-to-noise ratio is only showing developers the CVEs and security alerts they should take action on and ignoring the rest.

Here’s how Aikido intelligently ignores irrelevant security alerts and CVEs:

Development-Only Dependencies

By default, Aikido will not report vulnerabilities for dependencies marked only for installation in development environments, as they should not be present in staging or production environments.

Invalid CVEs or CVEs Without a Fix

Showing a CVE without a fix is just a distraction. Hence, Aikido temporarily moves these to a list of ignored issues until a fix becomes available before surfacing in the dashboard.

Unreachable Code

Aikido's code intelligence and reachability engine will ignore a CVE if a vulnerable function is not called in the code base.

This decreases the noise, especially for large libraries with many dependencies, such as TensorFlow.

Expired or Revoked Secrets

Aikido will ignore secrets that have been verified as expired or revoked, or appear to be variables. Aikido safely verifies the validity of known secret types by sending a request to an API endpoint requiring authorization that doesn't produce sensitive data.

Manual Ignore Rules

You can configure Aikido to ignore vulnerabilities under certain conditions, e.g. ignore reporting for specific paths in a repository.

Deduplication

Because most companies piece together their security infrastructure from several different sources, it's common for multiple systems to surface the same alert or CVE — plus, it’s common for traditional tools to surface the same CVE multiple times within a single repository. Talk about noise!

Because Aikido is an all-in-one platform offering you a single pane of glass across all security issues, you'll only see a single CVE alert for each repository with sub-issues listing the location of each vulnerability.

Boosting the Signal with Contextual Sensitivity Tuning

A security issue discovered in a repository handling sensitive data should be scored differently from an internal-only repository that doesn’t persist data at all.

Aikido provides various contextual indicators for every repository, helping uncover more security risks and appropriately weighting an issue's final severity score.

For example, by adding a domain name, Aikido can perform targeted scans for issues such as SSL vulnerabilities, cookie misconfigurations, if a CSP has been applied, and cross-site scripting (XSS) attacks.

Additional contextual examples include whether the application has internet access and which environments the application is deployed in.

Boosting the Signal for Exploitation Risk

Aikido uses real-time indicators to track the probability of a CVE being exploited in the wild, such as confirmed cases of exploitation, public code documenting how to perform the exploit, and any customer-specific cloud infrastructure concerns which may make them particularly vulnerable.

And because Aikido monitors both your code and cloud infrastructure, it can boost the severity of "toxic combination" issues arising from specific conditions under which your application is hosted, e.g. AWS instances using IMDS API version 1 are more vulnerable to SSRF exploits which can expose AWS Credentials.

Summary

Traditional security tools don't care about developer productivity. They're more than happy to bury a repository in a pile of false positives, wasting developers time that could've been better spent actually resolving security issues.

What makes Aikido different, is that we see the link between developer productivity and security. By removing irrelevant alerts and CVEs, genuine threats get more attention, and as a result, fixes get applied faster.

This win-win for developers and security is what we're all about and is how we're curing Security Alert Fatigue Syndrome for our customers.

Want to see it in action? Sign up to scan your first repos & get your first results in less than 2 minutes.

This is a question we get a lot from our customers. The NIS2 Directive’s wording is not always very explicit. NIS2 is a framework that countries need to implement. Because it’s a Directive and not a Regulation, each EU country has the autonomy to roll it out under their own interpretation.

NIS2’s language is broad, making it challenging to get your head around, especially until countries publish their specifics. But, we will answer as clearly as possible which companies NIS2 currently affects.

Aikido’s quick NIS2 self-check to see if you’re in scope

We like things to be practical and straightforward. So, to help make it easier, here’s our quick 5-step self-check to see if you’re in NIS2 scope:

1. Is your company working in an ‘essential’ or ‘important’ industry?
2. Check if you’re part of a sub-industry.
3. Do you fall within the size requirements?
4. If ‘no’ to 1, 2, and 3, double-check that you’re not an exception (pro tip: you may need to seek legal counsel to be on the safe side).
5. And, if ‘no’ to all of the above, check if your customers are or are not in scope.

Who does NIS2 apply to?

There are two key parameters to check to see if NIS2 impacts your company:

• Industry: If you’re part of an industry that is ‘essential’ or ‘important’.
• Size: If the size of your company meets certain ‘essential’ or ‘important’ thresholds, i.e. above X # of employees, €X revenue, or €X balance sheet.

Let’s look at both in more depth.

Which sectors does NIS2 apply to?

It all starts here. NIS2 is all about getting essential and important industries to be secure. NIS2 expands the number of industries that were the focus of the first NIS Directive. It differentiates between essential and important, but both categories are included in its scope.

Essential industries: energy, drinking water, wastewater, transportation, banking, financial markets, ICT service management, public administration, healthcare, and space.

Important industries: postal and courier services, waste management, chemicals, food, manufacturing (e.g. medical devices, computers/electronics, machinery/equipment, motor vehicles, trailers/semi-trailers/other transport equipment), digital providers (e.g. online marketplaces), and research organizations.

Some sectors are instantly in scope, no matter what. Some examples include domain name registrars, trust service providers, DNS service providers, TLD name registries, and telecom providers.

Beyond that, national authorities will have the power to designate individual companies that do not fall neatly into the essential or important sector categories. They can do this if they deem the company to provide a sole service, have a significant impact, and/or be essential to society.

NIS2 company size criteria

NIS2 has size cap rules. This means you’ll need to comply with the Directive if you cross certain thresholds.

What are essential and important companies for the size criteria?

• Essential companies: 250+ employees OR €50m+ annual turnover OR €43m+ balance sheet
  Note: An essential company that does not meet the essential size thresholds (above) but still meets the important companies size thresholds (below) is considered an important company. And, therefore still in scope.
• Important companies: 50+ employees OR €10m+ annual turnover OR €10m+ balance sheet

So, on the surface, NIS2 applies to medium enterprises and large corporations. And, leaves out small and micro enterprises. But, there will be exceptions. For example, if a company doesn’t meet the size thresholds, a national authority can exert its designation prerogative as with the sector criteria.

How do I know which country has jurisdiction over my business?

The European Commission says: ‘As a rule, essential and important entities are deemed to be under the jurisdiction of the Member State where they are established. If the entity is established in more than one Member State, it should fall under the jurisdiction of each of these Member States.’

There are exceptions. In some cases, that means considering where the company provides the service (e.g. DNS service providers). In other cases, the key is where their main establishment is (e.g. cloud computing service providers).

Are there other exceptions to the rules?

Of course, there are some related to the industry and size rules. On top of that, as countries implement the directive, there will be country-to-country differences to pay attention to as the localized rules come into effect (all by October 17, 2024).

For example, if you don’t meet the size requirements BUT are the sole provider of a critical service for societal or economic activity in a member state, you may still need to implement NIS2.

Note: If you’re active in the finance industry, you’re probably already familiar with the Digital Operational Resilience Act (DORA). DORA is a piece of legislation – not a directive like NIS2 – so it takes precedence over NIS2. We recommend focusing your efforts there first but make sure you check in when NIS2 is transposed into local law by your EU member state.

Don’t forget about the Cyber Resilience Act (CRA) as well. CRA sets out cybersecurity requirements for a range of hardware and software products placed on the EU market. These include smart speakers, games, operating systems, etc.

Are you looking for a bit more detail?

Here’s a great overview of who’s in scope, developed by the Centre for Cyber Security Belgium:

If your customers are in-scope, NIS2 will likely impact you

Did you know that NIS2 includes the third-party knock-on effect? That means even if you’re not directly in scope but your customers are, you will likely need to comply with NIS2.

Companies that must implement NIS2 will need to ‘manage and assess the risks’ associated with their ‘third-party providers’. This includes, for example, conducting regular security assessments, ensuring that you have adequate cybersecurity measures in place, and implementing contracts/agreements that require you to comply with NIS2 requirements.

So, if you’re a B2B company and you thought you were out of scope because of sector and size, but your customers are in NIS2’s scope, you should start preparing!

Aikido provides NIS2 report

Aikido Security has created a NIS2 report feature available in our app. We’ve designed this report to help companies who need to comply with the directive.

Are you likely affected by NIS2?
Find out where you stand with your application on NIS2.
Although our report is not exhaustive (and only covers your technical setup) , it’ll get you on started and on the right track.

Register for Aikido and get your NIS2 report for free!