Halloween is upon us, and while much of the world is focused on scary creatures like ghosts, ghouls, or werewolves, DevSecOps teams have a few scary creatures of their own to deal with. 

From the Dracula-like developer stuck in a world from centuries ago who is thwarting the creation of secure apps, to the DevOps ghosts that downplay the importance of app vulnerabilities, it’s important for DevSecOps teams to understand the threats that may be lurking in their own teams.

First off, there are the Dracula-like developers who are stuck centuries in the past. According to Dennis Hurst, founder of Saltworks Security, these developers exist out of a desire not to change the way they write code. “We run into this a lot, of ‘we’ve always built an application this way, why do I need to security test it?’ And they’re not sort of realizing that these applications are now on the internet, they’re public facing, or they’re connected to things that are on the internet, or they’re running in a cloud infrastructure so it’s no longer a nice sort of happy data center,” said Hurst.

According to Hurst, the way for teams to overcome these Dracula-like team members is to have clear leadership. “Without strong leadership, team members feel free to keep doing what they have always done, which stifles innovation,” he said.

Another scary member of the DevSecOps team to look out for are DevOps ghosts, in other words, shadow IT. According to Hurst, these are the people that believe “they can just magically go around all of IT and go straight to the cloud. The applications are there, sort of like ghosts, you hear them rattling around and you know that they’re there but you don’t actually see them, nobody knows about them, they’re kind of – maybe they’ll be there. We see this a lot in security where we find applications running on the internet that no one knew about.”

Hurst added that this isn’t a rare occurrence; it’s actually fairly common, especially with more employees working from home. People go home and take their laptops with them, so how do you secure that? 

“A lot of companies have jumped to the cloud for some parts of their business because of COVID, maybe they couldn’t get to the data center,” said Hurst. “So it’s just easier for people to get in their mind that ‘oh, I can just stand this application up in the cloud and when this is all over with we’ll figure out how to get it back in-house.’ We’re definitely seeing it more. We’re seeing more people going to the cloud, maybe using a corporate credit card to open the accounts even, so it’s not even a corporate owned account even, it’s just somebody’s personal credit card that they use to stand up a website somewhere, we see that more than we would like.”

Hurst believes that using monitoring systems is one of the biggest ways to protect against shadow IT. He explained that there are services that monitor the internet looking for properties that point back to or are linked to the company’s IT infrastructure. A big downside is that there isn’t really a proactive way of preventing someone from spinning up a service on their own. “Anyone can go out and stand up a website, but you can monitor to see when it happens. The faster you can address it, the easier it is to manage,” said Hurst. “So if a website is stood up for a day, it’s pretty easy to take that down or get them to move it. If it’s there for 6 months or a year, doing business, it becomes much stickier and challenging to get pulled out because you’re taking business offline.”

The Architecture Review Board’s “Bridge of Death” is another spooky DevSecOps component to look for. Development teams go through all of this effort and build DevOps pipelines and get things up and running, but once they get to the architecture review board, the questions they get asked are similar to the questions asked in the bridge of death scene in Monty Python and the Holy Grail (i.e. Arthur being asked what is the airspeed velocity of an unladen swallow?). 

“Many times security, which is part of that board, will ask questions that they didn’t tell the developers they were going to ask when they started the process,” said Hurst. “So they’re implementing new requirements. So as a developer you get to the architectural review board and they ask you three questions, or some number of questions that are just seemingly random, and if you get it wrong, they tell you to go back and rework. So it’s a lot like that movie where they get thrown into the pit of despair.”

To deal with the bridge of death in development, Hurst recommends clearly defining and communicating standards to development teams on what is required to take an application into production. 

Another area to look out for is the “build it and it will run” concept. “In Field of Dreams they kept saying build it and they will come. This is build it and it will run.,” he said. “There seems to be an attitude that if you go from whatever methodology you were using previously to DevOps, somehow magically the application will run even if you don’t test it properly and you don’t security test it properly.”

According to Hurst, it is common for people to artificially focus on the development part of DevSecOps, so they develop something well but they don’t test it well, or communicate with customers how to go live securely. 

In this instance again, proper leadership is the antidote. A good leader can mandate that when a team is moving to DevSecOps, it must be done fully, including proper testing for security, performance, and functionality, Hurst explained.

Finally, there are the oblivious CSOs, which is perhaps the most challenging issue of them all, Hurst believes. According to Hurst, CSOs tend to come from the networking or audit world, not the development world.  “A lot of times they don’t understand development. They understand conceptually how things get developed, but they don’t understand the business drivers of development. Because people say DevSecOps, there are assumptions that are made that security is being done properly in the development world.”

To combat this, Hurst recommends CSOs become more involved with developers and DevOps teams. 

“They have to be involved, they have to understand what’s being built and how it’s being built,” said Hurst. They have to understand what’s being done to properly secure it. So they have to be very involved. You can’t be oblivious to what’s happening or it just won’t happen. Ultimately in an organization, the CISO is the only central person in the corporation that owns security, and that has to include application security, you can’t just trust that hundreds and hundreds of development teams are all doing the right thing to protect the company. That’s just a recipe for a disaster.”