So having developers and operations collaborate only solves part of the puzzle. Some companies still have cyclical and separate security teams. DevSecOps is the collaboration between releases of all stakeholders to try to release and author secure software continuously.
It's likely a buzzword in most places of work. Automated scans and tooling are only part of the problem. Convincing a dev who believes otherwise that their framework defaults present operational and security risks can be an uphill battle, especially when neither side backs down, despite one party clearly being more experienced.
Good luck, but also be kind to yourself and dedicate 60% of the "study" time to doing, accept that some things may be job specific.
There is a lot of "devsecops" flexing in the space or people going their own way.
What you mean by devsecops?
So having developers and operations collaborate only solves part of the puzzle. Some companies still have cyclical and separate security teams. DevSecOps is the collaboration between releases of all stakeholders to try to release and author secure software continuously.
It's likely a buzzword in most places of work. Automated scans and tooling are only part of the problem. Convincing a dev who believes otherwise that their framework defaults present operational and security risks can be an uphill battle, especially when neither side backs down, despite one party clearly being more experienced.
I just added a disclaimer to the original post. Thanks for your feedback <3