I wanna create a Discord channel as a place for communication and planning for this project.
What's your comment?
@CirKu17 @ioggstream @SudE29537 @vanderaj @raphaelhagi

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

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.

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

Hi, is there a place where the full documentation is available for easy consumption as a web page or PDF?

I can go through the markdown files on the document folder but I feel like there should be a consolidated document published somewhere (maybe the OWASP project page?) to make it easier to read and reference.

Would there be a significant interest in moving toward diagram as code for the various schema in this repository?

I have used mermaid personally with significant success to either document workflow, git history and a few others common diagram.

It fosters diagram evolution given everything is "as code".

Not certain if they would render properly on the web but it does in GitHub markdown.

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.

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

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

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:

• https://www.defectdojo.org/
• https://defectdojo.github.io/django-DefectDojo/usage/models/

Hey All,
I can provide some content about accessing to pipeline configs, user types and branch protection to secure pipeline config files.
Is this topic sound valuable for you?
Thnks.

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

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

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.

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.

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

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.

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.