We’ve gathered some expert opinions about how software engineers can contribute to, improve, and even lead their organization’s software security program.
Who’s in charge of an organization’s software security program? It’s usually senior executives, notes this year’s BSIMM report, because they have access to the resources and support needed to drive these programs. “Those security initiatives born within engineering and led solely by development management, by comparison, have historically had little lasting impact,” the report says.
However, BSIMM10 points out an emerging trend: In many organizations, rather than a centralized security group imposing security activities from the top down, engineers are leading software security efforts from the bottom up. “Engineering-led security culture has shown itself to be a means of establishing and growing meaningful software security efforts in some organizations,” the report says, “whereas it struggled to do so even just a few years ago.”
This paradigm shift suggests brand-new approaches to software security activities. So we rounded up some expert advice for software engineers who want to contribute to, or even help drive, their organization’s security efforts.
Calling all #software engineers! Help us answer this questions: Where can software #engineers contribute most to their organizations’ #security efforts?
—Synopsys Software Integrity (@SW_Integrity) September 17, 2019
Why do we want software engineers to lead their organization’s software security efforts? They know as much about enterprise risk management, vendor management, compliance, large-scale testing, threat modeling, and so on as the software security team knows about CI/CD pipelines, ALM tooling, sensor creation, automate-first, and so on.
Improvement comes from building bridges and having all roles teach each other the important things.
—Sammy Migues, principal scientist, Synopsys
Select and integrate security practices … with your existing software development lifecycle and development process—during an acquisition or purchase, requirements specification, architecture, design, implementation, test and deployment. The objective of including security in a defined software development lifecycle is not to overhaul an existing process totally but to add well-defined security practices and security deliverables. Security needs to be tackled in the same way that software engineers address performance and reliability.
—Julia H. Allen, senior researcher in the CERT Program at the Software Engineering Institute (SEI), Carnegie Mellon University
Can’t believe Policy, quality and metrics is doing so bad ?
The first step all software engineers can take is to help shift the mindset within the development organization that security should be thought of as a property of a system, similar to quality, rather than a viewed as a feature. When you shift the culture this way, teams start to understand that security has to be a part of the engineering process itself to get it right. That way, security bugs are discovered, triaged, prioritized, fixed, and prevented just like any other quality bug. We see cultures shift in this direction all the time when organizations make a concerted effort to turn developers into security champions.
From an automation perspective, another step engineers can take is to determine if they have the right mix of tools integrated in the right way in their software delivery pipelines to improve the quality of software that is shipped. Ultimately, organizations doing this well are removing friction from the equation so that security is a natural part of the development workflow.
—Mike Ware, managing principal, Synopsys
Threat models are a collaborative exercise where representatives from delivery teams, security, business stakeholders and possibly other parts of the business get together to talk about what assets an attacker would be after, and how that adversary might craft exploits to gain access to them. Then the team catalogs those potential threats to both the application and supporting infrastructure, and brainstorms countermeasures to mitigate them. When security and delivery teams collaborate on threat models, they are able to build security into the design of the application, discuss security impacts and trade-offs (such as cost, timeline and scope). Threat modeling helps to identify potential issues at the earliest stage of planning and design, inform the security testing plan, and most importantly, the collaboration and discussion build empathy and trust between developers, security, and business teams.
Explaining to project managers how it all works in reality
Security community is the backbone of sustainable security culture. Community provides the connections between people across the organization. Security community assists in bringing everyone together against the common problem, and eliminates an “us versus them” mentality. …
Security community can manifest as one-on-one mentoring and weekly or monthly meetings to discuss the latest security issues. It can even become a yearly conference, where the best and brightest from the organization have a chance to share their knowledge and skills on a big stage.
—Chris Romeo, CEO, Security Journey
There are ongoing arguments about the different types of programming methodologies, many of them in opposition to each other. … Software engineers have thought long and hard about how we’re supposed to work together to write code. They haven’t reached a consensus, but that doesn’t mean that the ideas aren’t better than nothing. Our ambitions are so large these days that we need dozens, if not hundreds or thousands, of people working together, and without coordination it would be chaos. You can choose whichever side you like—as long as you choose one.
—Peter Wayner, contributor, TechBeacon