It is by no means a given that your app is secure. When we've assumed existing projects at Rappid Design, we've rarely seen any that would be considered secure. Even with our own projects, we find it takes a concerted and continuous effort to ensure our clients data is secure.

I explore some of the strategies we have employed here at Rappid Design to mitigate risk and ensure our apps are as secure as they can be given the practical restraints of time and budget. I could devote many volumes to this subject given how involved security has become.

‍

Security SDLC (SSDLC)

We've found that making security part of your SDLC (Software Development Lifecycle) improves outcomes immeasurably, especially when operating in a constant delivery (CD) environment which is very common, especially when adopting an agile methodology.

‍

The inner circle in the image above contains the 4 major pillars of the SDLC. The outer circle shows the related security elements for those major pillars.

‍

General

We provide a level of security training to all those involved in the SDLC. It is surprising how much people are not aware of when attending training which serves to highlight its importance. There are good training platforms such as Udemy and Pluralsight which can provide a good starting point.

‍

OWASP Top 10

Our team keep a regular eye on the findings of the OWASP community. Their top 10 list of vulnerabilities is a key starting point for those involved in the SDLC to consider when securing their app. Having awareness of common vulnerabilities helps bake secure practices into the SDLC.

‍

Requirements

Requirements are part of any software process. When using agile we construct user stories to define feature requirements and provide detailed developer notes to influence the implementation. Where appropriate we provide some form of risk assessment to accompany these.

If the requirement is to allow a user to login to the platform, a risk assessment would highlight that to reduce exposure to malicious hackers, we should restrict login attempts to a predefined number within a specific interval before further attempts are blocked for that email and/or IP address for a specific time.

‍

Design

At Rappid Design, we break design into technical design and visual design. Our UX (user experience) team constructs the various screens and flows in Figma based on the requirements. Often referred to as the visual specification, this usually involves customer sign off before being moved into a sprint (an agile block of work for a team over a specified time, usually 2 to 3 weeks).

Technical design is the second part and this typically involves an architect who assesses the technology requirements and constructs a design showing how the technology will service the requirement. This is also our first good opportunity to introduce threat modelling where we look at what could go wrong. Stride, Vast and Trike are common threat modelling frameworks.

Many of our applications require compliance and go through security audits so we lean towards Trike. A score is given to each threat model which lines up well with scores provided in security audits.

‍

Development

The steps prior to development help the developer(s) code with security in mind. But there are many risks in this phase. The best risk mitigator we have found is to use a tool like Synk. Synk is a SAST tool which analyzes the code you have written to establish vulnerabilities. In the past we would run Synk with every code commit and if vulnerabilities were found, these get raised up to senior developer who will assign remediation work.

Now, however, Synk have a Visual Studio Code (our IDE of choice) extension which highlights vulnerabilities as you write code. It helps avoid the cycle of create and patch as code is theoretically only committed once vulnerabilities have been remediated. This paired with running a SAST tool on commits has been very effective for us.

Most applications are constructed using a number of libraries. A SAST tool will analyze vulnerabilities in these libraries and highlight whether some need to be upgraded or avoid entirely. We have found that the majority of security issues are raised in these 3rd party libraries so it has highlighted how careful we need to be when selecting such libraries.

Code reviews are also helpful in not only ensuring code meets a certain standard but that code is safe. No code gets committed without it being code reviewed.

‍

Testing (QA)

Our QA team use a variety of approaches to ensure software quality. Manual testing involves testing individual features, regression testing allows for testing the entire platform manually and automated testing allows us to test regularly when code is committed to identify problem areas early.

On the security side, this is a good opportunity to introduce DAST (Dynamic Application Security Testing). This is internal and is where a QA member will attempt to penetrate the system.

‍

Deployment

Security configuration is an essential part of this phase. Passwords for various services are stored in some kind of secret storage such that even our own team members are not aware of or have access to them.

For most customers we create at least 3 environments, development, staging and production. Staging is production ready and allows for external security audits to be performed. Although this is helpful, most external audits (DAST) will eventually be done in production.

Although great thought has gone into ensuring that the platform is secure at every level, we often add a WAF (Web Application Firewall) from a provider such as Cloudflare. Cloudflare is scanning all requests for potential threats before those requests even hit the platform.

This is an excellent first line of defence and provides an extra layer of comfort to our customers and us.

‍