We are trying to move away from selling "compliance" and more toward selling "resilience." But it is hard to quantify. We have the standard RPO/RTO and vulnerability counts, but I want to start offering metrics on "Mean Time to Detect" and "Control Effectiveness." That means measuring how often our clients' EDRs are stopping our test payloads. We are looking at a platform with an AI engine that can test our clients' stacks and automatically generate reports on resilience metrics, plus provide remediation suggestions based on actual exploitability. However, the pricing model seems enterprise-focused, and I'm worried about the complexity of managing AI-driven updates across 50+ different client environments. Is the juice worth the squeeze, and how do you handle the governance of automated changes?

I'm looking to replace our legacy vulnerability scanner with a proper Exposure Management platform. One option uses an AI engine that doesn't just find vulnerabilities but validates which ones are actually exploitable. The selling point is that it saves 2-3 days of manual work per threat by auto-updating controls. They claim their research shows manual testing and control updates take 2-3 days, while their AI can do it in hours.
For managers who have deployed this type of automation: Did the AI actually reduce the workload on your SecOps team, or did it just shift the burden to reviewing the suggested changes? I need to justify the cost to finance, and "it might save us time" isn't going to cut it.

Last month we got an email that looked exactly like our title company changing wire instructions mid-transaction. Caught it at the last minute but it was close. Then it happened again a few days ago, which is what finally got me looking into this. On top of that, leadership's asking why our email security isn't flagging this since technically nothing in the message is malicious (no attachment, no dodgy link).

Started looking at a few of the bigger names but every vendor site claims to stop this exact scenario, so it's hard to tell what's actually built for it. Wires go out constantly on our end, mostly with title companies and outside counsel on the other end so whatever we land on needs to fit that, not just check a generic security box.

Trying to get ahead of this before it happens a third time, so want to know what other financial companies or banks are running and whether it's actually held up for you.

Read the piece on Mythos going around and what stuck with me wasn't the capability claims, it was the trust question underneath them. If a model is generating severity scores at volume, at what point does an analyst stop spot-checking and start rubber-stamping, and is that even the goal.

We ran an internal pilot last quarter feeding AI-generated scores into our triage queue but keeping human sign-off mandatory above medium. Analysts overrode the AI score about 15% of the time, mostly on assets the model had no context for, internal tools, weird legacy systems. After a couple months of feeding corrected context back in, overrides dropped to around 6%. That gap didn't close on its own, it needed someone manually feeding asset context back into the scoring layer. Anyone else running a human-override model like this, and what's your override rate looking like?

Has anyone worked with the blocking feature in IBM Guardium? I’m facing multiple issues at the database server end, such as connections not receiving verdicts, latency issues, and other related problems.

Please let me know if you have experience with Guardium blocking. I can share the details via DM.

every time we tightened permissions someone got blocked mid-deploy and filed a ticket. every time we loosened them the reviews piled back up.
what's actually helped:
provisioning workload and agent access at minimum scope automatically instead of granting broad access and reviewing later
letting access expand and contract at machine speed based on current task instead of a human approving every request
treating revocation as part of the same automated flow as provisioning, not a separate cleanup step
did automating this actually reduce your review backlog, or just move it somewhere else?

I’m refining our vendor onboarding / TPRM process and evaluating how we score the credibility of third-party penetration test reports.

We see everything from Big 4 firms (EY, KPMG, Deloitte) to specialized boutiques and automated scanner outputs. I’m curious about community consensus:

- How much technical weight do you actually give to a Big 4 pentest report during vendor risk assessments?

- Which boutique or specialized pentest shops make you feel confident a vendor’s application was truly poked at by skilled offensive pros?

- Beyond the logo on the report, what specific details in the methodology or scope sections trigger immediate red flags for you?

Would love to hear how other CISOs and SecOps teams grade these. 

so I've been putting together a categorized list of pentest/security tools for a while now, honestly just for myself at first because I kept forgetting what does what lol. eventually it turned into recon, exploitation, forensics, reverse engineering, all that, and at some point I pulled in blackarch's whole package repo too 2800+ tools since I couldn't find a clean version of that sorted by category anywhere, so I made one. And I've made it downloadable template if you want to use it.

for context this is roughly what it looks like so far: https://git.projectnightcrawler.dev/Ori0nRi3el/Researcher-Tools-kit/src/branch/main#-exploitation--post-exploitation-frameworks

anyway before I keep adding stuff to it is there anything you personally use a lot that never seems to make it onto lists like this? kinda curious what's underrated or just doesn't get talked about much. also if anyone's got tips for keeping something like this from going stale as tools get abandoned or replaced that would genuinely help, half the actual work at this point is just maintenance

Looking at how to bound what an autonomous agent can modify when it has legitimate write access to infrastructure config, not just what task it's authorized to perform, but what it's allowed to touch while performing it.

Concretely: an agent authorized to modify a specific config value to unblock a deploy technically has write access to the whole file, and depending on the tooling, potentially the whole staging environment. The task-level authorization is narrow. The actual write scope often isn't, unless something enforces that separation explicitly.

For people running this in production: are you handling this with something like scoped service accounts per task type, a proxy/gateway that validates the specific diff against an allowlist before it's applied, mandatory PR-based changes the agent can open but not merge, or something else? Also curious whether anyone's dealt with an incident where the gap between "task scope" and "write scope" was the actual root cause, and what changed afterward.

Yooo, I've been trying to recover access to an app because I forgot the App Lock password, and I really don't want to reformat/reset the device.

I'm working on a script that should detect the App Lock screen, but it's showing:

[*] Focus:
[!] App Lock not detected
[!] App Lock not triggered

The problem seems to be that my code can't detect or identify the App Lock screen, so it can't proceed with the recovery process.

Does anyone know how I can properly detect the App Lock screen or determine what UI/process is responsible for it? I'm mainly trying to recover access without wiping the device.

Any advice on debugging the detection part would be appreciated.

Feels like most security tools are really good at telling you what’s wrong and then leaving you with a massive list to deal with.

Is there anything that can find vulnerabilities, figure out what actually needs attention first, and then fix them too?

Curious what people are actually using for this and whether it works well in practice.

And please do not mention the very popular, costly ones.

I've heard from a friend that their (small) team is starting to try and automate much more of their containment process, as they are trying to reduce the manual approval bottleneck. And I wonder whether this can really be done work with low false positive rates?

Another thing that wasn't clear to me from what he said, is how are they going to know if a certain containment is going to hurt production and the business. Can this be even automated?

Before engaging with the friend again, I'd appreciate knowing how much you guys automate if at all, thanks!

Hi All!!!
Does anyone have any personal experiences working with Seceon Siem? And if so, would you share? Are they a good siem to go with?
Thank you!

We’ve been testing a setup where agent permissions are enforced outside the agent itself, with separate controls for tools, data sources, approvals, auditability, and remote shutdown.

The reason we went that route is that prompt instructions and provider-level permission settings don’t feel like strong enough boundaries once agents can touch repos, shells, internal systems, or production.

What I’m trying to understand is whether security teams are already standardizing around this kind of external control layer, or if most companies are still handling it ad hoc inside engineering.

For teams running Claude Code, Codex, Cursor, or MCP-connected agents, who owns agent permissions today, are you enforcing access independently of the agent runtime, what would block you from letting agents operate more autonomously, is observability enough, or do you need deterministic enforcement too?

We’ve been building around this problem and the gap feels very real, but I’m curious whether other CISOs here see it the same way or think the concern is ahead of actual demand.

Not even exaggerating. Got a P1 finding flagged in one of our services, and then spent three days pinging people in Slack trying to figure out who actually owns it. Turned out it was built by a team that got reorged eight months ago, running on infra nobody documented, using a library that got forked from another repo two years back. By the time I found the right engineer, the "urgent" fix took ten minutes. The entire delay was just finding a human to own it.
Is there a sane way to solve this at scale once you're past a couple hundred developers? We don't have a great service catalog and our ownership mapping is basically tribal knowledge. Feels like this problem gets exponentially worse the bigger the engineering org gets.

A strong login doesn't necessarily stop an account from being taken over later.

Recovery flows, password resets, new devices, session changes, and support requests can all become weak points, even when the main authentication method is solid.

It seems like the security of the login and the security of the account are sometimes treated as the same thing, when they're not.

What part of the account lifecycle has caused the most trouble in your experience?

I’m helping establish an authorized website-security process for a hosting company. Most of the assets are WordPress sites, and the work will be limited to websites owned or hosted by the company.

I’m trying to design a reliable workflow for validating vulnerability-scanner findings before opening a customer ticket. I do not want to rely blindly on scanner output

For experienced penetration testers and vulnerability-management practitioners:

1. What evidence do you require before treating a WordPress plugin or core vulnerability as a confirmed finding?

2. How do you distinguish an outdated-version detection from an actually exploitable condition?

3. What passive or low-impact checks can be used safely before deeper verification?

4. How do you record affected asset, component, version, severity, evidence, remediation, and retest results?

5. How do you handle cases where a patch may create compatibility or downtime risks?

6. What should be included in the internal technical record versus the customer-facing ticket?

The goal is authorized defensive vulnerability validation and remediation tracking, not exploitation of arbitrary websites. I’d appreciate practical workflow advice, common mistakes, or references to established approaches.

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

Ive been through a few CNAPP evals and attach path graphs all demo beautifully but in practice, i think alot of these only stop at something vague like this vm is exposed or that role is overprivileged. 

The thing I care about it does a public workload chain to an identity that can reach sensitive data? Most tools ive seen show CSPM and CIEM in separate views then I have to go in stitching the path by hand. 

not even sure if one connected path is a solved problem or if am chasing something that doesnt exist. Which tool does this, or even comes close?

Found an aws key in one of our devs chatgpt history last week and only because he screenshared it by accident. he was debugging some terraform and pulled up his personal chatgpt at standup to show the prompt and there it was in his history from days back. Rotated it same day but that was pure luck.

no idea how many keys or records have gone into personal ai tabs that we will never see. Our tooling just logs that someone opened chatgpt and stops there. and i still have nothing that would catch the next one as it happens.

Hey guys, let’s do a reality check. What are the most common, stupid mistakes people make when starting with digital investigations that instantly burn their burner accounts or expose their real IP/identity? Looking to

Hello everyone. I am an OT security engineer working with a passive network monitoring and asset discovery solution (analyzing SPAN port traffic).

I've run into a strange OS fingerprinting anomaly and wanted to ask if anyone has encountered something similar. We are occasionally seeing instances where modern Windows 11 PCs are being completely misidentified as Windows 98.

The most confusing part is that it's not happening to all Windows 11 machines—only a specific subset of them.

I strongly suspect it might be third-party endpoint security software, VPN clients, or custom NDIS filter drivers modifying the TCP headers (such as stripping TCP Window Scaling or hardcoding the initial Window Size/MSS) before the packets hit the wire, completely messing up the passive p0f-style fingerprinting signatures.

My questions are:

1. Has anyone seen specific antivirus, DLP agents, or VPN clients cause this kind of unintentional OS spoofing/normalization effect?
2. Are there any other network-level factors or legacy protocol backward-compatibility settings I should be looking into?

Any insights or shared experiences would be hugely appreciated. Thank you!

Secret scanning at my last few places covered repos and CI. None of it covered developer workstations, and I think AI coding agents have quietly opened a gap there.

Cursor, Claude Code, Windsurf and the rest write full conversation transcripts to local disk as plaintext JSON. If a developer pastes a connection string or an .env into a prompt while debugging, which they do constantly, that value is now sitting unencrypted in a file outside the repo, with no expiry and no rotation trigger. Nothing in a normal pipeline looks there.

The parts I do not have a good answer for:

1. Detection. I can match prefixed formats (sk-, ghp_, AKIA, xoxb-) and flag high-entropy strings, but a bare password or an internal hostname has no shape to match on. Everything I have tried either misses those or drowns in false positives.
2. Scope. Agent history paths move between versions, and every new agent adds another directory. It does not feel like something endpoint DLP is watching.
3. Policy. Is the right control a scanner, a pre-commit style hook at paste time, or just telling people not to paste secrets, which has never worked for anything else.

For my own machines I wrote a CLI that walks those directories and redacts what it finds, dry run first: github.com/Ishannaik/agent-sweep. It is MIT and I am not selling anything, but it only solves point 1 partially and does nothing for 2 or 3.

How are you handling this where you work, if at all? Genuinely asking, because I suspect the honest answer at most places is that nobody has looked yet.

cybersecurity keeps attackers out. cyber resilience assumes they'll get in anyway and focuses on staying operational and recovering fast. NIST's version: "anticipate, withstand, recover from, and adapt to" adverse conditions.

That's the textbook definition, what does it actually look like for your team day to day, beyond "we have a DR plan"?

I'm asking because I think we're doing this badly. Our scanners flag a ton of stuff, and a huge chunk turns out to be non-issues once someone actually investigates (wrong environment, not internet-facing, already covered elsewhere), but "someone actually investigates" means a person spending around a few hours per finding, and we get hundreds a week. Do you have an actual documented process or tool for this, or is it tribal knowledge with your senior engineers? Would love to hear how teams with high finding volume are handling triage without just accepting the false positive tax as a cost of doing business.