35,872 New Vulnerabilities in Just 6 Months. Is Your Application Secure?

It’s 2026. We’re talking about Artificial General Intelligence (AGI), AI agents are writing entire applications, and we’re shipping code faster than ever. Yet here we are, still battling security vulnerabilities. Are we building smarter applications or just finding faster ways to make them vulnerable?

In the first half of 2026, reports indicate that 35,872 new vulnerabilities were recorded, representing a 51.3% increase compared to the same period last year.

That’s a significant increase, and as developers, it’s something we should pay attention to.

Here is a breakdown of vulnerabilities across different programming languages and ecosystems:

With AI-assisted and agentic coding becoming part of our development workflows, we are writing and shipping code faster than ever.

But here is the question.

Are we becoming better at securing the code we ship, or are we just getting faster at introducing vulnerabilities?

We already know vulnerabilities are not going anywhere. And with the increasing adoption of AI in software development, the amount of code being produced will only continue to grow.

So how do we stay ahead?

One approach is something we commonly talk about in DevOps.

No, I’m not asking you to shift from your current position. 😂

Shift-left is a DevOps approach that involves moving activities such as testing, quality assurance, and security earlier in the software development lifecycle.

Instead of waiting until an application reaches production to discover security issues, we identify and address them during development.

Think about it this way.

Would you rather discover a hardcoded API key while writing your code or after your application has been deployed and someone has already exploited it?

I think we both know the answer.

For this blog, we will focus on three areas where developers can identify potential security vulnerabilities before they reach production.

And to make this practical, we will answer three questions.

1. Third-party dependencies

How can we identify vulnerabilities in the third-party libraries, open-source packages, and container images our applications depend on before pushing code to staging?

2. Our application code

How can we identify security weaknesses in our own code, such as hardcoded credentials, unsafe SQL queries, inadequate input validation, and insecure coding practices?

3. Our running application

How can we identify security vulnerabilities in our running applications and APIs, including authentication, authorization, session management, and exposed endpoints, before deploying to production?

To answer these questions, we will explore three security testing approaches:

• SCA — Software Composition Analysis

• SAST — Static Application Security Testing

• DAST — Dynamic Application Security Testing

The best part?

We will use open-source tools that you can start using today.

Let’s get into it.

Almost every modern application relies on third-party libraries, open-source packages, and container images.

Whether you are building with React, Django, FastAPI, Node.js, or running your application inside Docker, chances are your application depends on code you did not write.

And that introduces a challenge.

How do you know whether those dependencies contain known vulnerabilities?

This is where Software Composition Analysis (SCA) comes in.

Software Composition Analysis is the process of identifying and assessing risks associated with third-party and open-source components used in an application.

Simply put, it helps answer the question:

Are we importing vulnerabilities into our application through our dependencies?

Trivy is an open-source security scanner that can identify vulnerabilities in dependencies, container images, filesystems, and infrastructure configurations.

You can run it locally, integrate it into CI/CD pipelines, or use it in containerized and Kubernetes environments.

For this demonstration, I will use macOS.

If you have Homebrew installed, run:

Open your terminal and navigate to your project directory.

Then run:

Here is what we are scanning for:

Vulnerabilities: Known security vulnerabilities in supported dependencies.

Secrets: Accidentally exposed credentials, tokens, and API keys.

Misconfigurations: Potentially insecure infrastructure and configuration files.

You still need to review the findings, understand their severity, determine whether your application is affected, and prioritize remediation.

Also, keep in mind that a clean scan does not mean your dependencies are completely secure. Trivy primarily identifies issues based on available vulnerability information and supported scanning capabilities.

Now that we have looked at third-party dependencies, let’s focus on something closer to home.

Our own application code.

Even when all our dependencies are up to date, our application can still contain security weaknesses.

For example:

• Hardcoded credentials and API keys.

• Unsafe SQL queries that could introduce SQL injection vulnerabilities.

• Inadequate input validation.

• Insecure cryptographic practices.

• Improper handling of sensitive information.

• Insecure coding patterns introduced through AI-generated code.

That’s impressive.

But how do we know the generated code follows secure coding practices?

This brings us to our second approach.

SAST is a security testing approach that analyzes application source code without executing the application.

It helps identify potentially insecure coding patterns early in the development process.

Think of it as having an additional reviewer focused specifically on security

Semgrep is a static analysis tool that can identify security issues and coding patterns based on predefined rules.

It supports multiple programming languages, making it useful for developers working across different technology stacks.

Let’s try it.

On macOS, run:

Navigate to your project directory and run:

This runs a scan using Semgrep’s automatically selected rules.

You can also configure specific rulesets depending on your application and the security issues you want to identify.

You can take this further by customizing rules, integrating Semgrep into your development workflow, and running scans automatically whenever code changes are introduced.

Some issues, especially those involving business logic, complex authorization flows, and runtime behavior, may require additional testing.

Which brings us to our final question?

So far, we have scanned our dependencies and reviewed our application code.

But there is still one important area we haven’t covered.

What happens when the application is actually running?

An application may pass static security scans and still contain vulnerabilities that only become visible during execution.

For example:

• Missing security headers.

• Insecure session handling.

• Exposed endpoints.

• Authentication weaknesses.

• Certain authorization flaws.

• Improper error handling.

• Security misconfigurations.

These issues may not always be obvious during code reviews or static analysis.

This is where our third approach comes in.

DAST involves testing a running application or API to identify potential security vulnerabilities.

Unlike SAST, which analyzes source code, DAST interacts with the application while it is running.

It examines how the application responds to different requests and inputs.

For this, I recommend OWASP ZAP, also known as Zed Attack Proxy.

ZAP is an open-source web application security testing tool maintained by an active community.

It can help developers identify security issues in running web applications and APIs.

You can install ZAP using its desktop application or run it through Docker and other supported environments.

For macOS, you can use Homebrew:

Alternatively, you can download it from the official website.

Installation guide: https://www.zaproxy.org/download/

ZAP’s desktop installation requires a compatible Java runtime, although some installation packages include one.

Once installed, you can configure ZAP to inspect requests and responses between your browser and your application.

You can also perform automated scans against applications you own or are authorized to test.

One important thing to understand is that active security scans send potentially disruptive requests to your application.

Always test against an authorized environment, preferably staging, rather than blindly scanning production.

ZAP can identify many common web security issues, but complex authentication, authorization, payment, and business logic vulnerabilities may still require manual security testing.

I will dive deeper into DAST and OWASP ZAP in another blog, including how to configure it and scan an application.

As developers, we spend a lot of time thinking about how to make our applications faster, more scalable, and easier to maintain.

But security deserves the same attention.

With the growing number of reported vulnerabilities and the increasing use of AI-assisted development, being proactive about application security is becoming even more important.

The three tools we have explored — Trivy, Semgrep, and OWASP ZAP — are open source and relatively easy to get started with.

Even better, they can be integrated into CI/CD pipelines, making security checks part of our everyday development workflows.

Of course, these tools alone will not make an application completely secure.

Secure architecture, code reviews, proper access controls, threat modeling, and continuous monitoring still matter.

But they provide a good starting point.

The goal is not to write code with zero vulnerabilities. The goal is to identify and address as many security risks as possible before they become real problems.

And that’s a wrap!

I’d love to hear from you guys.

How are you approaching application security in your development workflows?

Are you using SCA, SAST, DAST, or other tools I haven’t mentioned?

Let’s learn from each other.

Cheers! 

1. Vulnerability Statistics —  https://scantitan.com/blog/vulnerability-statistics/

2. Trivy Documentation —  https://trivy.dev/docs/latest/getting-started/

3. Semgrep Community Edition —  https://docs.semgrep.dev/getting-started/quickstart-ce

4. OWASP ZAP —  https://www.zaproxy.org/getting-started/

5. OWASP ZAP Downloads —  https://www.zaproxy.org/download/