Rethinking pentesting for teams that ship every week
Posted by Peace_Seeker_1319@reddit | ExperiencedDevs | View on Reddit | 4 comments
one thing i’ve been rethinking lately: how we approach security in fast-moving teams...earlier, i used to think annual pentesting = baseline covered
But the more i look at how code evolves, the more that assumption breaks.
Software today is not static, it’s a continuous stream of small changes, which means vulnerabilities are also continuously introduced.
So evaluating security once a year is basically evaluating a past version of your system.... not the current one.
That shift in thinking honestly changed how i see “secure by design.” Found this article while exploring the topic, explains the difference pretty clearly:
https://www.codeant.ai/blogs/continuous-vs-annual-pentesting
Takeaway for me wasn’t “replace pentesting” but stop treating it as the primary line of defense..
Curious how others think about this, especially teams shipping multiple times a week
HolyPommeDeTerre@reddit
My first thoughts, but my brain may be out of the subject here.
I like security by design. But security is a multi layer, multi dimensional, concept. Meaning you need to have thoughtful tests at different layers.
If differs for different scale of company. Like a startup will change their DevOps setups regularly. Where big companies will have a layer of security around it already (doesn't mean there is nothing to do, but most are covered continuously already).
While scaling, you generally change the business side more (add features) than the other layers. Which is covered by multiple things already (different layers of tests, QA, reviews) which should catch most misuse of the application but you rarely check memory hacks (for example) at this level. I generally think about it at review time. And such things are generally tightly coupled to how the algorithm and general language works. So, I find it is brittle to add automated tests covering such (unless there is specific requirements for some standards to follow).
This is how I handle security but it is a matter of using the brain to find the flaws. And it's far from perfect. But at least the yearly baseline ensures the basis of what we build is safe enough and with thoughtful design we can have "gates" in the code that enforces data flow security.
Not sure it helps, not sure it's relevant. Glad to be convinced or to extend my knowledge.
ladycammey@reddit
Im shocked you 3ver thought of it as a primary line. I always thought of (good) pen testing as a way to find more obscure problems and checking your setup before launch. We sometimes plan high risk feature releases to be after it as well such as when we first allowed user content uploading.
Primary lines are meaningful development standards you actually check, code scanning, automated pen testing, and watching for CVEs in libraries with a plan for rapidly responding.
AromaticStrike9@reddit
These advertisements are so blatant. Do these morons think we don't immediately spot it?
ClideLennon@reddit
You think a team that ships weekly is moving fast?