Security is a matter of friction — applying as much as possible to malign actors and processes, and as little as possible to legitimate users and applications. For software developers, any additional friction can seem too much and lead to teams working around, rather than with, the processes intended to provide built-in security. Slack is a fast-moving company that needs lightning-fast development cycles and secure software. It's a situation that called for a tool they didn't have. So they built one and released it as an open source application for anyone to use.
Slack has a small development team and a seemingly insatiable appetite for new capabilities and features; it's not uncommon for the company to deploy code to production 100 times in a day. "Integrating security into products, with distinct steps and quite a bit of process, didn't align with the way things worked here," says Max Feldman, a member of the product security team at the company.
Feldman says that the development team looked at existing tools, including Microsoft's, but that the tools either added too much overhead or were oriented toward a waterfall development process. "Process can be antithetical to rapid development," says Feldman. His team's challenge was to, he says, "bring best practices into Slack while remaining "Slack-y."
The new tool is intended to help Slack implement a security development lifecycle. The application, dubbed "GoSDL," was described in depth in a recent company blog post. The goal, says Feldman, was to develop rapid and transparent development.
GoSDL is, he says, a fairly simple PHP application that allows any team member to begin the process of interacting with security. "The beginning of the process of a new feature is one where they can check whether they want direct security involvement," Feldman says. If so, the feature is flagged "high risk," not because of any actual risk but to make it high priority for security team action. If the security involvement box isn't checked, it doesn't mean that security steps aside, but their involvement begins with a series of questions about the impact on existing products and features.
Once the security team is involved it begins to put together risk assessments (high, medium, or low) for each component of the feature. The product engineer or manager is responsible for a component survey with additional checklists of potential issues.
All of the checklists and communications to this point are created in the PHP application running on the Slack platform. Once the lists reach the point of requiring action, the application generates a Jira ticket that creates the action item checklist.
"This empowers engineers and developers to evaluate their own security," Feldman says. "We'll be involved and help, but the more they're versed in security, the better we are." And that "better" is embodied in a cultural shift toward security, as well.
"One of the things we tried to do with the blog post and documentation is talk about the culture and how to use it," Feldman says, adding that the "transparency and communication are an integral aspect of this; without them it could still work but it would be much different."
It is important, he says, for security to be seen as a trusted partner in the development process rather than a blocking adversary. "The fostering of mutual trust between development and engineering is a goal. Engagement, getting familiar with people, meeting people as they join," is critical, he says.
"For us the behavioral and cultural aspects are sufficient but we've tried with the blog post to clarify how it might be useful. We want to let teams integrate the tool and make things pleasant for everyone," Feldman explains.
GoSDL is available on Github.