Secrets in the tree.
A token in a repository is already an incident, even if nobody has rotated it.
Security in the delivery path.
Threats, access, dependencies, and secrets treated as engineering work. This is not a certification and not a compliance badge.
Risk that ships with the build.
Symptoms we look for before naming a tool.
Dependencies without an owner.
A vulnerable library stays because nobody knows who may upgrade it.
Access checked only in the interface.
The API still answers when the screen is hidden.
Work we can do.
Scanners such as Snyk, and lists such as OWASP, are examples of the category. Naming them is not a partnership.
A threat model.
Assets, trust boundaries, and the few abuses worth designing against.
Access and secrets.
Authentication, authorization, least privilege, and a rotation path.
Checks in the pipeline.
Dependency and secret scanning, and a gate that can block a release. Static or dynamic tests only where they earn their cost.
Order of work.
Find the asset.
Data, credentials, and the actions a stranger must not take.
Put a control on the path.
A check that runs before release, with an owner when it fails.
Write the response.
Who rotates, who notifies, and what evidence is kept. No invented SLA.
Limits.
No certification.
We do not claim ISO, SOC, LGPD, or GDPR certification for Solid Solutions or for a client.
Website controls are separate.
Headers and the contact form on this site are not a security practice sold as a case study.
Questions we expect.
Will you certify our product?
No. We can design controls and reviews. A certificate comes from an accredited body, and we do not pretend to be one.
Do you require a particular scanner?
No. The control is the point. The product is chosen after the pipeline and the licence are known.
Bring the constraint, not a tool list.
We will say what is in scope, what is not, and what would count as proof.