(Automated) Security Testing in a DevOps World

  • Doctoral Researcher @ Institute for Internet Security
    • ​Blockchain Research Group Lead
  • Consultant @ Styrascosoft GbR
  • Testcontainers Maintainer and Open Source Enthusiast
  • Oracle Groundbreaker Ambassador
  • GitKraken Ambassador
  • Organizer Software Crafting Meetup Ruhr

Kevin Wittek          @kiview

"Oldschool" Development Pipeline

Excursion: Pentesting

  • Usually part of a quality gateway
  • Often missplaced in the classical development process:
    • Too early => Nothing productiv to test
    • Too late => Critical findings threaten release date
  • What is the motivation for a pentest?

Motivation

  • Integrate security into fast DevOps cycles
  • Find low hanging fruits by automated tools
  • Use pentests for more complex issues
  • Security awareness in developer context

"DevOpsy" build pipeline

Stage Available Artifacts
Build Source Code
Byte Code
Dependencies
Docker build Container Image
Staging / Production Container Image
Configured Environment

I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation.

We still make syntax errors, to be sure; but they are fuzz compared with the conceptual errors in most systems.

If this is true, building software will always be hard. There is inherently no silver bullet.

Static Application Security Testing

(SAST)

Dependency Check

https://snyk.io/

https://depshield.github.io/

https://github.com/jeremylong/DependencyCheck

https://www.blackducksoftware.com/de/black-duck-home

Demo

Exkurs: CVE, CPE, GAV

  • CVE: Common Vulnerabilities and Exposures
  • CPE: Common Platform Enumeration
  • GAV: Maven Group:Artifact:Version

Exkurs: CVE, CPE, GAV

  <entry id="CVE-2012-5055">
  ...
    <vuln:vulnerable-software-list>
      <vuln:product>cpe:/a:vmware:springsource_spring_security:3.1.2</vuln:product>
      <vuln:product>cpe:/a:vmware:springsource_spring_security:2.0.4</vuln:product>
      <vuln:product>cpe:/a:vmware:springsource_spring_security:3.0.1</vuln:product>
    </vuln:vulnerable-software-list>
  ...
  </entry>

cpe:/[Entry Type]:[Vendor]:[Product]:[Version]:[Revision]:…

<!-- org.springframework.security:spring-security-core:3.0.1.RELEASE -->
<dependency>
    <groupId>org.springframework.security</groupId>
    <artifactId>spring-security-core</artifactId>
    <version>3.0.1.RELEASE</version>
</dependency>

Sonatype OSS Index

https://ossindex.sonatype.org/

Static Code Analyis

"So I personally consider security bugs to be just "normal bugs".

I don't cover them up, but I also don't have any reason what-so-ever to think it's a good idea to track them and announce them as something special." - Linus Torvalds, https://yarchive.net/comp/linux/security_bugs.html

Static Code Analyis

https://www.veracode.com/

https://www.checkmarx.com/

https://www.microfocus.com/de-de/products/static-code-analysis-sast/overview

https://spotbugs.github.io/

https://find-sec-bugs.github.io/

Demo

Image scanning

http://layeredinsight.com/

https://github.com/coreos/clair/

https://docs.docker.com/ee/dtr/user/manage-images/scan-images-for-vulnerabilities/

Dynamic Application Security Testing

(DAST)

Dynamic Scanner

http://www.zaproxy.org/

https://portswigger.net/burp

Source: https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

But everything is better in a container!

Source: https://twitter.com/docker/status/831529743816224769

ZAP + Docker/testcontainers

Excursion: OWASP Top 10

  • A1:2017-Injection (SQLi, ...)
  • A7:2017-Cross-Site Scripting (XSS)
    • Persistent XSS
    • (Reflected, DOM based, Mutation based)

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_2017_Project

Demo

Gitlab-CI

Security Features

  • Container Scanning
  • Dependency Scanning
  • Static Application Security Testing
  • Dynamic Application Security Testing
    • OWASP ZAP
    • Kubernetes Deployment

Auto DevOps Pipeline

Code checks

Container Scanning

Conclusion

  • Integration into build chain possible
  • Security insights for developers
    • Possible without security experts
  • Open Source tools can provide some security benefits
    • Commercial products might provide different results

Outlook

  • Increase security awareness inside developer community
  • Security and developer communities need to work together:
    • Shared goal: Better software
    • Shared language would help
  • Security is continuously needed in DevOps

Resources

Source: https://twitter.com/signalsciences/status/647533893617238016

Questions?

Feedback: https://greach.contestia.es/

Made with Slides.com