How to improve relations between developers and security teams and boost application security

In December 1996, application security expert Chris Wysopal published his first vulnerability report. He found that data could be edited or deleted in Lotus Domino 1.5 if permissions were not set properly or URLs were edited. That security risk — broken access control —  is the number one risk on OWASP’s 2021 Top 10 list of application security risks.

“We know about this problem really well and knowledge about the problem isn’t solving the problem,” he said. 

Wysopal, who is Veracode’s CTO and co-founder shared a short history of his time as an application security researcher, from his time with The L0ft hacker collective to testifying in front of Congress to doing security consulting with Microsoft in the early 2000s. Wysopal spoke during a keynote at OWASP’s 20th anniversary event, a free, live, 24-hour event held on Friday.

Wysopal said that he started out as an outsider in the tech world, which gave him a unique perspective to call out problems that software engineers, company leaders and government officials did not see. Over the last 25 years appsec researchers have moved from critics standing on the outside looking in to professional colleagues working with software engineers to improve security. 

SEE: How DevOps teams are taking on a more pivotal role 

“As William Gibson said, ‘The future is unevenly distributed, and I think we can learn from the past and learn from those already living in the future,” he said. 

He shared advice on how to build closer working relationships among developers and security experts as well as how the appsec profession has evolved over the years. 

Building relationships to improve security 

Wysopal said he sees the latest evolution of appsec as security experts becoming official members of the software development team.  

“Success is being part of a team that is shipping secure code on schedule, working to continually improve the process and doing less work for the same secure outcome,” he said. 

Wysopal said strong relationships between the two teams is another key to making appsec work. Individual developers and security team members should consider these questions and find the answers:

• Who is your peer in development or security?
• Do you meet with them?
• Do you understand each other’s goals?
• Are you sympathetic to each other’s struggles?

Another key to success is ensuring shared accountability between both the security and software engineering groups:

• How can we establish the shared goal of shipping secure software on time?
• What can the security team do to make sure the dev team does not have to slow down?  
• What can the dev team do to help the security team to test faster?

“Also, this accountability has to be measured and reported on,” he said.

Wysopal said some applications by their very nature are harder to secure than others. His team considers both the nature and the nurture of each application when working to improve security.

The ideal environment for applications that are easy to secure looks like this:

• Small organization
• Small application
• Low flaw density
• New application 

It’s harder to secure older, larger applications with high flaw densities built at big companies, Wysopal said. 

In terms of nurturing secure applications, development teams use frequent scans and a variety of scanning types. Static and infrequent scanning make it harder to improve application security. 

Wysopal also shared some advice about how changing security practices can improve appsec, regardless of whether an application is easy or difficult to secure. In a good environment, best security practices can reduce the half-life of a vulnerability from 25 to 13 days. In a less than ideal environment, improving security practices can reduce the half-life of a vulnerability by more than four months.

The evolution of appsec

After he published his first vulnerability report, Lotus acknowledged the problem on its home page, explained how they fixed it, credited him for finding the problem and thanked him for doing so, Wysopal said.

“There was a new sense that some developers actually appreciated vulnerability research even in 1996, and it made us start to think maybe we should talk to developers,” he said. 

He and his fellow hacker Mudge (Peiter Zatko) started talking to software companies, including Microsoft about vulnerability research. In May 1998, he and his L0ft colleagues testified at a Congressional hearing, “Weak computer security in Government.”

“This woke up the world that industry and government need to work with vulnerability researchers,” he said.

Then in November 2001, Wysopal got an email about the launch of OWASP. The next phase was working with Microsoft engineers and the next challenge was to move from being an outside critic to collaborating with developers. 

Early tools were built for appsec researchers, not developers, and that meant that developers didn’t use those tools to improve security, Wysopal said.

Appsec teams needed to do more than simply find flaws because that approach made developers angry and stalled progress. 

“We needed to tread lightly or nothing would get fixed at all,” he said. “This approach might have been a step backward in the early days of automation.”

The focus then shifted to fixing problems with an emphasis on training, sample repairs and secure libraries, he said. This was the start of modern appsec. 

“One of the best things that has happened to appsec is processes changing to agile and
DevOps

,” he said. “This was really a forcing function to modernize how appsec was working.”

Developer Essentials Newsletter

From the hottest programming languages to the jobs with the highest salaries, get the developer news and tips you need to know.
Weekly

Sign up today

Also see