Blog

Security Testing in the SDLC: Do We Really Need It?

Functional testing has been a part of the Software Development Lifecycle (SDLC) for decades. Functional testing is about known expectations, straightforward processes, and easy-to-interpret results, so security considerations rarely showed up on the radar, more so because the goal was often to release the application “yesterday!”

But now, the growing number and scale of cyber attacks – and the fact that data is the new “currency” – are forcing organizations to rethink their approach to software/application security. This means thinking about and including security testing into the SDLC by asking (and answering) new questions like:

Is the server code free from vulnerabilities that could be exploited by bad actors to gain access to our applications, systems or data?

Are there vulnerabilities in our network, operating system or database?

Can the client be manipulated, say, through their browser?

Functional testing is about ensuring that the product functions the way it’s meant to. However, it cannot protect the software (and the organization) from security vulnerabilities and hackers. And that’s why security testing is absolutely critical in the SDLC.

What is Software and Application Security Testing?

Application security testing is a robust and rigorous analysis of security-related weaknesses and flaws in a software or application. The goal is to ensure that no exploitable vulnerabilities are missed and that the application and its data are protected from bad actors after release.

A competent security tester looks for all possible weaknesses in the product that make it vulnerable to intruder attacks and could lead to problems like loss of information or revenues, non-compliance, or a damaged reputation.

During security testing, the tester focuses on six major security properties:

  • Confidentiality: Data is only available to authorized users, i.e. the people intended to access it

  • Integrity: Data and system resources can only be changed by the right people in the right ways

  • Availability: Information and data are accessible to users

  • Authentication: The identity of users is established

  • Authorization: Users are explicitly allowed to access resources or data

  • Non-repudiation: Users (e.g. bad actors) cannot perform a malicious action, and later deny it

Security Testing Focus Areas

The term “security testing” is simple enough, but it encompasses multiple focus areas:

Network security: Looking for vulnerabilities in the network infrastructure, including resources and policies

System software security: Assessing weaknesses in the various software the application depends on, including the operating system and database system

Client-side application security: Ensuring that the client cannot be manipulated via a browser or any other tool

Server-side application security: Ensuring that the server code is robust enough to stave off intrusion attempts

Code security: Checking the application’s source code to identify and eliminate vulnerabilities during development, and ensure the code’s “long-term maintainability”. It involves checks for many aspects including:

The OWASP code review guide is a great resource for code security review best practices.

In short, security testing tests everything from the source code all the way up to the browser and thus provides a holistic approach for today’s cyberthreat landscape.

Manual or Automated Security Testing?

Many testing teams rely solely on automated security testing.

To quickly and accurately spot issues, it’s useful to incorporate automated tests into the CI/CD pipeline. However, such tests usually provide a mix of concrete and inconclusive results. For example, if the security parameter being tested is: Are encrypted communications being validated to prevent illegal interceptions and man-in-the-middle attacks? Automation can check for expired certificates or fully qualified domain names, but it cannot check for how the application handles these certificates. For this, manual testing performed by an experienced human who knows the application is invaluable. Automated testing also produces a lot of false positives, which also dilutes its usefulness.

This is why it’s critical to combine automated security testing with manual controls. And this is the approach that Packetlabs follows. By combining automated testing with extensive manual processes, threat modeling and extensive reporting, Packetlabs’ application security testing is a robust approach that’s well-prepared to meet today’s cybersecurity challenges.

Wrap-up

In today’s threat-riddled development landscape, both functional and security testing are vital to ensure that all vulnerabilities are caught and fixed early, and users get the high-quality product they demand and expect.

If you’d like to discuss your application security testing or penetration testing requirements, contact us. We’d love to provide a free, no-obligation quote.

Featured Posts

See All

December 10 - Blog

Hardware Token Protocols

Hardware token protocols: what are they, and what role do they play in your organization's cybersecurity? In today's article, our ethical hackers outline the most common hardware token protocols.

October 24 - Blog

Packetlabs at SecTor 2024

Packetlabs is thrilled to have been a part of SecTor 2024. Learn more about our top takeaway's from this year's Black Hat event.

September 27 - Blog

What is InfoStealer Malware and How Does It Work?

InfoStealer malware plays a key role in many cyber attacks, enabling extortion and lateral movement via stolen credentials. Learn the fundamentals about InfoStealers in this article.

Packetlabs Company Logo
    • Toronto | HQ
    • 401 Bay Street, Suite 1600
    • Toronto, Ontario, Canada
    • M5H 2Y4
    • San Francisco | HQ
    • 580 California Street, 12th floor
    • San Francisco, CA, USA
    • 94104