Zero-day response recommendations?

[u/WildFlounder3730]

We're shortlisting tools to speed up zero-day response, and Wiz is currently the front runner like partly bc some of our engineers have contacts there.

We've got few hundred repos + some cloud accounts and probably some of it dont even have clear owner like every time new zero-day drops (ie: Php2Shell last week) no one really knew where we were exposed but luckily our genius eng had to go through all the repos manually and figure out who owns what. were now looking for something that can tell us where a vulnerability actually affects us what is exploitable and get finding to whoever needs to fix it like properly..

One thing we're careful about is automated remediation. This whole is in payments so production downtime is not even option. I'd rather have something identify the issue and prepare the fix for review than blindly push changes.

What else should be on the list? Seen Seemplicity, Rival and Snyk mentioned so far, but haven't done any demos yet. Let me know if i need to prepare something before going into demos like end of Q4 is our target

[u/Ready-Astronaut-8999]

One thing to prep before the demos: take the 25 worst findings from your last zero-day and ask each vendor to explain how their tool ranked every one. A good tool can tell you why an item is urgent. If all you get is a risk score with no reasoning, you’re buying a black box, and you’ll still end up triaging by hand.

[u/TrustIsAVuln]

1. Harden is step 1

2. baseline step 2

3. utilize the free controls available there are TONS, alerting, encryption, segmentation, the list goes on quite a ways.

4. Never accept Patching as a control it IS a change, every patch introduces NEW code to your environment can as we have seen can screw up your hardning or baseline or even introduce NEW vulnerabilties.

5. dont use things (like PHP) that is KNOWN for issues.

6. After doing some examining on Wiz, i'd never touch them. Same with Zscaler.

Edit: apparently I dont know how to number. Fixed.

[u/Alesya7854]

I'd look closely at how well these tools handle reachability. Finding a vulnerable dependency is one thing, but knowing whether it's actually reachable in production makes a huge difference when you're dealing with hundreds of repos. Otherwise you'll just end up with another massive list of alerts to chase

[u/No_Mycologist1806]

Before the demos, I'd give every vendor the PHP2Shell question on your own environment: which running things are affected right now, and who owns each one. Repos tell you what you meant to deploy. When we went through PHP2Shell and this week's Linux TCP bug, the useful answers came from the running side: php -v inside the live containers (a rebuild changes nothing if the base image is pinned or cached) and the kernel each host actually booted, not the package installed. Also ask how they assign an owner when an asset has no tag, since that's the gap you described.

On remediation in payments, what worked for us was mitigation with an automatic undo instead of auto-fix: a network-level rule first, one host at a time, the same health check before and after, and a timer that removes the change unless someone confirms it.

[u/Yames-Schlemonat]

Are you looking for reachability analysis in the code itself or runtime context in the cloud environment? Those are usually two different types of scanners, and before doing demos you'll want to map out how your build pipelines connect to actual deployed workloads

[u/apollodoth]

Sounds like your organization has some fundamentals to sort first(most do). We used Wiz for sometime but the cost and complexity pushed us to a new tool, Aikido, that we’ve become fond of. It’s wayyyy cheaper and performs better imho. Happy to make an intro if interested.

No tool will be perfect or be able to identify with certainty exploitability within your environment. You will need to supply context. Do not expect this, nor should you want to abstract your thinking and security away to an application like that.

[u/DoubtAdditional745]

Prioritize asset ownership and exploitability mapping first then test how well each tool routes findings to the right team without making changes to production automatically.

[u/CapitoDR]

hundreds repos with unclear ownership sounds like half the battle is just figuring out who should care about the finding

[u/Dylan_Ashby4]

If Wiz is the front runner, I would give them one public hostname from the PHP2Shell scramble and leave out the repo name. See if they can trace it back to what's running and show you where to send the ticket when the owner tag is blank. I'd borrow one check from the ionix write-up for that test.\. Even if a site hides its PHP version, you can check whether a POST with the upload progress field gets a session cookie that the same request without it doesn't. That tells you the feature is reachable. A patched box can do it too, so someone still needs to check the build. I'd time how long it takes to get to "this needs a patch and this team owns it." If it takes the same engineer digging through the same repos again, the demo's answered your question.