Security by design
Secure software development
We develop and maintain applications within a management system certified under the Spanish National Security Framework (ENS) MEDIUM category. Every change goes through automated security scans before it reaches production: this is the quality guarantee behind our custom software and our products.
Approach
Security, built into the development cycle
The scope of our ENS certification is precisely the information systems that support the development and maintenance of software applications. Security is not reviewed at the end: it is checked automatically on every change and leaves auditable evidence.
- Security requirements from the design stage: access control, activity logging and information protection.
- Automated scans that block merging when they find serious issues.
- Results published in every review and reports kept as evidence.
- Anything that could not be analysed is explicitly flagged: it is not taken as passed.
- Code written with the help of AI is reviewed by a developer and goes through the same scans (safe use of AI).
Security pipeline
What we check on every change
The scans run in our continuous integration pipelines. If a scan does not meet its threshold, the change is not merged until it is fixed or justified.
-
Inspection
Reviewed change
Every change goes in through a pull request in which the scans are run and their results published.
Nothing is merged without review or without the scans.
-
SAST
Static analysis with Semgrep
Rules for code, compliance, infrastructure and secrets, plus our own rules mapped to ENS and ISO/IEC 27001 measures.
Blocks high-severity findings.
-
SCA
Dependencies and images with Trivy
Looks for known CVEs in the packages and container images that go into production.
Blocks high or critical CVEs that have a fix available.
-
DAST
Dynamic testing with OWASP ZAP
Tests the running application, both without credentials (black box) and authenticated (grey box).
Blocks high-risk findings.
Active dynamic scanning is only run against ephemeral or pre-production environments whose data can be lost, never against a client's real data. Exceptions for a CVE with no compatible fix are accepted with their reason documented.
Secure configuration
Headers, policies and infrastructure
Web applications are published with restrictive security headers. This very website is served with them and without any third-party resources.
- Strict Content Security Policy (CSP), with no inline scripts or styles
- Mandatory HTTPS with HSTS
- Protection against framing by other sites
- Restricted browser permissions (camera, microphone, location, payments)
- Referrer policy and cross-origin isolation
- Content type control (nosniff)
Reviewed infrastructure as code
Deployment files also go through static analysis, with our own rules aligned with the ENS security configuration measures: pinned image versions, secrets kept out of the code, databases not exposed, unprivileged containers and encrypted internal networks.
In products such as CIGES, sign-in supports a corporate directory (LDAP) or single sign-on and two-factor authentication; ACAE also keeps a log of each user's actions.
Vulnerability management
Vulnerabilities with a CVE identifier
We are a CVE Numbering Authority (CNA), under the supervision of INCIBE. When a vulnerability is discovered in one of our products, we fix it, notify affected clients before public disclosure and publish it with its CVE identifier and the version that fixes it.
Frequently asked questions
Questions about secure development
What is the difference between SAST, SCA and DAST?
SAST analyses the source code without running it; SCA checks third-party libraries and images for known vulnerabilities (CVEs); DAST attacks the running application as an external user would. They complement each other: each one detects problems the others cannot see.
Which ENS measures does secure development cover?
Mainly those for protecting software applications: application development (mp.sw.1) and acceptance and commissioning (mp.sw.2), as well as security configuration and vulnerability management under the operational framework. In ISO/IEC 27001:2022 they correspond to the controls for secure development life cycle, secure coding and security testing.
What happens if a vulnerability is discovered in one of your products?
It is assessed, fixed and affected clients are notified before public disclosure, in accordance with our vulnerability disclosure policy. As a CVE Numbering Authority, we assign it a CVE identifier and publish it in the list of vulnerabilities.
Can you apply this process to custom development for my organisation?
Yes. Custom software projects are developed with the same process, within the scope of our ENS MEDIUM certification.
Do you need secure software for your organisation?
We develop custom applications within a management system certified under the ENS MEDIUM category.
