u/Remarkable-Bet9533

We take card payments so we are in PCI scope and 6.2.3 is the one that caught us on the last assessment. Custom code must be reviewed for vulns before release, whether automated or manual.

Our QSA did not care that the change went through the pipeline with a clean scan. She wanted the review records and asked to see what our SAST was tuned to look for. We did not have either in a form we could hand over. Ended up spending the back half of that week screenshotting findings and writing up after the fact what the scanner checks for.

The scan itself is fine but turning its output into evidence an assessor accepts is all manual right now. For people who have been through an assessment, what are you running that does the code review and produces records mapped to the control?

For every plan we run, it comes back with a couple hundred findings and by now the team just scrolls past them. Tags, an encryption default that is fine for us and some rule for a threat model we do not run. Mostly noise, so people stopped reading it.

Considering we also don't block on any of it either as we tried failing the build once and people started slapping auto approve on everything to get past it. That experiment lasted about a sprint.

Then a couple weeks back a PR opened a security group to the world. It was in the plan output, way down under a pile of tag warnings and two of us approved the PR without catching it.

Now I am trying to work out the small set of things that should hard fail the build, public ingress, a wide open SG, encryption or logging switched off, then let everything else just be a report. How do you all decide what makes that list without it slowly growing back into the same wall of noise?

I handle security for a mid size healthcare provider with a handful of sites plus a lot of remote and telehealth staff. Two things keep me up and they are related.

1. is vendor access. Every piece of clinical gear comes with a vendor who needs to remote in to service it. The imaging system, the lab analyzers, the infusion pump fleet, each has a support contract that assumes we will let them reach the device. Today that is a mix of one off VPN accounts and a couple of jump boxes and half of them are standing access that never gets turned off. Any one of those is a path to systems with patient data on them.

2. The devices themselves. Half of what is on our clinical network cannot be touched. It runs an old embedded OS, it is FDA validated so we cannot patch it freely and it was never designed to be on a network at all. I cannot put an agent on an infusion pump.

What I want is to let a specific vendor reach one specific device for a service window, and to segment the clinical devices so a compromised one cannot wander to the EHR. Without disrupting care because none of this can take a system offline during a shift.

For the health IT people who solved the vendor access and device segmentation problem under HIPAA, what are you running. What holds up in a hospital?

An assistant wrote a chunk of our Terraform. It read clean, been approved and it had a security group open to the world on a port that had no reason to be public. The diff looked fine, the person who prompted it did not clock the CIDR and neither did the reviewers.

Luckily, a pre apply scan caught it. The config was syntactically perfect and quietly wrong, which is the exact thing eyes slide over.

What are you gating on before apply, is it advisory, does it really block? Advisory did nothing for us until we made it a hard gate.

The keyv and cacheable packages got popped this week, that is the Shai-Hulud worm going again, sixth time this year by my count. Same play every round, a maintainer token gets stolen, a malicious postinstall runs, it grabs more tokens and republishes itself further down the tree.

And surprisingly there’s little changes on our end between these. Most teams, mine included until recently, still run npm install in CI with postinstall scripts on, pulling packages fresh every build. One popular dependency upstream gets compromised and it is in our image before a human reads a changelog.

We pinned lockfiles and told ourselves that was supply chain security. It is not, infact it happily pins you to the compromised version. In your pipeline, what are you running that would have stopped this specific one?

Doing the container side of a FedRAMP effort and someone dropped a link to a catalog of hardened images with FIPS and STIG tagged variants, free, no account. My first thought was that "free" and "FedRAMP-relevant" do not usually sit in the same sentence, so I am trying to figure out what I am not seeing.

The images pull fine. The STIG ones reference an OpenSCAP scan, the FIPS ones reference validated modules. On paper that is a pile of work I would otherwise be doing by hand off UBI, so naturally I do not trust it.

Though I can't judge from outside how it holds up once an assessor starts pulling threads. Does a free image with a FIPS tag carry the same evidence a paid one would or is the tag doing more work than the certificate behind it can support. And if the free tier is not on a guaranteed patch timeline, does that on its own turn into a finding down the line.

Anyone taken free-tier hardened images into an actual package and had a 3PAO accept them? Trying to tell whether this is a trap I will regret at assessment or an actual shortcut.

Doing an audit before a big refactor and what stopped me was how much is running that no module owns. Not drift exactly, more resources that got clickopsed during an incident years ago and quietly became load bearing, plus things left behind when a stack got partially destroyed and a few resources survived on dependencies.

Rough count is a few hundred. Some are obviously dead. plenty are ambiguous, an EBS volume thats detached but somebody might have been keeping it deliberately, that sort of thing, and the person who would know left 2-3 yrs ago.

Importing it all into state sounds sensible until you weigh the effort against just deleting things and finding out what breaks, which is not something I can propose to my manager with a straight face.

How are you handling the archaeology part of this. Mostly I want to know how you decided what was safe to remove, the tooling side I can work out myself.

I've run awareness programs for years and ive come round to thinking the click-rate number leadership loves is mostly noise. People learn the rhythm of your simulations so the rate drops over time, without anyone being one bit safer against a real targeted attempt built for them specifically.

Report rate earns its place, basically how fast the weird email reaches the SOC, because that buys you early warning when a campaign is hitting several people at once.

And I'd go further, for the really well-made stuff, a compromised supplier or a clean impersonation with no payload at all, training isnt even the right control. you cant train someone to distrust an email that looks completely normal, thats a detection job, not something more awareness training is going to fix.