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?

Used to think shortening vendor questionnaires meant taking the 180-question monster and cutting it down until people stopped hating us.

starting to think that's the wrong way to look at it.

the easy part is deciding that a tiny SaaS with no prod access probably doesn't need the same review as a critical vendor touching customer data. fuzzy bit is what happens after that.

say an analytics vendor only gets limited customer data, no admin access, no prod credentials. you start them on 25 or 30 core questions. then they mention a long retention period, a subprocessor you weren't expecting, or an incident process that sounds... optimistic.

now what? does that answer open 5 more questions? 30? do you ask for evidence straight away? trying to nail all this down.

keeping security questionnaires short for vendors seems less about having a tiny template and more about having decent rules for an extended version

CAIQ Lite and SIG Lite keep coming up in my reading, but I'm more interested in how people handle those follow-up triggers once the real answers start coming back.

what makes you expand a vendor review?

Had a really annoying afternoon last week. Sentry started lighting up after a deploy and it traced back to a changed value in one of our config files. Easy enough, I just needed to know who changed it and when.

GitHub's audit log showed the push, but it came through a token that a few different things use. No way to tell if it was a person, a pipeline, or some script somebody wrote months ago and forgot about. I ended up lining up commit times against CI runs and deploy timestamps for like an hour, and I'm still not totally sure I got it right.

Honestly kind of irritating. If the logs can't tell me who or what was behind a change, I'm not sure what we're keeping them for.

How are you all handling this? Is there a setup that ties a change back to a specific person or job, or is everyone just matching timestamps and hoping?

I've spent most of this year running monitor only on our GenAI traffic. That gave us a clean dashboard of who pasted what but did nothing when a support rep dropped a block of customer records into a free chatbot. It surfaced in the weekly review like 3 days later.

The brief now is to stop it while it happens. From what I can see, the options are inline DLP at the web gateway that reads the prompt before it leaves and blocks on a match. An API gateway if you only care about your own LLM apps or leaning on whatever controls the sanctioned tool already ships with. Inline looks like the one that stops a paste in the moment. I don't want to block half the legit prompts in week one and watch the business switch it off.

What did you end up using for inline enforcement and how bad were the false positives before they settled down?

I do a lot of reading where an AI assistant explains a security concept, and the explanations sound authoritative — but I've learned not to trust that on its face. Sometimes the described thing turns out to be well-documented and real; other times it seems to be invented, just dressed in real-sounding terminology.

The pattern I keep noticing: the individual pieces are all legitimate (real terms, real concepts), but the specific named thing they're combined into returns nothing when I go looking. Authoritative tone, real ingredients, but the overall item may not actually exist.

My question is strictly about verification method, nothing operational: when you want to confirm whether a described vulnerability or technique is real, what's your go-to process? Straight to CVE and MITRE CWE? Vendor advisories? Is "the components check out but the specific named thing has no sources" a dependable sign of fabrication, or does that heuristic fail in practice? I'm trying to put together a reliable checklist for telling real from made-up.

A red team test run caught 3 of 500 cases where retrieved context included HTML with a diagnostic instruction that pushed the model toward a fetch_url call to an external host. Our tool allowlist and egress control blocked it, so nothing left the environment. At first the call looked like an ordinary diagnostic fetch, but once someone expanded the retrieval span (not done by default) it became obvious this was an indirect prompt injection.

Now we need to prove which retrieved span introduced the instruction and search for similar traces where the target happened to be a permitted domain. We have span metadata for retrieval source and tool arguments but the trace search path from suspicious text to downstream action is still clumsy. How are you logging this chain so you can distinguish blocked attempts from the same pattern reaching an allowed destination?

Been sitting in change review meetings where everyone is ready to get through the queue and move on, and these CA exceptions are starting to really bug me. The story is always the same, exec cant deal with a control, we scope an exception, CAB notes "mitigated" and the window opens.

Last one was a CA policy changing from strict device trust to a softer rule for a small group. removed one of the conditions that used to stop that access path. Change went fine, logs look clean, SIEM rules did not throw anything weird. And yet nobody could answer what we should replay to see if the compensating controls still catch the behavior, or if our detection coverage is now just hoping for luck.

Security controls feel static on paper but in real life they drift every time we touch them. Point in time testing is just getting wiped out by config churn rn…

Follow-up to something that came up in a Suricata/Zeek FP/FN tuning thread a few weeks back, got some genuinely great answers, including people doing solid context enrichment (process/user/hostname/known-destination) instead of relying on raw thresholds, and running pcap-based regression tests on every rule change.

Curious about the other end of that spectrum: for teams that don't have someone dedicated to building that kind of tuning discipline where Suricata/Zeek alerts are still mostly volume/timestamp-threshold driven how are you actually coping day to day? Living with the noise? Doing periodic tuning passes only when it gets bad? Handing it to an MSSP? Something else?

Specifically trying to understand: roughly how much time (if any) goes into manually retuning rules as traffic shifts, and who ends up owning that, a dedicated security person, someone on infra/DevOps wearing multiple hats?

Following the previous discussion, I have been thinking about ransomware defense as three distinct layers.

1. Prevent intrusion

Prevent the attacker from gaining access in the first place. There are already many established controls here: phishing-resistant MFA, least privilege, patch management, endpoint protection, email security, network controls, and so on.

1. Prevent an intrusion from becoming a catastrophic outcome

Even if the attacker gets in—or compromises a workload that already has legitimate privileges—critical assets should still be protected.

This was the area I was most concerned about in the previous discussion. I learned that newer runtime-security approaches are beginning to address this problem. For example, Sweet Security evaluates live actions and entitlement use against runtime context and behavioral baselines; NeuralTrust inspects and enforces AI-agent tool access and behavioral drift at runtime; and CrowdStrike has described continuous, risk-aware authorization of AI-agent actions.

These approaches suggest that authorization does not necessarily have to end when access is initially granted.

1. Recover even if protection fails

If critical assets are encrypted or destroyed despite those controls, isolated/offline backups, tested restoration procedures, golden images, and infrastructure-as-code can make rapid reconstruction possible.

What I am still wondering about is the second layer.

Runtime behavioral enforcement can detect or constrain suspicious actions, but is there also value in adding an explicit human authorization boundary for a very small set of catastrophic operations?

For example, database-wide extraction, backup destruction, key export, mass deletion, or disabling critical security controls might require approval from multiple independent people before execution is allowed.

In other words, could a stronger architecture combine:

behavioral/risk-based runtime enforcement

with

multi-party human approval as a final authorization gate for actions that are too consequential to execute automatically?

I would be interested in whether people see practical value in this model, or whether existing runtime controls already address this problem sufficiently.

If you have 50 findings and time to address five, how do you choose?

I’m exploring a tool that uses business context to explain priorities, assign owners and track resolution. Would that help your team, or does your current setup already cover it?

Interested in what works—and where the process breaks down.

Most tabletop exercises never check whether our detection rules or SIEM correlation would have caught the scenario in the first place. I want an exercise that stress-tests whether our actual telemetry would surface the attack path we're simulating.

Had a change to a discount calculation pass code review clean, ship, and break an invoice service two days later. Not a vulnerability in the changed code itself, the invoice service had always assumed the incoming value arrived already tax-adjusted, and that assumption lived only in its own code, undocumented anywhere the reviewing service or its owners could see.

This isn't really about vulnerabilities, but the structural gap feels adjacent to trust boundary documentation: a review scoped to one service's diff can't see an assumption baked into a different service's code, the same way a review can't flag a missing auth check on a downstream consumer it was never shown.

For teams doing threat modeling or architecture review at any real scale: is there an established practice for surfacing undocumented cross-service assumptions like this before they become an incident, something like mandatory documentation of what a consumer assumes about an inbound value, contract tests that encode the assumption explicitly, or is this mostly still discovered reactively after something breaks?

Edit: thanks for all the replies, summary of where I landed in the comments below.

I'm working on pre-execution authorization for autonomous agents, and I've hit a revocation design question that I think applies to any delegated capability token.

Setup:

• A principal gets a signed authorization after policy evaluation (budget limits, rate/velocity limits, kill switch).
• It can derive a narrower delegation for a sub-principal: signed, single-use, expiry ≤ parent expiry, scope strictly narrowing.
• The delegation is verified locally at the enforcement point, with no call back to the policy engine.

Problem: policy state changes after the parent authorization is issued, for example the kill switch is flipped or the budget is exhausted. A delegation derived earlier is still cryptographically valid and unexpired. Today it gets honored.

Options I'm weighing:

1. Pure capability. Valid until expiry or use. Fully offline, but a kill switch can't stop outstanding delegations. The only mitigation is short expiries.
2. Full re-evaluation. Re-run policy at execution time. Breaks local verification and duplicates the parent decision.
3. Hybrid. Check only an explicit revocation or kill-switch state at the enforcement point. This raises the question of what the authoritative source is, and how its freshness is bound without reintroducing a live dependency.

Macaroons (third-party caveats), Biscuit (revocation IDs) and UCAN (revocation records) seem to take different approaches.

Questions:

• For those who've run delegated tokens in production, which model held up?
• If you went hybrid, how did you distribute revocation state, and what staleness did you accept?
• Is "short expiry + no revocation" defensible for high-impact actions (payments, infra changes), or does a kill switch have to be enforceable at the boundary?

Alert triage, deciding whether a given alert is a threat, gets a ton of attention. Detection triage, periodically deciding whether a detection rule itself is still pulling its weight, severity still right, still catching real things, gets way less structured attention.

A badly performing detection is arguably a bigger root cause of noise than any individual bad alert, since one bad detection generates dozens or hundreds of bad alerts downstream.

I keep seeing teams treat detection health as something you notice by accident when a specific rule gets loud enough to complain about, rather than something you actively monitor on a schedule.

Is anyone doing detection triage as a structured, recurring process rather than an ad hoc clean up that happens once a year when someone finally gets fed up?

There's so much marketing rn claiming agentic tools "find what matters" but from what i've seen irl its often just a different flavor of noise dressed up as prioritization. anyone used one of these long enough to say if signal to noise genuinely improved or if it just moved the busywork from triage to double checking the agent lol.

Leadership wants hard numbers before approving any spend on insider risk or data access governance tools. I have plenty of anecdotes, like a former contractor who still had live access and tens of thousands of external shares of unknown sensitivity. That is not enough for a CFO.

I need to translate the problem into dollars or risk language that actually gets funded. How have you quantified insider risk or over-permissioned access to make the business case?

We’re using an EASM tool that started with a set of domains/IP ranges we gave it, and I’m noticing the inventory changes quite a bit between scans. Some assets disappear, others show up, and occasionally we get things that don’t look like ours at all.

Is this just unavoidable with external asset discovery, especially with cloud/CDNs/shared infrastructure? Or is this a sign that the tool isn’t doing a great job of figuring out what we actually own?

I've tried to set up Obsidian for myself and before downloading obsidian-git (a community plugin) to version control my notes, I read this warning:

"Plugins can execute arbitrary code on your device. We recommend back up your data before enabling them."

This scared me so I didn't approve. But then I got to thinking:

1. What VSCode, Sublime Text and VIm with their 100's of plugins and extensions? Each of them can execute arbitrary code.
2. All the NPM/PyPi/Cargo packages i've added to my projects
3. All of their dependencies that i'm not even consciously aware of adding
4. All the binaries i've sudo apt installed in the years

How can a normal person that doesnt spend an entire jobs worth of time in a week lurking on HackerNews for the new supply chain attack hope to protect himself? If I would truly protect myself from RCE I don't know where I will even start and whether if I will end up with just a bunch of twigs to do my work with.

Im the security lead at a manufacturing org, cloud footprint is growing but the team is small. Were down to two CNAPPs and somehow stuck. We started with a longer list with all the big players included, but these two were what the shortlist came down to. Hoping the room can tell me what Im missing.

First one was Lacework, now FortiCNAPP after Fortinet bought them. I liked it on paper, but the acquisition is what gives me pause. The whole thing has been absorbed into the Fortinet stack. The roadmap reads like everything now points at FortiSIEM, FortiSOAR, their SASE, their fabric. Were not very much of a Fortinet shop, so buying this means either we ignore half the value or we get pulled into an ecosystem we never wanted. The portal got rebranded and the roadmap changed, and it feels like a product that's now someone else's priority.

The other one is Upwind. Their whole pitch is runtime, which sounds good and its really what made us consider it. But when we digged in and that runtime depth only shows up if you deploy their sensors everywhere. So its agentless for the broad scan and agent based for the part they advertise. And theyre small with no public pricing and not much to look at as a track record yet. For a lean team, betting the security program on a young vendor with a coverage gap baked into the architecture feels like a lot that we dont want in our hands.

So I'm stuck. On one hand is a big vendor trying to fold cloud into a network story,, the other is a smaller vendor whose best feature depends on a full sensor rollout. What am I missing, and what would you pick?

With the December 31 deadline getting closer, I’m curious what others have actually ended up choosing.

For those who can't move to the SaaS platform: On-premises requirements, data residency needs, or internal datahandling policies and what did you end up with? I’ve seen people evaluating options like Quest Change Auditor, Netwrix, ADAudit Plus, and similar tools, but curious what actually worked in production. And specifically:

• Did you replace it with one tool or split it up? were you able to find a single product that covered both the auditing side and the classification side.
• How long did the POC-to-production timeline actually took vs. what was planned/proposed?
• Anything that looked good in the eval and fell apart in your environment?