DevSecOps is not meant to fail if Processes, Products backed by People with the right attitude followed by continuous learning and improvements is in place. It’s not very important how the journey starts but how consistently it improved over time.
There are a lot of fundamental principals that need to consider while you are defining the Organizations DevOps road map. But in my opinion, the following two lay the foundation of success.
- DevSecOps is not a Role
- Open by Default, Closed by Exception
image credit: Microsoft
DevSecOps is not a Role
Generally, in a project, you define the staffing requirement or onboard engineers as a ‘DevSecOps Engineers’ with relevant skills and experience to implement DevSecOps road map. But always remember
DevSecOps is not a role… it’s a Philosophy… it’s a Culture… it’s Attitude
You can start the project by considering DevSecOps as a role during the initial phase. But as this journey progress, you need to start focusing on Doing things right rather than only doing the right things.
You have to plan the transition to all the team members (also involved stakeholders as and when required) by DevSecOps SMEs in all the areas (right from continuous planning to continuous feedback). This will not only help team members to take responsibility and perform all the required actions in their day to day work, but also improves the Project DevSecOps maturity level.
Improvement of DevSecOps maturity is one of the key matrics for the stakeholders. Continuous improvement in the DevSecOps maturity helps to build confidence in terms of planning, costing, and most importantly reduce the time to the customer.
Believe me or not in today’s world time to the customer is a matter of survival for business.
DevSecOps as a shared responsibility and it needs to be owned by all the members irrespective of roles, responsiblities and skills.
Open by Default, Closed by Exception
It’s a debate that is as old as the information management industry itself. You may have the question, does everyone need access to everything, or what if someone misuses the information? So wait, please read the statement once again.
It’s Open by Default closed by exception
This concept is based on the “Need to know” principle. You will have access to all the required information, so you will be able to perform the job.
Defining information sensitivity is one of the most important tasks. Organizations need to have well defined and governed policies in place. This will help you and teams to put proper checks and controls while implementing the “Open by default and Closed by exception” policy.
Also, The “open by design” principle does not mean that just anyone can edit all information; most information will be read-only and some will be less than that. Tagging information with correct classification will help the team members to act vigilantly.
If you are concern that people will share information inappropriately outside of the organization I strongly recommend that make sure your teams are well trained and everyone understands appropriate use of policies.
Trust plays the biggest role. You need to trust the people that they are trying to do the right things for your Organization. If not then you have a bigger problem than just Information security.
If information is truly sensitive it should be secured and governed by your ECM policies. If not, it should be open to your team members.
You might have diffrent views/ suggestion. Please do let me know using Disqus section.
- Manage Azure DevOps Pipelines Variables
- Enable CI against all Branches
- VSTS Build and Release Agents
- People, Process, Product - DevOps - Build & Release
- IaC Deployment using VSTS Release and GitRepo