DevSec Disconnect
Developers, Programmers, or Coders typically dislike Security and they have their reasons to do so. On one hand, developers consider security as authoritative mechanism which forces tools & processes on them. They consider security as a hindrance to product delivery. On the other hand, Security consider developers as lazy, non-cooperative, & autocratic. This phenomena is termed as DevSec Disconnect.
All these issues can’t be resolved at once but it’s good to start somewhere & take one issue at a time.
Developers Complain:
Security is getting in the way and slowing us down. They have arbitrary requirements and are acting as gatekeepers. We need to push this feature to production. We can’t delay this release to our Product Managers.
Security Complain:
Developers are lazy and are not implementing the recommendations security provided. Their code is insecure so they can’t push this feature to production. They want us to be reactive and not proactive.
How do we solve this constant battle ?
There are various ways to come to an agreement where Developers & Security both are comfortable for a common goal to achieve a secure product. Some common complains & misconceptions are discussed below:
- Security folks are not developers or coders, how can they understand what we do or how we do it
Security Engineers should learn coding if they are not proficient in programming. This would help them understand the developers point of view. At the same time this also means that developers need to be more cautious and write secure code as security folks are now better equipped to understand their code and coding methodology.
2. I don’t know how to implement Security
Secure coding training can fix this problem. Also, developers should ask security team for recommendation to a particular issue thus they can learn how to fix a particular issue and improve overall quality of program
3. Why is security so important and why so much effort & time is being invested
Developers should be made aware about the importance of Security & ROI. This can be done by frequenting sessions on security by people belonging to leadership.
4. The security program is difficult & undefined
Secure-SDLC is the best way to handle this issue, as this provides uniformity on how to approach security. Goal of security and how to achieve that goal should be communicated to the developers. Whitepaper or program statements can also help.
5. Security people change their minds all the time
Remediation & Resolution should be communicated clearly to developers. Process & procedure should be clearly stated in order to make them readily acceptable. Standards to follow should be communicated in the roadmap for the year.
6. I can’t please everyone
Developers have to manage requirements between product managers, technical managers, QA & security. To comply with what security has recommended, they might go against the immediate plans of their manager. This can be resolved by planning for security beforehand and keeping margin for security patching before release. Security team should also adhere to developer timelines
7. Security acts as a gatekeeper
Gatekeepers are frustrating because they need to control the process which in turn slows down the process of delivery. Security team also does not believe in the gatekeeping approach, and the resolution is automation, but automation is not absolute. In order to keep security flow intact final security approval, maybe at production release, is required.
8. Security is an overhead and deliveries suffers because of it
Security should always be planned in advance when writing codes & planning sprints. This gives ample time to developers & security team for secure coding & security assessments respectively.
9. House is always on fire, we never celebrate success
Celebrate security wins, even the smallest one with not just the security team or the stakeholders but with everyone. This gives them a sense of inclusion & responsibility.
10. Security tools are loud, obnoxious, and inaccurate
Optimising automated tools and removing false positives can easily resolve this and security team should take up this activity before enforcing it on developers
P.S: Above contents are based on personal experiences and would love to know about yours. Do drop your comments and we can discuss with the common good of improving Dev-Sec sync.
