Models show a particular perspective to solve the problem. Imagine World Map, the map model is not the truth, the size of the countries you see on the map is not true. The map was developed to aid navigators to reach from one region to another. Eric Evans author of Domain Driven Design explains this well. For your use case, you have to design and select the model rather than fit it into the decided/FOMO model.

This blog focuses on the SSDLC model and the DevSecOps model and their gap.

SSDLC

Microsoft introduced the SDL, and Core Software Security: Security at the Source was published a decade back. At that time most of the companies were in the iterative model, a few were in waterfall mode and agile practices were in traction among companies

Secure Software Development LifeCycle (SSDLC) or Secure Development LifeCycle (SDL) is a methodology to build secure practices and tools to capture security flaws in each stage of SDLC.

The above captures the SSDLC process in comparison with the SDLC practices.

Secure Requirements

Product teams research what’s next to be built for the product and publish the requirements and set the expectations with stakeholders. Here, brainstorm on the requirements that are present and list all the abuse cases or possible threats to the proposed requirements from the product team

Owasp Abuse Case Cheat Sheet

Secure Design

As the design starts for the confirmed requirements in the form of High-Level Design/Low-Level Design/ Swim Lane Design, brainstorm or Threat Model the developed design.

Having a checklist to do a secure design will be helpful. One can design a custom checklist from Owasp ASVS. The checklist should cover the following aspects

1. Authentication

2. Authorization

3. Access Control

4. Cryptography

5. Resiliency

6. Defence In Depth

7. Logging and auditing

8. Repudiation

9. Compliance adherence

Follow the security design principles

Secure Development

Integrate static analysis tools such as SAST, SCA and secret scanning into IDE and CI

SAST - static analysis on code which replaces manual code review

SAST Tools

SCA - Captures all the third-party libraries’ vulnerabilities used in the code. Captures transient dependencies

SCA Tools

1. Dependabot ( Does not support transient dependencies, support only for npm)

2. Snyk Open source

3. Dependency Checker ( only supports minimal language)

4. Dependency Track

5. Fossa

6. ShiftLeft

Secret Scanning - Scans the code for secrets

Secret Scanning Tools

1. GitLeaks

2. TruffleHog

3. GitRob

Application Security Tools

Secure Testing

Testing the feature in pre-prod stages and foolproofing in security aspects. This is a manual cum automation process.

1. Running E2E test with the QA team. Share test cases with QA Team to be part of E2E regression tests

2. Manual Security Review, Test for logic flaws

3. Run automated scans such as Burp scans and Zap active scans as part of the security review process where you can focus on spending time on authorisation and logic flaw bugs.

Secure Deployment

After the changes/features are going to be deployed, make sure to review the configurations. The configurations can include edge configurations, CDN configurations, WAF configurations and Rate Limits.

1. Reviewing Security configurations, configuring WAFs and rate limits

2. RASP such as API Security monitoring

3. Threat Monitoring

Gaps on SSDLC

1. Focused on Development practices and tightly coupled to them. It stops on the software feature has been released.

2. Focused on Application Security

3. Does not include/have visibility over infrastructure operations in the fast-paced adoption of cloud-native technologies

4. Communication is missing in SSDLC, how do you plan, and how do you prioritize vulnerabilities in agile practices followed by the dev team? How do you scale the plan? Not having a clear plan on ownership, responsibilities and prioritisation in the plan, doing all others won’t reap you benefits. If you are not able to fix issues, the security debt will be increasing MoMShare

DevSecOps

The raise of DevOps and the adoption of DevOps culture and practices is at full pace. In the beginning, DevOps focused on solving development and operations gaps and didn’t include security into it. DevSecOps focuses on solving development and operations including the security aspects.

Ownership and responsibilities of DevOps vary depending on who owns the ops part of it. In the case of SRE, the ops part is owned by the SRE team and in the case of DevOps, the ops part is owned by the dev team. Alex explains it beautifully in the below Twitter thread.

Plan

Here, agile practices are followed religiously.

Treating Security as a Feature in planning goes a long way. Security as a feature means that security is considered in planning like a regular feature request. Get stakeholder alignment. Jeevan, Director of Product Security at Twilio explains getting stakeholder alignment in his Linkedin post.

Security is planned at this stage.

1. Plan for security fixes and have alignment with the leadership team to prioritise security issues.

2. If the plan includes design changes, plan for a secure design (covered in SSDLC Secure Design)

3. Include Security as part of the Definition of Done in agile practices

Development

After security has been planned, design and development start. Include SAST, SCA, Secret Scanning, IaC and Compliance as code in the development workflow. Drive Security Tool as code rather than manual testing methods.Understanding the branching methodology used in the company helps here. If your developer environment uses the GitFlow branching strategy or Trunk-based branching strategy., introduce Security toolsets which I have mentioned before as a passive scan depending on the branching strategy. Passive scan means that there is no quality gate involved, faster feedback for the devs to identify and fix, and vulnerabilities are not pushed to the Vulnerability Correlation platform.

Test

Depending on the branching strategy, tests are run in your CI pipeline. In the case of Trunk based, a pr is raised to the mainstream branch where all the tests would run to qualify for the release. Include quality gates and active scanning of the security toolsets. Collect all the vulnerabilities in Vulnerability Management tools such as DefectDojo for efficient triaging with Jira and deduplication support.

Release

The release focuses on the CICD pipelines. We have to include container scanning tools to scan container images as a quality gate. Trivy is a prominent container-scanning tool.Here, the build that has passed the quality gate will be pushed to a container registry such as Jfrog, ECR etc which is ready to be deployed in k8 clusters.

The below table captures the blocking criteria for the tools integrated into the CI environment

Deploy

After release passes the quality gates, depending on the deployment strategies, security should be considered.

Deploying into lower environments such as pre-prod staging environment for Quality assurance, E2E tests will be performed. In addition to the quality test, a security test will be run.

Strategies might differ in higher environments deployments. Deployments can be canary or blue/green deployments for software that has a large user base with careful rollout and rollback strategies.

Here is the stage where infrastructure changes might be done. New infrastructure or changes in existing infrastructure might be required. The new domain name should be registered in route53. This is where compliance plays a huge role. The new infrastructure or changes should be compliant and well monitored

Deploy Tools

1. CNAPP - Wiz. CNAPP is going to cover the entire toolsets in DevSecOps. Gartner Report. CNAPP covers CSPM+CWPP

2. GateKeeper 

3. Kube Hunter, KubeScan, and KubeAudit for scanning the k8 cluster. We can scan the k8 cluster once in 6 months to find any misconfigurations in k8 clusters.

Deploy tools mainly CNAPP, CSPM and CWPP varies on the installation types. It is classified into agent-based and agentless-based deployments. Agentless-based deployments are of less quality than agent-based deployments as they won’t cover every nook and corner. Nevertheless, agentless-based deployments are better than having nothing.

The below image is referenced from Gartner Document. This talks about the tools that cover different areas in cloud-native infrastructure.

The above discusses infra-level deployment. For application code that is deployed, review Application Security configurations and configure WAF’s rules and rate limits.

Monitor

After Deployment has been done, monitoring the deployed changes for any alarms and spikes is crucial to detect any errors in the rollout. Graphana and Prometheus play a huge role in monitoring the rollout. If the rollout is failing, the rollback strategy will be implemented.

The abuse cases and security debts that are identified and not prioritised will be added to be monitored. Having effective mechanisms to monitor will help us in being proactive against attacks.

1. RASP such as API Security monitoring platforms

2. Threat Monitoring

Having an incident response plan and playbook will be required to handle the detected incidents.

Others

Follow “Everything as code”, and automate every security practice cause that will only catch up with the fast-paced DevOps environment.

Conclusion

SSDLC and DevSecOps cover only the software release cycles. It does not cover the entire security such as Enterprise/IT security, Governance, Vulnerability Management and Risk Management.

As you have read the two models, SSDLC and DevSecOps “Dev” parts are similar and interchangeable. The crux is SSDLC does not concentrate on Infrastructure, the Ops Part of DevSecOps.

If you ask an application security engineer, they tell you SSDLC is the way to go. If you ask a cloud security engineer, they tell you DevSecOps is the way to go. If you are in a cloud-native development environment and have an SRE or DevOps team, I would prefer to follow the DevSecOps Model including SSDLC parts rather than including DevSecOps methods in SSDLC.