Most breaches are ordinary, and so is the security work that stops them.
The software holding your customer list, your prices and your staff records is a business asset. It is also the one asset nobody opens until something has already happened.
Security work on an application is not dramatic. It is reading the code, checking who can reach what, keeping the parts current, and fixing what turns up in an order that matches the risk.
Application security is the work of finding the ways your own software could be misused, and closing them, rather than a product you install. The usual questions are plain ones: can a customer change a number in the address bar and see another customer’s order, and are passwords stored properly. Then there are the libraries your system is built from, and whether any of them have known holes.
Where it earns its place.
The work we actually do
- Secure code review, by reading the code rather than only scanning it
- Checking permissions endpoint by endpoint, not screen by screen
- Dependency and version upgrades on a schedule, not after the news
- How passwords, tokens and uploaded files are stored
- Server and database access, and who holds which key
- Fixing what is found, in an order agreed with you
What we do not do
Worth saying at the start rather than in a footnote at the end.
- Certify you against any standard
- Act as your auditor or issue you a certificate
- Make your business compliant, because that obligation is yours to hold
- Run penetration tests ourselves, rather than through qualified specialists
What we can do is build the mechanism a standard asks about, and write down plainly what the system does and does not do. An assessor then judges it. The duty stays with your business, which is also where the decisions about risk belong.
The findings that come up most
Nothing exotic. These are the ones we meet on real business systems.
- An id in the address bar nobody checked belonged to the person asking
- An admin screen protected only by being hard to find
- An API endpoint that trusts the app to have checked the permission
- Old libraries with published problems and a fix already available
- Backups and log files readable by more people than anybody intended
- One administrator password four people know
How a piece of work runs
- Scope
- Review
- Findings
- Fix
- Retest
- Routine
- Agreeing what is in scope and what must not be touched
- Reading the code and the access rules against how the business works
- A written list ordered by what would actually hurt
- Fixes done by us, or by your own developers if you prefer
- Checking the fix closed the thing it was meant to close
The retest is the step usually skipped. A finding marked fixed and never checked again is a finding that is still open.
Keeping it from drifting back
A single review ages. The library that is current today has a problem announced in March.
- Security patching inside ordinary maintenance, not as an event
- A permission check written alongside each new feature
- Error reporting, so an attempt is visible rather than silent
- A named person who receives the alerts
- A yearly look at who still holds access, and why
When this is the right choice.
- The application holds customer, staff, health or payment records
- A customer or an enterprise buyer has begun asking you security questions
- The system was built by somebody who has left and nobody has read the code since
- Access has grown by exception over several years
- You are preparing for an assessment and want the software ready before the assessor arrives
When it is not.
- A business that wants a certificate, which has to come from a certification body and not from a development company
- An organisation that will not fund the fixes, since a list nobody acts on only records the problem
- A system still being designed, where getting the access model right now costs less than reviewing it later
- A brochure website with no login and no data, where patching and a backup are the whole of it
Questions we are asked about it.
Can you make us ISO 27001 or SOC 2 compliant?
No development company can. We build and document the technical parts a standard asks about, such as access control, logging, backups and patching. The audit itself is done by a certification body, and the obligation stays with your business.
Do you do penetration testing?
We arrange it through qualified specialists rather than claiming it ourselves, and we fix what they find. Keeping the testing separate from the building is the point of doing it at all.
What will a review cost us in downtime?
Reading code and access rules costs none at all. Fixes are released like any other change, through staging first, and anything risky is scheduled with you rather than done on a Tuesday afternoon.
Our software was built by another vendor. Can you review it?
Yes, and it is common work. We need the code and access to a test environment. Where the code is not available, the review is limited to what can be seen from outside, and we say so in the report.
How often should this be done?
Patching belongs in ordinary maintenance every month. A proper read of the code and the permissions is worth doing yearly, and again after any change to who uses the system or what it holds.
Will you tell us if the answer is that we are fine?
Yes, and it does happen. The report says what we looked at and what we did not, so you can see the shape of the assurance rather than only a verdict at the end.
Services that use it.
What it sits with.
Not sure Application security is the right choice?
Tell us what the software has to do and who opens it. If something else fits better, we will say so, and say why.
- No obligation
- We reply the same working day
- Your details stay private