During a recent presentation, I displayed a graphic of the Software Development Lifecycle (SDLC) with “Cybersecurity Practices” in the center of it. It was intended to illustrate that integrating security practices into all phases of the SDLC is the simple solution for ensuring security within development.  Simple, until you peel back all the roles within each phase and discover that you are now in a dangerous, risky, and costly version of cyber roulette. Each role involved in the process presents a different “security risk” round in the chamber. Every phase in the lifecycle could become the smoking “security breach” gun. So, how do you ensure that security is inherent in all roles and at all phases of the SDLC—regardless of your organization’s size? How do you prevent cybersecurity from becoming a risky game of chance inside your organization?”

Knowing the Odds

“Every time we do anything, you have to make sure you put on that security expert hat and try to think through what data is being shared, what is being opened up or exposed, what components are we integrating, and what access do they have?” states Shea Brock, Senior Software Engineer at Logical Operations.

IT professionals in small to mid-size organizations are wearing many different hats, and often personally bear the responsibility if a breach occurs. They not only have a full picture of all the systems but may benefit from integrating security holistically. For instance, product owners may be developers and can prioritize security at the ownership level and throughout development, reducing the risk of security gaps at the testing phase. Smaller organizations may also have fewer layers between development and business owners, which can streamline prioritizing security. On the flip side, smaller teams may be operating under aging development principles, or have a business strategy that prioritizes time to market over security exponentially increasing risk.

Larger organizations rely on a system of checks and balances and typically have solid cyber practices, which can place the burden more heavily on specific roles. For example, when the security of software code is the responsibility of the testing team, it lives separate from the planning and activities of the software process. A disconnect may result in an inability for the security suggested by the testing team to fit naturally into development. Resolving this can extend the development timeline and create animosity between teams.

Beating the Odds

By creating a software development culture where all phases and roles within the SDLC are held responsible for cybersecurity, organizations can minimize time to market and create a positive culture of secure coding regardless of size.

“I feel that security considerations need to be an inherent part of any development culture,” Stephanie Miller, Lead Software Engineer at General Code states. “Even if the devs are not themselves security experts, they need an awareness of both the security needs of the data and application as well as common threats and their mitigation techniques.”

Validating that developers are coding securely, that product owners have a knowledge of basic security concepts, and that stakeholders are aware of security by design concepts can be a daunting task for organizations. We discussed last week how stakeholders can tackle the task with education, compliance and leading by example. For developers and test team candidates it is essential that organizations can validate their ability to code securely and validate secure code.  To do this organizations can invest in developing assessment tools themselves or save resources by using industry-recognized certifications such as CertNexus’ Cyber Secure Coder as a tool to validate knowledge and skills to integrate into a cyber secure development culture. Certifications should validate a development teams ability to do the following:

  • Identify the need for security in software projects.
  • Eliminate vulnerabilities within the software.
  • Use a Security by Design approach to design a secure architecture for your software.
  • Implement common protections to protect users and data.
  • Apply various testing methods to find and correct security defects in your software.
  • Maintain deployed software to ensure ongoing security.

By focusing roles and the individuals responsible for the SDLC adds another building block to the cyber cultural change.

CSC Readiness Assessment