Skip to content

Security Scanning of KaaS Code Assets

Overview

Our Security Toolbox

Our security testing strategy covers multiple aspects of application security:

  • Snyk - Static Application Security Testing (SAST) for code, dependencies, and container images. focuses on static analysis (examining code without executing it)
  • Prisma Checkov - Infrastructure as Code (IaC) compliance scanning for Terraform, CloudFormation, Kubernetes manifests, and other IaC frameworks. Ensures our infrastructure configurations follow security best practices and compliance requirements before deployment
  • Invicti - Dynamic Application Security Testing (DAST) for runtime vulnerability detection in deployed applications. Tests running applications to discover vulnerabilities that only appear at runtime, such as authentication issues, business logic flaws, and server misconfigurations

Together, these tools provide defense in depth across the entire application lifecycle, from code development to production deployment.

Security Tool Testing Type Scan Target When It Runs Primary Use Case
Snyk SAST Code, Dependencies, Containers Scheduled Find vulnerable dependencies and code patterns
Prisma Checkov IaC Compliance Terraform, K8s, CloudFormation On commit, PR Ensure infrastructure follows security policies
Invicti DAST Running applications Post-deployment, scheduled Discover runtime vulnerabilities and misconfigurations

What is Snyk?

Snyk is a developer-first security platform that helps identify and fix vulnerabilities in code, dependencies, and container images. At Novo Nordisk, we use Snyk as our primary tool for **Static Application Security Testing (SAST) ** across our code repositories in GitHub and Azure DevOps as well for container image scanning in GHCR and ECR, GitHub and AWS container registries.

Snyk is provided by the AppSec team and for documentation on its setup, access and use, please refer to their documentation.

Adopting these tools not only secures and hardens the platform, but is also a prerequisite to qualify for handling strictly confidential data on our Kafka cluster.

What We Use Snyk For

Snyk provides comprehensive security scanning for:

  • Source Code Analysis - Identifies security vulnerabilities and code quality issues in our application code
  • Open Source Dependencies - Scans third-party libraries and packages (npm, Maven, NuGet, pip, etc.) for known vulnerabilities
  • Container Images - Analyzes Docker images and their base layers for security issues and misconfigurations in GHCR and ECR

Note: For Infrastructure as Code (IaC) security scanning, we use Prisma Checkov instead of Snyk IaC. Checkov scans our AWS Terraform configurations to ensure compliance with security policies and best practices.

Getting Access to Snyk

Requesting Access

Access to Snyk is requested through novoAccess. The following entitlements can be requested based on your role and responsibilities:

  • Snyk : Tech Lead - Grants permissions to manage the Snyk organization, set up integrations, and invite new members - Only one tech lead per organization is encouraged - Use this role if you need to configure organization settings and manage team access
  • Snyk : Developer - For development team members - Allows adding new projects, reviewing scan results, fixing issues, and initiating project tests - This is the most common role for development team members - Use this role for day-to-day vulnerability management and remediation
  • Snyk : Viewer - Provides read-only permissions to view scan results and vulnerability reports - Suitable for stakeholders, managers, or team members who need visibility without making changes - Use this role for audit, compliance, or reporting purposes

Accessing Snyk

Once your access request is approved, you can access Snyk through:

Snyk VS Code plugin

To get feedback faster while you code, it is recommended to install the Snyk plugin for VS Code.

You'll find a guide on how to get it working here.

Vulnerability Management Process

1. Vulnerability Notification

Snyk continuously monitors our projects and sends email notifications when vulnerabilities are detected.

When we receive the email look especially for any critical vulnerabilities as these need to be fixed ASAP. For non-critical vulnerabilities we generally strive to address them in the next release if a fix is available.

2. Accessing the Snyk Dashboard

When you receive a vulnerability notification through email and identified critical vulnerabilities, do the following:

  1. Log in to the Snyk Dashboard
  2. Select the affected project from the project list
  3. Review the vulnerability details, including: - CVSS score and severity rating - Exploit maturity (indicates if the vulnerability is actively exploited) - Reachability analysis (whether vulnerable code paths are actually used) - Available fixes or upgrade paths

3. Prioritization Framework

Follow this prioritization approach based on Snyk best practices:

  • Priority 1: Critical Vulnerabilities
    • CVSS Score: 9.0 - 10.0
    • Action Required: Fix immediately (within 24-48 hours)
  • Priority 2: High Vulnerabilities
    • CVSS Score: 7.0 - 8.9
    • Action Required: Fix within 1-2 weeks (1 sprint)
  • Priority 3: Medium Vulnerabilities
    • CVSS Score: 4.0 - 6.9
    • Action Required: Monitor regularly and fix in next release
  • Priority 4: Low Vulnerabilities
    • CVSS Score: 0.1 - 3.9
    • Action Required: None, fix in next release and whenever a fix is available

4. Fixing Vulnerabilities

Fixing vulnerabilities can be done through Snyk itself or manually.

Option A: Automated Fix (Preferred)

  1. In the Snyk dashboard, click "Fix this vulnerability"
  2. Review the proposed fix (usually a dependency upgrade)
  3. Choose to: - Open a fix PR - Snyk creates a pull request automatically
  4. Review the automated pull/merge request
  5. Follow the usual test, change and release process after that

Option B: Manual Fix

If automated fixes are not available:

  1. Review Snyk's remediation advice in the vulnerability details
  2. Check if a newer version of the dependency addresses the issue
  3. Update the dependency version in your package manifest: - go.mod (Go) - Dockerfile (base images)
  4. Follow the usual test, change and release process after that

Option C: Refactoring

If no direct fix is available:

  1. Evaluate if the vulnerable dependency can be replaced with a secure alternative
  2. Consider refactoring code to remove the dependency
  3. Document the decision and implementation plan
  4. Track as a technical debt item if immediate refactoring is not feasible (A story for the backlog)

5. When to Ignore Vulnerabilities

Snyk allows you to ignore vulnerabilities in specific situations. This should be done judiciously and with proper justification:

Valid Reasons to Ignore:

  • Not Reachable: The vulnerable code path is not executed in your application
  • Protected by Other Controls: The vulnerability is mitigated by network policies, authentication, or other security measures
  • No Fix Available: No patch exists, and the risk is acceptable given other compensating controls
  • False Positive: After investigation, confirmed as a false positive
  • Dev/Test Dependencies: Vulnerability exists only in development or testing tools, not production

Through the Snyk UI you can click "Ignore" on a vulnerability to not be notified about it again.

What is Invicti (DAST tool)?

Invicti is a Dynamic Application Security Testing (DAST) solution that performs automated black-box security tests against running web applications and APIs. Because DAST analyzes application behaviour and output rather than source code, Invicti supports applications built with any programming language or framework and can test both public-facing and internal (CORP) services.

What We Use Invicti For

  • Runtime vulnerability detection in deployed applications and APIs
  • Finding authentication issues, business logic flaws, and server misconfigurations that appear only at runtime
  • Providing proof-of-exploitability and technical details to help developers reproduce and remediate issues
  • Integration with CI/CD pipelines, Azure Boards, and MS Teams for automated triage and tracking

Getting Access to Invicti

Requesting Access to Invicti

Access is granted through NovoAccess. You can request the entitlement named DAST-Invicti : Basic Access. Once approved, Invicti can be accessed via MyApps (search for "Invicti Enterprise").

Endpoints Configured for Invicti scans

  1. All Kafka clusters (both dedicated and public) across all environments. For production, a quarterly Invicti scan is scheduled.
  2. REST API endpoint of the kaas-pipeline-agents-task-initiator-lambda API Gateway — quarterly Invicti scans are scheduled for both VAL and PROD accounts.

Invicti scans will target the configured endpoints and report findings to the Invicti portal or integrated issue-tracking systems.

Invicti Scan and Vulnerabilities identified

1. Vulnerability Notification

Invicti will notify you of identified issues via the platform UI and through configured integrations (currently via email notification to KaaS SME and PO). Review the scan summary and the technical report for details, risk rankings, and proof-of-exploitability where available.

2. Accessing the Invicti Dashboard

  • Log in to the Invicti portal (your organization’s instance, e.g. https://novonordisk.netsparker.cloud) via MyApps.
  • Navigate to KaaS Website Group to view all the scan reports and also run a new scan when required.
  • Review the summary, then the detailed technical report for reproduction steps and remediation guidance.

3. Prioritization Framework

Use a risk-based approach for DAST findings. Example prioritization guidelines (adapt based on your team’s SLAs and risk appetite): * Priority 1 — Critical: Immediate action (within 24–48 hours). Vulnerabilities that enable remote code execution, complete account takeover, or exposure of sensitive/GxP data. * Priority 2 — High: Fix within 1–2 weeks. Vulnerabilities that allow privilege escalation, significant business logic flaws, or exposure of sensitive endpoints. * Priority 3 — Medium: Fix in a normal release cycle. Issues that have limited impact or require specific conditions to exploit. * Priority 4 — Low: Track and fix when practical. Informational findings and low-impact misconfigurations.

Note: DAST findings often include proof-of-exploitability; if a finding is confirmed, plan a retest after remediation.

Additional Resources