DevSecOps is Dead
ฝัง
- เผยแพร่เมื่อ 17 มิ.ย. 2024
- Take a stroll down memory lane, with a people's history of security in information technology. Major shifts in the industry have driven security transformations in every decade, and this one is no different. A tectonic shift in how we implement security is underway, because DevSecOps is dead.
In this video, Resourcely CEO Travis McPeak details the 4 historical phases of security, and the 5th emerging phase that is displacing DevSecOps.
Learn more or get started at www.resourcely.io!
00:00 Intro
01:23 Phase zero: nobody does it
04:26 Phase one: IT does security
07:25 Phase two: Security team
11:38 Phase three: DevSecOps
16:53 Phase four: Secure by default
23:15 Conclusions
👀 CyberSec here. I listened to your points & I can see why you made this video. Most of what you pointed out is true. HOWEVER, regardless of automation, we will ALWAYS require human oversight at the most basic level.
Cybersecurity in its current form will evolve to ONLY DevSecOps. All disciplines of tech (network, sysadmin, AppDev, cloud engineering, etc) will merge into one-due to automation. DevSecOps will survive them all. Ai / ML will require continual oversight.
In short, DevSecOps is the FUTURE of tech. No death in site whatsoever.
Essentially we are now building the kind of tooling and guidance for cybersecurity that we did for safety in the aerospace engineering field. It's not on engineers to remember a giant list of vulnerabilities and how to mitigate them, they have a set of standards (including test guidance for things not covered explicitly by those standards) that make sure they consider the vast majority of possible issues.
That being said, having companies actually follow those is another matter as recently observed with a certain manufacturer...
I'm starting school for CS so this is very helpful! Thank you for making this video
So, frequently rebuild all apps/containers/hosts/whatever to get "latest", (the patched versions... that are then immutable).
Move version micro-management and churn out of dev hands.
Personally a fan of this, but it does have some abrasion points IME:
- Doesn't solve for individual dev saying "I need froxbozzle 1.3.17, because my code breaks with 1.4.18. Why should my code have to work with patched versions? PROVE to me that I should have to keep up."
- ...or manager saying "Why are devs still getting tickets to maintain their software, I thought we got rid of maintain-to-CVE-reporting?"
- Or lots of angles pushing back with "but hard versions are STABLE, pinning is a BEST PRACTICE, why are we introducing risk by auto-patching to newer things."