WordPress Migration from OVH to AWS
The Revista GODOT website used to go down every day. Now it doesn't go down, and it costs 30% less.
30 % in server savings, with better performance than before
Custom software
Technical Review of Your Software
Your software was developed by another supplier or by your own team, and you don’t know whether it was built well. We review it from the inside, tell you what is good and what isn’t, and give you a plan to fix what matters.
- Code review
- Report by priority
- Second review
Who it is for
It is for you if…
- Companies with their own software that will grow with it. And who want to know whether it is well built.
- Anyone buying a company or a piece of software who wants an outside opinion before signing.
- Anyone changing supplier who wants to know what they are taking over and what needs fixing.
- Anyone who has had a security incident and wants to know what other flaws remain.
It is not for you if…
- Anyone who wants someone to try to break into their system from outside (a penetration test). We review the code from the inside. These services complement each other.
- Anyone who wants a report to put in a drawer without fixing anything.
What you get
- Report sorted by importance
Each problem with what could happen, where it is in the code and how urgent it is. Written for the decision-maker, with the technical detail in a separate section.
- Fix plan
What to fix, in what order, how much effort it takes and what evidence each fix leaves behind.
- Second review
After the fixes, we review each problem again and confirm that it has been resolved.
- Shareable summary
A document you can share with a client or an investor without giving details that could open up new risks.
What we review
We review the code, its internal structure and how changes are published. Who can access it and what they can do. Where access keys are stored. How personal data is handled. Which third-party components it uses and whether they have known flaws. What tests exist. And whether there is a record of who did what.
How we rank what we find
Not all problems weigh the same. Each one is measured by what could happen, how easily it could happen and how much it costs to fix. You get a short list of what is urgent and a longer list of what is worth fixing over time.
Fixing it and checking that it’s fixed
The plan can be carried out by your supplier, by us or by both of us together. When it’s finished, we review each problem again and confirm in writing that it has been resolved.
If your client or the law asks for more
The report includes the method, what was reviewed and the evidence for each problem. There is a summary version to share with a client or an investor, without details that could open up new risks. A large client may ask you for an external review, or someone may want to look at your code before a purchase. This is the report they will want to see. If you sell to the public administration, what its security rules require is on the Custom software page.
What we build it with
We review the code in your repository, the place where it is stored with its full history, under a confidentiality agreement. We keep no copies. We check what we find against the OWASP list of the most common flaws in web applications, and against previous reports if there are any. We also look at how the servers are configured and at the automated publishing process (pipeline). Each problem found comes with its evidence in the code, its impact and its priority.
Glossary
- Code
The instructions that programmers write and the computer executes. This is what we review.
- Internal structure
What components the software has and how they communicate with each other. In the industry this is called architecture.
- Third-party components
Parts of the software not developed by your supplier, but by third parties, on which your software depends. If one has a security flaw, so does your software.
- Security breach
A flaw that could allow someone to access or see what they shouldn't.
- Confidentiality agreement
A contract in which we commit not to disclose anything we see.
What problems it prevents
What can go wrong and how we prevent it.
- Fixing what doesn't matter first
Problems are sorted by their impact and the likelihood that they will occur, not by the order in which they appear.
- A problem being considered resolved when it still isn't
The second review checks each one and confirms it in writing.
- The review turning into a full rewrite of the software
The plan is specific and has a clear scope. A large change is split off and quoted separately.
- Your code ending up in other people's hands
Only the assigned team can see it, under a confidentiality agreement. We keep no copies.
A related case
Frequently asked questions
It depends on the size of the code and on whether there are previous reports. After the initial meeting we agree on what will be reviewed and when you will receive the report. The second review takes place after the fixes.
Only the assigned team, under a confidentiality agreement. We work with access to your code and keep no copies.
First, a meeting to agree on what will be reviewed. Then we send you a fixed quote. Fixing what we find is quoted separately, if you want us to do it.
Yes. It includes the method, what was reviewed and the evidence for each problem. The shareable summary is designed for exactly that: a client or an investor.
Yes, it does. We only need access to the code and any documentation you have. If you don't have the code, mention it in the meeting.