Diving into Cybersecurity in the 2026 AI Era
Why cybersecurity, and why now
I am working on a cybersecurity project that has pushed me to learn application security more seriously. Part of the work is evaluating AI-assisted security tools; another part is thinking through how to operationalize a service that helps teams identify, prioritize, and remediate findings.
The job is simple to describe and difficult to do well: turn security signals into evidence, then help the right people act on them.
I am evaluating where AI-assisted tools add real value and how a service could help teams move from a pile of findings to a trackable remediation process. Rather than build “another scanner,” I am interested in an evidence and orchestration layer around the tools a team already uses.
I am especially interested in the gap between a possible issue and a useful finding. A useful finding has enough context for someone to understand the risk, judge its confidence, and decide what to do next. That is a much higher bar than producing a long report.
AI raises the stakes. It helps teams produce and change code faster. It also increases the volume of code, integrations, and agent-driven actions that must be secured. Attackers can use the same speed to research targets and iterate on attacks.
The security landscape I thought I was entering
My starting picture of application security was familiar: scan code for risky patterns, scan dependencies for known vulnerabilities, look for leaked secrets, and put sensible checks into the development pipeline. Those practices are still essential.
Each type of tool sees a different part of the problem:
- Static application security testing (SAST) examines source code for vulnerable patterns and data flows.
- Software composition analysis (SCA) looks at third-party dependencies.
- Secret scanning looks for credentials that should never have been committed.
- Infrastructure-as-code, container, and CI/CD scanning look for risky configuration, packages, and pipeline controls.
- Dynamic testing observes an application while it is running; it can support authorized offensive validation in a controlled environment.
The first lesson was simple: no single scanner is a complete security program. A scanner can flag a vulnerable library that is not reachable in an application. A finding may also be mitigated by authentication, network boundaries, or another compensating control. On the other hand, a tool can miss a broken authorization rule because the problem is in the meaning of the workflow, not in one obviously dangerous line of code.
What the AI era changes
New capabilities for attackers
AI has changed the economics of security work. It can accelerate research, summarize unfamiliar code, and help people generate or adapt material at scale. That applies to defenders, but it also applies to people looking for weaknesses.
AI agents are not autonomous hackers. Defenders should expect faster iteration and prepare to validate more claims in less time.
New capabilities for defenders
This is where I am most interested. The most credible AI-assisted security tools do not ask an LLM to replace every established control. They combine repeatable analysis with contextual help: explain a finding, connect it to surrounding code, reduce duplicates, suggest a narrow fix, or help an analyst decide what to investigate next.
LLMs can also make security knowledge easier to use. They can summarize OWASP guidance, explain an unfamiliar vulnerability class, or help analysts navigate a new advisory. That saves time, but it does not remove the need to check the primary source, confirm that the information is current, and test the conclusion against the system in front of you.
GitHub, for example, describes Copilot Autofix as using CodeQL alert data and code context to propose a potential fix. Its documentation explicitly says developers must evaluate the suggestion and preserve intended behaviour. A generated patch is a starting point for review, not an approval stamp.
For me, the right mental model is hybrid:
- Deterministic tools provide repeatable coverage and evidence.
- AI helps with reasoning, triage, explanation, and remediation ideas.
- Tests, review, and accountable owners decide what gets changed.
New systems to secure
We are not only securing conventional applications that happen to use AI to write code. We are increasingly securing applications that contain models, retrieval systems, agents, tools, and external data sources.
That expands the questions an AppSec team has to ask. What data can a model access? What actions can an agent take? What happens when untrusted content reaches a tool-using system? How do permissions, logging, and approval boundaries work? The OWASP Top 10 for LLM and generative-AI applications is a helpful orientation point, covering risks including prompt injection, sensitive-information disclosure, supply-chain risk, and excessive agency.
From scanning to contextual validation
- Scanning answers an important first question: what might be wrong?
- Contextual validation asks the next one: does it matter in this application, in this environment, right now?
A dependency scanner might flag a known vulnerability in a library. The alert becomes actionable only after checking whether the affected function is used, whether it is exposed through the application, and whether existing controls reduce the risk. That context may turn one alert into a priority fix and another into a documented non-issue.
That requires more than a file and line number. It may require the affected code path, the exposed API, the user role, the deployment configuration, the network boundary, and the controls around it. The result should be an evidence-backed finding that a team can reproduce, discuss, and prioritize. It should not be a severe-looking alert with no clear next step.
The system is only one part of that work. Teams also need a process for assigning an owner, discussing the finding, recording a decision, and following it to a clear status. A finding may be remediated, accepted as a documented risk, marked as a false positive, or closed for another recorded reason. That workflow gives people the context and accountability to make the right decision instead of letting alerts disappear into a backlog.
Continuous offensive security, within a safe scope
Traditional testing often produces a point-in-time report. Modern delivery changes applications too often for that report to be the whole picture. Continuous offensive security applies an adversarial mindset repeatedly and under explicit authorization: after a meaningful release, a new API, a changed authorization flow, or a new AI integration.
Continuous offensive security means controlled, event-driven validation in approved environments, with clear scope, logs, and human oversight. It verifies the risks that matter most and feeds the results back into remediation; it does not authorize indiscriminate scanning or autonomous attacks against production.
Seen as a progression, AppSec has moved from periodic reports to checks in pull requests and CI/CD, then to continuous validation as systems change. AI-assisted AppSec builds on that foundation by adding application and runtime context plus remediation support; secure coding, testing, and human judgment remain necessary.
The progression looks like this:
What I am learning right now
This work is helping me turn a broad market of security products into a more concrete set of questions. In practical terms, I am asking whether a service can:
- run approved scanners against an approved repository and commit;
- retain the evidence behind each finding: tool, version, configuration, location, and time;
- normalize overlapping findings rather than make people triage the same issue repeatedly;
- use AI to add context or draft a remediation path; and
- keep a human owner responsible for prioritization and change approval.
Tools I am watching
I am watching these tools to answer practical questions about the workflow:
- GitHub Advanced Security and CodeQL: how much can scanning, dependency analysis, secret detection, and remediation support fit naturally into a GitHub workflow?
- Semgrep: where does deterministic, rule-based analysis benefit from AI-assisted detection and triage?
- Snyk: can one platform help teams secure AI-generated code, AI systems, and conventional applications?
- Google CodeMender: when an agent finds a vulnerability and proposes a patch, what evidence is enough for a developer to approve it?
- OpenAI Codex Security: where can agentic codebase analysis improve validation and remediation work?
For each, I look for clear evidence, a fit with the environment's data and governance requirements, and a faster path to resolution. Cost also varies with repository size, scan frequency, validation depth, and the models used.
What has been harder than expected
The hardest part so far has been learning to resist simple answers.
More findings do not automatically mean more security. A critical severity label is not the same as demonstrated exploitability. An AI-generated explanation can be clear and still be wrong. And a patch can make an alert disappear while changing the behaviour the application needs.
Those failures point to practical questions: which commit introduced the issue, which code path is affected, who owns the application, what data is involved, and which controls already apply? They also explain why AI needs guardrails of its own: approved data boundaries, isolated execution where appropriate, logs, repeatable inputs, and human review for consequential actions.
A beginner's map for learning responsibly
If you are starting from the same place I am, I would begin with foundations before chasing every new agent or product announcement.
- Learn how web applications work: requests, authentication, authorization, sessions, APIs, databases, and deployment.
- Learn the common vulnerability classes and the security vocabulary around them. OWASP is a strong place to start.
- Learn what SAST, SCA, secret scanning, IaC scanning, and dynamic testing can and cannot see.
- Practice only in legal, intentionally vulnerable labs, training environments, or systems you are explicitly authorized to test.
- When you evaluate an AI tool, ask for evidence: file and line references, the relevant data flow, tests, limits, and a clear explanation of where your code and data go.
Looking ahead
I am excited by the direction of the work. AI can help security teams spend less time translating raw alerts and more time validating risk, making decisions, and fixing what matters. It can also create new attack surfaces and new reasons to be careful.
My test for any AI-assisted security tool is simple: does it make a real security decision easier to evidence, own, and close?
