After the multitude of high-profile software supply-chain breaches we’ve seen in recent years, 2023 will provide an opportunity for organizations to reassess how they approach governance of their software-development lifecycles (SDLCs). To proactively prepare for and address the shifting threat landscape, organizations will need to make some big changes in how they prioritize and allocate responsibility to secure code. There are a few areas in which organizations need to focus to prepare for these shifts—but it all begins with driving security awareness and education at the engineering front lines.
No matter which team holds the final responsibility for identifying and remediating vulnerabilities, developers must be considered key stakeholders in any application security program. For engineers to maintain applicable security controls at the development stage, they must be fully empowered in their roles as the first line of defense against threats. Any vulnerability at this stage can impact their ability to efficiently release secure code.
Even though developers are uniquely positioned to mitigate threats early on, most aren’t security experts. To gain more awareness of how today’s threats can impact both code quality and the resilience of code-development platforms, software engineers need to understand the impact of weaknesses in each phase of software development. To that end, they need real-time context on the threats and vulnerabilities that exist in each phase of the SDLC.
Rather than overwhelm developers with long, unwieldy training sessions that often are unactionable and generic, organizations should implement development platforms that deliver small coding challenges with relevant, context-appropriate lessons. This real-time knowledge-building helps developers immediately put new skills into practice so that they’re able to identify security issues as they code.
In addition to independent training, frontline engineers need to work closely alongside their security and compliance counterparts to develop policies that can be codified into the SDLC. This means adopting concepts such as policy as code and API-based security services that drive more effective workflows and increased contribution and collaboration between departments. For even more effective dev-security collaboration, the build pipeline should be the single source of truth for orchestrating the vulnerability-remediation workflow before release.
Due to the changing regulatory landscape, the time saved by bypassing controls to increase release velocity can lead to technical debt that is quickly due at the next audit. Compliance standards (such as PCI-DSS) are increasingly focused on prescriptive governance controls in software development that test for dependency vulnerabilities, design defects, and configuration errors. When a project can’t provide evidence of these controls at a monthly or quarterly review, it becomes more likely that expensive rework will be needed.
Auditors, security teams, and developers should collaborate together on a continuous-assurance model that demonstrates how the organization is meeting standards and regulatory obligations via programmatic controls. This collaborative process begins with aligning on security and compliance requirements. Next, stakeholders should determine how automated controls and DevOps tool chain artifacts will meet these expectations. From there, the goal should be to create a database of the effectiveness of the agreed-upon controls throughout every phase of the SDLC; such a database should continuously and automatically update, with logs.
The result will be a reliable chain of custody for evidence of all applied pre-deployment controls. Consequently, the build pipeline will become an asset to expediting audits.
As the broader threat landscape evolves, organizations must adopt workflows that better empower and incentivize developers to resolve vulnerabilities faster and earlier in the development process. By working within the boundaries of their pipelines, where awareness, guidance, and expectations for how to handle threats to their code have been implemented programmatically, and by reducing reliance on security resources further along in the development process, teams can ultimately deliver secure code much faster—without sacrificing release quality.
