Slashdot Mirror


92 Percent of Enterprises Struggle To Integrate Security Into DevOps (betanews.com)

A large majority of organizations are struggling to implement security into their DevOps processes, despite saying they want to do so, according to a new report. From a report: The study commissioned by application security specialist Checkmarx looks at the biggest barriers to securing software today depending on where organizations sit on the DevOps maturity curve. The report finds 96 percent of respondents believe it is 'desirable' or 'highly desirable' for developers to be properly trained on how to produce secure code.

As developers take responsibility for the security of their software, respondents believe it is more important to educate developers and empower them than it is to educate other stakeholders in the organization like ops specialists and security specialists. However, 41 percent agree that defining clear ownership and responsibility in relation to software security remains a big challenge, and just 11 percent say they have adequately addressed the need for developer education. Software security is a boardroom issue according to 57 percent of respondents, it's a matter of business risk.

3 of 90 comments (clear)

  1. Re:Security in DevOps by FictionPimp · · Score: 4, Interesting

    We have the opposite. We have a dedicated security engineering team that works along side our engineering teams. We ensure that the security requirements are met and even pair program with the other engineers. I write code every day in my security engineering role. I build pipelines, I write scripts, build recommendations and requirements, and even sometimes get down in the day to day with helping engineering solve complex issues.

    Lastly, my masters program included a secure software design course. It was terribly lacking.

  2. unfortunatelly DevOps is used for cost cutting by kiviQr · · Score: 3, Interesting

    It is hard to DevOps with security when in most organizations DevOps means 1 person is doing a job of 4+ people (BA, Dev, QA, SysAdm). Security is usually first one to get compromized (cost, time, and scope would be considered before security).

  3. Re:Security in DevOps by adosch · · Score: 3, Interesting

    THANK. YOU. That's been my experience, too. I will say 99% of branded info-sec analysts in any organization I've been at are just certified, expensive turn-key Big brother security scanner stack, banner grabbing phrase repeaters who say a lot of buzzwords (Blue Team, Read Team, FISMA, go-go-go) like we're playing Halo charades. I'm not knocking them --- that's why I don't have or want their job, but I know it's hard to exercise security when the expertise, competency, skill and where-with-all of a developer, or sys-admin/engineer hat caring about matching CVE numbers to package releases or the developer who can code OO-Python, C++ or PHP like a mad-man but is absolutely nebulous about any sort of vector attacks, how exploiting or overflows generally work, or in-memory attacks, all that BS that exists today.

    I don't blame the people in those positions though, it's the churn of an organization and the management: whatever you're working on makes the business, and more times than none, it's bottom line get-it-out-the-door or get-it-released 100% of the time. And I feel like there also a lot less expertise and well-rounded computer-science and highly technical people these days in positions. Everyone just wants it to 'work' and never look back. Unless you're in a relatively respected position or valued enough for someone to listen to, "That's great, but we really need to focus on security here, there, over there and right here" AND actually set up a foundation for people applying, implementing and caring for security in their respective roles, this is how it will always be.

    It doesn't matter how many leaks, hacks or compromises of millions of accounts at this place or that place will be in the future, thinking and priorities to security as a whole have to change first and be just as high on the list as that new feature in you're working on in that 2-week Agile sprint.