With the growing pace of applications embracing contemporary technologies like containers, Kubernetes and cloud native stacks like AWS and Azure, ensuring that apps using these technologies get secured is paramount. Product teams will end up having to prioritise security along with a truck load of other things on their backlogs. This poses significant challenges for companies trying to get their apps to the market on time.

In this article, we will look at a step-by-step approach towards Application Security Assessments that can help product teams to be proactive about application security, rather than being reactive.

Methodology and Steps

While many industry experts talk about various concepts to incorporate application security, DevSecOps has been a popular choice among top software giants. Among the many available, Gartner’s DevSecOps model has been one of the foremost proponents of this concept. Our article will focus on certain key concepts that will resonate with Gartner’s representation of DevSecOps and its implementation in the real world.

Read more: This is what’s making your DevSecOps inefficient

Taking this into consideration, we will propose our step-by-step approach to Application Security Assessment in two aspects: Manual and Automation. First let’s talk about facets of automation that can be implemented in a given software development lifecycle iteration.


Automation : The medium of implementation

In the contemporary scenario, applications are built to scale and are optimised for performance when they are deployed in production environments. This is where DevOps plays a key role to operationalise the agility of product development by deploying the apps seamlessly across their hosted infrastructure.  However, the challenge for the product teams lie in anticipating and preventing attacks from malicious users across the world.

Read more: The biggest issues with appsec automation

While traditional threats like Denial of Service or Distribute DoS attacks are quite well handled through IDS/IPS and WAF systems, sophisticated attacks like XML External Entity(XXE), Insecure Deserialisation or Insecure Direct Object Reference  flaws still tend to exist in many applications.

Product teams should look to create feedback loops across the SDLC to provide information about new and existing vulnerabilities. This can be achieved by embracing automation to enhance application security.

Going in this order helps product teams to start shifting security left, iteration after iteration and ensure that they are able to scale up on maturity across sprints. This will be much more effective with the following changes in the team culture.

Read more: Why one issue made this dev team change their whole methodology

With that, we will now look into the list of things product teams will have to execute manually as part of their security checklist.

Manual Assessment: Things to consider

In the earlier section, we have discussed the automation possibilities to the Application Security Assessment challenge; and while it has its benefits, it also brings about a pernicious problem of result management.

Read more: Why automatic vulnerability correlation is so important

Among the many challenges the product teams have in dealing with qpplication security, arguably one of the biggest ones is prioritisation. Given that the product teams collectively have limited time in any given sprint, this means that security is one among the many things that they will have to do. Invariably, application figures quite low in the ranks given its propensity for obscurity and complexity.

Here are some ways you can effectively utilise the results from tool automation:

Check it out: Vulnerability metadata is more important today than ever before

Product teams looking for success in conducting application security assessments should keep in mind that both tactical and strategic awareness are essential ingredients.

The key is in finding the right balance among these two aspects and iteratively pushing the boundaries of appsec capabilities within the team. It’s always better for teams to start small and from the left of the proverbial software development lifecycle.

Leave a Reply

Your email address will not be published. Required fields are marked *