<img height="1" width="1" style="display:none" src="https://alb.reddit.com/snoo.gif?q=CAAHAAABAAoACQAAACi3UkU6AA==&amp;s=hMfJ_f7PVQOiL2csDznj0MZz_-_Sym2oeAYASWsHW4c=">

Deep Dive: Fannie Mae's DevSecOps Journey + SAST and DAST in Continuous Integration

Oct 17, 2018 6:46:04 PM By Erik Dietrich My Post (16)

A big part of Fannie Mae's approach involves two security-related concepts.  These concepts are static application security testing (SAST) and dynamic application security testing (DAST).

In order to understand where this fits into the development cycle, consider the graphic below.

Fannie Mae 1

In the middle, you have the "go-live" moment, with things on the "left" occurring pre-production, and things on the "right" occuring in production.

Understanding when to leverage which tool is critically important, and you should understand that SAST and DAST don't just play a role on the left here, but also on the right.

Within Fannie Mae, they have used several SAST tools, and those start within the IDE.  Beyond that, they use a point security integration that is part of SonarQube, as well as a tool called Fortify Software Security Center.  This helps to get everyone in the development process involved in security as early as possible.

Philosophically speaking, Fannie Mae leverages a lot of sophisticated tooling, and they value the usability of tools like dashboards.  But the most important thing they do is that they proactively identify potential vulnerabilities and lodge them as actual defects, from a process perspective.

From a roles and responsibilities perspective, the DevSecOps journey can be illustrated with this diagram.

Fannie Mae 2

 

As you can see, DevSecOps at Fannie Mae is a highly cross-functional concern, with several different parties involved.  Developers, security analysts, build engineers, dev services, and security champions all play a part.

Because so many people are involved and need to collaborate, it's essential to have centralized reporting so that everyone can use the same information.

Toward that end, they have a custom screen within Jenkins that shows all vulnerabilities in a single, centralized location.

When it comes to static analyzers, one of the biggest dangers is false positives. And that's unavoidable. You'll always have false positives with these tools, so you need to calibrate and tune your rulesets to ones that make sense for your environment.

This also applies to DAST, the other side of the equation.  Just as with SAST tools, you'll need to calibrate and tune your rulesets.

Speaking of DAST tools, Fannie Mae incorporates DAST tools into their process as well, both under the heading of continuous integration and continuous deployment.  

Fannie Mae 3

Because of the dynamic runtime nature of DAST tools, they can speak to a healthy cross-section of potential vulnerabilities.  These include the following.

  • Cross-site scripting
  • Command execution and remote code injection
  • SQL injection
  • Cross frame scripting
  • Authorization issues
  • Information disclosure
  • Cross-site request forgery
  • Insecure communications
  • Session and cookie related issues.

With all of this impressive tooling at your disposal, it's easy to lose site of something important.  And that’s the idea that all of this tooling is supplemental to the core effort of human activities, like penetration testing, manual testing, custom scripts, and general manual intervention.  

They can guide you in a good direction and call your attention to things, but they cannot replace human ingenuity.

***

Missed Chitra Elango’s session, or want to see some other great presentations from October 17? Head over to https://www.alldaydevops.com/live and make sure you’re registered. Then, catch up on what you missed (or re-watch your favorites)!

About the author, Erik Dietrich

Erik Dietrich is a veteran of the software world and has occupied just about every position in it: developer, architect, manager, CIO, and, eventually, independent management and strategy consultant. He’s the cofounder of Hit Subscribe and writes at daedtech.com. Connect with him @daedtech.