DevSecOps isn’t a technology in and of itself. It’s a process that offers both speed and resiliency in software creation. For government entities, this will be an invaluable tool. Already, we’re seeing agencies like the Veterans Affairs and Defense departments adopting these strategies to expedite software development while enhancing cybersecurity. However, when reviewing issues with DevSecOps implementation in the private sector, three common failure points—budget, time and people—could be equally challenging when adopting this process for government use.
These issues stem from a misunderstanding of what DevSecOps is supposed to be: a marathon, not a sprint. The time, expense and staffing put into it at the start might be intimidating. However, in the long run, these efforts will pay dividends.
Budget
The return on a DevSecOps investment will come back tenfold, but only with the right foundation. That takes proper funding. This is a step where a lot of organizations fall flat.
In one study of DevSecOps implementation challenges, budget was cited as the second most common barrier. That’s not an unreasonable concern; any major organizational change is going to come with a hefty price tag attached. Of course, that cost is complicated in a government agency, where every nickel and dime spent requires a committee-level consensus. However, if organizations want to make speed and security a priority in their infrastructure, they will have to make DevSecOps a line item in their budget.
While the front-end cost of DevSecOps certainly isn’t cheap, it’s a process that—when given the time and oxygen to grow—results in major cost savings. In fact, the Air Force reports that switching to a DevSecOps model reduces development costs by 40% on average. Getting over the budgetary hurdle requires agencies to change their way of thinking. Instead of seeking out short-term gains, they need to focus on the long-term benefits. This philosophy doesn’t just apply to budgets, either. It also offers major time savings.
Time
To get time, organizations need to make the time. Many of the concerns and solutions with the time component of DevSecOps implementation align directly with budgetary issues as mentioned above. An investment upfront is required to enjoy even more significant savings later.
There is a lot of red tape involved in changing a policy for a massive agency. It’s not just a matter of deciding to do things a new way. Instead, it requires various stakeholder involvement and approvals—all of which can be slow to come. However, if the time spent is treated as an investment in the beginning, it pays dividends in the long run.
When Veterans Affairs chose to take a DevSecOps approach, officials were able to massively accelerate their software release lifecycles. Enterprise Program Management Office Lead Dan McCune reported that the agency was able to deliver over 80% of its products within 90 days after moving to a DevSecOps strategy.
Culture is the key to driving the adoption of DevSecOps in a hurry. Veterans Affairs made a point of failing quickly when mistakes were made, and then bouncing back. Meanwhile, officials celebrated successes vocally to prove the new strategy was worth the investment of time. Of course, a strong culture is built on having the right people on board.
People
Your staff are your culture and culture is everything. Organizations must break down the walls and get cross-organizational communication going day one in a DevSecOps strategy; it will save time, money, and sanity.
Unfortunately, the government invented stovepiping—and not the good kind that keeps a house from filling with smoke. It’s the kind that isolates intelligence (a.k.a. workers) and keeps them from sharing critical information.
In a DevSecOps environment, this is counterintuitive. Developers and security experts need to understand what and who they’re developing for; they create in a silo without context. And while silos are great for reducing smoke damage, they’re not so good when it comes to innovation.
Interdepartmental working teams are a good solution to the silos that often plague government work. Getting the administrators who want the features talking with the developers building the and the security expert protecting the data is critical. With cross functional teams, all the stakeholders get a say in the development of a new product. They can even serve as the beta group for testing and refining new solutions. The key is an open, collaborative culture that encourages everyone to share ideas regardless of their background.
Government agencies that want to take advantage of DevSecOps need to give the process the time and oxygen to grow. Oxygen in this context can mean money or just freedom for workers to come up with new solutions. With the upfront investment, they gain the long-term benefits of quality, speed, and resiliency that only come with a DevSecOps approach.
Daniel Riedel is senior vice president of strategic services at Copado.
source: NextGov
