Operators of B2B portals and dealer systems
Systems that external users log into. These portals carry customer lists and price data; an authorisation flaw here means commercial information leaking directly.
CUSTOM SOFTWARE · APPLICATION SECURITY
Application Security and Code Audit: The Audit That Looks From the Inside
We run security audits on delivered or inherited applications: authorisation and data access flaws, authentication weaknesses, injection risks, secrets and key management, dependency vulnerabilities. We also work on the side of closing the findings.
A business's most valuable data often sits inside its least protected application. The dealer portal carries the customer list and prices; the quoting system reveals the cost structure; the field application holds staff and customer data. These applications were usually written quickly, did the job, and then grew by accretion. Security was rarely a day-one priority — and afterwards, nobody went back to look.
The problems most often encountered in practice are not exotic. A user changing the number in the address bar and seeing another dealer's order; a weakly built password reset flow; a permission hidden in the interface but not checked on the server, callable from outside; the database password written into the code; a library not updated for years carrying a known vulnerability. These are all ordinary mistakes, and because they are ordinary, they are widespread.
The work we do is the audit on the code and architecture side. The authorisation logic is reviewed line by line; authentication and session management are assessed; injection risks in the data access layer are hunted down; where secrets are kept and how they are distributed is checked; dependencies are scanned against known vulnerabilities. Findings are reported not as guesses but by showing where they are and why they are a problem.
We state the boundary plainly: formal penetration testing is subject to a separate authorisation regime, and we do not claim to provide that service. Our work is code and architecture auditing together with the closing of findings; if you hold a penetration test report prepared by another party, we can work on closing the findings in it. This distinction is a mark of how seriously the work is taken; in proposals that promise both, one of the two is usually not genuinely done.
Who is it for?
Who is Application Security and Code Audit a good fit for?
Companies running inherited software
Businesses that have parted ways with the team that wrote the system and have taken it over. Not knowing the security posture at handover is normal; the audit should be done as a natural part of the takeover.
Companies exposing APIs externally
Businesses offering interfaces to customers, suppliers or marketplaces. Interfaces are usually written for internal use and opened up later, and the permission model is not revisited during that transition.
Owners of applications processing personal data
Systems holding staff, customer or health data. Here security is not only technical; it is the technical counterpart of a legal obligation.
What we build
What we deliver within Application Security and Code Audit
Authorisation and data access audit
We verify that a user can only reach their own data, and look for ways of reaching someone else's record by changing an address or identifier. We check that permission enforcement happens on the server, not in the interface. In practice, the most frequent and most serious findings come from this heading.
Authentication and session management
The login flow, password policy, password reset, session duration and multiple-session behaviour are reviewed. The reset flow is one of the most exposed and most neglected points.
Injection and data layer risks
How the database queries are constructed is examined; queries built by concatenation and unvalidated inputs are identified. Side routes such as file upload, exports and report generation are assessed as well.
Secrets and key management
Where database passwords, API keys and certificates are kept, how they are distributed and who can reach them is reviewed. Secrets sitting in the code repository are searched for, version history included; a secret that looks deleted lives on in the history.
Dependency and component vulnerabilities
The libraries in use are scanned against known vulnerabilities and an upgrade path is mapped out. Priority is set by whether a component is actually used, not merely present.
Closing the findings and knowledge transfer
Findings are ranked by severity and the fixes are applied; your own team can do this instead if you prefer. At the end of the work we leave a short secure development checklist so the issues do not recur.
Technologies
The technologies we work with
- Source code security review
- Authorisation model analysis
- Static analysis tools
- Dependency vulnerability scanning
- Secret scanning (code and history)
- API permission and input validation testing
- Logging and monitoring assessment
- Remediation and verification round
Process
How we move from discovery to go-live
- 01
1. Scope and access
Which applications will be reviewed, the state of access to the source code and the working window are agreed. Scope and duration are fixed in writing; whether the live environment will be touched at all is settled from the start.
- 02
2. Mapping the architecture and permission model
The application's data model, user roles and access logic are mapped. Most authorisation flaws hide not in individual lines of code but in this model itself.
- 03
3. Audit and verification
Findings are produced through code review, automated scans and targeted probing. Every finding is assessed for whether it is genuinely exploitable; a report full of theoretical warnings is useless.
- 04
4. Reporting and prioritisation
Findings are ranked by impact and ease of exploitation, each with a remediation recommendation. Items needing urgent closure go on a separate list and are reported ahead of the report itself.
- 05
5. Closure and re-audit
After the fixes are applied, the affected findings are re-tested and closure is recorded. The team is left with a short secure development checklist and a dependency update regime.
Frequently asked questions
Common questions about Application Security and Code Audit
Do you do penetration testing?
No. Formal penetration testing is subject to a separate authorisation regime, and we do not claim to provide that service. The work we do is the audit on the code and architecture side. If you hold a penetration test report prepared by another party, we can work on closing its findings. In proposals that promise both, one of the two is usually not genuinely done.
We don't have the source code — is an audit possible?
The scope narrows, but it is not entirely impossible. Reviews from the interface and data side, and the dependency assessment, remain possible. But the clearest evidence of whether the authorisation logic is built correctly is the code. If the source code cannot be reached, taking over the software comes onto the agenda first; that is a separate piece of work.
What happens if findings come up?
Findings are ranked by severity and reported together with remediation recommendations. Urgent ones are reported without waiting for the report. We can apply the fixes, or your own team can; the report is written clearly enough to make that possible. Taking the report and continuing on your own is also an acceptable outcome for us.
Will our system be affected during the work?
The review is carried out largely on code and configuration — that is, read-only. If probing on the running system is needed, it is done in a copy environment or in a window agreed with you, not on the live system. The live environment is touched only with your written approval.
How often should it be repeated?
A one-off audit shows the state at the moment it was done. As the code changes and the dependencies age, the picture changes. The regime that works in practice is this: dependency scanning runs continuously and automatically, while the full audit is repeated after major changes or at set intervals. We agree the frequency together, based on how fast the system changes.
What do we end up with?
An audit report with its scope in writing; findings ranked by severity, each with a remediation recommendation; a separate list of urgent items; the fixes applied and the re-audit results; a dependency update regime and the secure development checklist left with your team. Everything produced, report and applied fixes included, is one hundred per cent yours.
Contact
Let us talk about your Application Security and Code Audit project
In a 30-minute discovery call we listen to what you need and tell you honestly whether custom development or an off-the-shelf product is the better answer.
Related
Related pages and guides
Software Takeover and Recovery Test and Quality Automation KVKK Compliance and Data Governance B2B Dealer System Let's Audit Your Application After delivery: maintenance, support and capacity subscription
Architecture Consulting and Technical Debt Audit
We assess your existing software estate independently: an architecture map, a technical debt inventory with prioritisation, dependency and vendor lock-in risk, the team's way of working and a realistic roadmap. It is a piece of work that sets direction without writing code.
Details →Software Productisation: From Project to Product
We turn a working piece of software written for a single client into a sellable product: separating the core from the client-specific layer, a configuration engine, multi-tenant data isolation, installation and release management, and subscription infrastructure.
Details →Supply Chain Management (SCM)
We make it visible from one place where demand and supply diverge, which supplier is holding to its promised date and where the goods are waiting right now. The aim is not to install a new ERP; it is to gather the off-chain information your current system does not know and tie the planning decision to data.
Details →Procurement Management (PMS)
We bring together in a single chain where a request came from, which quotes were obtained, who approved what, and whether the invoice that arrives matches the order. Procurement runs in the system rather than in people's memories; every step can be read back afterwards along with its reasoning. Your existing ERP stays where it is.
Details →Supplier Relationship Management (SRM)
We bring together in one record who the supplier is, when each of its documents expires, how well it kept to its delivery dates last year and which price agreement is in force. The approved supplier list stops being an Excel file. A supplier portal connects to the same structure as an option.
Details →Transport and Fleet Management (TMS)
We build a layer that plans the shipment, assigns the vehicle and the route, compares carriers and freight rates, issues the e-waybill and collects proof of delivery from the field. If you run your own fleet, fuel, maintenance and document costs accumulate in the same system; if you work with hauliers, a record is kept of which job went to whom and at what price.
Details →