so i been comparing notes with peers at a few conferences this year and there's exactly a pattern forming that i wanted to sanity check here.

i feel like the recurring theme is genai adoption outpacing governance..like the teams stand up ai tools faster than security or legal can review them, and that gap gets harder to justify going into eu ai act enforcement later this year. and theb the second theme, and this is the one that surprised me less but still comes up in every conversation, is resourcing...like being asked to cover more surface area (browser, saas, ai, endpoint) and prove roi on the spend, without a proportional increase in headcount or a board that's willing to add line items. want to understand by posting here what's the biggest recurring theme you're hearing from other decision makers right now? trying to figure out if what we're seeing is universal or specific to our industry.

I started today with the games but i only finished level 0 using command prompt.
After a research, I think everybody say that it should be done on linux.
I asked for it on google and it says it is safe and i can complete all the levels using command prompt
Is it true? I have a task to finish all the levels this week for an internship

Hi everyone,

I'm interested in learning how security teams detect and validate potential CrowdStrike API credential leaks on public sources such as GitHub, GitLab, Paste sites, cloud storage exposures, CI/CD logs, etc.

A few questions:

1. What indicators do you typically look for when hunting for CrowdStrike API credential exposures?
   
2. Are there unique patterns for CrowdStrike Client IDs, Client Secrets, OAuth tokens, or related artifacts that help reduce false positives?
   
3. What tools or secret-scanning platforms do you use (GitHub Secret Scanning, TruffleHog, Gitleaks, custom regex, etc.)?
   
4. How do you validate whether a finding is a real credential exposure versus a false positive?

Thanks!

our incident response runbooks are built for the world of compromised servers and leaked credentials. and its funny that none of it maps cleanly onto an ai incident response case, like an agent that did something it shouldn't have because of a prompt...so not a breach. there's usually no cve and no obvious point of compromise, just an agent that got manipulated or made a bad autonomous decision inside its allowed permissions. i mean our existing runbook assumes you're hunting for an intrusion, and half the time with agents there isn't one.

want to understand from anyone who's had to respond to an agent-related incident, what did the process look like, and how different was it from a standard breach runbook? trying to figure out if we need something entirely separate or just an addendum to what we already have.

we've been pulling in more threat intel lately (KEV, EPSS) but i'm not convinced any of it is changing how we prioritize vulns in practice

rn the flow is basic: scanners fire, we get a pile of CVEs with CVSS scores (~2k new ones a quarter off Tenable), we dump them into tickets and teams work the list mostly by severity and asset type. we've bolted on KEV/EPSS flags in a few places but it still feels like "CVSS first, everything else if we remember."

i'm trying to figure out how ppl are wiring threat intel into the vuln workflow so it drives decisions instead of just being extra columns in a report. we’ve bolted on KEV and EPSS but it still feels like CVSS is making the decisions and everything else is just metadata. or exploit attempts we've seen internally but in practice it all ends up as more metadata on the same backlog.

some talk about custom scoring models that blend CVSS, exploitability, asset criticality, business context. others seem to use simpler rules like "if it's KEV and internet-facing, it jumps to the front of the queue." i've also seen this logic live in very different places: inside the vuln tool, inside SIEM/SOAR playbooks, or just hacked together w/ spreadsheets and scripts.

for ppl who've made threat intel change what gets patched first, what did you end up doing that worked?

I did a password leak check on an old email account out of curiosity and found out it had been in a breach.

Not gonna lie, I kind of brushed it off at first because I barely use that email anymore, but then I started remembering all the random accounts tied to it and realized it could still be a problem.

Spent the last hour by changing passwords, checking for reused ones, updating 2FA, trying to figure out what ancient accounts are still linked to that email.

Honestly the most annoying part is realizing how much forgotten stuff is still out there. I noticed my VPN provider has leak monitoring tool which is suppoed to alert you if your data is leaked online. Have anyone tried surfshark alert? Are there any noteworthy tools out there?

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

Hi all, I'm doing research to help upgrade my company's cybersecurity infrastructure and there is one thing (probably a few, tbh) I don't really understand yet. Where does DSPM fit into a business's security architecture? Is it closer to CSPM, access governance, or something else? Basically, what makes DSPM worth buying instead of just tightening existing controls?

Hi, I am new so pls dont mind my flair choice, if it's wrong.

So when you are handed raw event logs during an active/after an incident, do typical contracts/compliance rules actually allow you to upload those unredacted/redacted files to a third-party cloud tool for parsing and to build timeline?

The reason I ask is because I am trying to understand how much freedom contracts provide to people responsible for incident management. Although the role demands privacy, i have seen many people talking about using third party tools and some even mentioned sending whole logs to AI(sounds terrible).

Just curious to learn more about the gifts incident management roles bear before i make a decision.

budget cycle is coming up and i need to make the case for keeping our security program funded, ideally growing it. last cycle the cfo looked at my slide and asked "if we cut this in half, what breaks?" and i didn't have a clean answer that would land in that room. i still don't have one.

the stuff that's easy to measure isn't the stuff that matters. i can show vulns closed, MTTR trending down, phishing sim click rates dropping, all of it goes in the right direction on a slide. but none of it answers the question a cfo actually asks, which is: what would have happened if we hadn't spent this money and how much worse would it be.

that counterfactual problem is what gets me every time. you can't point to breaches that didn't happen. you can't quantify an incident that never occurred. so you end up arguing from activity metrics and hoping the room connects the dots between "we patched more crits faster" and "we are less likely to get hit" and that leap doesn't always land.

the closest i've come to something that holds up is showing attack surface shrinking over time, fewer known-exploitable vulns sitting on internet-facing assets, tracked over quarters not sprints. patching velocity and MTTR never survived the "so what" question in that room. exposure reduction at least maps to something real: this is what could have hurt us, and it's smaller than it was six months ago

for security leaders who've gotten budget approved on the strength of a risk reduction story: how did you frame it and what did you measure that survived the "what would have happened anyway" question?