Security dogfood tastes terrible. It's expensive, cumbersome, and proprietary. Security teams grant themselves special access and special privileges. It's little wonder the temptation exists within fast-paced DevOps teams to tack security on later, working around outdated and stale security requirements instead of actually building a secure product.
Software development teams have known for a long time now they have to eat their own dogfood. After all, if they won't eat it, why should their customers? DevSecOps requires security teams to be developers, too. Outside of a dedicated security team, developers are used to this mentality. They won't use services they don't "trust"* or can't figure out how to use. We know it is difficult to sell security, but by approaching it by mandating arbitrary policies and privileges that security teams are exempted from, or at least, less encumbered by, security becomes a much harder proposition to teams. Honestly, who can blame them?
By building Security as Code, DevSecOps breaks some of these barriers down. A recent conversation with another developer, not on a DevSecOps team made this clear. When he learned our team requires MFA re-authentication every hour, he was shocked. "Developers will rebel! You can't interrupt their workflows that way!" He was even more shocked when he learned for all the DevSecOps engineers around the table, this was our policy. Our team learned to work within these limits, and while they are still occasionally frustrating, there is a minor workflow interruption and a major increase in security. Further, this is a pain we feel and feel encouraged to lessen either through our own development or by using the services of a vendor.
Eating your own dogfood extends beyond policies. The security services built by our team do not special-case our other services. Our account is graded, just as every other account is. Our account can receive a failing grade, too; although it should not be difficult to imagine the difficulty in convincing other teams to increase their security grades when the security team's score isn't leading the company. And so, our time is spent developing means to keep our team's score as high as possible. The expertise and tools can be shared with the rest of the company to help them also keep their security scores high.
Consider the scenario of a security service which monitors other team's services. If the security team does not eat their own dog food and grants themselves a backdoor to perform scans, monitor server status, etc., the security team has just made themselves a prime target with incredibly high stakes. One mistake, one Heartbleed-level flaw, and every single service monitored by the security team is at risk. Building high-quality security tools that do not discriminate will improve your security and the security of every other team in the company. Building high-quality services for general consumption is an atrophied muscle in most security teams, but is the ideal state for DevOps teams.
Go on and try your own dog food. It might taste awful now, but it's impossible to have a high-performing DevSecOps team dedicated to securing a company operate without it. By working through their own pain points, the entire company can be made safer.
*A note about trust: Outside of the security world, trust means something different. It does not mean encryption best practices are being followed and mutual certificate authentication is happening with each transaction to ensure only "trusted" users and services are allowed to connect. It means the consumer has faith the API calls they are making will succeed and return accurate data.