Automated tools may ease entry into DevSecOps

But not without a change to organizations’ culture

How to bridge the gap between software development and security was high on the agenda last week at IP Expo Manchester, as the need to fix vulnerabilities in Internet of Things (IoT) devices becomes increasingly pressing.

Like many in the industry, Anant Shrivastava, director of NotSoSecure Global Services, a pen testing and infosec training company owned by Claranet, believes integrating security through automated tools is part of the answer.

“Our clients were struggling with how to keep up with security,” Shrivastava told attendees at last week’s expo.

“We were constantly finding issues in their [client] applications and they were not able to cope with the changes that were needed.

“So that’s when we started thinking, why not integrate security into the developer side?”

While it sounds straightforward, DevSecOps – the process of building security into product development from the start – faces a number of organizational and cultural challenges in order to make systems and networks truly safe for all.

“When I talk about ‘secure by default’, I am talking about having that initial stage, which is having baked-in security,” Shrivastava told The Daily Swig.

“This concept is present, but people have never worked towards it because security has always been an afterthought.”

On the developer side, the pressure to turn around projects on tight deadlines makes any pen test completed after deployment appear as a blocker. Security researchers find vulnerabilities in a developer’s code, with the necessary implications that they [developers] must go back to the drawing board.

“Maybe it’s something very small, or maybe very large, but something is wrong, and you only get to know [that] after the entire process is done and a pen test is completed,” Shrivastava said.

These challenges, however, are something Shrivastava thinks can be achieved through the use of cross skill training and automated tools to detect common bugs before a pen test occurs.

“Ideally, when you move into DevSecOps, everyone is the same,” he said.

“Everyone knows about how to deploy in production, everyone knows how to read code, everyone understands what the security implications are.”

DAST, the way to do it

There are two practices considered necessary to ensuring security throughout the pipeline – Dynamic Application Security Testing (DAST) and Static Application Security Testing (SAST).

A code scanner such as Bandit, for instance, implements the SAST security check when the developer’s code is not running, whereas DAST tools like w3af or Burp Suite Enterprise Edition operate when the code is running.

“For each organization there will be a different set of processes that you’ll have to go through, and so each organization will require a different set of tools,” Shrivastava explained, adding that organizations will need time to test which mechanisms are right for them, since plenty of open source and private options [are] available.

“Tools should have the capability to handle false positives, false negatives, mark them up, and then any sort of code scanning tool will start giving you good results,” he said.

Software composition analysis is another way that organizations can protect against a future fallout of failing to patch vulnerabilities, Shrivastava said, particularly as developers are increasingly reliant on third-party packages for programming.

Shrivastava said: “Software composition analysis is an interesting area as most of the bugs in this category are out of your control, and someone else is responsible for introducing and fixing them.”

“Hence the visibility is pretty low, until and unless we are specifically looking at them,” he added.

Automation in this sense can catch critical vulnerabilities like cross-site scripting (XSS) and leave security researchers with the time to focus on other significant flaws within a product.

“We’ve moved into an era where your system build process is automated by means of easily readable text, or what we call infrastructure as code,” Shrivastava said.

“What we’re trying to do here is inspect that infrastructure code and figure out bugs.”

But Shrivastava recognizes that weaving security throughout the development process is no “silver bullet” to securing infrastructure.

“DevSecOps helps organizations reach a bare minimum baseline security standard,” he said.

“Once that’s achieved, the continuous loop starts, which observes the attacks, or successful attacks, and then tweaks the process to avoid committing similar mistakes in future.”

What an organization does when it identifies bugs is another factor to keep in mind.

“Are they working towards holistic fixes and ensuring such bugs and classes of bugs are removed from code,” Shrivastava said.

“Are they improving the pipeline so that such bugs are not left in code again? If they are, then DevSecOps is succeeding.”