[ Removed by Reddit on account of violating the content policy. ]

Hi all, I'm trying to learn how infrastructure and network audits work in practice and would love some input from people doing this daily.
What are the control gaps you find most often?
Where do auditees tend to be weakest (patching, access reviews, firewall rules, logging)?
Any audit checklists you'd recommend

Hi everyone,

Our application security workflow is increasingly AI-assisted from threat modeling and SAST/SCA to code reviews and vulnerability analysis. We use Claude, OpenAI, and Copilot to perform SAST with custom prompts, and source-code context along with internal tools[traditonal sast, jars moderation]. Burp Suite for manual validation.

But here's the challenge: when AI helps developers write code and AI helps security teams review it, how do we reliably catch vulnerabilities that escape both?

I'm looking for ways to improve coverage, independently validate findings.

For those working in AppSec, DevSecOps or AI-assisted security:

• How do you identify vulnerabilities that AI-driven reviews miss? If so, have you?
• What independent validation or testing mechanisms do you use?
• How do you automate repetitive security testing while keeping human expertise focused on high-risk issues?
• Have you built effective security agents or workflows that genuinely reduce manual effort?

I'd love to hear about your real-world approaches, automation strategies and lessons learned not just tool recommendations.

We're talking to vendors who keep pitching both, but I'm not sure if my company needs that because we're still a pretty small org. Can someone explain to me why we would budget for both, or if one would be preferable to the other?

Last year we brought on a tool to get runtime context on our workloads and help prioritize vulns, mostly to cut noise based on what’s actually loaded in memory. At the time it seemed like a no brainer, since direct exploitation or even chained attacks mostly can’t work against components just sitting on the filesystem.

We ran a threat modeling exercise the other day on some new systems running AI agents with tool access, and in some cases a shell. It got me thinking: can’t the agent load anything it needs at any point, unlike older deterministic code? And if so, doesn’t runtime context based prioritization fall apart completely?

Can anyone with practical experience in this area chime in? I’m at my wits end brainstorming hypotheticals with GPT.

We're looking at replacing our old VPN with zero trust access for remote staff, mostly for internal web apps and a few admin tools. The VPN works, but it gives people more network access than they really need and the policy cleanup has become a mess.

We already have SSO and MFA in place, but some of the older apps are not exactly friendly to this setup. I'm thinking of starting with one low risk app, checking logs and device posture, then moving access over in stages instead of trying to switch everyone at once.

We ended up running our pilot through Cato and it handled the legacy apps better than we expected. The staged access worked because we weren't trying to migrate everything at once.

For those who have done this, what caused the most trouble during the rollout? Would appreciate any practical lessons, especially around legacy apps and users who still need broader network access.

[ Removed by Reddit on account of violating the content policy. ]

My team stopped trusting the scanners and last month we hand-triaged every open finding on our three main services. I need to know if these numbers are normal.

That's like roughly 5% real overall with two engineers spending most of the month on this, we can’t keep doing it manually.

What filters out the noise and ranks what’s left before a human ever looks at it?

Every Monday i build the fix-these-first list and the two scanners barely agree on what belongs at the top of it, which for a long time i put down to one of them being bad.

Then i took a single host with a single CVE and diffed the two findings field by field, one said 9.8 and the other said 5.3, and the gap turned out to be three separate things stacked on top of each other.

The scanner calling it critical has no credentials on that subnet so its fingerprinting a version and cant see whether the patch landed, and the other one can, which explains a chunk of it on its own.

On top of that the word critical doesnt mean the same thing in both consoles, one thresholds at 7.0 and the other at 9.0, and one weights EPSS and known-exploited data while the other is pure CVSS.

Both vendors closed my tickets as working intended and both were right, which is the least useful outcome available.

We wrote a reconciliation rule, it runs in axonius where both scanner feeds land, and now we report a number that matches neither console.

How do others handle this, and does anyone have a method that survives scrutiny.

Hey guys, I’ve recently been reading papers that use LLMs to understand code logic and infer security-related semantics from source code and comments.

I’m curious how people with hands-on experience in static analysis or white-box security testing view these approaches.

1. Can LLMs actually help overcome limitations of traditional static analysis, such as complex inter-procedural data flows?

2. How reliable is LLM-based code understanding? Could generating multiple possible interpretations and verifying them work? If so, how would you validate them?

3. For agent-driven static analysis, how do you ensure reasonably consistent results across multiple runs on the same codebase?

For those who have experimented with LLM-assisted code analysis, what have you found genuinely useful, and where do these approaches fall short?

Looking into securing AI coding agents on developer machines, mainly around access to local credentials, internal APIs and cloud tools. Bay is one of the options I’m checking out for visibility into what agents are doing and blocking actions outside their intended permissions. Has anyone used it for this? How well does it work without interrupting normal dev workflows.

For teams managing PKI across a mix of on-premises servers, cloud workloads, and internal applications, how do you identify certificates that aren't already tracked by your central certificate inventory?

I'm particularly interested in certificates issued by internal CAs, self-signed certificates, and certificates deployed manually by individual teams. These can be easy to miss if discovery relies only on the systems connected to your certificate management platform.

I've been looking into approaches to certificate lifecycle management and cryptographic discovery, including work in this area by companies such as Encryption Consulting. I'm trying to understand how these approaches translate into day-to-day security operations rather than just what the tools promise.

Do you get reliable coverage through authenticated asset discovery, network scanning, CA inventory audits, or a combination of these methods?

Also, how do you distinguish between a certificate that's simply missing from the inventory and one that represents an actual security risk, such as an unexpected certificate, weak configuration, or an untracked private key?

I'd appreciate specific technical approaches that have worked well in larger environments, including any limitations you've encountered.

Everyone worries about people pasting into chatgpt. For us the problem was access. Someone wired an agent into the drive to save time and it could read every client's folder, the one it needed and all the others. Blocking the consumer tools did nothing there as the agent was approved.

We scoped what each AI thing can reach and a co worker only sees the records for the job its doing and the rest stays invisible to it. How are people governing their AI tools and agents can touch, short of locking it all down?

Our team is evaluating data security posture management platforms, but our strict zero-egress requirement is making it tough. A lot of modern tools seem to force you into multi-tenant SaaS.

We have sensitive internal files and database records that cannot leave our network perimeter under any circumstances. Sending raw payload data out to a vendor cloud is an absolute non-starter for our security architecture board.

For anyone managing strict data residency requirements, what are the best Varonis alternatives you have actually deployed on-prem or in self-hosted environments?

Been asked to lead attack surface discovery and the first thing I see is CMDB, cloud inventory, DNS all disagree on what we own externally. we are lining up a poc for a few ASM tools, same limited seed list for each, and we keep quiet about some subsidiaries and vendor managed infra we already know about. Idea is to see who can link unknown asset discovery back to us with decent attribution instead of just scanning whatever we fed them

If you have done this kind of internet facing assets poc, how did you test that the surprise assets really belongs to you and not random noise?

Im just curious to get people's thoughts. In regulated environments... why do people think so highly of pentests and so little of compliance assessments, when they both do the same thing: determine if an organization is meeting its controls?

In all of the pentest engagements I have sat in, most of the findings are the same (unpatched server, app not upgraded, admin account creds cached on a box, legacy protocol not disabled). If orgs are not patching servers (or maybe they have a legacy box not being patched)... that would normally end up being caught on both engagements.

Both pentests and assessments are point in time. Pentests for my environment have typically been higher cost and only cover the technical side. So why do we look more favorably at one versus the other?

Weve had a hardening project open for three quarters now. The scanning half was easy and the cutting half keeps getting handed back, because no service owner wants to sign off that removing a package is safe. Im looking at tooling that produces runtime evidence for what an image touches so the decision stops being a judgement call. Six teams and no central platform group makes this political more than technical. How did you get service owners to accept a slimmer image?

For agents that can call tools, access internal data, send messages or change things in other systems, how are you putting guardrails around them?

I’m trying to understand where policy gets enforced, how teams handle prompt injection and sensitive data and where all of that shows up for security afterward. Are you handling this inside each app, through the existing security stack or with a separate layer for AI traffic?

For ppl running ai endpoint security tools alongside a normal endpoint detection and response EDR stack, how do you handle the overlap in practice? I am especially interested in what gets flagged that EDR alone missed, and how much manual tuning it took to get the false positive rate down to something a SOC can actually act on. The harder question is what happens once agents start running with regular user permissions instead of a locked-down service account. That single change seems to break a lot of assumptions baked into older endpoint tooling, since the behavior looks legitimate from a credentials standpoint even when the action itself is not.

About a year before a major public-sector cyber incident, my colleagues and I accidentally discovered a security issue that could potentially expose personal information on a very large scale.

We worked with one affected party to fix the issue, but realized the underlying problem could exist elsewhere. We subsequently sent an anonymous warning through an official government reporting channel, explaining the risk and recommending that they review the relevant API and access controls.

A major incident later occurred that may be related. I don't want to claim it was the same vulnerability, or that the warning was received or acted upon, but the system and access point is the same.

I still have a copy of the warning and a few other documents, but most other supporting material was destroyed later because we believed the issue had been resolved.

From an infosec/responsible disclosure perspective, what can a surviving copy of such a warning reasonably establish, and what additional metadata or corroborating evidence would make it more credible?

I'm also interested in what should be redacted or preserved before showing it to journalists.

I'm deliberately leaving out the organization, country, vulnerability details, and identifying information.

Every environment I've worked in has a load balancer or door controller or UPS that sends its own idea of syslog and nobody ships a parser for it. Right now it's our door controllers, whose messages change shape every firmware update, so failed badge events stop alerting until I patch regex nobody else on the team can read. Is there a saner way to keep parsing for those boxes from breaking or is hand-rolled regex just the job?

Security testing today usually means scanners in CI, periodic human pentests, or carefully limited tests against staging or production. I’m curious whether another model will become normal: a disposable “attack twin” of the current production environment.

The idea would be to generate an isolated environment from the same deployment artifacts, infrastructure-as-code, IAM model, network policies, and application configuration as production. Real secrets and customer data would be replaced with safe equivalents, while identities, tenants, service relationships, and external integrations would be reproduced or simulated as accurately as possible.

An AI security agent could then use browser, API, shell, and network tools to attempt exploitation, privilege escalation, lateral movement, destructive actions, and controlled exfiltration. Every action would be recorded, and the environment would be destroyed afterward.

This would not be ordinary staging: it would be created per test, derived from the current production configuration, isolated for adversarial testing, and designed to be compromised.

For people working in DevSecOps or AppSec:

• Is this meaningfully different from the staging or ephemeral environments you already use?

• Which parts of production would be hardest to reproduce faithfully?

• What evidence would you need before trusting a finding from the clone?

• Where would this fit: nightly testing, a release gate, or between human pentests?

• What do you use today for attacks that are too risky to run against production?

I’m interested in practitioner experiences and objections, especially from anyone who has tried cyber ranges, production-like security environments, or autonomous pentesting.

I saw a few posts discussing how more people are giving AI agents access to real tools and business systems, and it got me thinking about how people are actually handling the security side of it.

Personally I have been trying to understand the best way to give agents access to things like emails, APIs, DBs etc without giving them too much access. There are things like readOnly access, approval gates, limiting permissions, monitoring what they do etc but not sure what ppl are actually using in practice.

I am wondering 3 main things:

• People who are already using AI agents how are you limiting what they can access/do
• How are people testing or controlling agents once they are running in production

OR are you just giving them access and hoping they dont decide to do something crazy???

Feeling overwhelmed and looking for some help with how my team should prioritize DSPM findings when it seems like our company's data security is being held together by a duct tape and chewing gum. Is there a general best practice for how we should be working through this never ending list?

Going through breach reports from the last year and it's the same story over and over. Leaked API tokens and OAuth apps nobody remembered approving. Nobody phished a person, just found a key under the mat...

Are non human identities the easiest way in now and what are you doing about the ones nobody owns?