Development vs. Security: Who is Responsible for AppSec

Security is no longer just a SecOps job. It’s a business requirement that all relevant stakeholders must collectively fulfill. Developers must ensure that they have security top-of-mind while designing products and writing code. Security teams must collaborate with the developers during all the stages of the SDLC and ensure that the proper security controls and policies are being implemented.

Shifting security left

There’s an apparent necessity to bridge the gap between development and security teams.  Security considerations need to be pushed to the left of the SDLC – developers need to be trained to make application code secure by design. Providing developers with the tools to automate and monitor security controls and checks themselves can help in this regard. There is also a need to establish procedures and frameworks for better communication and collaboration between the two teams.

Security in the cloud

Educating your developers regarding security is especially important if you’re moving to the cloud. Before an application gets deployed on a cloud platform, it must be scrutinized for any security flaws or vulnerabilities. Development and security teams must collaborate to ensure that there are no misconfigurations in the way the application is deployed on the cloud. A tiny misconfiguration (e.g., an overly permissive firewall, publicly accessible storage bucket) can potentially put your infrastructure at risk of compromise.

What (really) is a secure product?

An executive told the audience that a secure product is one that goes through a formalized, well-documented process of becoming secure. The process must be reviewable, unanimously agreed upon, and devoid of any doubts. The first step to formulating such a process involves collecting business requirements and translating them into practical action points.

Another attendee chimed in by saying that the definition of “secure” differs for different products. For example, ensuring 99.99% uptime of an internally used documentation tool may not be your #1 priority. However, if we talk about a tool that’s used by the sales team to track customer journeys, you’d have to go the extra mile to make it highly secure and available.

Security is a quality issue

Various executives agreed that security is a quality issue. Developers are often very conscious of their code quality. If security is added as a metric for code quality, developers are very likely to start taking it seriously.

A speaker remarked that developers are great at solving problems. And security is just another problem that they must solve. It’s important to let developers know that security isn’t an add-on and not an afterthought; it’s an intrinsic functional requirement. Once they understand this, they should be able to identify and collect requirements for security, just like they would for any other feature.

Security is a differentiating factor

A participant said you don’t always have to release X amount of new features to be a good product. These days you can use security and compliance as your differentiating factors. E.g., you can release a new version which announces your compliance with various security standards and regulations, such as GDPR, HIPPA, and PCI DSS.

Software security resources for developers

An exec mentioned that OWASP SAMM (Software Assurance Maturity Model) is a great resource for analyzing and improving your secure development lifecycle. It includes various best practices for governance, design, implementation, verification, and operation functions. Another great resource is Microsoft SDL (Security Development Lifecycle), which presents a refined process to develop and maintain secure software.

‍

‍