Implementing application security throughout the SDLC

Developers and students have to be told to pay attention to security

Recent studies show that developers do not actively pay attention to the security of their code unless directed otherwise. Still, application security is fundamental from the early stages of app development.

All team members, including developers and QA people, involved in the product design stage, should at least be aware of the need for application security.

The University of Bonn researched two groups with 20 Computer Science students each. Researchers gave the students a task to develop a registration program for the university’s social network. One group was explicitly told to store user passwords securely while the other group was not.

The participants who were not told to store user passwords securely didn’t make any effort to implement secure code. In the other group, out of 20 participants, 12 applied some level of security.

What if the study was conducted with web application developers instead?

The team from the University of Bonn did the same research with freelance developers. They posted an advertisement on, pretending to be a start-up company. The researchers specifically asked for the assistance of developers with the registration function of a sample social network website. Forty-three applicants were split into two groups. One of the groups was again told to store user passwords securely, while the other group was not.

Out of 18 participants who failed to include a secure password storage mechanism, 68% belonged to the group that was not instructed to implement secure code.

The study conducted on freelance developers confirms the tendency of developers not to implement security measures for storing user passwords unless otherwise directed.

Specifically requesting developers to write secure code plays a critical role in the design of any application.

Developers have to follow development and news in web security. Otherwise, they will make risky mistakes, like using weak hashing algorithms.

As seen in the research by the University of Bonn, developers often use weak methods. They often use encoding or encryption instead of hashing or use inadequate hashing algorithms. Developers need to examine these terms to find out the meaning, capability, and limits of each.

If we want to have secure web applications by design, we have to educate students and developers about the best, the latest and most secure solutions. A lack of knowledge about handling and securing user data will cause confusion, and worse, open a back door for malicious users.

Shortcomings of SAST tools / Why is DAST the better choice for integrating application security into the SDLC

Despite having access to source code and being able to test code for vulnerabilities, SAST tools have significant limitations. SAST tools can detect many different vulnerabilities in the code, but everything they identify is in the code and may not exist in the compiled application, or may not be relevant in the combined application. As an example, they can detect the absence of access control, but they cannot verify if it is running appropriately in the compiled application based on the actual implementation. 

Another problem with SAST tools is that they produce high numbers of false-positive results. It’s difficult to verify whether or not some identified issues are actual vulnerabilities. This results in developers and security experts spending hours on end trying to distinguish between true vulnerabilities and false ones instead of focusing on resolving true vulnerabilities. Moreover,  If SAST tools don’t find any problems, it does not mean that your code is secure as they only look at the code and not at the compiled application, APIs, etc. Related to this is the fact that most applications today use 3rd party libraries and web-services. SAST tools do not have the ability to test vulnerabilities in web-services, thus leaving your application vulnerable.

The problem with false positives persists with the majority of DAST tools as well.  We are proud to say that Bright is one of the few DAST tools, if not the only one that will not report any false-positive findings. We validate that every vulnerability can actually be exploited before we report it.

Shift security left with Bright

Shift left is a simple term for a challenging task which is at the heart of DevOps. You need to move application deployment, quality and security considerations closer to the developer to ensure that potential issues are detected and resolved sooner as early as possible and at the lowest cost. CI/CD automation technology including CircleCI, Azure DevOps and others certainly makes shift-left easier.

As our previous post about the cost of remediating issues over time shows, the cost associated with bugs and security issues as they move through the delivery chain multiplies several times over at each step.

By addressing issues at the point of origin, shifting left has a clear ROI. In traditional development, dedicated teams are responsible for security and quality assurance. They generally respond to issues, not necessarily preventing them. Once the code is moved to integration or production, it is often too late to take precautionary measures. Also, IT teams are focused on system-level security, which is different than application security, where sneaky issues can be missed. 

Bright seamlessly integrates into your SDLC and enable developers and QA teams to run application security tests throughout the CI/CD process. By choosing Bright’s AIAST ® solutions, organizations are able to test for known and 0-day vulnerabilities and security scans can be run early in the SDLC.

Secure your app with every build

Sign up for a FREE Bright account.
Related Articles