Powered by MOMENTUM MEDIA
cyber daily logo
Breaking news and updates daily. Subscribe to our Newsletter

Op-Ed: Strengthening application security with policy-as-code

Today’s businesses are not short on policy mandates and principles meant to define governance objectives for all parts of the organisation, including application and software development life cycles.

user iconFrancis Ofungwu
Fri, 04 Aug 2023
Op-Ed: Strengthening application security with Policy-as-Code
expand image

While these policies may be well documented and reviewed annually during required awareness training, they are not always easily adopted into the day-to-day workflows of developers on the engineering frontlines, however.

While documentation is critical for keeping organisations aligned on the latest policies and guidelines, it is often too abstract or unactionable in practice. For organisations to build trust into their development workflows and processes, they need to consider implementing governance objectives directly into the software development life cycle (SDLC) to reduce the likelihood of malicious or accidental cyber events.

The crucial next step to aligning development, security, and operational objectives at scale is implementing policy-as-code or the practice of programmatically applying an organisation’s risk management objectives to its development ecosystem. This tactic enables more efficient and automated security inspection and demonstrates compliance within the context of development workflows. Here are some of the benefits of policy-as-code and how organisations can integrate this practice into existing DevSecOps workflows.

============
============

Defining policy-as-code

Policy-as-code serves as a forcing function to implement required security testing into DevSecOps workflows while also significantly reducing the need for separate work streams for auditing. In practice, it requires turning security policies and testing plans into pipeline instructions, thus ensuring that necessary controls in accordance with the organisation’s security and compliance standards are applied throughout the SDLC.

This approach is beneficial for developers and security teams alike. Developers are given immediate access to crucial security policies while working within their existing DevSecOps tools and processes. This reduces their reliance on security teams and cuts down the cycle time for feedback, allowing them to work faster while still maintaining security standards. Security teams are no longer required for every security decision within the SDLC and can focus on scaling and developing proactive security strategies.

Creating security-aware developers

Although security is a key priority for organisations, GitLab’s recent research found that around half of organisations globally still see collaboration silos across developer, security and operations teams. The strains between development and security teams have been discussed for years, but what has become clearer over time is that developers aren’t given the specific, in-context guidance they need to build secure code efficiently.

While the principles behind shifting left in security work in theory, what often happens in practice is that developers don’t have quick access to qualified security decision making in real time, so hard-to-understand vulnerabilities ultimately make their way downstream to security teams. Developers can ship code faster by adopting a shared framework for policy enforcement and compliance, knowing that it adheres to organisational policy.

Implementing policy-as-code

To make policy-as-code actionable, developers and security teams need to align on predefined security processes and determine how to weave them into the SDLC while still prioritising speed and efficiency. Security teams need to understand the day-to-day software development and use that to inform how they can create policies that build the necessary security controls into workflows. Developers need to stay open-minded to the fact that each stage of the development life cycle can introduce unique vulnerabilities and adopt a holistic set of practices that makes the development process more secure.

Examples of practices for implementing policy-as-code into DevSecOps pipelines include:

  • Defining non-negotiable security scans and testing as part of the continuous integration (CI) process
  • Establishing and enforcing change management expectations within pipelines, including identifying which roles can approve code changes
  • Instituting separation of duties by ensuring expected CI jobs cannot be bypassed or dismissed in the development workflow
  • Defining test scenarios or gates in which approval or exceptions require peer review or security sign-off
  • Defining which artifacts and logs are needed during the development workflow for audit evidence
  • Enabling accountability and traceability through digital signatures that provide authenticity of code committers
  • Implementing required changes management objectives by programmatically enforcing guidelines for code reviews

Policy-as-code, like all security endeavours, is not a “set it and forget it” practice. It requires continuous focus and evaluation of processes that will evolve alongside the growing threat landscape. As with all DevSecOps practices, it’s critical to centre collaboration and transparency throughout the process. Security and speed are not mutually exclusive goals for a development team – policy-as-code can help organisations realise the value of DevSecOps.


Francis Ofungwu is the global field chief information security officer at GitLab.

newsletter
cyber daily subscribe
Be the first to hear the latest developments in the cyber industry.