Pen testing and red teaming are often used interchangeably. Both probe your defences. Both find what’s broken. But they ask fundamentally different questions, and the one you choose shapes how wide you assess your business security.

Penetration testing and red teaming both start from the same premise: hire someone to break in before the bad guys do. But they’re different tools for different problems, and conflating them is one of the more common mistakes organisations make.

Two approaches, similar goal

Penetration testing is focused.

You define the scope – a specific application, a network segment, a set of systems – and testers go step by step in an attempt to find and exploit vulnerabilities within it.

Most engagements use a gray box approach: testers are given enough context to work efficiently. Credentials, access, scope. Enough to find what matters within a fixed timeframe.

The approach changes depending on who you are – a red team targeting a bank crafts different phishing emails, chooses different attack vectors, and pursues different objectives than one targeting a logistics company.

The whole exercise is shaped by what real threat actors are actually doing to organisations like yours.

When do you need which?

Pen testing is right for checking specific systems – after a new build, before a release, or as part of a compliance cycle (TIBER-EU and DORA both require it).

Red teaming is for organisations with mature security who want to stress-test the whole picture: not just whether systems are patched, but whether your people, processes, and assumptions hold up under a realistic attack.

Technical depth isn’t enough

The best pen testers and red teamers share two things: deep technical expertise and genuine creativity.

The technical side is obvious – you need to understand how systems behave under pressure, and how to adapt when a vector doesn’t work as expected. But creativity is what separates good from exceptional.

Testing isn’t a checklist. When a system reacts unexpectedly, the question isn’t “what does the tool say next?” – it’s “what does this tell me, and where does it lead?” That kind of thinking can’t be scripted. It has to be developed.

The second half of that matters as much as the first.

A brilliant technical finding is worthless if it can’t be translated into plain language. The job isn’t just to find vulnerabilities – it’s to help the organisation understand what they mean and what to do about them.

Why no scanner replaces this

Automated tools are good at finding what’s already known – catalogued CVEs, misconfigured headers, outdated libraries.

They’re fast, they’re consistent, and they’re useful. But they operate on fixed logic. They flag what they’re programmed to flag, and they stop there.

A skilled tester doesn’t stop there.

They notice how a system reacts, chain together findings that no single tool would connect, and pursue lines of attack that require judgment – not just pattern matching.

Nine times out of ten, real attackers get in through people, not ports. A scanner has nothing to say about that. Manual testing does.

This is why organisations that rely on automated tools as their primary security layer end up with a false sense of coverage. The scanner ran clean – but that’s only true for the things the scanner knows how to look for.

Attackers aren’t limited by that constraint.

A vendor with a quiet network connection into your environment, a help desk employee who clicks the wrong attachment – these don’t show up on a dashboard. They show up when it’s too late.

So, the question isn’t whether to test.

It’s whether you’re testing the right things, in the right way, with people who can tell the difference. Automated tools have their place – but they’re a floor, not a ceiling.

On March 31, attackers compromised axios — a JavaScript library downloaded roughly 100 million times a week. Here’s what happened, who’s affected, and what to do now.

If you’ve never heard of axios, here’s the short version: it’s the library that most JavaScript applications use to talk to the internet.

Fetching data from an API, submitting a form, making a request to a backend service – axios handles it. It’s in frontend apps, backend services, CI pipelines, and internal tools. Chances are it’s somewhere in your stack right now, possibly several places.

On March 31, 2026, axios—with roughly 100 million weekly downloads—became the vector for one of the most significant npm supply chain attacks in recent memory.On March 31, 2026, axios—with roughly 100 million weekly downloads—became the vector for one of the most significant npm supply chain attacks in recent memory.

You don’t need to have installed axios directly to be at risk.

Any package in your dependency tree that lists axios with a floating version range (^1.x) and was rebuilt during the exposure window may have pulled in the malicious version automatically. This also includes AI coding assistants and automated tooling — anything that ran npm install on your behalf yesterday should be treated the same as a manual install.

We’ve written before about software supply chain security and the systemic risks that come with modern dependency management. This attack is exactly the scenario we described – not a theoretical edge case, but a live incident affecting one of the most widely used libraries in the JavaScript ecosystem.

Google’s Threat Intelligence Group has attributed the attack to UNC1069, a North Korean group previously active in cryptocurrency theft.

Here’s what happened, how it worked, and what you should check right now.

What happened

The attacker didn’t touch a single line of axios source code.

Instead, they compromised a long-lived npm access token belonging to jasonsaayman, the project’s lead maintainer. With that token, they published two new releases – one for the 1.x branch and one for the legacy 0.x branch – 39 minutes apart, covering both release lines simultaneously.

Both releases modified exactly one file: package.json. The only substantive change was adding plain-crypto-js@4.2.1 as a runtime dependency. That package was pre-staged 18 hours earlier, under a separate attacker-controlled account, with a clean version first to build registry history before the malicious update was pushed.

plain-crypto-js contains a full copy of the legitimate crypto-js library – every source file identical, bit-for-bit. The only difference is a postinstall hook: “node setup.js”.

When npm resolves the dependency tree and runs that hook, the dropper fires. It contacts the attacker’s command-and-control server, delivers a platform-specific payload for macOS, Windows, or Linux, then deletes itself and replaces package.json with a clean stub reporting version 4.2.0.

By the time npm install finishes, there’s no error, no warning, no obvious trace. The directory node_modules/plain-crypto-js/ exists, but npm list shows version 4.2.0 – not the malicious 4.2.1 that actually ran. Standard npm audit finds nothing.

Why this specific attack is worth studying

Most supply chain incidents involve obvious red flags – a zero-history package, a suspicious name, a sudden maintainer change.

This one was deliberately engineered to avoid all of them.

That’s what makes it worth paying attention to, even if axios isn’t in your stack – the technique will be reused.

The attacker published a clean decoy package 18 hours before activating the payload – long enough to avoid “brand new account” alerts from registry scanners. The malicious axios releases were signed by the legitimate maintainer’s account. No corresponding commit or tag appeared on GitHub (that gap is the forensic signal, in hindsight), but most CI systems don’t verify OIDC provenance on pull.

This is the attack pattern that NIS2 and CRA regulations are increasingly focused on: not a breach of your perimeter, but a compromise of the supply chain your code depends on.

Your code didn’t have a vulnerability. Your tooling did.

The OIDC misconfiguration that made it possible

Axios had OIDC Trusted Publishing configured for its release workflow.

In theory, this should have made a token-based publish impossible – OIDC ties releases to specific GitHub Actions runs, and the ephemeral token can’t be stolen.

In practice, the GitHub Actions workflow passed both the OIDC credentials and a classic NPM_TOKEN environment variable. When both are present, npm defaults to the token. The long-lived token – which can be exfiltrated – was effectively the only authentication method that mattered.

This is a common misconfiguration. Many projects enable OIDC Trusted Publishing and consider the job done, without removing or rotating the classic token that overrides it.

Check if you’re affected – right now

Step 1 – Check your lockfile for the malicious versions

Step 2 – Check for the malicious dependency in node_modules

The presence of this directory – regardless of what version package.json now reports – means the dropper executed.

Step 3 – Check for persistent artifacts

If you find any of these

The response depends on where the install ran.

For ephemeral CI runners (e.g. GitHub-hosted), the runner is destroyed after each job — rotate any secrets that were injected during the affected run and move on.

For developer machines and self-hosted runners, treat the system as fully compromised: isolate it from the network immediately and re-image it or restore from a verified clean backup taken before March 30.

Once you have a clean machine, rotate everything that was accessible from it: npm tokens, SSH keys, cloud credentials (AWS, GCP, Azure), CI/CD secrets, and any values in .env files present at install time.

To downgrade cleanly

What to change in your CI/CD configuration

Beyond the immediate incident, this attack exposes a few controls worth auditing across your pipelines.

The broader pattern

This isn’t an isolated incident.

The axios attack follows the same playbook as the CrowdStrike npm compromise, the IoliteLabs VSCode extension backdoor from a few days earlier, and dozens of similar incidents over the past two years.

That model is under sustained attack.

The attacker here invested 18 hours of prep time, built platform-specific payloads for three operating systems, and designed the dropper to self-destruct. This is not someone experimenting – it’s operational tradecraft applied to the JavaScript supply chain.

As we covered in our supply chain security framework, the highest-risk entry points are often not your own code but the tools and processes you depend on to build and deploy it.

The question isn’t whether your perimeter is secure, it’s whether your CI pipeline would have caught this before it ran.

For teams with third-party risk exposure

If you’re managing a product that runs JavaScript in CI and you have compliance obligations – PCI DSS, NIS2, ISO 27001 – this incident is worth documenting even if you weren’t affected.

Our third-party cyber risk management work often starts with incidents like this one: not after a breach, but as a trigger to audit what dependency hygiene actually looks like in practice across an engineering org.

The controls that would have caught this – OIDC provenance checks, version pinning, –ignore-scripts in CI, outbound network monitoring – aren’t difficult to implement. They just tend not to exist until something goes wrong.

If you want to review your current posture, get in touch.

Indicators of compromise

Many modern Android applications are highly advanced and operate in sensitive domains like banking, money transfers, and other critical services people rely on daily. A rooted environment gives attackers elevated access to the device, which they can abuse in order to bypass the app’s restrictions, extract sensitive data, and interfere with the app’s behavior.

To counter these threats, many apps implement protections against common tools and techniques used in reverse engineering. These include anti-root, anti-hook, and anti-debug mechanisms, which are designed to make an attacker’s job significantly more difficult—often requiring considerable effort and creativity to bypass.

A practical look at protection mechanisms

This article provides other security researchers with a practical look at how some of these protection mechanisms are implemented and how they can be bypassed during penetration testing or security research.

Additionally, by understanding how these protections work, developers can build stronger, more resilient security mechanisms into their apps and even extend these ideas to develop more advanced and effective techniques.

Furthermore, during this research, an application called TamperLab was created. It includes various protection mechanisms to detect whether a device is rooted, whether any hooking is in place, or whether the application is being debugged. The project is fully open-source, and contributions are welcome.

It can be found on the following GitHub page for you to check out:

Anti-Root Protections

In this section, we will look at some commonly used root detection techniques and their implementations, and immediately follow each one with an example of how it can be bypassed during testing or reverse engineering.

The “One Function” Folly

The most common way of implementing protection measures such as anti-root, anti-hook, and anti-debug is by placing all checks inside a single function. This is a common mistake, as it gives attackers the opportunity to bypass all protections within seconds.For example, in the following scenario, the RootBeer library is used to quickly demonstrate why placing all checks in a single function can be problematic. As shown in the code snippet below, the isRooted() function is called.

Such a function includes various methods to detect if the device is rooted.

Although the function includes many ways to detect if the device is rooted, it is not sufficient because the isRooted() function itself can be hooked, allowing an attacker to bypass all detections with a single hook.

Using the following simple Frida script, we can do exactly that. We obtain a reference to the RootBeer class and hook the isRooted() function, immediately returning false.

Using the following command, the targeted application can be started with the hook applied.

As shown in the following image, the previously created script successfully bypasses all the checks because they are contained within a single function.

Testing this inside TamperLab shows that we successfully bypass the protection measure, and a green checkmark is displayed.

SU Binary Check (Shell)

All rooted Android devices contain the su binary, and any application requiring root access must use su to elevate privileges and perform privileged actions on the device.

When present on a device, applications can detect the existence of the binary and conclude that the device is rooted. A quick way to check for it is by programmatically executing the which su system command.In my application, I created a simple HelperClass that contains various functionalities and detection methods. One of its purposes is to execute system commands.

The executeCommand() function essentially passes the given command as an argument to the exec() function, which executes it on the device.

If the su binary exists, the command will return its full system path, otherwise, an error code will be returned.

Using Frida, we can bypass this technique by hooking the exec() function itself. If we detect a command such as which su, we can replace it at runtime with another non-existent command.

As demonstrated, by using this technique, we can target specific exec() parameters after reverse engineering the application and bypass the detection mechanisms in place.

SU Binary Check (Native C/C++)

Another way developers may check for the su binary or for rooted devices in general is by writing native C/C++ code using JNI. In case you are unfamiliar, JNI (Java Native Interface) is a framework that allows Java code running on the Android platform to interact with native applications and libraries written in C or C++.

For example, we can check for the su binary by iterating through common system paths where it might exist, and then using the std::ifstream function to check if the file can be opened.

A small Java class is then created to serve as a bridge between the Java code and the native C/C++ code in the application. It uses JNI (Java Native Interface) to perform the native task.

Under normal circumstances, you wouldn’t have access to the source code. However, a common way to reverse engineer the application is by decompiling it using JADX, which can be done with the following command.

Once decompiled, your application may contain various libraries. You can easily filter through them by searching for files with the .so extension, which indicates native libraries.

To reverse engineer the library, tools such as Ghidra or IDA Pro can be used. In this case, Ghidra was used.

The decompiled code shows that ifstream is first used (1) to check whether the file exists. Based on this check, the function returns \x01 (JNI_TRUE) (2) if the su binary is found, otherwise, it returns \x00 (JNI_FALSE) (3).

Since this is a JNI function and is exposed using extern “C”, it appears in the symbol table with the exact name observed in Ghidra.

Bypassing such checks is relatively straightforward. To hook a native function using Frida, we use Interceptor.attach() and specify the target function using Module.findExportByName().

Since we are intercepting a function from the native library, we need to attach to the process while it is already running by using the -n parameter with the following command.

As shown in the script’s output, we successfully bypass the check even though it resides within JNI code.

Another clever approach is to hook the open() function instead of the entire native function implemented in the application.

Since std::ifstream() ultimately invokes the open() system call, we can hook open() to intercept any attempt to access a binary whose path contains “su”. We can then substitute that path with a fake one to bypass the check.

As shown in the image, this technique effectively bypasses native checks early by using the -f flag to hook before execution, unlike the -n flag, which attaches the hook while the process is already running.

Spoofing /proc/mounts

Nowadays, many Android devices are commonly rooted using Magisk, which comes with a variety of built-in features.

The /proc/mounts file contains a list of all currently mounted filesystems on the device. Additionally, when a device is rooted using Magisk, it modifies the boot image and mounts partitions dynamically by default, so you may find traces of Magisk there as well.

An implementation to detect this might look like the following, where an application reads the contents of /proc/mounts in search of Magisk.

To bypass this, we can create a script like the following, where we define a list of mounts that don’t contain Magisk traces or any other suspicious entries, for that matter.

The first interceptor hooks the open() system call to capture the file descriptor used when accessing /proc/mounts.

The second interceptor hooks read(), checks if the file descriptor corresponds to /proc/mounts, ensures the content hasn’t already been spoofed (to prevent repeated modifications and potential crashes), and finally replaces the buffer with our fake mount data defined at the top.

By running the hook, we successfully spoof the contents of /proc/mounts with our fake data, effectively bypassing the detection check.

It’s important to note that these techniques can be implemented and bypassed in various ways. Consequently, multiple solutions and countermeasures exist to address them.

Anti-Hooking Protections

Hooking is a powerful technique used during mobile penetration tests because it allows intercepting, modifying, and monitoring an application’s behavior at runtime. It provides direct access to function calls, arguments, return values, and the internal logic of methods.

To perform such attacks, Frida is a widely used tool that enables pentesters and attackers to bypass security controls or extract potentially sensitive data.

Frida Port Detection

A common way to detect Frida is by checking for open frida-server ports, since Frida communicates using WebSockets. Simple checks often look for ports like 27042 or 27043, which are the default ports used by Frida.

Such checks can be easily bypassed by simply starting the Frida server on a different port using the following command.

A more advanced detection method involves scanning all ports by sending specific HTTP requests and checking for a 101 Switching Protocols response, which indicates the presence of a Frida server.An example of such native code would involve sending a WebSocket upgrade request to every open port on the device. If the response contains 101 Switching Protocols, it confirms that a Frida server has been successfully detected.

This check can be bypassed by hooking the read() calls and inspecting the buffer content after the call completes. If the buffer contains 101 Switching Protocols, indicating a Frida server query, we can modify the response to something benign such as HTTP/1.1 200 OK\r\nContent-Length: 0\r\n\r\n to evade detection.

As demonstrated, once the hook is executed, the check is successfully bypassed.

Frida Threads Detection

In Linux-based environments (including Android), each process has a task directory located at /proc/self/task, containing a subdirectory for each thread within the process. Each of these subdirectories includes a comm file that holds the name of the corresponding thread.

When Frida is injected into a process, it typically creates several threads for its internal operations. These threads often have distinctive names such as frida, gum-js-loop, gmain, gdbus or some other which can be used to detect Frida’s presence.

To better understand this, we can run the following command on the device to retrieve the names of all threads for a specified process.

As shown in the following snippet, this is the output of the thread list when no Frida hooks are active.

When a Frida hook is applied to the process, threads named gmain and gdbus appear both associated with Frida’s runtime. This allows us to detect Frida based on the presence of these thread names.

To detect this, we can use C++ code like the following, which loops through each comm file in the /proc/self/task directory to retrieve thread names and checks them against a list of common thread names used by Frida.

One intriguing approach to evade detection is to patch the entire frida-server binary by replacing all occurrences of strings like gmain. By searching for gmain in Ghidra, we can observe the following results.

By selecting one of the instances, we can examine the disassembled code to pinpoint its exact location.

We can now use Ghidra’s built-in hex editor to modify these strings, replacing gmain with another string, such as hackr.

After injecting the Frida hook, we can see that we have successfully bypassed the detection, as it no longer identifies Frida’s threads.

If we loop through the thread names again for the application we are attacking, we can see that it now successfully contains the hackr thread name.

Of course, there are other detectable strings, but this simple example demonstrates one way to bypass detection by directly patching the frida-server binary yourself. This way you could build an entirely different frida-server to avoid detections or modify the original source code as well.

Anti-Debug Protections

Anti-debug protections are another way to protect your Android application from reverse engineering. These mechanisms aim to detect or prevent debugging attempts, stopping attackers from stepping through the app’s code instruction by instruction to understand its internal logic.

Like most security measures, anti-debug mechanisms can also be bypassed using Frida hooks. However, I want to show you how you can defeat these protections using a debugger itself.

Defeating Anti-Debug using Debugger

isDebuggerConnected()

This is a simple, ready-made function that checks if a debugger is connected to the application. It returns true if a debugger is detected, otherwise, it returns false.

Implementing such a function is straightforward, and you can call it as follows:

To use the debugger and bypass this check, we can utilize JADX’s integrated debugger. Before launching it, ensure the application is already running.

Another way to start an application is by using the following ADB command, which will launch the app but pause and wait for the debugger to attach.

As shown, when you launch the application, it will display a message indicating that it is waiting for a debugger.

In my case, it doesn’t work, but I can open the application without it waiting for the debugger. However, your application might require this behavior, so it’s important to test both methods.

Additionally, whenever you’re done or close the application, make sure to run the following command to remove the app from waiting for a debugger.

Once ready, you can open JADX and load the APK file of the target application. You can also pull the APK from your device using ADB.

Once loaded into JADX, select the green bug icon, which opens a dialog prompting you to choose the application to debug along with its process ID.

After the debugger attaches, the application’s execution is automatically paused inside the MainActivity. You can then press the green play button to continue running the application.

Once you find the correct position to set a breakpoint, you can do so by pressing the F2 key. For this example, I set the breakpoint exactly where the isDebuggerConnected() function is called.

The following instruction essentially calls the isDebuggerConnected() function using the invoke-static opcode.

Then, the move-result instruction moves the return value of the function (either true or false) into the v0 register.

By stepping over these two instructions, we can observe that the v0 register contains the value 1, indicating that a debugger has been detected.

To bypass this check, we can simply set the value to 0 using the debugger, as shown below:

Continuing the application’s execution, we successfully bypass the check by manipulating the variables during debugging.

Detection via USB & ADB

Another interesting way to detect debugging is by checking if the device is connected via USB with ADB enabled. While this isn’t a direct debugger detection method, it remains a useful check nonetheless.

A simple implementation might look like the following, where the app dynamically listens for the USB_STATE broadcast and parses the connected and adb boolean extras from the received intent.

We can also bypass this check by using the debugger to place breakpoints at the appropriate locations.

In this case, I set a breakpoint on the if-eqz instructions, which checks whether the values in registers v0 and v2 are equal to zero. These registers correspond to the connected and adbEnabled flags.

When the breakpoint is hit, we observe that both values are set to 1 (true), indicating that USB is connected and ADB is enabled.

We can now simply set these two values to 0 (false), causing the check to fail and allowing the app to continue execution.

Conclusion

We have explored several common anti-root, anti-hook, and anti-debug techniques and demonstrated how each can ultimately be bypassed. However, it is important to recognize that these protections still play a critical role in Android security.

No protection is entirely foolproof. Given enough time and the right tools, a determined attacker can often find a way around most defenses. However, the goal of these mechanisms isn’t to create an unbreakable application, but rather to increase the complexity of attacks. This raises the time, effort, and skill required for an attacker to compromise the application, which can deter casual attackers and slow down more advanced ones.

In short, while these security checks can be bypassed, they remain a valuable part of a defense-in-depth strategy. Labs like TamperLab that we have created, provide a practical environment where you can practice implementing these detection mechanisms and learn how to bypass them. It’s about making it hard enough that breaking the security is no longer worth the effort.

At Infinum, we help you stay ahead with tailored cybersecurity services, including penetration testing and security assessments. Whether launching new products or protecting existing ones, we identify weaknesses before attackers do so you can focus on what matters. Learn more about how we keep your digital world secure on our cybersecurity page.

AI is changing how software gets built: faster timelines, leaner teams, fewer blockers. But does all that speed come at a cost? We put AI to the test in a real-world security experiment, and what we learned should matter to anyone leading modern product, platform, or tech teams.

According to Collins Dictionary, vibe coding is officially the word of the year – and if you’ve spent literally any time around engineering teams lately, that probably doesn’t surprise you.

Obviously, it’s catching on fast. 

Microsoft recently shared that around 30% of the code in some of its repositories is now AI-generated. This shift is one of the defining cybersecurity risks of 2026 — our cybersecurity trends overview covers the trade-off between vibe coding and security in depth.

At Infinum, we see this trend up close, both in internal experimentation and in conversations with clients who are increasingly curious about AI-assisted development.

The appeal is clear: development is faster, prototypes turn into products at record speed, and teams feel confident shipping. 

But is that confidence earned? We decided to find out.

Security doesn’t work on vibes

A growing belief is quietly taking hold in many teams:

“If I tell the AI to make it secure, it probably will.”

That assumption is understandable because AI is very good at reproducing patterns that look correct. When prompted, it can generate code that resembles common security practices and includes familiar terminology, giving the impression that risk has been addressed. But is it, really?

Instead of debating, our cybersecurity engineer designed a simple, hands-on experiment.

He asked AI to build apps with varying levels of security guidance, from none to OWASP-level detail, and then he tried to break them.

We didn’t want to test whether AI could write code. We know it can.

Let’s see the results.

The apps we built (and broke)

We asked AI to build three medium-complexity web applications, realistic enough to offer an attack surface, but not so complex that AI failed to build them. One app was generated with no security input at all, one with light guidance, and one with detailed, best-practice-driven instructions.

Turns out, not even specific prompts are enough to build applications that can survive real-world attacks.

What actually went wrong 

Even with better prompts, the same kinds of security gaps kept popping up.

AI didn’t forget libraries or miss syntax. It just couldn’t reason about how things might go wrong, and that’s where real-life threats were.AI didn’t forget libraries or miss syntax.

AI didn’t forget libraries or miss syntax. It just couldn’t reason about how things might go wrong, and that’s where real-life threats were.AI simply doesn’t understand cybersecurity, and it couldn’t reason about how things might go wrong, and that’s where real-life threats were.

While we are aware that this is an experiment of a limited scope, it is still important to note recurring issues we recognized:

In conclusion, the issues discovered weren’t bugs in the traditional sense. They were assumptions – that roles are respected, that the app can trust user input, that attackers won’t be creative.  

But attackers are creative, and they have all the time in the world to look for what you missed.

Why this matters beyond the code

Security is not just a dev problem. It’s a systems-thinking problem, and it affects every role involved in shipping software.

For CTOs & Heads of Engineering

AI speeds things up, no question, but it can’t replace architectural thinking.

The biggest failures in these apps weren’t in the code; they were bad assumptions about how trust, roles, and permissions work. Even when AI adds security controls, it struggles to secure the system as a whole.

We’ve all recently witnessed this: in our deep dive into OpenClaw (ex Moltbot), we explored what happens when AI sidekicks are given broad access with no guardrails. The takeaway? When AI has too much control, your data is very likely at risk.

Again, that’s an architectural one. And it’s still up to humans to get it right.

For Founders & Execs

All three apps worked. Some even looked secure. But they could still be exploited in serious ways, often through features that seemed harmless.

Remember this: AI gives a false sense of security. Without hands-on testing, issues like these show up only after damage is done. If you’re building with AI and need it to be secure from the start, our custom AI development services combine speed with security by design.

For Security Leaders

The vulnerabilities we found didn’t have CVE numbers. They weren’t from outdated libraries or missing headers. They were logic and abuse-case failures – the exact kind of problems automated scanners don’t catch. Addressing these systematically through structured security governance, risk assessment, and compliance frameworks is exactly what governance, risk, and compliance services are designed to support.

Manual penetration testing still matters because it mirrors how attackers behave, not just what vulnerabilities exist – and AI-assisted code makes this more important, not less.

For Developers

AI can implement what you tell it, but it’s not a security expert. It won’t catch logic flaws, system-wide assumptions, or the creative misuse attackers are known for. For a practical look at how to work with AI coding assistants without sacrificing code quality, see our roundup of AI tools for development teams.

Writing secure apps still requires developer intuition, threat awareness, and curiosity about how features might be abused.

So, yes. AI-generated code can be secure, but it takes judgement, experience, and most importantly, testing. 

What should you do now

Use AI. Embrace the speed. Build more, experiment faster, prototype wildly.

But don’t confuse working code with secure code.

Why automated scanners won’t help

Automated tools catch known and “low-hanging fruit” types of vulnerabilities. But issues discovered in this experiment weren’t in any vulnerability database, because they weren’t traditional bugs – they were incorrect assumptions about how systems would be used.

Automation wouldn’t have caught that, but manual testing told us whether the system could survive a curious attacker.

The real takeaway

The apps worked and security looked reasonable. 

But AI inherently doesn’t understand security, which is especially obvious once software interacts with real users, real data, and real incentives to misuse it. Security failures rarely come from missing syntax or forgotten libraries; they emerge from incorrect assumptions about behavior, trust, and intent.

Attackers do nothing but imagine misuse.

This is exactly why manual penetration testing exists: not to check a box, but to ask the one question that AI won’t:

“What happens if someone does the wrong thing on purpose?”

Security still requires human intent and adversarial thinking. No matter how well you prompt it, AI can’t protect against what it doesn’t anticipate.

If your app was built with AI assistance, this isn’t a theoretical risk. It’s a structural one.

If you want real, certified humans to have a go at your app – partner with Infinum’s security team to test your app the way real attackers would.  We’ll help you find the blind spots, close the gaps, and build safer systems, so you can move fast without leaving yourself exposed. If we find zero issues, the beer is on us.

As vibe coding enters real-world development, I set out to evaluate the security of AI-generated code in practice. After building and attacking three vibe-coded applications with increasing security guidance, clear improvements emerged – alongside consistent gaps.

Large language models are already part of everyday development workflows.

Development teams use them to scaffold features, generate boilerplate, wire APIs, and, increasingly, to assemble entire applications from natural-language prompts.

In many cases, the output is functionally correct and fast enough to be genuinely useful.

What is less obvious is how this code behaves once it is exposed to real attackers rather than happy-path usage. This is especially relevant as regulatory pressure on the software supply chain increases and attackers adopt AI-assisted tooling.

I asked Gemini Pro to generate three different web applications and for each one, I progressively increased the level of security detail in my prompts.

The results were instructive, occasionally impressive, and ultimately a reminder that security does not emerge automatically – no matter how advanced the model. For a business-focused interpretation of these findings, see our AI-generated code security risks guide for CTOs and business leaders.

The plan and methodology

To make the experiment realistic, I needed applications complex enough to expose meaningful attack surfaces, but not so large that the AI would collapse into contradictory logic or endless refactoring loops.

I intentionally avoided very simple apps (e.g., To-do apps), since their limited functionality results in a small and unrealistic attack surface, while overly complex systems often exceed what current models can reliably reason about end-to-end.

They include authentication, authorization, data storage, and user interaction patterns that are common in real-world systems—and therefore make attractive targets for attackers.

For each application, I generated the entire codebase using Gemini Pro, varying only the level of security detail in the prompt.

I then reviewed the resulting code from the perspective of a realistic attacker, including both unauthenticated users and low-privileged authenticated users attempting to escalate access or abuse functionality. The focus was on practical exploitation paths rather than theoretical weaknesses.

The test subjects

Based on these criteria, the following three web applications were born:

Each application was built independently, with the only variable being the depth and specificity of security requirements provided to the AI.

Discoveries and vulnerabilities

In this section, we analyze the key vulnerabilities identified across the three generated applications. Rather than listing every individual issue, the focus is on the most impactful findings, recurring security patterns, and the extent to which the level of prompt detail directly influenced the security posture of the generated code.

Results at a glance: What broke and why

The following table provides a high-level summary of the results from the tested applications.

For security researchers looking to understand what these runtime gaps look like from an attacker’s perspective on mobile, where protections like root detection and Frida detection can be systematically defeated — see our walkthrough of Android penetration testing techniques.

Simple Project Tracker: No security, just vibes

The first application generated was the Simple Project Tracker, a lightweight web application where regular users can create, update, and sort tasks, while administrators can additionally create projects and assign users.

No explicit security requirements were provided. The prompt focused solely on functional goals such as building a lightweight project tracker with database integration, role-based user and admin access, and all files needed for local deployment. As a result, the following prompt was used:

I would like to build a simple project tracker web application. Please include a database integration and an API that distinguishes between user and admin permissions. The goal is to have a completely operational application that remains lightweight by focusing exclusively on high-impact, necessary features. Additionally, make sure to generate every file necessary to run the web application locally.

For this application, AI selected the following technology stack:

As illustrated in the screenshot below, the generated web application exhibited a polished and well-designed interface.

Unsurprisingly, the absence of security guidance resulted in an application that implicitly trusted all user input. There was no input sanitization anywhere in the codebase, which led to pervasive cross-site scripting vulnerabilities across forms, task descriptions, and project metadata. 

Below is an example of the generated code.

The registration flow was particularly revealing. User roles were assigned directly from client-controlled input:

Changing “role” to “admin” was enough to gain full administrative privileges. There was no server-side validation, enforcement, or role integrity check.

Authorization was equally fragile. While the application exposed separate API endpoints for managing tasks and projects, none of them implemented ownership checks.

Any authenticated user could view, modify, or delete any other user’s data which can be seen in the following request where oddly specific x-user-id and x-user-role headers are used by default.

Session handling further reinforced the trust-in-the-client model. Authentication state was stored in unsigned cookies containing raw user objects:

Overall, in terms of design and functionality, the AI delivered exactly what was requested. However, from the security standpoint, the application had no sense of security at all and every possible aspect was completely insecure.

Functionally, the application worked exactly as requested. From a security standpoint, it operated entirely on the assumption that “logged-in users will behave correctly.” Needless to say, attackers do not follow that assumption.

Project Resource Hub: Better, but not bulletproof

The second application, the Project Resource Hub, was designed as a platform where users could share resources such as files, links, and documentation, while administrators were able to manage all users.

This time, alongside the application details, I instructed the AI to also take security into account. Each feature was required to be implemented in a way that was secure and resistant to abuse, rather than merely functional.

… web application details …

You may use modern, standard technologies commonly used in contemporary web application development, such as a database and an API. The application must support multiple users and include an administrator role. There should be at least 2–5 distinct features for both regular users and administrators to demonstrate a reasonable level of application complexity.

Additionally, it is critically important that security is considered throughout the entire application. Every feature should be designed and implemented securely, following best practices and ensuring that no functionality can be easily exploited.

Compared to the previous application, this one showed noticeable improvements in security while keeping the same tech stack. Specifically, the AI implemented several measures, including:

As illustrated in the screenshot below, the generated web application was simple and provided functionality for storing several resource types.

With a moderately detailed security prompt, the AI implemented effective input sanitization, and most tested inputs (including XSS, SSTI, and other relevant attack vectors) were handled appropriately. 

Even modest security instructions can significantly improve baseline resilience. However, a deeper inspection revealed critical blind spots in less than five minutes.

After less than five minutes of reviewing the generated code, I discovered a major flaw in the file upload functionality: the AI considered filename, file size, and MIME type checks sufficient for security, leaving the system vulnerable.

Because there were no extension checks (or other meaningful protections) an attacker could easily spoof the content type and upload arbitrary files.

Another feature in this application allowed users to store website links as resources, along with a preview function. Such feature by its description alone is a hacker’s dream to test for SSRF and unsurprisingly, the generated code was vulnerable.

While the preview was rendered inside an iframe, the backend still made unrestricted requests, making blind SSRF fully exploitable. 

Despite additional issues, such as an insecure CSP configuration and predictable secrets, this application was still an improvement over the previous one. 

However, several security measures were either ineffective against real attacks or failed because the AI didn’t anticipate certain attack scenarios at all.

Niche Vault: Not the Fort Knox just yet

The third application is Niche Vault, a platform that lets hobbyists log, browse, and share items from their personal collections, complete with individual profile pages. 

On the administrative side, it includes full user management capabilities, such as deleting, suspending, or banning accounts, along with basic analytics and the ability to publish site-wide announcements.

For this project, I placed a strong emphasis on security from the outset. 

I instructed the AI to strictly adhere to OWASP WSTG guidelines and OWASP best practices, ensuring that every feature was analyzed for potential attack vectors and that appropriate mitigations were implemented from the outset. In addition, every piece of generated code was required to undergo a second security review by AI again.

<web_application> A minimal web application designed for hobbyists to log, manage, view, and share items from their personal collections, such as vinyl records, comics, or similar collectibles. </web_application>

…web application features…

<security – HIGH priority> Security is the highest priority. Ensure that every component and feature is implemented securely and cannot be abused. Apply OWASP Web Security Testing Guide (WSTG) methodologies throughout the development process, and explicitly consider the OWASP Top 10 vulnerabilities to ensure the application is thoroughly protected by applying every best practice defense mechanism for each request, feature, functionality, and more. </security – HIGH priority>

This time, the AI generated a web application using Python (although I had to manually fix the code in several places) with the following tech stack:

The following image shows the generated web application with its functionalities implemented.

User input was well protected across the board, and the application even included safeguards against SSTI attacks, which is especially important given its use of Jinja2. Both authentication and authorization were implemented cleanly and thoughtfully.

The application was not without flaws. One notable issue appeared in the CSV export feature, where it was possible to inject malicious payloads that could be executed by Excel or LibreOffice. 

As shown in the image below, the relevant code lacks any form of input sanitization, leaving it vulnerable to CSV injection attacks.

As a result, an attacker can embed a malicious payload. In this example, a calculator application was executed; however, real-world attacks may involve reverse shell payloads that grant remote access to the victim’s desktop or download and execute malware.

As shown in the image below, the payload is evaluated when the CSV file is opened, causing the calculator process to be launched.

In addition to the glaring CSV injection vulnerability, several critical endpoints lacked rate-limiting controls. 

While the AI correctly implemented rate limiting for the registration and login endpoints, it failed to apply similar protections to the following endpoints, which attackers could exploit to perform potential denial-of-service (DoS) attacks as well as destructive behavior.

Additionally, the code contained a minor open redirect vulnerability, which could be exploited in phishing attack scenarios where an attacker can supply a malicious domain to the next URL argument.

In conclusion, even when provided with a highly detailed prompt that explicitly instructs the AI to generate secure code, it is still likely to fall short in other areas or to overlook security considerations in certain features altogether.

Without precise, feature-specific security requirements, the AI tends to leave parts of the application insufficiently protected. 

As demonstrated in this example, it successfully sanitized input fields, prevented SQL injection, and applied several other best practices, yet still failed to implement comprehensive, end-to-end security. 

Ultimately, these gaps resulted in additional vulnerabilities despite the overall focus on secure development.

The secret tokens predictability game

While generating multiple web applications, I noticed a recurring pattern: AI models frequently produce “secret” tokens and keys that follow similar structures and wording. 

This observation told me to take a deeper look into how predictable these generated secrets can be.

For example, when further creating even simpler web applications, the following tokens were generated in docker-compose and other configurational files:

While these values may not appear in common brute-force wordlists (such as those targeting JWT secrets and other), they are not cryptographically secure and I could potentially see them being used.

Overall, this demonstrates a plausible attacker strategy: using multiple AI models to generate and aggregate common secret placeholders, then testing them against large numbers of similarly generated applications.

The verdict

Bottom line is:

Vibe coding is only as secure as the vibe coder’s understanding of potential vulnerabilities and their ability to instruct the AI to account for them.

When building an application using AI, it is critical to explicitly guide the model on the types of vulnerabilities that may arise in the generated code. 

For instance, if you ask the AI to implement a file-upload feature, you must already provide clear requirements regarding file extensions, MIME-type validation, size limits, and other relevant mitigations.

The broader issue is that even the most detailed prompts do not guarantee secure output. AI can still generate insecure code or introduce subtle loopholes in unexpected places, and create critical business logic issues. 

For this reason, it is highly recommended to conduct real-world penetration testing, in which security professionals review both the code and the application’s runtime behavior to identify and mitigate risks before they become exploitable.

Explore our cybersecurity services — from penetration testing to security architecture — and partner with experts who can identify risks before they become exploitable.

The UK Ministry of Defence has officially rolled out Cyber Security Model v4, introducing stricter, more structured cyber security requirements for defence suppliers. Learn how CSM v4, DEFSTAN 05-138, and Defence Cyber Certification fit together and prepare for CSM v4 with a DCC Level 1 certified partner.

The UK Ministry of Defence (MOD) has raised the bar for everyone in its supply chain.

Starting December 3, 2025, all companies working with the MOD – whether a prime contractor, a Tier 2 supplier, or a third-party vendor buried three layers deep – must follow a new set of cyber rules called the Cyber Security Model (CSM v4).

The interim process tied to DEFCON 658 is out. 

In its place? A more structured, standardised framework that holds every supplier and their subcontractors accountable for how they assess, manage, and report cyber risk.

So, what’s changed, and what does compliance actually look like now?

Learn how MOD suppliers can prepare for Cyber Security Model v4 from AMR CyberSecurity – part of Infinum, a Defence Cyber Certification Level 1 certified company.

What is CSM and why does it matter?

The Cyber Security Model (CSM) is the MOD’s framework to make sure every link in its supply chain takes cybersecurity seriously. It’s a risk-based model that applies proportionate security controls based on the nature and sensitivity of the work being delivered.

But this isn’t just about your organisation. Under CSM v4, cyber accountability flows downstream, meaning you’re also responsible for assessing and validating the cyber posture of your subcontractors and third-party vendors. No matter how large or small, one weak link can put an entire contract at risk.

So, what exactly does the MOD expect you to do?

Bottom line: If you want to work with the MOD, you need to take cybersecurity seriously – and be able to prove it.

DEFSTAN 05-138: What the MOD Expects

Building on the CRP levels established during the initial CSM risk assessment, DEFSTAN 05-138 outlines the specific cybersecurity controls that suppliers must meet based on their assigned risk profile.

This MOD standard acts as the benchmark for what’s expected at each level, from basic hygiene to expert-grade defences. The higher the risk, the more comprehensive and stringent the requirements. These controls form the foundation of both the SAQ process and any future DCC certification.

Here’s what each level includes:

It’s important to note that these controls are considered a minimum baseline. 

Depending on the nature of the contract, the MOD may impose additional cyber requirements on top of DEFSTAN 05-138, raising the bar even further for critical or sensitive work.

Enter DCC: Independent certification for defence suppliers

To move beyond self-assessments and strengthen assurance across the defence supply chain, the MOD, together with IASME as the Certification Authority, introduced the Defence Cyber Certification (DCC).

DCC isn’t a full replacement for the Supplier Assurance Questionnaire (SAQ), at least not yet. But it’s clear that the MOD is positioning DCC as the gold standard for demonstrating cyber maturity. 

Over time, it’s expected to become more tightly integrated into the Supplier Cyber Protection Service and potentially reduce the burden of repeated self-reporting.

How it works:

For suppliers working on sensitive contracts, or for the ones hoping to, DCC is quickly becoming table stakes. It’s a proactive way to prove compliance, strengthen your competitive edge in defence tenders, and demonstrate to the MOD that cyber security is not just a policy on paper, but a practice in action.

How can we help

Whether you’re tackling your first Risk Assessment or gearing up for DCC certification,we are here to support you. 

As a Level 1 certified DCC Certification Body, we provide more than just checklists. We’ve partnered with both prime contractors and subcontractors throughout the MOD supply chain, helping defence suppliers navigate CSM v4 from day one – whether you’re assessing your CRP, preparing for DCC, or building a CIP roadmap.As a Level 1-certified DCC Certification Body, AMR CyberSecurity – part of Infinum provides more than just checklists. We’ve partnered with both prime contractors and subcontractors throughout the MOD supply chain, helping defence suppliers navigate CSM v4 from day one – whether you’re assessing your CRP, preparing for DCC, or building a CIP roadmap.

From independent assessments to hands-on consultancy, we tailor our approach to fit your organisation’s needs, so you’re not just compliant, you’re truly cyber-resilient. If you want to discuss your next steps, contact us.From independent assessments to hands-on consultancy, we tailor our approach to fit your organisation’s needs, so you’re not just compliant, you’re truly cyber-resilient. If you want to discuss your next steps, contact us.

If you haven’t kept up with AI tooling discussions, you may have missed OpenClaw (formerly Moltbot and Clawdbot). Marketed as “The AI that actually does things,” it acts as your personal AI assistant that can clear your inbox, send emails, manage your calendar, and even check you in for flights. It also acts out – to say the least.

What sets Moltbot apart from cloud-only assistants is its deep integration with applications already running on your system, such as WhatsApp, Telegram, Slack, and Discord. It interacts directly with your operating system to manage everyday tasks, bringing AI assistance into your local workflow rather than keeping it locked behind a web interface.

However, from a security standpoint, this level of access is bordering on a worst-case scenario. This is the same principle we found in our experiment on AI-generated code security risks — AI systems don’t fail because they lack capability, they fail because they make incorrect assumptions about trust.

The developers are transparent about the dangers. Moltbot’s installer explicitly outlines its extensive capabilities and describes the system as “inherently risky“. While this transparency is commendable, it highlights the unusually broad level of access the AI operates with.

During onboarding, the system prompts you to enable “skills,” which are essentially permission scopes granting the bot access to local applications and external services. Some of these are highly sensitive:

After installation, Moltbot exposes a local web dashboard running on port 18789 by default. This serves as the primary control panel for managing the bot’s capabilities.

The critical issue is that there is no authentication mechanism in place. If this dashboard is exposed to the internet, any unauthenticated user can interact with the underlying operating system and connected services.

This is not a hypothetical risk. A simple Censys query reveals more than 1,500 publicly exposed, unauthenticated Clawdbot instances. These real-world deployments grant unrestricted access to anyone who stumbles across them.

As for the chatbot itself, it delivers exactly what is promised: it can reliably execute system commands.

The bot does have some built-in safety measures; by default, it will refuse to execute suspicious commands like reading the .env file that contains API keys.

However, these guardrails are easily bypassed. While prompt injection is a known threat, the simplest way to extract this sensitive data is to ask the bot to list environment variables. This can immediately leak the OPENAI_API_KEY and other critical credentials that are used and configured.

The viral popularity of the tool has also attracted bad actors. One reported case involved a fake Visual Studio Code extension posing as a “ClawdBot Agent“. While it looked like a legitimate installer, it was actually secretly installing credential stealer on user’s systems.

Source: https://www.aikido.dev/blog/fake-clawdbot-vscode-extension-malware

Specific Tips Moltbot/Clawdbot Users:

While AI agents are highly effective for automation, they also introduce significant risks — especially when built without proper security design from the start. If you’re building agents for your business rather than experimenting with third-party tools, see how we approach AI agent development with security and governance built in. To keep your data and devices safe in the meantime, follow these best practices:

Given the rise of lookalike installers and “agent” add-ons, verify sources rigorously before installing anything.

AI agents are here to stay, but until secure-by-default practices (authentication, least privilege, hardened networking, and auditable controls) become standard, the safest mindset is simple: If it can operate on your system, it can compromise it.

If your company builds or sells software and connected devices in the EU, the new Cyber Resilience Act is something you need to pay close attention to. CRA introduces enforceable secure-by-design requirements across the entire product lifecycle. Here’s what product leaders and engineering teams should know to get ahead of compliance.

Remember the Raptor Train? 

A botnet of more than 200,000 compromised connected devices hijacked through unpatched vulnerabilities and insecure defaults, not because those companies lacked internal security policies, but because the products themselves were never designed or maintained with long-term security in mind.

This kind of large-scale product risk is exactly what the EU’s Cyber Resilience Act (CRA) is meant to address, especially given the fact some estimates claim there are nearly 21 billion connected devices in the world today.

So, let’s dig into how the CRA addresses the security of the connected devices.

What is Cyber Resilience Act? 

CRA is one of the most significant shifts in digital product regulation in years that sets mandatory cybersecurity requirements for digital products sold in the European market. 

While NIS2 and DORA regulate how organizations operate, CRA regulates what certain organizations build. 

It applies to nearly any “product with digital elements” (PDE) – a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately.

For product leaders, engineering teams, and security owners shipping digital products to the EU market, CRA will change how products are planned, developed, released, and maintained.

In other words, cybersecurity is no longer a “launch and forget” problem. It’s a product discipline.

What CRA actually requires

At its core, CRA turns cybersecurity into a product safety requirement. To sell in the EU, a product must meet baseline security expectations throughout its lifecycle. 

That includes:

You must perform risk assessments early, design with security controls, strong configuration, authentication, and encryption in mind, test for vulnerabilities, and avoid shipping known exploitable vulnerabilities.

The supply chain is widely recognized as a significant cybersecurity risk today. Any included libraries, open-source packages, third-party modules, or firmware components must be documented and traceable through a Software Bill of Materials (SBOM). Managing these third-party components systematically, beyond just documentation is what a third-party cyber risk management framework is built for.

Manufacturers must document and patch newly discovered vulnerabilities and maintain security updates – typically for five years or for the expected lifespan of the product, all the while keeping up transparent communication towards their customers.

Actively exploited vulnerabilities and severe incidents must be reported quickly (24h early warning, 72h detailed report).

Before you place a product on the EU market, you’ll need an internal or third-party assessment and to affix CE marking demonstrating compliance. Non-compliance can lead to fines up to €15M or 2.5% of global turnover and prohibiting the sales of products that do not meet mandatory requirements.

Who is impacted?

CRA applies to the entire digital-product ecosystem:

CRA classifies products by risk level, so higher-risk products (e.g., identity systems, password managers, browsers, network equipment, industrial devices) require independent conformity assessments, while lower-risk products can rely on self-assessment.

Additionally, not every digital product falls under the scope of the CRA, it mostly focuses on consumer products. 

Standalone websites and cloud services are exempt when they are not used to enable or operate a product with digital elements, as is non-commercial open-source software. Products that are already regulated under dedicated EU sector frameworks are also excluded.

For more details on the above, the recently released CRA implementing act contains technical descriptions related to important and critical products.

Key dates

The biggest CRA challenges ahead

Based on the current cybersecurity trends and how most companies ship software today, CRA will expose several weaknesses:

How we help companies become CRA-ready

At Infinum, we work with organizations to build digital products that are secure by design – and now, compliant by design. Our cybersecurity offering supports CRA readiness across the product lifecycle, from threat modeling and secure architecture all the way to continuous monitoring and long-term maintenance planning.

CRA compliance isn’t just about meeting legal obligations; it’s about earning and maintaining customer trust in an increasingly competitive market by building safer, more reliable products.

Most teams don’t know where they stand today, so reach out for a CRA gap analysis or product security review to close the gaps before regulation becomes a blocker.Most teams don’t know where they stand today, so reach out for a CRA gap analysis or product security review to close the gaps before regulation becomes a blocker.

Cybersecurity in 2026 is no longer about what’s coming next, but about managing what’s already here. AI-driven attacks, stricter global regulations, supply chain exposure – here’s how to stay ahead when compromise is no longer hypothetical.

It’s 8 a.m. Your company’s email system goes down.

Minutes later, a poisoned update floods your development pipeline, silently embedding malware into every product your team touches.

AI-generated phishing emails land in employees’ inboxes, flawlessly mimicking the voices of their managers.

Customer data, vendor credentials, and financial records are exposed before anyone even realizes an attack has begun.

This is no longer science fiction.

Many of the trends we predicted in 2025 – large breaches, ransomware waves, rising supply-chain compromises, and AI-enabled cyber attacks have fully materialized. 

What was once the future of cybercrime is now simply the present. Here’s what that means as we step into 2026.

Regulations are still driving change

In 2026, cybersecurity regulations are moving toward greater global convergence and stricter enforcement. 

Key developments include the EU’s NIS2 Directive for critical entities and the EU Cyber Resilience Act (CRA), which mandates security for products with digital elements and reporting obligations starting September 11, 2026. 

Across the Atlantic, the U.S. Cyber Incident Reporting for Critical Infrastructure Act (CIRCIA) is coming into force, requiring rapid reporting of cyber incidents and ransomware payments.

Turning regulatory requirements into something teams can actually operate requires clear ownership, realistic controls, and alignment with how the business works.

AI still on both sides of the fence

Artificial intelligence has become both the sword and the shield.

Threat actors now rely on AI to scale phishing operations, localize social engineering campaigns at speed, evade detection by generating polymorphic malware, and automate reconnaissance across massive attack surfaces. 

Anthropic’s article on the first AI-orchestrated campaign says that this marks a pivotal shift in cybersecurity, highlighting the emergence of AI agents – systems that can be run autonomously for long periods of time and that complete complex tasks largely independent of human intervention.

Deepfakes, voice cloning, and identity fraud also became mainstream tools for deception, with deepfakes in particular growing increasingly difficult to detect.

The result is what many organizations now recognize as a crisis of authenticity – verifying identity, intent, and digital trust has never been harder.

At the same time, a new risk category has emerged: attacks targeting AI systems themselves. Data and model poisoning, prompt injection, model extraction, and compromised AI pipelines are becoming real concerns. 

Protecting AI systems is now inseparable from protecting core infrastructure.

On the defensive side, organizations are increasingly deploying AI-powered security operations platforms and agentic SOC tooling to process behavioral alerts, correlate signals, and accelerate incident response. 

AI now plays a central role in threat detection, analysis, and automated containment, helping defenders simply keep up with the scale of modern attack activity.

The rise of vibe coding and the speed-security tradeoff

We’re not done with AI quite yet.

AI-assisted development has transformed how software is built. Natural-language prompts replace detailed requirements. Entire features are generated instantly. Deployment cycles have collapsed from weeks into hours.

The productivity gains are enormous, but so is the risk. Wiz showed that almost 20% of vibe coded apps include serious vulnerabilities.

In 2026, the challenge is clear: organizations must preserve development speed without abandoning safety. 

Automated code security analysis, dependency scanning, AI-generated testing, and policy-based delivery guardrails are becoming mandatory to keep pace with modern development practices.

The evolution of phishing

Of all cyber threats in 2025, phishing remained the dominant force.

High-profile attacks, such as the Scattered Spider compromise of Marks & Spencer and the Co-Op incident, highlighted the enormous financial impact of credential-focused campaigns, with losses estimated at £300M and £270-440M, respectively. 

What changed in 2025?

Phishing became more sophisticated and precise:

In 2026, defending against phishing means putting identity security at the center of operational defense:

Identity has become the new firewall, the first line of defense in a landscape where trust is constantly under attack.

Modern supply chain security = owning risk beyond what you control

Cue Shai-Hulud 2.0 as a prominent recent example.

Shai-Hulud 2.0 demonstrated how upstream compromise of developer tooling can silently infect thousands of downstream projects, without attackers targeting the end organizations at all. 

By poisoning packages that developers trusted and pulled directly into production, the attack bypassed perimeter defenses entirely.

We can almost predict the headlines for 2026.

Security maturity is now measured not only by how well you protect your own assets, but by how deeply you understand and manage your entire vendor ecosystem, including your shadow IT. 

Dependencies are no longer just code libraries – they are hosted platforms, analytics services, support tools, collaboration APIs, and managed cloud infrastructure.

The axios npm supply chain attack in March 2026 shows exactly how this plays out — a single compromised npm account turned a library with 100 million weekly downloads into a malware delivery vehicle for under three hours.

In 2026, supply-chain security is operational security:

For a structured framework to manage this vendor exposure end-to-end, our guide to third-party cyber risk management walks through the full lifecycle from vendor identification to offboarding.

These steps now define baseline resilience.

Resilience meets prevention

The mindset around cybersecurity has changed.

While prevention remains critical, leadership teams now actively assume that compromise is possible, even likely, and design accordingly.

The breaches in recent years showed that many attacks operate without malware, relying instead on stolen credentials, social engineering, abused APIs, or compromised vendors. These techniques bypass traditional perimeter defenses and signature-based detection tools entirely.

In response, organizations should be prioritizing:

The focus is shifting from “How do we prevent every attack?” to “How quickly can we detect, contain, and recover?”

With ransomware-as-a-service still looming large and threat actors broadening their scope, robust resilience and incident response capabilities are becoming the new benchmark of cybersecurity maturity. 

Finding a holistic security partner

In this new environment, cybersecurity requires more than just point solutions or compliance checklists.

Organizations need a holistic security partner – one that understands modern application ecosystems, AI exposure, supply-chain complexity, and operational resilience.

That’s why Infinum’s emerging cybersecurity offering covers a wide-range of cybersecurity services. Here’s how we can help:

As we step into 2026, organizations need cybersecurity that is practical, adaptive, and deeply integrated with how modern products are built and operated.

If you need help to design, deploy, and operate secure digital products that can stand strong not only today, but through whatever innovations tomorrow brings – contact our experienced team.

Sometimes the most dangerous piece of software is the one you didn’t even write. With supply chain attacks on the rise, software supply chain security is now critical to protecting not just your code, but everything your code depends on.

When we talk about a “supply chain,” most people picture the journey of a physical product: from raw materials through manufacturing to assembling, distribution, and sale. Obviously, no company does it all alone; they rely on a network of partners to make it happen.

Software works the same way.

Modern applications aren’t built from scratch, they’re assembled. Behind every app is a complex ecosystem of developer tools, CI/CD systems, cloud services, and open-source code. As The Linux Foundation reports, 70 to 90% of most applications today are made up of third-party components.

We saw that risk explode into reality recently.

Cycode states that a phishing campaign led to the hijacking of core NPM packages like chalk, debug, and strip-ansi, libraries downloaded over 2 billion times per week. SC Media reports that days later, another attack infected more than 200 NPM packages, including those linked to CrowdStrike, using a self-replicating worm that exfiltrated data, created rogue GitHub workflows, and attempted to spread downstream.

It’s no longer just about writing secure code, it’s about securing everything you rely on to build, deploy, and maintain it. 

In this article, we’ll introduce supply chain security and cover best practices for reducing risk – from defining requirements all the way to development, deployment, and maintenance.

The topics we’ll cover include:

What is Software Supply Chain Security (SSCS)?

Software Supply Chain Security (SSCS) is the practice of securing all the components, tools, people, and processes involved in the development, deployment, and maintenance of software, from third-party libraries and CI/CD pipelines to developer environments and cloud infrastructure. 

If you’re only securing your app but ignoring the tools and dependencies you use to build it, you’re not secure. Modern software isn’t built from scratch. It’s assembled. And even a single vulnerable dependency can compromise your entire product.

That’s why SSCS is a critical part of secure software development. It ensures every link in the chain is trusted, verified, and resilient. It’s also why regulations like NIS2 or CRA put so much emphasis on it.

What are the most common threats in the software supply chain?

Software supply chain security goes far beyond writing secure code. It’s about making sure malicious actors can’t sneak in through the tools, environments, and people your app depends on.

Here are some of the most common entry points attackers exploit:

Most common types of supply chain attacks

Once inside, here’s what those attacks can look like in the real world:

And that’s not even an exhaustive list.

Many of these attacks exploit gaps in the development process itself.

Even if your code is secure and your infrastructure hardened, vulnerabilities can slip in when there’s limited visibility, inconsistent practices, or missing security checks — which is why integrating security throughout the Software Development Lifecycle (SDLC), often referred to as the Secure Software Development Lifecycle (SSDLC), is so valuable.

Integrating security at every stage of the SDLC

The SSDLC encourages embedding security practices at every stage of development. This approach, often referred to as “shifting left”, helps identify and remediate threats early, before they reach production. 

It doesn’t eliminate supply chain risks entirely, but it reduces the risk of vulnerabilities slipping through unnoticed and the likelihood that compromised dependencies, misconfigured pipelines, or weak controls turn into full-blown breaches.

Here’s what that can look like:

How to adopt secure software development lifecycle (SSDLC) practices

Let’s break it down through some high-level SSDLC phases and their security-minded steps:

1. Planning

Planning is arguably the most critical step for supply chain security, as it helps prevent hidden vulnerabilities through thorough due diligence.

2. Design

Design is your chance to build supply chain defenses into the architecture.

3. Development

Development is where insecure code or unvetted dependencies can silently enter your supply chain. 

4. Testing

Testing is where you validate not just your code, but the behavior of any external components or APIs. It helps expose risks before they become real threats

5. Build & deploy

Build and deployment pipelines are a prime target for supply chain attacks. Securing CI/CD is a non-negotiable for trust and integrity.

6. Distribution

Distribution is when your software becomes part of someone else’s supply chain. It helps build trust and transparency with clients and downstream users.

7. Maintenance

Maintenance ensures your supply chain remains secure over time. Nothing is more dangerous than running software that becomes forgotten.

You don’t need to get it perfect from day one. Just start building with intention, iterate often, and treat security as a shared responsibility across your stack.

Which industry standards and frameworks to explore for SSDLC?

Luckily for you, you don’t have to start from scratch.

There are frameworks built by security pros to help you get it right. Use OWASP SAMM, NIST SSDF, or Microsoft’s SDL as a baseline to evaluate your current practices and make steady, structured improvements.

How to build a response plan and keep your security policies sharp

The worst time to figure out your incident response plan is while the incident is happening.

Investing time into developing a clear, actionable incident response plan is non-negotiable. 

And that’s just the beginning.

As software evolves, so do the threats. If your security policies are stuck in last year’s playbook, you’re not protected. Review and update your practices regularly, from dependency management and access control to patching and third-party risk.

Stay informed, stay adaptable, and stay ahead before someone else forces you to.

How to manage human risk in the supply chain security

Technology alone isn’t enough. Security depends on people, and people are often the easiest way in.

Phishing and social engineering remain some of the most effective tactics in supply chain attacks. Recent incidents like the hijacking of chalk and debug began with a fake MFA email sent to a trusted maintainer. No zero-days. No malware. Just a well-crafted message and a moment of inattention.

That’s why security culture matters as much as security tooling.

Start with the basics:

Isn’t this all a bit too much?

Yes, it can feel like a lot. But you don’t need to boil the ocean, just start where it matters most. Use a model like OWASP SAMM to assess where you stand, identify your biggest risks, and go for a few quick wins.

Here are a few that pack a punch:

Security maturity comes from small, consistent moves in the right direction

Remember: you can outsource code, but you can’t outsource accountability. What matters most is building a culture where no one makes security the other person’s job.

Proceed to shift security left, raise awareness, automate what you can, patch early, and document everything. If you need some extra support, feel free to reach out to our certified experts.