Author: Felipe Ferrari

Nowadays, most people take it as a fact that the software we use daily is secure, and that is not really representative of the reality we live in in the software industry. A lot of the software on the market today has been written with the priority of being in production as soon as possible and without much consideration for the security aspect. This neglect of code and infrastructure security risks poses a significant threat. A single security vulnerability can lead to a wide variety of problems, including data breaches, financial losses, legal concerns, and a long list of harms to customers and to companies as well.

In this article, we will go through potential security vulnerabilities that can be found in the code and in the infrastructure, specifically focusing on code and infrastructure security risks. By understanding these risks, we can better address the challenges associated with maintaining secure software systems. Additionally, we will explore some metrics that can be useful to keep track of potential security vulnerabilities and mitigate them effectively.

In this article, we are going to go through a couple of solutions to a common problem when developing mobile applications, and this is Dependency Injection.

We all saw a project that was calling singleton classes from any part of the code without any security when writing data to them, battling with race conditions, and coupling implementations to all these issues. You can also find many third-party libraries that can help to solve or at least manage these problems, but many times we don’t want or we can’t add extra dependencies; in this case, a good approach is to implement the solution that fits your needs in a basic but sufficient way and with native code.
To start with this, we will go through the problem first and see what would actually help us. Let’s say we have a class called AViewModel that needs to use ServiceA; the first thing to think of is to instantiate the service in the initializer or directly inside the class like this:

In this article, I’ll be comparing the encryption standards we consider safe with the actual technology and what could make them not be safe anymore during the coming years. I will also try to analyze how we can prepare for the future at different scales in our industry — software development.

First of all, I want to expose the two main types of encryption that the majority of software we use relies on. This is mostly based on what the USA’s National Institute of Standards and Technology (NIST) states, as of today, in 2022.