I recently sat down with one of our customers to discuss how their application security program is evolving after kicking things off 18 months ago. They were kind enough to share their challenges, insights, and hopes for the future. I was interested to learn that most of their challenges lie in being able to change the culture of how their teams address security and maintaining constant communication with development and security leads.
The high-level program goal was to get security on-boarded and to get developers to agree with resolving high priority issues quickly so that there would be zero vulnerabilities within the apps
Developers are now focused on remediating the findings reported by Data Theorem
1254 findings were resolved after 12 to 18 months
Prioritization takes persistence from security leads so they need to have daily, weekly, monthly follow up chats or quick meetings
Teams have restructured and now consist of 1 security lead and several developers on every team to work together to remediate
In the first 18 months, Data Theorem was used to combat all vulnerabilities that were in production. Now the team is adding Data Theorem to pre-production process with static and dynamic scans
Focus on team policy agreements. Production alerts must get immediate attention
Automatic CI/CD
Jira alerts to allow the team to be served their workflow and remediation priorities automatically (would not have been able to succeed without these prescriptive code samples)
Leverage partnership with Data Theorem to make feature changes/requests
Persistent communication and oversight of development teams to make security a priority (change of culture)
Gradually get on the path where this is automatic: coding > then scan for vulnerabilities > then jira ticket is created for teams to remediate > then approval to go to production = all automated
Show Proof: It was a low barrier to entry once we showed the Data Theorem report and had proof of the issues
Prioritize: Show the team that they only need to start with in-production app issues or vulnerabilities
Enforcement: Establish Information Security office (even if it's only one person) to enforce policies in the interest of the app user
Normalize DevSecOps: After some time, introduce penalty to business units if they do not use Data Theorem in development process. If they don’t remediate findings, the Infosec office won’t approve or certify the software update
We started by asking for too much commitment and lost developer or security buy-in to work with us. At times, we had to dial back and work to get them engaged again. Sometimes this was because our weekly stand-up meetings were too long and other times it was because we realized we needed to speak to different people in different international times zones. Another mistake we made was not being attentive to what developers need. We had to revisit our requests and decide whether we could give them more time and less alerts.
Restructuring our teams was difficult and took several iterations, but it was worth it. We had it a wrong a few times, but ultimately the structure of having one security lead per team has now worked for us to be able to introduce new changes and drive adoption faster.
Our biggest failure was thinking that we could get the teams to regularly act on the security alerts without having some kind of accountability. We did not want individuals being called out for not acting on the alerts, but when the code is already provided for in an automated Jira ticket, there is not much effort needed. So establishing our information security office is helping to shift the culture so that everyone understands that business requirements won't be met unless security is prioritized.
Reach and maintain 100% coverage for apps and associated APIs
Convince development teams to resolve the smaller issues too
Encourage all teams to leverage features such as API Discover and API Inspect so that the cloud is also secure
Start UI testing
Learn more about how our customers start and grow their appsec security programs.