Understanding Development Work Practices Allows Security Teams to Speak to Developers Using Terms They Understand
Buckminster Fuller famously said that giving people a tool will shape the way they think. Similarly, when it comes to development teams, understanding how development tools work can provide a valuable window into the developers thought process. Security teams can use these insights to better advance their agendas and get vulnerabilities detected and fixed faster.
Security teams understand the risk associated with fielding vulnerable applications, but they need the support of the DevOps team to build secure applications and address identified security issues. This puts them in the situation of needing to influence the behaviors of these teams. Understanding how DevOps teams work and acknowleding the tools they use to accomplish their goals allows for security teams to tailor their message and best shape the behavior of developers for mutually-successful outcomes. Security professionals can start by learning the answers to several questions.
How Do Developers Track Their Workload?
Developers typically track their work load in defect tracking or change management systems such as Atlassian JIRA, Bugzilla, HPE Application Lifecycle Management (ALM) and IBM ClearCase. These systems manage the various types of work that developers must accomplish – new features, bugs, and performance issues, and the systems allow for the assignment, scheduling and tracking of these various tasks. Some systems are targeted at teams using specific development approaches such as Agile, but each of these can be customized to better model the development practices of a given team.
A key difference between security and development teams is that security professionals care about vulnerabilities and developers care about bugs. The critical point for security teams to understand is that developers will likely not care about vulnerabilities until those vulnerabilities are being tracked in in their bug tracking system. Testing report PDFs and Excel spreadsheets are common tools for reporting and tracking vulnerabilities in the world of security, but developers do not speak PDF and they do not speak Excel spreadsheet – they speak defects and change orders.
For security teams to make progress in addressing vulnerabilities, their first priority should involve getting the vulnerabilities they care about translated into defects or changing requests that the development team will track. This typically requires a conversation between security teams and a representative from the development team, but crossing this boundary helps to remove friction from the remediation process. Reducing this friction makes it easier for developers to start acting on addressing vulnerabilities and harder for them to justify inaction.
Where Do Developers Spend Most of Their Time?
Developers spend a tremendous amount of their time in their Integrated Development Environments (IDEs). This is where they write and test code and save code updates back to version tracking systems. Common IDEs include Microsoft Visual Studio, Jetbrains IntelliJ, and Eclipse. The objective for security teams is to get information about application security integrated into these environments to further reduce friction from the remediation process. If developers can track down the location of vulnerabilities in code and receive guidance on addressing these vulnerabilities without leaving their IDE, they can fix vulnerabilities faster.
How Do Developers Test Their Code?
A critical shift that occurs as development teams move to embrace Agile methodologies and DevOps practices is that toward automated testing. As the pace of development and releases escalate, development teams must be able to quickly “smoke test” new builds of software to have confidence that recent changes have not broken previously-developed functionality. Development teams use unit testing to validate the quality of individual code functions and integration testing to validate the correctness of user-exposed functionality. These automated tests allow developers to add new functionality and make changes to existing functionality while maintaining a level of confidence that their changes have not broken the application. A common unit testing toolset is the xUnit framework and a common tool for building functional and regression test suites for web applications is Selenium. Security representatives would do well to look at the sort of automated verification approaches that development teams are using and look for opportunities to extend those checks to involve security.
How Do Developers Automate and Orchestrate Common Processes?
There are several steps typically involved in a development team taking the latest results from their development, turning that into a new software build, and then determining if that build is of an acceptable level of quality to consider releasing. Development teams use automation servers to coordinate the continuous integration, deployment, and delivery processes with common examples such as Jenkins and Atlassian Bamboo. These continuous integration/continuous delivery (CI/CD) pipelines are a critical tool for development teams looking to quickly create new stable builds of their software projects. In addition, smart security professionals learn to take advantage of these automation efforts to implement application security testing that occurs often – providing development teams near real-time feedback about possible security issues that have been introduced to recent software builds. Successful security teams take a pragmatic view when attempting to integrate security testing into CI/CD pipelines; they need to be aware of the need for strict automation and realistic about the degree of testing that can be integrated into a typical build cycle. But when done well, integrating application security testing into CI/CD pipelines can be a huge win for security teams looking to decrease the number of vulnerabilities that get deployed to production.
What Metrics Do Developers Track and How Do They Track Them?
Many development team metrics – such as the time required to fix bugs – can be reported by the defect tracking systems. Some teams use additional tracking systems such as SonarQube to track code-level measurements like technical debt and defect density. Sophisticated development teams using these metrics to drive behavior present an excellent opportunity for security representatives to include meaningful security metrics alongside the quality-centric metrics usually being tracked.
Gaining an understanding of the tools that development teams use provides security teams with valuable insight into how developers work, how they make decisions, and the incentives that drive them. Taking the effort to learn more about development work practices pays dividends for security representatives because it allows them to speak to developers using terms they understand. It also opens opportunities for security concerns to be handled by development teams while leveraging the investment that development teams have made in their processes, tools and infrastructure. The result is that security gets more of that want – faster vulnerability detection and resolution – with a minimum of fuss and a decreased impact on the activities of the developers.