We care about your product's security

Digital product design: Security comes first!

When we begin developing a digital product, the process has a number of priorities – target users’ issues, client partner’s business goals, innovative design – but equal to all these, from day #1 of our commitment to our partner’s product, security is an essential focus.

To begin with, even our standard product discovery workshop outline, which targets the product concept and business idea, enables us to learn about the partner’s business and the product itself – valuable context that helps us map potential vulnerabilities and risks that will be addressed later in the process, when building the product backlog of priority tasks.

In fact, throughout the development process, the development team monitors security issues and ensures that our security standards are applied in practice. Here are some examples of our approach to product security when working with our partners:

• Dependencies – It’s a common (and highly effective) practice to use open source third-party components (libraries, frameworks, modules) in app design. After all, if every element of every digital product was designed from scratch, the product would never reach the marketplace! However, while open source components are often cited as superior, the risk here is that these component pieces contain bugs and vulnerabilities which, in turn, means the security of your finished product is dependent on those bugs and vulnerabilities.
• Bug-catching – Or, to put it another way, the art of using tools to scan the app’s codebase for bugs in the programming. Utilities such as PHPStan or kics allow us to check for basic misconfiguration, quickly and easily.
• Code review – Reviewing and auditing the product’s code not only improves app performance, it can catch potential security breaches as well. We regularly carry out reviews as a precautionary measure, especially before an app is deployed to the live production environment.
• Code refactoring – To avoid problems that might be hidden in the code of mature products, we sometimes carry out a code refactoring. Aside from addressing potential security issues, this helps to avoid technical debt, and often provides users with greater value. (Check out this example of a recent code refactoring exercise).
• Beware of technical debt – Technical debt occurs when developing a product without sufficient thought or anticipation of future scaling: you do the job well according to today’s needs without sufficiently considering tomorrow’s. It’s what a product accrues if you don’t refactor your code when making improvements or adding features. It also happens naturally when you develop MVP versions of products. So, technical debt is often inevitable – you just need to be aware of the potential security risks and bear that in mind during the development process.
• Logging in securely – We suggest giving an app’s users the option of logging in via their Facebook or Google accounts and credentials. This tends to be more secure than having separate credentials and passwords. For a start, users that create a new user account for every app or platform also tend to reuse passwords, which is a risk. Then, if one app or platform is breached, the cyberattacker now has access to multiple accounts. If single sign-on isn’t possible, we recommend securing passwords with encryption (using algorithms like bcrypt or argon2i).
• Penetration testing (pentesting) – Pentesting (sometimes called ‘ethical hacking’) is a controlled attack done for the purpose of identifying any weaknesses in an app or platform’s security. It is not necessary as a standard – not every product is perceived as a potential target – but it can help in the prevention of critical vulnerabilities for the future. When working with a partner whose product will be handling confidential information, we strongly encourage pentesting.
• Last but not least - all the products are being reviewed by a QA specialist.

These are the most common security issues when developing or improving a digital product. Our approach is to talk through the risks and potential countermeasures with our partners throughout the product’s life cycle, keeping security on the agenda.

You might be also interested in the article:

6 Product Development Myths

Infrastructure security issues

What about infrastructure while we’re designing digital products? What about the security of the tools and resources that enable and manage the flow, storage, processing, and analysis of data? At Boldare, our default option (i.e. unless of course we agree with a specific partner to create something unique) is to go with the tried and tested, using the most popular and secure solutions.

• GitHub & GitLab – We use both GitHub and GitLab as version control systems to manage and host our source code software development. Both of these solutions are cloud-based, which guarantees high levels of safety and security, and both offer multiple security tools that prevent code from being overwritten or deleted, helping keep various dependencies safe.
• Cloud computing services – For most products we work with AWS or Netlify solutions to give us services that are both flexible and secure, including features such as daily backup while allowing scalability. What this means is that we don’t keep any data on our client’s servers. External solutions like AWS and Netlify are simply faster and more secure.
• Infrastructure as code – We also use Terraform (an open source infrastructure as code tool) for easier and more secure configuration of infrastructure resources. By using a tool like Terraform, we have the added advantage that everyone who joins a project can easily grasp how it works. Similarly, we use tools like KICS by Checkmarx to ensure that infrastructure configuration is secure.
• Principle of least privilege – As a fundamental design principle, within the infrastructure of a product, we ensure that all the ‘parts’ (whether processes, users or programs, etc.) can access only the data and resources necessary. Everything works but nothing has access to more than it needs – balancing performance with security.

Product security and the human factor

We know what you’re thinking (or what you should be thinking if you’re security-minded): all these processes and tools are great but what about the people using them?

We take no offense. It’s true that people can introduce risks into digital product development. That’s why, for a start, we make sure every single Boldare employee will take a security course during their onboarding process. It’s obligatory for everyone, regardless of job role or specialization and whether they’ll be hands-on involved in our partners’ products or not. This way we know that every Boldare employee knows how to spot potentially vulnerable situations. As they say, knowledge is power… it can also be security.

You might be also interested in the article:

Read also

What is trunk-based development and how can it benefit your product?

Besides that, we always try to go the extra mile when we think about a product’s security. We have two roles dedicated to security – Security Master and Security Maintainer – whose expertise is available to development projects on demand. Between them, these roles are responsible for defining and maintaining our security standards, keeping them strict, realistic and efficient. Furthermore, they monitor existing products, ensuring they continue to comply with those standards.

Security is an evergreen issue

According to the Ponemon Institute and IBM, 2021 was a record-breaking year for cyberattacks, with a 10% increase in average total cost and an expectation that 2022 will see an increase on that. There is no point in the future when security will cease to be an issue for digital products. That’s why, at Boldare we build a strong security focus into our product development processes, from the very first meetings and workshops right through to product scaling and maintenance. The most beautiful or intelligent app in the world is only as good as its security level.