Cybersecurity does not start in the pentest. It starts in the process.

For a long time, security was treated as the last stage of development. The system was built, someone ran a tool, performed a few tests and, if nothing too serious appeared, the application moved to production.

That model no longer matches reality.

Today, systems change all the time. New features ship every week, external dependencies are updated, APIs connect to third-party services and infrastructure runs in increasingly distributed environments. In this scenario, testing security only at the end is like installing an alarm after the door has been open for months.

With artificial intelligence, this context becomes even more sensitive.

AI accelerates development, documentation, code analysis, testing and automation. But it also accelerates mistakes. An insecure snippet can be generated faster. A vulnerable dependency can be suggested naturally. An agent can execute actions in the pipeline, call APIs, read files, interpret failures and try alternative paths within the permissions it received.

That is why cybersecurity must enter the development cycle from the beginning.

It is not about looking for flaws only when the system is ready. It is about creating a process capable of preventing known vulnerabilities from entering the code, detecting risks quickly and validating whether controls continue to work after publication.

This is the principle of DevSecOps: development, security and operations working together. Security stops being a barrier at the end of the project and becomes a continuous discipline inside engineering.

Pentesting matters, but it is not a process

In practice, this starts with a simple change: security cannot depend only on an annual pentest.

The pentest, or penetration test, remains important. It simulates real attacks, identifies logic flaws, tests permissions, validates impact and finds problems that automated tools do not always see. But it should not be the only control.

A mature program combines several layers.

The first is shift left, which means moving security testing into earlier development stages. Instead of discovering a critical flaw on the eve of release, the team identifies the issue in the code, pull request or architecture.

Then comes continuous security in the pipeline. With every relevant change, the system can run automated checks: secret scanning, code analysis, dependency analysis, authorization tests and infrastructure analysis.

There is also shift right, which looks at the system after it is in production. Security does not end at deploy. Teams need to monitor errors, access patterns, suspicious attempts, abnormal behavior, exposed services and new vulnerabilities that appear over time.

With AI, these three movements become more important. Shift left reviews what AI helped produce. The pipeline controls what automation tries to publish. Shift right observes whether a new behavior, human or automated, moved outside the expected pattern.

How AI changes the security context

AI changes the context because it enters both sides at once.

On the builder side, it accelerates code, scripts, queries, tests, documentation and integrations. This increases productivity, but it also shortens the interval between idea and deploy. If the review process is weak, the company simply ships risk faster.

On the attacker side, AI can also accelerate reconnaissance, reading error messages, creating payloads, varying attempts, analyzing APIs and searching for known patterns. It is not magic. It is automation applied to steps that used to be slower.

And there is a third layer: AI agents. When an agent stops only answering and starts acting, it becomes part of the attack surface. If it accesses repositories, tickets, files, databases, test environments, deployment tools or external services, its permissions must be treated with the same seriousness as any technical identity.

This does not mean avoiding AI. It means governing its use.

A company can use AI to review code, suggest tests, summarize alerts, classify vulnerabilities and support log analysis. But it must define limits: which data can be sent, which tools can be invoked, which actions require human approval and which records must be available for audit.

AI without process becomes a shortcut. AI with process becomes capability.

Tests that need to enter the flow

Some tests are fundamental in this process.

SAST, or Static Application Security Testing, analyzes code without running the application. It helps find unsafe function usage, vulnerable queries, validation flaws, exposed credentials, inadequate cryptography and possible injection points.

SCA, or Software Composition Analysis, looks at dependencies. This is essential because modern applications use dozens, hundreds or even thousands of external packages. Sometimes the risk is not in the code written by the team, but in an outdated, abandoned or vulnerable library.

Another important control is secret detection. Tokens, passwords, private keys, .env files and cloud credentials should never be in the repository. And when they appear, deleting them is not enough. The credential must be considered compromised and must be revoked or rotated.

DAST, or Dynamic Application Security Testing, tests the running application. It interacts with routes, forms, APIs, parameters and headers to identify insecure behavior, such as session flaws, file exposure, overly detailed errors, missing security headers and unintended endpoints.

In the AI context, additional tests enter the flow: prompt injection attempts, sensitive data leakage, improper tool use, actions outside scope, unauthorized file access and isolation failures between users, clients or environments.

When AI participates in development, its output also deserves review. Generated code should not enter as an exception to the process. It should go through review, tests, dependency analysis and architecture validation like any other code.

Not everything can be automated

Tools help, but they do not understand everything.

Business logic flaws require human context. A scanner may not understand that a user should not approve their own request, apply the same discount multiple times, change an order after approval or access another company's data.

This type of risk appears when someone understands the process and thinks like an attacker.

That is why good security combines tooling and method.

Before testing, the team needs to understand what can be attacked. This work is called threat modeling. The team identifies important assets, user types, permissions, entry points, external integrations, sensitive data, AI agents, connected tools and abuse scenarios.

Simple questions already reveal a lot:

• Who can access this feature?
• Can one user see another user's data?
• Can this operation be repeated without limit?
• Does the system validate the rule on the server or only hide the button on screen?
• Does the action leave enough record for audit?
• Can an AI agent trigger this operation without approval?
• Can the prompt or log expose sensitive information?

Those answers become tests.

Authorization and APIs remain central

In business systems, one of the most critical areas is authorization. It is not enough to know whether the user is logged in. It is necessary to know exactly what they can do. Common users, managers, administrators and technical agents must have clear permissions.

And these permissions need to be tested in the backend, not only in the frontend.

Hiding a button is not security.

Security means blocking the action on the server.

APIs are another sensitive area. Many serious flaws happen when an API allows someone to change an identifier, access another client's data, alter properties that should not be changed or query sensitive information without proper validation.

That is why APIs need specific tests: authentication, authorization, rate limits, data exposure, method changes, abusive pagination, file upload and parameter manipulation.

With AI, this care increases. Agents and automations often interact with APIs directly. If the API does not validate rules on the server, automation may execute an action that the interface would never show to the user.

Infrastructure is also code

Infrastructure also counts.

A well-written application can be compromised by a poorly configured deployment. Open ports, exposed services, default credentials, debug mode, public buckets, outdated containers, accessible backups and excessive permissions are doors that should not be open.

As infrastructure is increasingly declared as code, it must also enter the security pipeline: infrastructure file analysis, image validation, permission review, secret policy, environment segmentation and continuous monitoring.

If AI creates deployment scripts, suggests configurations or operates internal tools, those artifacts need to pass through the same filter.

A vulnerability cannot become a forgotten report

In the end, cybersecurity applied to development is not an event. It is a cycle.

A basic flow could work like this: at every commit, check secrets. At every pull request, run SAST and dependency analysis. During build, validate image and infrastructure. In staging, run dynamic tests, authorization tests and AI-specific tests when agents or models are connected. Before important releases, perform full scanning, threat modeling and manual pentesting. After fixing, retest.

And everything must be traceable.

Each vulnerability should have an owner, severity, evidence, impact, deadline, status and retest. Without management, a vulnerability becomes a forgotten report. With management, it becomes work until it is fixed, formally accepted or discarded as a false positive.

Maturity appears in indicators: mean time to fix, findings by severity, recurring vulnerabilities, percentage fixed within deadline, vulnerable dependencies, findings before production and findings in production.

The most important metric is not how many vulnerabilities were found. It is how many stopped coming back.

Fixing a flaw is necessary. Learning from it is what improves the system.

Security is method, evidence and responsibility

Software security does not promise a "100% secure" product. That promise is not realistic.

What it delivers is something more serious: a verifiable, continuous and risk-oriented process.

In the current context, that process needs to include AI. Not as an inevitable threat, and not as a magic solution. AI is capability. And every new capability needs limits, traceability, review and governance.

A secure system is not born from an isolated tool.

It is not born from a pentest at the end.

It is not born from luck.

It is born from method, evidence, discipline and responsibility from the first line of code to production operation.