pentest for startups

For many startups, cybersecurity and penetration testing in particular are issues that need to be addressed because of the requests of their customers or investors. 

Some startups have a security by design approach and processes that integrate security testing into the software development cycle. Other startups are less mature on the subject, as they do not have in-house security skills. They have questions when it becomes necessary to perform a first pentest. 

Our expertise in pentesting and our experience with many startups (from early stage to series C and beyond) allow us to advise you on an approach adapted to your objectives and development phase.

Security and pentesting requests from startups’ clients 

Large companies vs. SMBs

Depending on startups’ customer profile, the security requirements are not the same. For startups that sell digital solutions to large enterprises, security is an essential element. Information systems of large companies must comply with cybersecurity standards (ISO27001 for instance). This implies selecting third-party solutions that provide security guarantees. For many startups, this means that the client may request a pentest report or other documents (security policy, incident response plan, etc.) during the purchase process of the solution.

For startups that sell their solution only to very small companies and SMBs, security requirements are generally lower. If customers aren’t very mature on the subject and don’t perform security audits for themselves, they are unlikely to ask for a pentest report from a provider. However, this is probable to change as the security level of small businesses increases. For example, startups that formalise security policy and have regular audits in place to meet their clients’ enquiries are then becoming more demanding to their service providers on security issues. 

For startups that offer mainly BtoC or CtoC services, there are no security requirements during the purchasing process. However, depending on the service and the type of data handled by the solution, presenting security guarantees and above all avoiding incidents help to strengthen user confidence and may lead them to choose one platform over another.

Pentest, security policies, incident response plan…

The security requests expressed by startup clients may concern several types of deliverables: risk analysis, security audit report, security policy, incident response plan, etc. Not to mention the declarative forms to fill out.

Some demands can be confusing, especially when it’s the first time you’ve been asked to do this. From one large company customer to another, the documents needed are different and the security requirements don’t focus on the same elements.

Being ISO27001 or SOC2 certified allows you to answer many questions and to attest to the implementation of protections based on standards. If you don’t pass these certifications, having a formalised information policy helps to show that various subjects are well handled internally. Besides, sharing security audit reports on the scope that interests clients (at least the solution evaluated as part of a purchasing process, or even more broadly the IT systems of the solution editor potentially exposed to attacks) illustrate in concrete terms that a third party assessed the level of security. It also attests the resolution of the security problems that may have been identified.

Pentest tailored to startups

Penetration testing services and deliverables

The pentest is tailored to the security objectives and the scope of the analysis. If the end clients are primarily focused on protecting their data, the possibilities of accessing an online solution from the outside should be tested first. If it is a SaaS (multi-tenant) solution, the possibilities of accessing a customer account via another customer account should also be tested first. The integrity of the customer journey is a major issue? Priority should be given to testing the entire customer journey for technical and logical vulnerabilities. Service continuity is critical? DoS testing should be included in the pentest. And so on.

The deliverables are also adapted to the final objectives. In addition to the technical report, which is the primary deliverable where each identified vulnerability and the technical fixes to be implemented are described, it is possible to obtain different documents more aimed at communication purposes:

  • re-audit report attesting of the correction of the flaws, 
  • non-technical summary for management or external partners, 
  • security audit certificate or security seal allowing general communication without disclosing details of the pentest carried out.

Adapting pentest to the release cycle speed

Pentests can be conducted at regular intervals. Performing recurring penetration tests can meet many objectives: steadily testing the scope (carrying out several ‘small’ pentests spread out over time, rather than a ‘big’ one at a time), testing the patches implemented following previous penetration test sessions, and testing new developments as they are put into production.

For a startup that has developed a product (web / mobile / IoT), regular testing new developments is a major challenge to ensure the security of the product. It is common to think about the right frequency of pen testing: every year? every six months? every quarter? every month?

The right answer depends on several factors: the criticality of the target (or the requirement level of the end customers), the release cycle speed and the ability of the technical team to integrate security feedback as it comes in.

For most startups, the right balance lies between one pentest per semester and one pentest per quarter (i.e. 2 to 4 pentest sessions per year). For particularly critical solution (e.g. payment methods), one penetration test per month may be chosen. In this case, the tests are shorter and focus on the latest changes, to prevent any possibility of holes in the system.

In some other cases, the rate of one pentest per year is taken. It is then a very comprehensive pentest that allows testing in depth and focusing on all functionalities of the new version. This applies to startups that are relatively autonomous about security and whose end customers do not require to see very recent reports.

Adjusting pentest to an increasing level of risk exposure

Although cyber risks affect everyone and there is no such thing as zero risk, there are different levels of risk exposure. For example, a startup that publishes online payment methods or a cryptocurrency platform is a more critical target than a startup enabling services between individuals. 

But the level of risk exposure does not depend solely on the core business. A startup that has raised several million euros will amplify its media visibility and will be seeking to increase its market share, which also intensify cyber risks. The acquisition of first customers or large company partners enhance cybersecurity requirements. In addition, as they grow, many startups are asked to develop new services or products, thus expanding their portfolio and their attack surface. As the number of employees rises, so does the organisational complexity, therefore a need for more security processes and controls, and more risk of social engineering attacks.

It is necessary to take into account the stage of development and the level of risk exposure in order to implement a pentest strategy adapted to the realities of startups. Contrary to popular belief, it is possible for a very young startup to start performing penetration tests on a reduced scope with a very small budget. Integrating an initial security feedback via a mini-pentest will give a startup the opportunity to ensure the solidity of its foundations and to quickly rectify certain technical choices if necessary.
Then, the audit can be planned in an incremental way as the sessions progress: slightly more in-depth tests on certain particularly sensitive functionalities, then increasingly complete tests on a technical scope, then tests integrating social engineering attacks, then an in-depth review of the cloud infrastructure, etc. Working in this way makes it possible to gradually support a startup on its concrete security challenges, by adapting the tests to the priority issues and the budget.

Pentest budget

With Vaadata, the budget for a pentest can vary from €675 to €30,000. Between these two extremes, there are almost infinite nuances. For a startup, the amount for an audit is often between €3500 and €10,000. 

This average takes into account startups in different industries, with different levels of security requirements and different levels of functional and technical complexity of the product. Our point of view is that it is always possible to adapt to a client’s budget, knowing that in some cases budget constraints will lead to a review of the scope and/or depth of the pentest, and that it will be possible to work in stages to split the tests and therefore the security expenses.

Complementary tests: vulnerability scanner, bug bounties…

Vulnerability scans (automatic searches) and bug bounty platforms (crowdsourcing) provide complementary solutions to pentesting. Between two pentest sessions, these solutions carry out continuous testing, but they each address different needs.

For security tests on a large portfolio or a large volume of targets, vulnerability scanners are an appropriate solution. They contribute to a first level of testing on a very large perimeter, in addition to regular penetration tests on the most critical and/or technically representative targets. When the volume of targets is smaller, vulnerability scans can also be a first step in ‘roughing up’ the work before a penetration test and in internalising a first level of security testing. However, it should be kept in mind that handling these tools requires time and skills, whereas a pentest can also identify first-level flaws (in addition to complex flaws) without any additional cost.

For security tests on a critical target exposed on the Internet, bug bounty is an interesting solution. It will allow searching for rare flaws without time constraints, since some researchers will accept to spend a lot of time digging a lead in exchange for an attractive bonus perspective (attributed only if a flaw is finally identified). This will be complementary to regular penetration tests that cover a scope in a methodical and comprehensive manner.

Choice of security and pentest providers for a startup

Global approach or specialisation

When choosing a security provider, the question arises of whether to choose a company offering a complete range of cybersecurity services or a hyper-specialised company. In one case, the advantage will be to have a single entry point for different types of services. In the other case, the advantage will be to focus on a very strong expertise in a particular field (such as pentesting). 

At Vaadata, we believe in hyper-specialisation to ensure a maximum level of efficiency in penetration testing. It is possible to work with different partner companies to facilitate exchanges and to have a main contact to ensure an overview of the different security topics.

Experience with startups and ability to adapt the service

This aspect is essential for cybersecurity services. Indeed, the risks are not at all the same for a startup early stage and for a mature company of 500 people. The level of risk also depends on the core business and the technical context, but generally, startups need people who can adapt to their constraints and budget.

There is also a notion of pragmatism in supporting young companies on cybersecurity issues. Some services allow to quickly obtain concrete feedback and to correct a first level of vulnerabilities. Other services correspond to a more global approach to risk management, and are therefore potentially longer and more costly. It is interesting that the service provider can propose a process based on iterations. For example, it is possible for a pentest to start with rapid tests on the most exposed perimeter, then gradually add more in-depth tests and/or tests on a wider perimeter. This can be done in a series of stages spread over several years, depending on the pace of development of the startup and the growth of its security challenges.

Internalisation and appropriate tools

Some cybersecurity tasks can be internalised, depending on the time and skills available in the startup’s team.

The most frequently internalised tasks in startups are that of DPO and CISO, which are combined with other functions. Thus the CISO mission often falls to the CTO or CIO, who is responsible for an overall vision of the IT systems, including security. From an operational point of view, this means dealing with security issues by relying on various service providers to prevent incidents and to meet partners’ requirements.

Sometimes startups internalise a first level of technical skills in security, for example with an experienced developer capable of conducting a first level of tests using different tools. This has the advantage of clearing the ground before having a pentest conducted by a specialised third party and of obtaining more positive reports to share with the startup’s customers and partners. It also allows the specialist provider to focus on finding complex vulnerabilities and therefore on its real added value.

Priorisation of actions

For startups and more generally for solution providers, security priorities are usually decided according to customers and market constraints.

However, after meeting urgent business requirements, such as being able to quickly show an audit report to a prospect to unblock a situation, it is important to take the time to look at the bigger picture. For example, some of the issues raised by a security audit require impactful changes in development practices. The result of an audit can be used as a basis for establishing a technical security roadmap. 

In addition, preparing for a security certification will enable priorities to be clearly established by identifying the company’s weak points and the actions to be implemented in the short, medium and long term.