LH Bank
A careers website LH Bank’s recruiters run themselves
- UX/UI Design & User Research
- Web Application Development
- System Integration & API Development
Quality & Security
Application Security Engineering
We handle security as part of design and development: sign-in and permission models, secrets kept out of the code, dependencies scanned on every build. We also review and fix applications already in production.
Application security is the engineering work that decides who can sign in, what each user may see and do, where credentials are kept and how weaknesses in code and libraries get fixed.
For GMMTV's e-book platform we built Amazon Cognito sign-in and protection against screenshots and screen recording. In the reporting system we built for GMM Grammy's accounting team, each user sees only the companies they may see.
Is this the right fit?
The situations this work is built for, and what you get at the end of it.
You may need this if
Security review comes after the build
Findings arrive at the end, when fixing them means reworking code other features depend on.
Sign-in has grown in pieces
Several login methods, unclear session handling, and permissions set up for an organisation chart that has since changed.
Nobody tracks library vulnerabilities
Libraries with published vulnerabilities stay in production because nothing scans them and nobody owns patching.
Credentials sit in source code
Passwords and API keys are kept in code, configuration files or chat threads, and rarely changed.
What we deliver
Sign-in and permission design
OAuth 2.0 and OpenID Connect, single sign-on, session handling and role-based permissions that match who approves what.
Secure coding against OWASP risks
Code written and reviewed against the OWASP Top 10, with security checks in the pipeline before each release.
Dependency scanning and patching
Third-party libraries scanned on every build, with a named owner and a schedule for applying patches.
Secret management
Credentials moved into a secrets vault, rotated, and readable only by the services that need them.
Review of a live application
An assessment against OWASP risk categories, with findings ordered by exposure.
How we work
Every engagement runs through the same six-stage fitting process, from the first consultation to long-term care. The stages stay in the same order; how deep each one goes depends on the project.
See the full fitting process- ConsultationDiscover
- MeasureAnalyze and architect
- PatternDesign
- FittingBuild with you
- FinishingHarden and launch
- AftercareMaintain and support
Where we start on a live application
The quick fixes come first. Credentials found in source code or configuration files move into a secrets vault and are rotated, since anyone with repository access may have copied them. Dependency scanning is added to the build, and vulnerable libraries are patched in order of exposure.
Sign-in and permissions take longer. We map every way a user can log in and which roles can see or change which data. Where permission checks were added screen by screen, we move them to one place on the server, so a new screen cannot skip them.
We also design the audit trail: who did what, when and under which role. Failed sign-ins and permission denials are logged and sent to monitoring, so your team sees an attempt as it happens. All of this goes out in small changes alongside feature work, so the roadmap keeps moving.
Organizations we work with
Engagements span build, integration and long-term support. Named with permission; clients under NDA are not listed.
Related services
- VA & Penetration Testing: for a controlled attack test of a live system.
- Software Testing & QA: when the concern is functional defects.
- Application Modernization: when the framework no longer receives security updates.
- Web Application Development: for a new system, with security built in.
Frequently asked questions
How much does application security work cost?
It depends on the applications and APIs in scope, the user roles and sign-in methods, the environments involved, and whether you need a one-off review, the fixes that follow, or ongoing security work. We send a written estimate after a short scoping call. Public-sector projects are estimated against the TOR.
What do we receive from a security review?
A report listing each finding, where it is, how it could be exploited, what it exposes and what fixing it involves, ordered by exposure and grouped where findings share a cause. We walk your team through it, then make the fixes ourselves or support your developers while they do.
Do you do penetration testing?
Yes, as a separate service, VA & Penetration Testing, listed under related services on this page. It covers scanning, controlled testing within an agreed written scope, and a retest of fixed findings. That page also explains what our report can and cannot be used for.
How does this relate to PDPA?
PDPA affects several design decisions: who may see personal data, how it is encrypted, how access is logged and how long records are kept. We build those technical controls and treat PDPA requirements as design input. Interpreting what the law requires of your organisation sits with your legal advisers.
Will security checks slow down our releases?
There is setup effort at the start: adding scans to the pipeline, moving secrets into a vault and agreeing who patches what. After that the checks run on every build and add little time. A security review held only at the end of a release cycle usually causes longer delays.
Related work
GMMTV
Copy-protected e-books for GMMTV fans, on three app stores
- UX/UI Design & User Research
- Mobile Application Development
- Web Application Development
Next step
Start with a conversation
Tell us about the problem you are trying to solve. A senior person reads every inquiry and replies with our view of fit, scope and cost, including when another option would suit you better.