New Project: DevOps Security Automation Pipeline

[matt....@owasp.org]

I have existing code for a ruby based command line tool which I just open sourced that can do these things:

Take input from: 

• Github Repo
• Filesystem
• Docker image
• ISO

Run existing open source tools on it including: 

Filesystem:

• AV
• FIM

Code: 

• Brakeman
• Bundler-audit
• OWASP Dependency Check
• Custom checks for secrets in source code

Live App: 

• ZAP (TBD)

Filters of Findings (To reduce false positives): 

• JIRA

Reporting Output: 

• Text
• JSON
• CSV
• JIRA

The ultimate idea would be to be able to use this tool to automate security steps within a DevOps pipeline - getting a dev team input on a timely basis related to their code.

There are lots of opportunities to extend and the app is built to do this.

It is currently hosted at:  https://bitbucket.org/jemurai/pipeline/

I would be willing to move it to an OWASP github project if there is interest.

[johanna curiel]

Interesting, I kind of have an idea what the tool does but I think some more documentation with an example will be more clear

Especially in DevOps area, there are no OWASP tools trying to cover that

[Matt Konda]

Hey Johanna,

I moved the tool to github.  Still building it incrementally but making progress. https://github.com/OWASP/pipeline  Definitely agree about documentation and examples.

There is also a group of us that have been meeting around what tooling and other items should be considered when thinking about Security and DevOps.  We've talked a lot about pushing for open API's for security tool integration and common data models so that we can share what's working.

That effort has been lead by Aaron Weaver and Matt Tesauro out of this project: 

https://www.owasp.org/index.php/OWASP_AppSec_Pipeline

We've had some pretty solid participation from neat folks - many from industry like ThoughtWorks, Intuit and Target.  We were having meetings every two weeks on Friday but we fell off through Thanksgiving.  Anybody that is interested is welcome.  I can email Aaron or you can reach him directly to get involved.  There was some great initial inertia but its very much in the beginning stages.

Matt

[johanna curiel curiel]

Hi Matt

I noticed someone made a similar question on the github I had regarding the OWTF project.

Just as suggestion, as I know you are building a tool from scratch in Ruby.

Agree that the focus of OWTF is pen testing and Pipeline is broader as it could be integrated with SAST tools from the build  process. I would have expected here FxCop (.NET)as is really a tool that is already integrated into VS studio and the results could be extracted into a 'Pipeline' during the code. Also OWASP O2 can serve you for this purpose as SAST tool.

Checkmarks & other vendor tools are quite expensive but I see the utility of having an open source tool integrating with Commercial tools, however from my open source perspective I think that integrating with first SAST/DAST open source tools makes the use of the Pipeline open to everyone. Right now potential users of this tool are limited to vendor tools with exception of Threath Fix which is also open source available.

If I understood well, the purpose of Pipeline is to be integrate it into the build process, therefore I think that adapting OWTF to integrate with the build process is question of building a module to do this. The one thing missing into OWTF is a module into the first pipeline process in code, m SAST module . In this case open source tools like FindBugs or FxCode will be by first priority.

[johanna curiel curiel]

Hi Matt

Oops the other email was sent before I was finished ;(

I noticed someone made a similar question on the github regarding how is this different from OWTF I had.

Just as suggestion, as I know you are building a tool from scratch in Ruby.

Agree that the focus of OWTF is pen testing and Pipeline is broader as it could be integrated with SAST tools from the build  process. I would have expected here FxCop (.NET)as it's a tool that is already integrated into VS studio and the results could be extracted into a 'Pipeline' during the coding phase. Also OWASP O2 can serve you for this purpose as SAST tool.Findbugs on Java code for example. Vendors have more languages available. Form a Developer perspective I would like to see clearly which tools will serve my purpose depending on the language used. Coverity is free available to open source tools.

Checkmarks & other vendor tools are quite expensive but I see the utility of having an open source tool integrating with Commercial tools, however from my open source perspective I think that integrating with first SAST/DAST open source tools makes the use of the Pipeline open to everyone. Right now potential users of this tool are limited to vendor tools with exception of Threath Fix which is also open source available.

If I understood well, the purpose of Pipeline is to be integrate it into the build process, therefore I think that adapting OWTF to integrate with the build process is question of building a module to do this. The one thing missing into OWTF is a module into the first pipeline process in code, m SAST module . In this case open source tools like FindBugs or FxCode will be by first priority.

my view of the pipeline with open source. Here we see that vendor tools are doing an excellent work integrating into the manage process with tools like Jira, only ThreathFix is available (so far I know correct me if I'm wrong)

Code(SAST tools)	Manage (JIRA)	Store(GIT)	Build (Process)	Deploy(DAST)
FoxCop(.NET)	Threath Fix	OWASP O2	Dependency Check	ZAP
OWASP O2(.NET)		FoxCop	Findbugs	OWTF(api with ZAP, Nikto, Watapi- works with plugings)
Findbugs(Java)		Findbugs		Burp
Coverity(open source tools)

If this was in Python or Java I would have surely like to contribute, but Ruby is not my thing ;-). I think you can get more devs help you if you build this with Python ;-)

Cool project and I think a total integration into the devops/pipeline of building software is a need to build proper security into the development and ops process of SDLC.

Cheers

Johanna

[Matt Konda]

Awesome feedback, Johanna.

I'm still processing it.  Hope to get back with more questions in the coming week.

Matt

[johanna curiel curiel]

Hi Matt

This guy created an add-on for ZAP that extracts the Alerts reports and creates a JIRA issues from :

https://neatrick.wordpress.com/2015/12/14/an-add-on-for-owasp-zap-to-export-alerts-of-a-web-application-as-issues-to-jira/

Basically in order to manage everything well, should all the tools be able to import those issues to JIRA or Github issues... right?

That would be cool. Imagine you have and API engine (Pipeline API) that extracts the info from these tools, and imports then to JIRA or Github issues.

Then you have a complete DevOps process from Code to Deploy ;-)

 Using JIRA rest api we can indeed log all the found issues to JIRA. Would the PIPELINE be something able to extract and expand these options for Code and Build and Deploy Process?

I think for Code And Build process separating the 'pipeline' per Programming language is important.

I can build a pipeline for JAVA DevOps using Open Source tools , the PIPELINE API ENGINE (he he created with  JAVA as a REST service)

Code(SAST tools)

Manage (JIRA)

Store(GIT)

Build (Process)

Deploy(DAST)

Findbugs-PIPELINE API imports found issues to JIRA/GITHUB	PIPELINE API -imports issues to JIRA	PIPELINE API-Creates Issues to GITHUB	PIPELINE API-: OWASP Dependency Check found issues , imports them to JIRA	ZAP -AddOn ==> imports found issues to JIRA
				Burp API- PIPELINE consumes Burp services and imports issues to JIRA

What do you think about this concept? 

[Matt Konda]

Hey Johanna,

I wanted to circle back on this email chain.  I did re-read your input and agree with a lot of it, need to think about other parts more.  You definitely get the idea of what the tool is intending to do and present the stages really well - along with some great ideas (github issues and others).

Is there a time we could catch up on slack to bounce ideas further?

Matt

[johanna curiel curiel]

Hi Matt

Sure. I've been working on a ZAP add-on to log found issues to Github (from Alerts reports)

We can indeed work out  a pipeline for Java, for example. Like I mentioned, for me is Java/Python 

I'll try to catch up you on the slack, I have an idea for a nice infographic with a Java DevOps security Pipeline

Then work out a more robust API with a Dashboard. I'll send you my idea on a plan tomorrow

cheers

Johanna