What changes for you
The report stops being a list of open questions and becomes a list of fixes you can point to.
An external security test has looked hard at your product and written down what it found. Some findings are serious, some are minor, and a few read as if they were written for another kind of product. Meanwhile a customer, often the one who asked for the test in the first place, is waiting to hear what you will do about it.
The usual problem is not knowing what the report says. It is finding the people to act on it. Your engineers are already committed to the roadmap, and pulling them off it to work through a list of findings means something your customers asked for slips instead.
Here, the findings you choose are fixed in your own code. Each fix lands in your repository, where your team can read it, see what it touches and ask about it. The report you received becomes the list you work down, and the answer to your customer becomes a matter of showing what changed.
For you, the gain is time and a clearer conversation. The roadmap keeps its people. The customer gets an answer grounded in changes that exist, not in a plan to make them.
What you decide
You decide which findings come first. A report rarely sorts itself into the order your business needs. One finding may be the one your customer named in their email; another may sit in a part of the product few people use. You set the order, and you can change it when a new question arrives.
You decide the access. We work within the access you grant, and nothing more. If the findings sit in one service or one repository, the access can stop there.
You decide what is out of scope. Some findings concern things that are not code: your hosting provider’s settings, your company’s policies, or how your staff sign in to internal tools. Those are named as such and left with you, rather than stretched to fit.
You decide what a finding needs when the fix is not simple. Now and then the honest answer to a finding is a choice: retire an old feature, ask users to sign in again, or change something they have grown used to. Those choices come to you with the options and what each would mean for your users.
You decide what your customer is told. The fixes are yours to describe, in your words and at the level of detail your customer needs.
What you see along the way
You see the same list you started with, changing state. The findings from the report are the list you follow. When a finding is fixed, you can see it, and you can open the change behind it in your repository.
You see each fix explained in plain terms: which finding it answers, what was wrong and what is different now. An engineer who joined last month can follow it, and so can the person who has to answer the customer.
You see where the work stops. A report can name a risk without pointing at a single line of code, and some findings turn out to belong to a supplier or to a process rather than to your product. When that happens, you are told plainly, so the answer you give your customer is accurate.
We want to be clear about what this is not. It is not a certificate, and it is not a statement that nothing else is wrong with your product. A test looks at what it was asked to look at. The fixes answer the findings in front of you, and the judgement about what that means for your customer stays with you.
How the work is carried out stays confidential, as your work with us does. What stays visible to you is every fix, in your own repository, before you share it with anyone.
If the request came as a questionnaire rather than a test report, hardening security before the questionnaire is the page for you. Secrets never leave in a commit covers keeping passwords, keys and tokens out of your repository.
A sound way to begin is with the one finding your customer asked about first. Grant access to the part of the product it concerns, and see the fix in your repository before you decide on the rest.
