How we work

Engineering quality and standards

What the sentence “we work on the basis of ISO/IEC 25010, BSI and OWASP” actually means.

Which standards we apply, at which point in the process, and what evidences their application. Where your procurement department asks about supplier standards, we send the full document and answer the specific questions.

Outline your case
Scope of certification

We do not hold an ISO certificate

blue veery GmbH holds no ISO certificate and no other security certification. The standards and guidelines listed below are applied as a reference point for our own process — and we can show where each of them takes effect.

ISO/IEC 25010 is a product quality model, not a management system standard: it defines the characteristics against which software is assessed. Certification applies to management system standards, for example ISO 9001 or ISO/IEC 27001. We hold neither, and we do not claim otherwise.

Where a certified supplier is required, it is worth establishing that at the outset. We will indicate which elements we can document and what cannot be confirmed with a certificate.

Reference

Three reference documents and what each one does

Each of the three documents answers a different question. They are applied together, not interchangeably.

ISO/IEC 25010

what is assessed

A product quality model. It provides the vocabulary and the structure for the non-functional requirements with which we describe the targets in the contract.

BSI

how the process is organised

Guidance from the German federal office for a secure software life cycle: from the requirements through to the handling of vulnerabilities.

OWASP

scope of code verification

A list of risk categories together with verifiable requirements, to which every audit finding is referenced.

AI in development

Standards on the use of AI in software development

There is no standard that certifies code produced with the help of AI. Certification applies to ISO/IEC 42001 — a management system standard for artificial intelligence, covering organisations that supply and use AI-based solutions; we do not hold that certificate. The remaining documents are guidance, and it is these that shape the way we work.

ISO/IEC 42001:2023artificial intelligence management system
Requirements for organisations supplying and using AI-based solutions. As a management system standard, it is subject to certification.Status: we do not hold the certificate.
ISO/IEC 5338:2023AI system life cycle processes
An extension of the software life cycle processes to the specifics of systems that use artificial intelligence.Status: guidance, no certification.
ISO/IEC 23894:2023risk management in AI
Guidance on identifying and handling the risk associated with artificial intelligence.Status: guidance, no certification.
BSI and ANSSIAI assistants in programming
Joint recommendations of the German and French agencies on working with code generators.Status: the basis of our AI tool policy.
OpenSSFinstructions for code assistants
Recommendations on configuring AI assistants: input validation, the choice of dependencies, SBOM, language-specific guidance.Status: applied when configuring the tools in projects.

All of these documents share one common denominator: responsibility for the code stays with the engineer. An AI tool shortens the time in which code is produced, but it takes on no responsibility for the result and does not change the scope of the verification that code is subject to.

Application

How we apply them in a project

ISO/IEC 25010:2023product quality model
The vocabulary and structure of the non-functional requirements. In the specification we record measurable targets for the characteristics that matter in the project at hand.In practice: the acceptance criteria in the contract — response time, test coverage, maintainability rating.
BSI TR-03185secure software life cycle
The shape of the whole life cycle: requirements, design, development, testing, release, handling of vulnerabilities.In practice: the process description and the checklists handed over before the project begins.
BSI and ANSSIjoint recommendations for AI assistants
The rules for working with code generators: verification of every fragment, awareness of the risks, control of the dependencies.In practice: our internal AI tool policy, set out in a separate document.
OWASP Top 10:2025risk categories
The list of ten categories every audit starts from and by which the report is organised.In practice: an audit report ordered by categories A01–A10.
OWASP ASVS 5.0.0verification requirements
Verifiable requirements that give an unambiguous result for a single control point.In practice: a list of findings referenced to ASVS requirement numbers.
Risk categories

The structure of the report under OWASP Top 10:2025

The 2025 edition added two new categories: the software supply chain and the handling of exceptional conditions.

A01Broken Access Control
A06Insecure Design
A02Security Misconfiguration
A07Authentication Failures
A03Software Supply Chain Failuresnew
A08Software or Data Integrity Failures
A04Cryptographic Failures
A09Security Logging and Alerting Failures
A05Injection
A10Mishandling of Exceptional Conditionsnew

This list is used in the AI code audit as the structure of the report. Every finding goes into one of the categories and, where appropriate, to a specific ASVS requirement as well.

Process

Quality gates in the development process

The gates are either automatic or require a second person. None of them is optional.

1Code changeworking branch 2Reviewsecond engineer 3Testsautomated in the pipeline 4Analysis and scanscode and dependencies 5Releaseonce the gates are passed No fragment of code reaches production bypassing the review and the automated gates.
Consequences

What this means for the project

Quality targets are set before the start — which characteristics are measured and against which thresholds. This is part of the acceptance criteria, not a marketing statement.
Every finding has an address — a specific OWASP category and, where appropriate, an ASVS requirement number as well.
The raw results are available — pipeline reports and scan results from the day of acceptance are provided on request.
The full document on request — “Engineering quality and standards” contains the process description and the checklists. We hand it over before the work begins.
Sources

Source documents

Every statement above can be verified at source. The documents we refer to are listed below.

How this looks in the contract

Tell us which project you have in mind. The full document on quality and standards is provided before the work begins.

Outline your case