Communications of the ACM
DevSecOps: Resolving Disagreements Between Developers and Security Teams
In the lengthy process of building corporate IT systems or adapting already implemented software products to meet new requirements, additional, sometimes unpredictable tasks always arise. They are often related to the control of secure development and the elimination of cybersecurity risks.
The tasks of secure implementation of IT systems are covered by the DevSecOps methodology. DevSecOps is intended to improve the traditional application development process, which implies that programmers write the code, and cybersecurity specialists control its security.
Sometimes, conflicts and disputes arise between these adjacent teams. It is impossible to avoid them in the process of launching new products. And they certainly require a solution.
Developers often think that security officers exist only to stop them from doing their job. Developers regard security recommendations as overly conservative, aimed at eliminating extremely rare, practically non-existent risks.
Security people, in turn, view programmers as troublemakers who do not care about anything and are in a hurry to put their code into operation, bypassing the stage when it is necessary to make sure that the company's management, security and regulatory control are entirely complied with, and the code carries no risk.
This tangle of interests eventually gives rise to many misconceptions about how everything really happens and what to do in order to achieve the best result.
In this post, I want to highlight the main reasons that, in my opinion, cause a misunderstanding of DevSecOps operations.
DevSecOps misconceptions
Misconception 1: Compliance and security can be identified as separate stages in the process of preparing enterprise software for operation.
Real life: As practice shows, the most effective control over compliance and security requirements can be achieved when they are continuous throughout the entire process of software development and implementation. If companies treat compliance and security as a one-time event, then, in this case, they will have to be repeatedly distracted by auditors. To address their newly appeared comments and requirements, additional developers will be assigned, preventing developers from performing their primary tasks. Losses become very tangible. When security issues are not regularly worked out since the start of the project, security officers have to spend significantly more time and effort identifying and blocking possible risks. This additional work does not add any palpable product value to the software being created.
Misconception 2: To solve security and compliance problems, it is enough to equip developers with additional tools.
Real life: While the use of security and compliance tools certainly helps with many tasks, these software tools by themselves usually do not solve the underlying problem. The use of each additional tool requires appropriate qualifications, and the results obtained must be analyzed. After that, recommendations are formed and transferred to product development managers. They should take the time to evaluate their significance and set priorities for the software implementation process. The assigned tasks will need to be completed by the developers. Each step takes time and money. Moreover, the oversaturation of the ecosystem with auxiliary tools leads to an increase in its complexity. A more effective approach is to find a comprehensive solution rather than a list of tools. This will reduce potential points of failure and provide a holistic view of the company's security posture.
Misconception 3: To prevent noncompliance, it is enough to train developers.
Real life: A lot of things in the software supply chain do not happen the way coaches see them. The developers they train are primarily focused on learning new technologies and implementing them in their products. They are willing to study and implement innovative solutions without being engaged in constantly conducting security tests and reading new regulations. At the same time, implementing security requirements should become the norm for developers. It is misleading to expect them to be more diligent outside their direct duties. Information security tasks should be integrated into their job description and everyday work. This will help to bring innovation and put out resentment.
Misconception 4: To resolve disagreements, it is enough to embed a security professional into the DevOps team.
Real life: Without a doubt, having a security expert in a software development team can help programmers understand security issues better. At the same time, much will depend on corporate culture and personal relationships. In the event of disagreements, the split between the teams may, on the contrary, intensify.
Misconception 5: Small companies do not attract serious cyber criminals.
Real life: Cybersecurity threats are growing primarily not because of the size of the target company and its popularity in the market but because of the increase in the financial damage that modern cyberattacks can cause, for example, due to phishing or cell tracking apps that help steal confidential business information or personal data. No company can feel completely safe. Losses due to cybercrime can be pretty significant even for small companies.
Misconception 6: When implementing automation tools, the level of security increases and a higher level of compliance is ensured.
Real life: Many automation tools are just pointed solutions for performing specific tasks. They do not provide end-to-end automation. Of course, some parts of the software release process affected by automation become more secure if such tools are deployed. However, security flaws at other stages do not disappear. Reducing attention to them can reduce the level of security in general. It is necessary to strive to automate the entire pipeline.
Misconception 7: Implementing DevSecOps will solve most problems.
Real life: To meet the challenges of DevSecOps, it is not enough just to hire employees who know the existing requirements. Contradictions often arise between the teams of developers and security specialists, the resolution of which requires the participation of a leader. Otherwise, disagreements can turn into serious conflicts. To resolve disputes, it is not enough to simply rearrange the production stages. It is necessary to build a special culture within the company so that all participants understand that security is the number one priority for each of them.
Conclusion
In order to effectively solve the problem, it is necessary to rely on a complex, end-to-end software pipeline. In the low-risk progressive delivery environment, developers have the ability to create. At the same time, security experts get governance and safety. An end-to-end pipeline satisfies both teams and resolves possible disagreements. With a shared pipeline platform, all members of development and security teams have advanced visibility and control over the entire development process while feeling personally responsible for security. This conclusion may not be optimal for companies of all levels. Most likely, it will be suitable for large corporations. At the same time, the proposed set of misconceptions is of interest to small organizations as well. I hope this article will help them better understand their processes and more effectively address the security and compliance challenges.
Alex Vakulov is a cybersecurity researcher with over 20 years of experience in malware analysis and strong malware removal skills.
No entries found