DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Software Design and Architecture
  3. Security
  4. To Succeed, DevSecOps Must Actually Include DevOps

To Succeed, DevSecOps Must Actually Include DevOps

Don't take the "Sec" out of DevSecOps and leave the rest of the principles and values behind.

Derek Weeks user avatar by
Derek Weeks
·
Jan. 10, 19 · Opinion
Like (2)
Save
Tweet
Share
7.01K Views

Join the DZone community and get the full member experience.

Join For Free

Before implementing any DevSecOps tools, you have to embrace that DevSecOps is disruptive to the entire security tool landscape. Too many tools are just putting lipstick on a pig.

But how do you know which ones are lipstick and which ones transform the pig from the inside out? Larry Maccherone laid this out in his talk at our Nexus User Conference. If you're not already familiar with Larry, he is an industry-recognized thought leader on DevSecOps, Lean/Agile, and Analytics and currently leads the DevSecOps transformation at Comcast. In other words, he knows what he's talking about.

The problem in the DevSecOps landscape today is that people are labeling “traditional tools” DevSecOps without any DevOps principles for the tools, culture, and processes. As Larry points out, “Tools that don't give results for hours or sometimes days or lack the ability to integrate well with the dev team's other tools and practices are a non-starter. What's needed to add security to DevOps are tools that must be able to do their job within a rapid-cycle CI/CD pipeline.”

pasted image 0-2

Core to DevOps is not only closer integration between Development and Operations, but empowering each of them to know, understand, and perform in all areas. It requires culture and behavior shifts that can be difficult, but worthwhile. DevSecOps integrates security into the mix so that security is more than an afterthought and roadblock to deployment. It is present from the beginning and part of the habitual thought process for everyone, throughout every step of the pipeline.

“DevSecOps is empowering engineering teams to take ownership of how their product performs in production, including security.”

Developers need to create a habit of thinking about and building for security from the beginning. Again, this requires behavior change, and, as Larry underscored, “If you are trying to change the behavior of developers, you should be a developer yourself. Bolt-on security by security specialists won’t scale. So, security must be a primary concern of the development team.”

unnamed-6

The key is that the development team takes the primary responsibility that the product is ready to ship, but how do you get them to take ownership? Larry lays out a three-part framework for adopting new practices for a DevSecOps culture change:

Step 1: Win the Hearts and Mind of The People You Are Trying to Change

There is a cavernous lack of trust between dev teams and security teams: security is a hindrance or give us work that doesn’t matter and dev can’t be trusted to do anything.

There are three tools Larry recommends to do this:

Tool 1: The DevSecOps Manifesto

  • Build security as opposed to just bolting it on
  • Rely on empowered engineering teams more than security specialists
  • Implement features more securely rather than security features
  • Rely on continuous learning instead of end-of-phase gates
  • Build on culture change, not simply policy enforcement

Tool 2: The Pledge.

The security team needs to have dev understand these are the risks that you will expose.

We, the Security Team, recognize that Engineering Teams...

  • Want to do the right thing
  • Are closer to the business context and will make sure trade-off decisions between security and other risks
  • Want information and assistance so they are improve our security posture

Pledge to...

  • Lower the cost/effort side of any investment in developer security tools or practices
  • Assist 2x as much with preventative initiatives as we beg for your assistance reacting to security incidents

Understand that...

We are no longer gatekeepers but rather tool-smiths and advisors.

Tool 3: The Trust Algorithm

This helps to understand the influence of factors on trust and how to use them to build trust. For instance, trust is eroded by more apparent self-interest. If developers view the security requests as, “Do this for us so we can do our job and look better,” it will harm the trust they have. However, if it is viewed as, “Do this so we can stop a pubic data breach that would erode our stock value - which we both gain or lose from,” it lessens the apparent self-interest, increasing trust.

The Trust Algorithm

trust = credibility + reliability + empathy

----------------------------------------------

apparent self-interest


Step 2: DevSecOps Self-Assessment

It takes about 90 minutes. Make it easy for them to complete the steps. Pick one or two red cells that you want to turn green in the next quarter, do what it takes to help them, and put the biggest bang for the buck on the top so they know where to start.

unnamed (1)-3

Step 3: Get Management Involved

This is the last step that Larry outlines. He suggests visualizing DevSecOps maturity with a roll-up of the self-assessments. The height of green, amber, and red bars represent the number of teams in the organizations that are at that level and how much each level has changed over time. This is to shift their focus away from just vulnerability reports — they need to see positive changes. Make sure you let management set the goals and then see progress towards the goals.


unnamed (2)

If you want to explore the Trust Algorithm more, Larry penned a five-part blog series on it for DevSecOps Days.

Larry’s full talk from the 2018 Nexus User Conference includes more detail about each step — you can watch it you can watch it here.

security DevOps Trust (business) dev teams

Published at DZone with permission of Derek Weeks, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Spring Cloud: How To Deal With Microservice Configuration (Part 1)
  • Writing a Modern HTTP(S) Tunnel in Rust
  • Connecting Your Devs' Work to the Business
  • Easy Smart Contract Debugging With Truffle’s Console.log

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: