Services
Cybersecurity and compliance
Application security and compliance: code and architecture review, threat modelling, dependency hygiene, protective headers, GDPR and WCAG as automated CI/CD gates.
- Who it is for
- Teams shipping software
- Scope
- Code, architecture and the release pipeline
- Outcome
- A requirement as a CI gate
- Standards
- OWASP Top 10, WCAG, GDPR etc.
What the work covers
Security review of code and architecture
OWASP Top 10 and ASVS as a checklist, not as a scanner report.
Threat modelling
On a concrete data flow, not on a general diagram.
Dependency hygiene
Automated updates with a grace period, vulnerability alerts in CI.
Protective headers and content security policy
CSP checked by an assertion on the built page, not in the configuration.
Secret handling
Part of the layer visible from outside, checked by an assertion on the built page.
CI/CD gates
Legal, accessibility and SEO requirements as assertions on the generated page.
Consent and data retention
Under GDPR and Polish electronic communications law.
Accessibility to WCAG
Checked in the build, not in a spreadsheet.
Where a review starts
Application security is tested where it is created: in the code, in the architecture and in the release pipeline. We start at the system boundaries: who authenticates, who may see what, where outside data comes in. The result is a list of findings ranked by what can actually be acted on.
Threat modelling is done on a concrete flow, not on a general diagram. A form that accepts a file, an integration pulling data from someone else's API, a panel with user roles. Each has its own set of questions about what happens when the data arrives in a shape nobody planned for.
Dependencies and the layer visible from outside
Dependencies are today's most common way in. Updates run automatically, with a grace period, so that a freshly published and compromised version of a package cannot enter the build the same day. Vulnerability alerts land where the rest of the work lands, instead of waiting in a separate panel.
Protective headers, the content policy, secret handling and consent configuration are the layer visible from outside and the easiest to break while changing something else. Which is why an assertion on the built page checks its state, rather than the memory of whoever configured it once.
Why compliance is written into the pipeline, not into a document
A requirement written into a document gets read once, remembered for a week and forgotten. A requirement written into the pipeline halts the build every time it stops being met. Legal, accessibility and SEO requirements become assertions that check the generated page, not the intent recorded in a policy. An assertion either passes or it does not.
Tools and standards
- OWASP Top 10
- OWASP ASVS
- STRIDE
- Content Security Policy
- GDPR
- WCAG 2.2
- Google Consent Mode v2
- TypeScript
- Node.js
- GitHub Actions
- Dependabot
- Cloudflare Workers
Proof: our own audit package
The method is applied here first. The package is public on npm.
- Distribution
- Public npm package
- Language
- TypeScript
- Where it runs
- The CI pipeline of every service we maintain
It audits the technical foundations of a site: crawlability, metadata, structured data and basic accessibility. One of the services running it is CyberKatalog.pl.
check-build-output.mjs
The consent requirement for embeds under article 399 of the Polish electronic communications law is a single assertion. It checks that the contact page carries no Google Maps embed address before a visitor consents. Should anyone restore the map without consent, the same build that passes today stops passing.
What changes once it is in place
- Findings ranked by what can be acted on, not by a scanner's score
- A requirement written into the code holds at every deployment, not only on audit day
- A compromised package cannot enter the build the same day, because updates have a grace period
- A regression halts the build before it reaches production, instead of waiting to be noticed
Typical use cases
- Security review of a web application before it goes live for end customers
- Threat modelling for a panel with roles and an integration pulling data from an external API
- A gate guarding consent for embeds (maps, video, advertising pixels) before a visitor gives it
- A gate checking basic accessibility thresholds in the built version of the site
Questions that come up most often
How does a CI gate differ from a one-off audit?
A requirement written into a document gets read once, remembered for a week and forgotten. A gate halts the build every time a requirement stops being met. Legal, accessibility and SEO requirements become assertions that check the generated page, not the intent recorded in a policy.
What is the security review based on?
On the system boundaries: who authenticates, who may see what, where outside data comes in. OWASP Top 10 and ASVS serve as a checklist. The result is a list of findings ranked by what can actually be acted on.
How are dependencies kept in check?
Updates run automatically, with a grace period, so that a freshly published and compromised version of a package cannot enter the build the same day. Vulnerability alerts land where the rest of the work lands, instead of waiting in a separate panel.
What do you check in the layer visible from outside?
Protective headers, the content policy, secret handling and consent configuration. That layer is the easiest to break while changing something else. An assertion on the built page checks its state, rather than the memory of whoever configured it once.
What is your own audit package?
An in-house package, public on npm, written in TypeScript and covered by tests. It audits the technical foundations of a site and runs in the CI pipeline of every service we maintain.