Policy-as-Code

Policies are written in a high-level language, and code is entered into a policy engine that uses queries. The policy engine consumes these policies as inputs, processes them, and then delivers a query result. This result generates a decision that aligns with the policies in place to determine which type of application security testing (AST) is appropriate, when it should be used, and where.

Policy-as-code is a scripted, readable file that provides preconditions for testing a given application. These files are written in a supported programming language (such as YAML or Python) that is compatible with the tools an organization uses. The policies are enforced via API call to a CI pipeline, so security testing can be run without breaking current builds.

Key considerations for writing policy-as-code include

• Dependencies. Could testing potentially break the build or deployment? What types of findings need to be escalated to an issue-tracking system?
• Code changes. When was the change committed? What is the magnitude of the change? Does this warrant additional testing or manual code review?
• Business criticality of application being tested. Does this application handle sensitive data? Are there significant risks to downtime? What is the attack surface of this application?
  
  

In the context of application security testing, organizations can leverage policy-as-code to define the conditions for when to test, what testing tool should be used, and whether there is a need to test. By codifying these parameters, security teams can simplify the coordination of multiple AST tools and achieve precision in their testing workflows. This enables consistent, automated enforcement of security policies, and ultimately, the ability to achieve better software quality without compromising development velocity.

More specifically, enforcing policy-as-code helps in these important ways.

• It speeds up security testing. With automated policy enforcement, security testing can be triggered without manual intervention, and only when needed.
• It increases efficiency. By removing manual policy enforcement from the equation, policies can be updated and shared dynamically, removing unnecessary human elements that slow the process down.
• It helps with version control and improves visibility. Stakeholders can easily see what is happening in their operation, and automated version control allows for seamless updates or removal of updates in case of problems associated with new versioning.
• It minimizes mistakes and enables validation. With automated policies in place, errors caused by human involvement are avoided. Additionally, when policies are written in code, it’s easy to run validation activities and ensure accuracy.
   

Organizations today use a wide range of AST tools, and some can take days to provide security scanning results. Ever-increasing development speeds require application security testing tools and practices that can keep up.

Additionally, ensuring that software is compliant and secure means understanding software risk at the development level, in earlier stages of the software development life cycle. But without a cohesive testing strategy in place, organizations end up with manual scanning and code reviews, and overall, inconsistent security hygiene.

Further, integrating numerous tools across existing pipelines can be a complex and time-consuming undertaking, and can increase the risk of breaking existing build and release pipelines. If organizations can’t easily integrate their AST tooling with an existing software delivery tracking system, or prioritize security activities based on risk, security and development resources can easily become stretched thin.

These tooling challenges often result extraneous testing that adds hurdles and time lags to developer productivity. Security analysts will struggle to keep up with siloed tooling and manual reviews, and costly and potentially exploitable software flaws can go undetected due to lack of testing and broader visibility into process, decisions, and key findings. 

Policy-as-code helps overcome these impediments to DevSecOps by

• Providing continuous developer feedback loops. Policies can be enforced via API integration to directly communicate critical security activities to developers through Jira tickets or Slack notifications.
  
  
• Automating decision-making. Codifying the conditions that trigger security events based on predefined thresholds for application risk, code changes, and dependencies greatly helps reduce the friction in standardizing AppSec for agile environments. Policies-as-code eliminate the manual intervention that would normally be required to determine whether to test, and what test should be applied.

Black Duck® Software Risk Manager™ is a comprehensive ASPM solution that enables teams to

• Implement policy-driven AppSec at scale by defining and enforcing security policies that specify parameters for test execution and vulnerability management
• Unify user experience across disparate application security testing tools to simplify your resourcing and operations while improving tool consolidation across teams
• Consolidate vulnerability reporting and management across projects, teams, and tools to provide a complete picture of normalized, deduplicated, and prioritized security risks
• Simplify AppSec integration and orchestration in development workflows to integrate security workflows into existing developer toolchains and enable quick onboarding for existing projects and builds
• Optimize core application security testing with a single, unified solution to efficiently deploy, manage, and report on core application security testing functions