owasp / devsecopsguideline Goto Github PK

View Code? Open in Web Editor NEW

793.0 41.0 181.0 10.37 MB

The OWASP DevSecOps Guideline can help us to embedding security as a part of the development pipeline.

Home Page: https://owasp.org/www-project-devsecops-guideline/

License: Other

Python 100.00%

devsecops owasp shift-left security

devsecopsguideline's Introduction

OWASP DevSecOps Guideline

The OWASP DevSecOps Guideline explains how we can implement a secure pipeline and use best practices and introduce tools that we can use in this matter. Also, the project is trying to help us promote the shift-left security culture in our development process.
This project helps any companies of each size that have a development pipeline or, in other words, have a DevOps pipeline. We try to draw a perspective of a secure DevOps pipeline during this project and then improve it based on our customized requirements.

The Ideal goal is "detect security issues (by design or application vulnerability) as early as possible."

Initial steps

DevSecOps is all about putting security into DevOps. But to keep up with the pace of CI/CD, security has to be injected early into software writing and testing.

OWASP Proactive Controls lists the top 10 security controls every developer has to implement while coding any application. Consider this set as the starting point when you have to design, write or test code in the DevSecOps cycle.

You can also follow the OWASP Software Assurance Maturity Model (SAMM) to establish what to consider for security requirements (and more) according to your maturity level.

What to add in a pipeline

At first, we consider implementing the following steps in a basic pipeline:

Scan git repositories for finding potential credentials leakage.
SCA (Software Composition Analysis)
SAST (Static Application Security Test)
IaC Scanning (Scanning Terraform, HelmChart code to find misconfiguration)
IAST (Interactive Application Security Testing)
API Security
DAST (Dynamic Application Security Test)
CNAPP (Cloud Native Application Protection)
Infrastructure scanning
Continuous Scanning from other tools
Compliance check

We can customize the steps of our pipeline according to our Software Development Life Cycle (SDLC) or software architecture and add automation progressively if we are starting. For instance, we can switch from SAST/DAST to a regular test suite with built-in security controls or add an audit script checking for known vulnerable dependencies.

CI/CD is an advantage for SecOps, a privileged entry point for security measures and controls. However, when using CI/CD tools to provide automation, keep in mind that the tools themselves often expand your attack surface, so put security controls on building, deployment, and automation software.

devsecopsguideline's People

Contributors

Stargazers

Watchers

Forkers

ali-yazdani rejahrehim anees264 cirku17 frodriguezc mreetyunjaya mkulasi robertnoroozi arielshup paras-malhotra global-localhost global19-atlassian-net global19 gitr007 ioggstream probattu repson apython123 lichnak safe2008 todd-a-jacobs wurstbrot myugan sude29537 resxar royaflash bapushinde hydramagic yassineamraoui nateambringit vijulp mariuslihet hazembittar samuelarogbonlo nathanawmk adesurya azraelsec magnologan aagaio quynhlab tech-save filipi86 edulalmeida jjasonhenrique rammybt chidoziendukaku intltechventures mauchy81 sumitvgithub smbowen miladbr oppedijk wingless-archangel ylvaldes simiking kursatoguzhanakinci cybersecgurul ekmixon saradkc jilan804 atthisaccount fintoalef esrobinsoniii malektrad sachinpatkar joymondal milstein-corp lilaram isabella232 nishikinor elvis2131 jramirezg genjogu svenkatesans saichill kananasivachandran antodr ducthinh993 tunceryukler mohammadkamrani arvindmits planetlevel dnavarrom kujira-git raminfp sht abdennebi-forks bellaalo kur05uke dummy-andra holyeric mchamrosh despratesparten destroyyer baonq243 rocxyrock 0xd3vil zeeshansultan mbareck7 indrasekhar365

devsecopsguideline's Issues

Reuse the OWASP tool lists

I noticed that the SAST & DAST document lists a few tools.
Would it not be better to reuse the existing OWASP lists for this? Keeps just one source to maintain all of this data.
SAST list: https://owasp.org/www-community/Source_Code_Analysis_Tools
DAST list: https://owasp.org/www-community/Vulnerability_Scanning_Tools.

Add CI/CD to deploy https://owasp.org/www-project-devsecops-guideline

The current version of the site differs from the source code here on github

Adding SCA - Software Composition Analysis

I believe we should add a session on SCA. Not sure if it fits on one of the documents we already have.

Add privacy to the security guideline

Since we are dealing with several privacy laws and regulations, I believe it makes sense to add a privacy component to the DevSecOps security guideline.

Provenance

Add steps with provenance generating on Build and provenance check on Deploy

Discord Channel.

Hi All,
I hope you are doing well.
I created a Discord channel for communication, please join from the following link:
Discord Channel

Note:
the link will be expired in 7 days.

CC: @CirKu17 @ioggstream @SudE29537 @coadaflorin

Add open source solution

Gitlab security pipelines
Can be found: https://gitlab.com/whitespots-public/pipelines

With Security stage integrated into your team's pipelines, on, let's say, every release, Security stage is run and trigger Security pipelines to do the job. Security stage itself doesn't affect your time-to-market.
Security pipelines combine different types of security scanners in one "Security" stage.
Scans reports are sent to DefectDojo, where triage begins.

Pipelines integration instructions: https://www.youtube.com/watch?v=DLN1kNh_Ha0
SSDLC based approach is described here: https://www.youtube.com/watch?v=6FGV4OcrIB8
How to work with DefectDojo tutorial: https://www.youtube.com/watch?v=_uFOIf1BUwU

We are contributing to this project for about 2 years and are ready to share. Hope it worth being added here.

Adding Application Vulnerability Management

Hi,

I think we could add something related to the DevSecOps program management and metrics. Since the success of DevSecOps efforts on teams or enterprises relies on things like adoption, number of vulnerabilities, the time it takes to remediate the issues, etc. Application Vulnerability Management could be a good touchpoint to add to this guide.

We can look at:

Pipeline Tampering Risks & Prevention

Hi folks,
As a DevSecOps practitioner for many sizes of development, there is a critical one for maintaining DevSecOps Pipeline to prevent integrity violation and DRY principle with the pipeline consuming

Abstraction Ideas:

Pipeline definition store as separate repos
Consuming pipeline as git sub-modules
Pipeline call should be visible and measured

Benefits:

Pipeline enforcement
Pipeline integrity
Pipeline scalability

I'm happy to help but not so sure which category should we put it on

SCA - Software Composition Analysis

Hello there,

I would like to propose to add a SCA scanning close do SAST. Many security problems in software are related with libs with opened CVE issues.

Add source of schemas to assests folder

Hi, can u add the source scheme file of image to assests folder.
This will allow other users to change the images.

Adding IAST - Interactive Analysis

I see no mention of IAST on the tools lists.
It's a very powerful technique that people could benefit from, especially if they already have some automated functional testing. Technically it's much faster than DAST and the sync between HTTP requests and stack is very useful in debugging.

Location:
As soon as you have something running you can do IAST on it. So I'd say potentially right next to or before the DAST component. Also, if you do DAST and perform some automatic crawl of the application a lot of times that will help the IAST tool. IAST is dependent on external traffic to have something to monitor.

Dependency Security Management & Continuous Dependency Remediation

In the modern AppSec program, it's necessary to "shift-left" security & governance for dependency from the Code to the Plan stage.

Conceptual approach

Plan phrase:

For OSS Dependency:

Benchmark OSS dependency project with OpenSFF Scorecard

For vendor and third-party dependency:

Involve SBOM as artifacts release manifest in order to be aware of downstream dependencies. The benefits of the SBOM approach allow the security team to perform security assessments without the need for source code - might not available with third-party

Building private dependencies registry to secure store and sign-off for dependency to prevent availability and tampering issues from upstream maintainers

Code phrase:

Setup proper dependency security scanning tool in CI/CD pipeline
Setup Dependency Vulnerability Assessment to continuously scan and alerts for new finding developers

Software Composition Analysis & Supply Chain Risk Management

Hey!

I see that the SCA is a little bit less developed than other parts of the doc, so I'd be happy to expand on this to include various techniques, technologies, tools, and workflows on how this is done in a real-world scenario. Let me know if that's what you're interested in. I also gave a talk about it here.