Adding security into the SDLC

Why do I need security in my SDLC?

You might be asking yourself if adding more tasks, tools, and processes will make your system run slower and cause you to lose productivity. It might seem overwhelming at first, but once we add security to each stage of the process, we will start to see the benefits and identify potential issues before reaching production.

This type of early detection is beneficial to productivity and is a good use of resources. It’s one thing to fix problems in the design stage, and quite another to fix them during implementation or when already in production, at which point the cost increases exponentially. Not to mention the potential impact of deploying an application with vulnerabilities in production, which could cause a company to lose its reputation and even lead it to bankruptcy.

Adding security to our SDLC

Let’s look at some keys that I believe are important when including security in our development:

Define a budget for training. Identify skills that need to be worked on and suggest related courses. It is important to consider each person’s role and not ignore their interests. Motivation is important.
It makes a team of Security Champions. Select a person from each team to take the security ambassador role in the team. It is best to encourage personnel and ask for volunteers. This person should dedicate a small percentage of their time to security, and the rest to their usual tasks. They will become a point of contact between security and their team, leading security-related tasks.
Define security requirements based on the needs of the companies, whether they are internal requirements or applicable regulations (GPR, HIPAA, PCI, etc.).
Add the threat modelling task. There is no need to impose short-term results. This is something that will require a period of adaptation and learning.
It involves all team members. It is not just about architects or security personnel.
Each team member will have a vision to contribute.
You cam start with manual modelling , hosting interactive sessions, and brainstorming.
Once the process has been assimilated, evaluate the usefulness of an automatic tool such as IriusRisk. It will make the procedure easier, from the diagram to the results, generating threats and counter-measures, and integrating with tools that developers use daily.
Add unit, integration, functional, and/or architectural tests to verify that we don’t have known security problems. For example, validation of user input, security communication between components, or to check if functions are used which are not permitted in development, etc.
Add tools to find secrets and analyse the code and dependencies.
In development environments for which teams have feedback and can see as early as possible if they are doing something that could be a security risk. It is important for this to be as transparent as possible for daily work and not to involve additional effort.
Some options to apply:
Plugins in IDEs.
Add tasks to pre-commits.
Integration in pipelines:
Attempt to merge one team into the stable branch of the project
In the step to release, when preparing the new version of our project.
Vulnerabilities in dependencies can vary from one day to another, and therefore if the frequency of merges or work in repositories is low, the pipeline can be launched daily. The same would apply if there are many merges into the branch every day.
Add dynamic analysis tools:
Integration in pipelines:
Daily, weekly, or monthly launch. Must be adapted to development times.
Launch prior to each step to production of a new release.
Perform manual security tests:
In each release, limited time:
Analysis of the new functionality.
Analysis of critical parts.
Analysis of problems similar to those found in the past.
Annually:
Carry out pentesting every year, every six months, or whenever there are major changes to the application.
Monitor logs: once in production, review logs and monitor security events to identify any anomalous behaviour (multiple sign-in attempts for an accounts, multiple attempts to access resources without permission, user input validation failures, etc.).

Security personnel involved in these tasks should not be independent and isolated from the development teams. They should be part of the teams and collaborate with them.

Conclusions

As a final thought, it is important to remember that not all companies are the same, and that not all teams work in the same way. Therefore, the integration of new security tasks and organisation is not set in stone. Each case should be analysed and adapted to existing needs and available resources.

It is always good to remember that impositions and a lack of explanations do not usually end well. It is important to be transparent and explain the benefits and requirements for the team to get involved.

‍