API - Application Programming Interface. Software development to

Application Security (AppSec)


27th October 2021

5 min read

Implementing application security (AppSec) from the beginning

There is a movement in the IT security world that is gaining traction, and it is based around the implementation of security within applications from the beginning. You may have heard buzzwords like “AppSec”, “DevSecOps” and “Shift Left”, but what do they actually mean? What does it take to “Shift Left” when developing a secure application? You can read about dealing with dependencies in our blog post Enhancing Security in your Software Development LifeCycle – Dealing with Dependencies.

In this article, we will explore how implementing security testing and controls earlier on in an application’s Software Development Life Cycle (SDLC) can impact a business. We will also discuss the ways a traditional application assessment may bring to light bigger issues than just insecure code, as well as the differences between the remediation performance of any potential vulnerabilities.

Using SQL injection as an example, even though injection has slipped in the OWASP Top 10 this year, injection attacks are still prevalent and common during application tests. Consider that an application has been fully developed in the ‘traditional’ method; no security assessments were performed at the beginning (threat modelling) or during (secure code reviews). Then, before the application is put into production, a security assessment is required for assurance purposes.


The scenario

Consider a scenario where a software development company contacts us for an application assessment. The application consists of a bootstrap frontend. There is a search form for querying critical business information, such as customer order details from an online retailer. The frontend end is supported by an API, which queries the business-critical database.

During the application assessment, a consultant identifies a potential SQL injection vulnerability in the search functionality with an apostrophe (‘). A database syntax error is returned.

There are many actions we could perform at this point. However, we only need to validate the weakness, for which a sleep command will suffice. Once the vulnerability is confirmed, a call is made to the relevant security contact and we discuss in-depth the vulnerability that we have identified and our recommendations to remediate this.


What next?

The consultant continues the application assessment in the hunt for more vulnerabilities, but the client now has a situation on their hands. An application has been developed to the point of release and all of a sudden, a significant security issue is identified.

This causes a number of challenges. Do the developers action the finding, mitigate the issue by ensuring database queries are parameterised and user input is sanitised, and accept that there are no longer any bugs in the code? Or, should they perform a full code review to supplement the application assessment with a further level of assurance?

Consider that the application does not solely support searching for customer orders. It likely supports queries for searching for items, quantities, sizes and colours; which may all support additional filters such as ordering or grouping. All of which may provide an opportunity for a malicious actor to achieve SQL injection.

There may be thousands of lines of code to analyse and check for entry points and insecurely written database queries. This takes a significant amount of time and often results in development teams missing deadlines and overspending on this remediation activity.


Shift Left, DevSecOps?

This is why Shift Left and DevSecOps (or SecDevOps) have come into the spotlight. The industry wants to build secure applications from the ground up which eliminates the need for the above remediation activities.

This may consist of threat-modelling prior to any code being written. A detailed plan of the application structure, its processes, inputs and outputs, and authentication mechanisms is used to identify where weaknesses may be found in the development stage.

Developers may be trained to write secure code or given access to tooling that will help to identify and explain potential vulnerabilities. There are tools available that analyse code or can be implemented into DevOps pipelines that automatically check for vulnerabilities and provide detailed information, prior to being accepted and merged into the codebase. The following describes the types of security tools that can be utilised and how they differ in their approach.

  • Static Application Security Testing (SAST) – Tools that implement static testing methodologies will scan source code with the aim of identifying vulnerabilities. They will perform these code reviews of the programming language you use and automatically discover any vulnerabilities that may be present, without having to run or execute the application at all.
  • Dynamic Application Security Testing (DAST) – Dynamic testing tools will analyse applications whilst they’re are running, without reviewing the source code. These tools will use methods, such as fuzzing, to attempt to find vulnerabilities dynamically and therefore is not programming language specific.
  • Software Composition Analysis (SCA) – Software composition analysis tools are designed to identify any open source software that is included in the code base. These additional open source libraries may introduce unwanted vulnerabilities and SCA can help identify them before your application is put into production.
  • Interactive Application Security Testing (IAST) – This a hybrid testing methodology which combines static and dynamic approaches into predefined test cases to find vulnerabilities within software. These tests can either be automated or performed by a security professional.

Each approach has its own pros and cons and it’s often the case that multiple approaches are implemented to ensure a greater level of assurance.

Final thought

Shift Left and DevSecOps are not going to happen overnight and are not a responsibility that relies solely on the development team. The shift has to be adopted by the entire organisation and support should be given to the development team by offering expertise and tooling. Collaboration between security teams and development teams should be encouraged.

There should not be a compromise between rapid development cycles and best practice security. When an organisation adopts security early on, both can be achieved. This will improve security posture and reduce costs of security integration while maintaining fast delivery which ultimately leads to business success.

Get in touch with us today and see how we can assist your development team in building secure applications.


  • Insights
  • Labs
White box penetration testing

Uncovering vulnerabilities with white box penetration testing

As a business owner or IT professional, you understand the importance of protecting your company’s sensitive data, systems and reputation from cyber threats. One of…

API penetration testing

Securing APIs through penetration testing

APIs (Application Programming Interfaces) have become the backbone of many modern applications, and indeed the foundation of some businesses services. APIs enable seamless communication between…

The importance of a post-penetration test action plan

The importance of a post-penetration test action plan

As cyber threats continue to evolve and become more sophisticated, businesses must stay one step ahead in protecting their sensitive data and network infrastructure. Penetration…

How to choose the right penetration testing partner

How to choose the right penetration testing partner for your business

In today’s digital landscape, cybersecurity threats are evolving at an alarming rate. With the growing number of cyber-attacks and data breaches, businesses must prioritise their…

IoT device security, penetration testing

Securing the Internet of Things: Penetration testing’s role in IoT device security

The world is witnessing a remarkable transformation as more devices become interconnected, forming what’s known as the Internet of Things (IoT). From smart refrigerators and…

Man working as a junior penetration tester

My first month working as a junior penetration tester

Entering the world of cyber security as a junior penetration tester has been an eye-opening experience for me. In my first month, I’ve encountered challenges,…

Password cracking: How to crack a password

An introduction to password security: How to crack a password

Online Password Cracking An online attack is performed in real-time, against live services or applications to compromise active user accounts. Such attacks typically occur when…

Application Security 101 – HTTP headers

Application Security 101 – HTTP Headers Information Disclosure

Server Header Information Disclosure The most common HTTP header that is enabled by default in most web servers is the ‘Server’ header, which can lead…

SPF, DKIM, DMARC and BIMI for Email Security

SPF, DKIM, DMARC and BIMI for Email Security

Sender Policy Framework Sender Policy Framework (SPF) is a DNS TXT record that is added to a domain that tells email recipients which IP addresses…

Terraform security best practices

Terraform security best practices (2022)

The following sections discuss our most important Terraform security best practices: The importance of Terraform State Terraform must keep track of the resources created. When…

Security vulnerability in Follina exploit

Preventing exploitation of the Follina vulnerability in MSDT

The Follina Exploit A zero-click Remote Code Execution (RCE) vulnerability has started making the rounds which is leveraging functionality within applications such as Microsoft Word.…

Application Security 101 – HTTP headers

Application Security 101 – HTTP headers

1. Strict-Transport-Security The HTTP Strict Transport Security (HSTS) header forces browsers and other agents to interact with web servers over the encrypted HTTPS protocol, which…