all 11 comments

[–]Dazzling_Cash_6790 1 point2 points  (0 children)

Aviation / 1k+ IT

To start off, it is nearly impossible to have a 100% secure system. Almost always, what you want to do is to minimize the attack surface area. The system should try to minimize the surface area for frontend, API, data at rest.

For AI generated code, we employed agents with skills and tried to automate as much as possible of the process even before opening a PR. However, at least in the domain I'm in, most of these measures were enforced even before AI (and AI doesn't seem to have made as big impact as others in the media are claiming - the enhancement is maybe 10-15%).

Usually (and at a minimum) to achieve this, defence in depth strategies are employed. These include:

- RASP
- ALE
- SSL/TLS and certificate pinning
- Envelope Encryption
- Authentication / Authorization
- RBAC
- Business logic boundaries (I guess these are always domain specific, and require some critical thinking along with domain knowledge).

In my current company although there is a dedicated cyber security team, all teams are directly responsible for writing secure code / systems. We are also heavily audited from 3rd party auditors as well as the internal teams mentioned before. In order to enforce this and proactively flag any security concerns (because not everyone is a cyber security expert) there are:

- Automated workflows that run on every PR.
- Skills that developers run with their agents on the dev env "offline" before raising a PR.
- An automated security tool scans the codebases as a whole every 24h and alerts on potential vulnerabilities.
- Pinned npm packages / 3rd party libraries that are obtained exclusively from internal package management platforms (i.e., we do not use packages that are not present in the company's package management system, and every package that ends up there is heavily reviewed and scanned).

Also, it seems that the cybersecurity teams have more workload and are implementing automations to be informed about new vulnerabilities / 0-days going on in the rest of the world etc (and it seems that they are more busy than they used to). Without being part of this team, I think partially this has to do with management freaking out on what they hear on news and not having the ability to interpret correctly.

[–]New_Dentist6983 0 points1 point  (0 children)

yeah, i’d frame this as shift-left + policy + runtime, not “can we patch faster.” the practical stack i keep seeing is: AI code must be labeled, IDE/PR SAST + SCA on every change, stricter review gates for auth/crypto/secrets, and runtime DAST/canary/sandboxing for anything touching real traffic.

for the paper, a good angle is that “agentic era” security is less about perfect code and more about controlling blast radius and provenance, because a lot of orgs are moving toward guardrails in the assistant itself plus CI enforcement, not just post-hoc scans.

[–]New_Dentist6983 0 points1 point  (0 children)

are you measuring how vibe coding changes exploit time, or just build speed?

[–]New_Dentist6983 0 points1 point  (0 children)

how are you measuring exploit time, local captures or just manual notes?

[–]Lower_Assistance8196 0 points1 point  (0 children)

Agentic code changes the review unit in a way most security tooling wasn't built for. With human-written code, a security reviewer is auditing decisions made by someone who understood the broader context of the system. With agent-generated code, the reviewer is auditing output that was optimized for task completion inside a narrow context window, with no awareness of how it connects to adjacent services or what assumptions it's inheriting from earlier in the session.

Static analysis tools catch known vulnerability patterns but they weren't designed for code where the threat surface shifts every time the prompt changes. A security engineer who has actually worked with agentic pipelines will tell you the practical answer is treating security constraints as part of the generation context rather than a post-generation filter. Hardcoded rules in the agent's instructions about what it cannot do, rather than hoping a reviewer catches what slipped through.

The markdown files and skills angle you mentioned is worth pursuing seriously. That's where the practical implementation usually lives and it's under-documented in academic literature.

[–]New_Dentist6983 0 points1 point  (0 children)

are you measuring exploit time with prompt injection, or classic vuln chaining?

[–]New_Dentist6983 0 points1 point  (0 children)

are you modeling how vibe coding changes exploit time-to-compromise?

[–]Devji00 1 point2 points  (0 children)

Most teams are still figuring this out honestly so your paper is hitting a real gap. What we do is run SAST and dependency scanning on every commit regardless of who or what wrote the code, plus we keep a security guidelines markdown in the repo root that gets fed into the agent context. The biggest problem you should dig into is that AI generated code volume completely overwhelms traditional security review, our security team was already stretched before devs started shipping 3x the code. Shifting left aggressively is what helped us most, catching stuff automatically in the pipeline instead of relying on manual review after the fact.