Developers should be in charge of Application security: Whitesource security report

Security these days is a major concern for all organizations dealing with user data. We have newer apps being developed daily, crunching in user data to provide users with better services, great deals, discounts, and much more. Application security has become one of the top priorities and needs to be taken care of at every stage of software development. Hence, over the years software testing has shifted from testing just before release to testing during the early stages of the software development lifecycle (SDLC). This helps developers to discover vulnerabilities during early stages and to tackle them easily with lesser efforts.

A recent report from WhiteSource, an open-source security and license compliance management platform, highlights how developers should be in charge of application security and how organizations are investing heavily to produce secure code.

The development team should be in charge of software security

According to a Whitesource report, “for the day-to-day operational responsibility for application security with 71% of the respondents stating the ownership lies in the software development side, whether it is by the DevOps teams, the development team leaders or the developers themselves.”

This is because fixing the vulnerability in the development or coding phase produces better-secured applications. And, if these are handled by development teams, security teams can focus on other bigger security aspects for the organization, on the whole. developers-should-be-in-charge-of-application-security-whitesource-security-report-img-0

In comparison to the previous waterfall method where software testing was done before the release, after adopting a DevOps approach, the testing has moved to early phases to avoid bottlenecks at a later stage.

Whitesource report says, “the 36% of organizations have moved past the initial implementation at testing at the build stage and are starting to integrate security testing tools at earlier points in the SDLC like the IDE and their repositories”.

developers-should-be-in-charge-of-application-security-whitesource-security-report-img-1

How are organizations investing in secure code?

It is possible for a vulnerability to escape the final test rounds and affect users after being released in the market. This can bring in customer dissatisfaction, bad reviews towards the application, customer loss, and many other disadvantages. In such cases, organizations are trying their best to resolve vulnerabilities by testing tools, training, and time spent on handling security vulnerabilities, the Whitesource report says.

“Along with training, developers are tooling up with a range of application security testing (AST) technologies with 68% of developers reporting using at least one of the following technologies: SAST, DAST, SCA, IAST or RASP”, the report says. For organizations that are working with DevOps, the question is not if they should integrate automated tools into their pipeline, but which ones should they adopt first.

[box type="shadow" align="" class="" width=""]

Static Application Security Testing (SAST) is also known as “white-box testing” and allows developers to know about security vulnerabilities in the application source code earlier in SDLC.

Dynamic Application Security Testing (DAST) also known as “black-box testing” helps to find security vulnerabilities and weaknesses in a running application(web apps).

Interactive Application Security Testing (IAST) combines static and dynamic techniques to improve testing. According to Veracode, IAST analyzes code for security vulnerabilities while the app is run by an automated test, human tester, or any activity “interacting” with the application functionality.

Run-time Application Security Protection (RASP) lets an app run continuous security checks on itself and respond to live attacks by terminating an attacker’s session and alerting defenders to the attack.

[/box]

Security in the development phase, an added task for developers

With the help of such technologies (SAST, DAST, SCA, IAST or RASP), issues can be notified before and after production, thus, adding visibility to the application’s security and also enable teams to be proactive.

However, the issue may be constantly thrown at the developers which they will have to research and remediate. “It is unreasonable to ask developers to handle all security alerts, especially as most application security tools are developed for security teams focused on coverage (detecting all potential issues), rather than accuracy and prioritization”, the Whitesource team mentions.

The report states, “Developers claim that they are spending a considerable amount of their time on dealing with remediations, with 42% reporting that they spend between 2 to 12 hours a month on these tasks, while another 33% say that they spend 12 to 36 hours on them.”

How can developers ensure security while choosing their open-source component?

Developers said they check for known vulnerabilities when they choose an open-source component. This ensures “their open source components are secure from the earliest stages of development”. The Whitesource team shows a graph where survey “respondents from North America (the U.S. and Canada) showed a higher level of awareness to check the vulnerability status of the open-source components that they were choosing.” For the Europeans though, open source compliance rated higher on their priorities.

developers-should-be-in-charge-of-application-security-whitesource-security-report-img-2

On asking respondents how their organization detects vulnerable open source components in their applications,

34% of them said they have tools that continuously detect open source vulnerabilities in their applications

28% of them use a code scanner to review software once or twice a year

14% manually check for open source vulnerabilities, but only for the high severity ones

24% said the security team notifies them

Once developers discover the known vulnerability in their product they need to find a quick and effective path to remediating it. Most of them turn first to GitHub’s Security Alerts tool for help, Whitesource reports. The graph below shows other free security tools in the market similar to GitHub. developers-should-be-in-charge-of-application-security-whitesource-security-report-img-3

Detection vs Remediation of vulnerabilities

Developers take a more proactive approach to detect vulnerabilities. However, the same isn’t applicable when it comes to vulnerability remediation. “25% of developers only report on detected vulnerabilities and 53% are taking actions only in specific cases,” the report states.

“Developers are investing many hours is research and remediation so why aren’t we seeing more developers taking action? The reason probably lies in the fact that most application security tools' main goal is to detect, alert and report.”

developers-should-be-in-charge-of-application-security-whitesource-security-report-img-4

We cannot just blame developers if there is a vulnerability found. They also need to have the same quality of tools that speeds up the process for vulnerability remediation. Talking about manual processes, they are time-consuming and require a certain amount of skill set, which are certain challenges faced.

Whitesource concludes that next-generation application security tools will be those that are developer-focused, closing the loop from detecting of an issue, all the way through validation, research, and remediation of the issue.

To know about this survey in detail, read Whitesource Developer security report.

Kazakhstan government intercepts nationwide HTTPS traffic to re-encrypt with a govt-issued root certificate – Cyber-security or Cyber-surveillance?

“Why was Rust chosen for Libra?”, US Congressman questions Facebook on Libra security design choices

Introducing Abscissa, a security-oriented Rust application framework by iqlusion