DevSecOps Portal

What is DevSecOps?

DevSecOps is the practice of integrating security seamlessly into every phase of the DevOps lifecycle — from planning and coding through testing, deployment, and monitoring. The term combines Development, Security, and Operations into a unified, continuous workflow.

Traditionally, security was a gate at the end of development — a separate team that reviewed finished software before release. This created bottlenecks, late-stage vulnerabilities, and a cultural divide between developers and security teams. DevSecOps dismantles that wall entirely.

The Shift Left Principle

"Shift left" means moving security activities earlier in the Software Development Lifecycle (SDLC). The further right a vulnerability is found — in staging, production, or post-breach — the exponentially more expensive it becomes to fix.

Each phase injects security — not as a blocker, but as an automated check. A failing SAST scan in the build phase stops insecure code from progressing, costing minutes to fix rather than weeks after production deployment.

Three Pillars of DevSecOps

DevOps vs DevSecOps

Security Champions Program

A Security Champions program embeds security-minded developers within each engineering team. They act as the first line of security defence — raising awareness, conducting lightweight threat reviews, and bridging communication between developers and the central security team.

• 1

  Identify Volunteers

  Select motivated developers with security interest from each team. One champion per squad of 6–10 developers is the recommended ratio.

• 2

  Training & Certification

  Provide OWASP secure coding training, threat modeling workshops, and access to security tooling. SANS GSEC or OWASP WSTG are good starting points.

• 3

  Embed in Sprint Ceremonies

  Champions participate in sprint planning to flag security requirements, and in retrospectives to review any security incidents or near-misses.

• 4

  Recognition & Career Path

  Make the role visible and valued. Security champions should have dedicated time (~20%) for security activities and a clear career growth path.

Core DevSecOps Toolchain

SSDLC Overview

The Secure Software Development Lifecycle (SSDLC) is a framework that integrates security activities into every phase of traditional software development. It is not a separate process — it is security woven into the existing SDLC fabric, ensuring that security is designed in, not bolted on.

At IT Industry, implementing SSDLC governance across enterprise banking platforms reduced security vulnerabilities by 45% and improved audit outcomes significantly. The key is consistency — every project follows the same security gates regardless of team, technology, or timeline pressure.

Phase 1: Security Requirements

Security requirements must be defined before a single line of code is written. This means translating regulatory obligations (RBI guidelines, PCI-DSS, ISO 27001) into concrete, testable requirements that development teams can act on.

• 1

  Define Security User Stories

  Write security requirements as user stories with acceptance criteria. Example: "As the system, I must encrypt all PII data at rest using AES-256 so that unauthorised access cannot expose customer data."

• 2

  Abuse Cases & Misuse Cases

  For every user story, define corresponding abuse cases — how could an attacker misuse this feature? These drive security test cases in later phases.

• 3

  Regulatory Mapping

  Map each requirement to applicable regulations — RBI IT Framework, NIST CSF, ISO 27001 controls, or GDPR. This creates the audit trail from requirement to control.

• 4

  Risk Classification

  Classify the system's data sensitivity and risk level. High-risk systems (core banking, PII-heavy) require more rigorous security controls and review gates than internal tooling.

Threat Modeling

Threat modeling is the systematic process of identifying potential security threats to a system, analysing their impact, and defining mitigations — done at the design phase before code is written. It is the most cost-effective security activity in the SSDLC.

Secure Coding Standards

Secure coding standards define the rules developers must follow to prevent common vulnerability classes. They should be enforced via automated linting in IDEs and SAST tools in the pipeline — not left to code reviewers alone.

 ✗ VULNERABLE — Never do this
String query = "SELECT * FROM users WHERE id = " + userId;
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery(query);

 ✓ SECURE — Always use parameterised queries
String query = "SELECT * FROM users WHERE id = ?";
PreparedStatement ps = conn.prepareStatement(query);
ps.setInt(1, userId);
ResultSet rs = ps.executeQuery();

Security Testing Phases

Compliance Frameworks

The Secure Pipeline Architecture

A secure CI/CD pipeline embeds automated security checks at every stage — transforming the pipeline from a fast path to production into a security validation gauntlet that blocks vulnerable code automatically, without requiring manual review for every change.

SAST & DAST Integration

pipeline {
  agent any
  stages {
    stage('Secrets Scan') {
      steps {
        sh 'gitleaks detect --source . --exit-code 1'
      }
    }
    stage('SAST — Coverity') {
      steps {
        sh 'cov-build --dir cov-int mvn compile'
        sh 'cov-analyze --dir cov-int --all'
        sh 'cov-commit-defects --stream myapp-main'
      }
    }
    stage('SCA — BlackDuck') {
      steps {
        synopsys_detect detectProperties: """
          --blackduck.url=https://blackduck.company.com
          --detect.project.name=myapp
          --detect.policy.check.fail.on.severities=CRITICAL,HIGH
        """
      }
    }
    stage('Container Scan — Trivy') {
      steps {
        sh 'trivy image --exit-code 1 --severity CRITICAL myapp:latest'
      }
    }
    stage('DAST — OWASP ZAP') {
      steps {
        sh 'zap-baseline.py -t https://staging.myapp.com -r zap-report.html'
      }
    }
  }
}

Secrets Management

Hardcoded secrets — API keys, database passwords, certificates, and tokens — in source code repositories are one of the most common and dangerous security failures. A single leaked secret can expose entire cloud environments.

• 1

  Pre-commit Secret Scanning

  Install GitLeaks or detect-secrets as a pre-commit hook. This catches secrets before they ever enter the repository. Integrate with GitHub/GitLab native secret scanning for an additional layer.

• 2

  HashiCorp Vault / AWS Secrets Manager

  Store all secrets in a centralised vault with fine-grained access control. Applications request secrets at runtime via API — never store them in config files or environment variables in plaintext.

• 3

  Dynamic Secrets

  Use Vault's dynamic secrets feature for databases — generate short-lived, unique credentials for each application instance. These auto-expire, drastically limiting the blast radius of any compromise.

• 4

  Secret Rotation Policy

  Mandate automatic rotation schedules: API keys every 90 days, database passwords every 30 days, certificates before expiry with 30-day buffer. Monitor for rotation failures with alerting.

Container & Image Security

Containers introduce unique security challenges — vulnerable base images, overprivileged containers, exposed ports, and insecure registries. Security must be enforced at every layer: image build, registry, orchestration, and runtime.

# Stage 1: Build
FROM maven:3.9-eclipse-temurin-17 AS build
WORKDIR /app
COPY pom.xml .
COPY src ./src
RUN mvn package -DskipTests

# Stage 2: Run — minimal image, no build tools
FROM gcr.io/distroless/java17-debian12
WORKDIR /app
COPY --from=build /app/target/app.jar .

# Run as non-root user (UID 1000)
USER 1000
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

Software Supply Chain Security

The SolarWinds and Log4Shell incidents demonstrated that attackers target the software supply chain — compromising dependencies, build tools, and distribution mechanisms rather than attacking applications directly. Supply chain security is now a critical DevSecOps discipline.

OWASP Top 10 Overview (2021)

The OWASP Top 10 is the globally recognised standard for web application security risks, maintained by the Open Web Application Security Project. It represents the most critical security risks to web applications, based on data from hundreds of organisations and thousands of applications.

Broken Access Control

The #1 risk. Access control enforces policies so users cannot act outside their intended permissions. Failures lead to unauthorised information disclosure, modification, or destruction of data, or performing business functions outside user limits.

Cryptographic Failures

Formerly "Sensitive Data Exposure" — this category focuses on failures related to cryptography (or lack thereof) that often lead to exposure of sensitive data such as passwords, credit card numbers, health records, and personal information.

Injection

Injection flaws occur when an application sends untrusted data to an interpreter as part of a command or query. SQL injection remains the most prevalent, but injection vulnerabilities exist for LDAP, NoSQL, OS commands, XML parsers, and template engines.

-- ATTACK: Input: ' OR '1'='1
-- Results in: SELECT * FROM users WHERE username='' OR '1'='1'
-- Returns ALL users — authentication bypassed

-- ✗ VULNERABLE PHP CODE
$query = "SELECT * FROM users WHERE username='" . $_POST['user'] . "'";

-- ✓ SECURE PHP CODE — Parameterised query
$stmt = $pdo->prepare("SELECT * FROM users WHERE username = ?");
$stmt->execute([$_POST['user']]);

Security Misconfiguration & Beyond

Cross-Site Scripting (XSS)

XSS flaws occur when an application includes unvalidated user data in a new web page. Attackers can execute scripts in victims' browsers to hijack sessions, deface websites, redirect users, or steal credentials via keyloggers.

Content-Security-Policy: 
  default-src 'self';
  // script-src 'self' https://trusted-cdn.com;
  style-src 'self' 'unsafe-inline';
  object-src 'none';
  base-uri 'self';

Shared Responsibility Model

The cornerstone of cloud security is understanding the Shared Responsibility Model — what the cloud provider secures and what the customer must secure. Misunderstanding this boundary is responsible for the majority of cloud security incidents.

Zero Trust Architecture

Zero Trust is a security paradigm built on the principle of "Never trust, always verify." It assumes breach — treating every request as potentially malicious regardless of network location, explicitly verifying identity and context before granting access to any resource.

IAM Governance

Identity and Access Management is the single most important security control in cloud environments. Mismanaged IAM is the root cause of the majority of cloud breaches. A robust IAM governance program continuously monitors, audits, and right-sizes cloud permissions.

• 1

  Never Use Root/Owner Accounts

  AWS root accounts and Azure Owner accounts must be locked away — MFA enabled, access keys deleted, and used only for the most critical account-level operations. Create named IAM users or service principals for all regular operations.

• 2

  Use Roles, Not Users for Services

  EC2 instances, Lambda functions, and containers should use IAM Roles with instance profiles — never long-lived access keys stored in config files or environment variables. Roles provide short-lived, auto-rotating credentials.

• 3

  Implement Permission Boundaries

  Use IAM Permission Boundaries and Service Control Policies (SCPs) in AWS Organizations to set maximum permissions across entire OUs. Even if a developer creates an overprivileged role, the SCP cap prevents it from being exploitable.

• 4

  Regularly Audit with Access Analyser

  Use AWS IAM Access Analyser or Azure AD Access Reviews to identify over-permissioned roles, unused permissions, and external access grants. Right-size permissions quarterly using CloudTrail data to identify actually-used permissions.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "s3:GetObject",
      "s3:ListBucket"
    ],
    "Resource": [
      "arn:aws:s3:::myapp-data-bucket",
      "arn:aws:s3:::myapp-data-bucket/*"
    ],
    "Condition": {
      "Bool": { "aws:SecureTransport": true }
    }
  }]
}

Infrastructure-as-Code Security

IaC tools — Terraform, CloudFormation, Pulumi — mean that infrastructure misconfigurations are now code bugs. Security scanning for IaC should be treated with the same rigour as application code scanning.

Cloud Security Monitoring

Cloud-native monitoring tools provide visibility into threats, misconfigurations, and anomalous behaviour across the entire cloud estate. Combined with a SIEM, they enable rapid detection and response to security incidents.