# lucabertelli.consulting - full text

> Complete text of the service pages, field guides and blog articles published by Luca Bertelli, freelance Cloud Native and Platform Engineering consultant based in Italy and working across the European Union. The index version is at https://lucabertelli.consulting/llms.txt. Each entry states its language and canonical URL; cite the URL when quoting.

Contact: info@lucabertelli.consulting
Generated: 2026-10-24

## Services

### DevOps Consultant (English)

- URL: https://lucabertelli.consulting/en/services/devops-consulting
- Language: en
- Summary: Freelance DevOps consultant working across Italy and the EU: delivery automation, CI/CD pipelines, Infrastructure as Code and operational practices for Fintech, Insurtech and industrial teams.
- Topics: DevOps consultant, DevOps consulting, freelance DevOps, DevOps consultant Italy, freelance DevOps consultant, CI/CD automation, CI/CD consulting, Infrastructure as Code

Freelance DevOps consulting for teams that want to ship more often, with fewer incidents and without depending on a single person.

Outcomes:
- Frequent, repeatable releases with no night windows and no manual steps
- Shorter build and deploy times, giving developers feedback in minutes instead of hours
- Infrastructure described as code, versioned and rebuildable from scratch
- Operational knowledge spread across the team rather than held by one person

Deliverables:
- Assessment of current delivery and operations, with a reasoned order of priorities
- CI/CD pipelines implemented on your stack (GitLab CI, GitHub Actions, Argo)
- Reusable Terraform modules and a clear environment structure
- Operational runbooks and documented architectural decisions
- Hands-on support for your team throughout adoption

## The problem I usually find

The request almost always arrives the same way: releases are frightening. They pile up for weeks, they need an agreed window, they involve the one person who "knows how it works", and every so often something breaks in production without anyone being able to say why.

Underneath that surface the causes are remarkably consistent. Test environments do not resemble production, so problems surface late. Infrastructure was built by hand over time and nobody can rebuild it. Pipelines exist but they are slow and unreliable, and the team has learned to re-run them until they pass. Secrets are scattered across environment variables and config files.

None of these are tooling problems. They are process problems, and tools alone do not solve them.

## How I work

I always start with an assessment, because installing tooling before understanding how a team works is the fastest way to add complexity nobody asked for. I look at the real path a change takes from commit to production, measure where time is lost and where incidents originate, and turn that into a list of interventions ordered by impact against effort.

From there the work is incremental. Continuous integration comes first, because a pipeline the team does not trust makes everything else pointless. Then infrastructure comes under control with Terraform, so environments are rebuildable and comparable. Finally delivery gets automated, typically with a GitOps approach where the desired state of the system lives in Git and reconciliation is continuous.

The last phase is the one that matters most a year later: knowledge transfer. Documented decisions, runbooks for recurring operations, working sessions with the team. A successful DevOps engagement is one after which the client no longer needs the consultant.

## The experience behind it

I have worked on these problems since 2018, first as a DevOps Engineer, then as a Cloud Native Engineering Manager, and today as an independent consultant. The sectors where I have the deepest experience are Fintech, Insurtech and industrial: contexts where the constraint is not only technical but also about compliance, auditability and service continuity.

That background explains the approach. In a regulated environment it is not enough for a deployment to work. It has to be traceable, repeatable, and explainable to whoever audits it.

Frequently asked questions:

Q: What does a DevOps consultant actually do?
A: A DevOps consultant works on how software travels from the repository to production: CI/CD pipeline automation, infrastructure as code, environment standardisation, observability and operational practice. The goal is not to introduce tools but to cut the time and risk of every release, while leaving the internal team able to maintain what was built.

Q: Do you work as a freelancer or through a consultancy?
A: I work as an independent freelance consultant registered in Italy. That means one technical counterpart who takes part in the implementation rather than only supervising it.

Q: How long does a DevOps consulting engagement last?
A: It depends on scope. A focused assessment takes a handful of days and produces a prioritised list. A full adoption path, with pipeline implementation and team enablement, runs over several months with verifiable milestones. In both cases the scope is agreed before we start.

Q: Do you work remotely or on site?
A: Mostly remotely, with on-site days available for workshops, design sessions or team training. I work primarily with clients in Italy and the European Union.

Q: Which DevOps technologies do you specialise in?
A: Kubernetes and the CNCF ecosystem, Terraform for Infrastructure as Code, GitLab CI and GitHub Actions for continuous integration, Argo CD and Argo Workflows for GitOps and automation, HashiCorp Vault for secrets management, Prometheus and Grafana for observability.

Q: How much does a DevOps consultant cost, and how is the work priced?
A: Two models. A fixed price for work with a defined output, such as an assessment or a migration with a clear perimeter, and a daily rate for longer engagements where the scope evolves with the team. In both cases you receive a written proposal with the deliverables, the estimated effort and what is excluded before anything starts, so the number is comparable with other quotes rather than a surprise on the first invoice.

Q: Should we hire a DevOps engineer or bring in a consultant?
A: Hire when the work is continuous and specific to your product: someone has to own the platform day after day. Bring in a consultant when the problem is a transition that ends, such as setting up the delivery pipeline, migrating to Kubernetes or preparing for a regulation, or when you need a second opinion on choices already made. The two often combine: I set up the practice and the pipelines, then hand them over to the person you hire, who inherits documentation and a working system rather than a blank page.

### Cloud Consulting and Migration (English)

- URL: https://lucabertelli.consulting/en/services/cloud-migration-consulting
- Language: en
- Summary: Cloud consulting across Italy and the EU: adoption strategy, migration of applications and infrastructure to AWS, Azure and Google Cloud, governance and cost control.
- Topics: cloud consultant, cloud consulting, cloud migration, cloud adoption, cloud consultant Italy, cloud cost governance

Cloud adoption and migration of applications and infrastructure, with costs under control and without rewriting everything on day one.

Outcomes:
- A migration strategy ordered by risk and value rather than a big bang
- Cloud environments that are consistent with each other and rebuildable from code
- Predictable cloud spend, attributed to the teams and projects that generate it
- No accidental lock-in: binding choices are explicit and justified

Deliverables:
- Assessment of the application portfolio and workload classification
- Wave-based migration plan with exit criteria for each wave
- Landing zone and account/subscription structure in Terraform
- Governance model: naming, tagging, budgets and spend alerts
- Assisted migration of the first workloads, as a reference for the rest

## The problem I usually find

Cloud rarely arrives as a single decision. In most organisations I work with it crept in piecemeal: a team that opened an account for a prototype, a vendor that brought its own infrastructure, a partial migration abandoned halfway. The result is an unplanned hybrid environment, with accounts nobody governs and spend that grows without anyone knowing who produces it.

The opposite variant is just as common: the "lift and shift" that completed but never really finished. Virtual machines were moved, the architecture stayed exactly as before, and now you pay for the same resources plus the provider's margin. Cloud is perceived as a failure when in fact it was never adopted, only rented.

## How I work

The starting point is workload classification. Each application is assessed on how tightly it is coupled to the underlying infrastructure, what data it handles, which regulatory constraints apply and how variable its usage profile is. That grid makes it reasonably clear what should move as-is, what should be reworked during migration, and what is better left where it is.

Before anything moves, the landing zone gets prepared: account structure, networking, identity and permissions, secrets management, naming and tagging conventions. All described in Terraform, because a cloud environment built by hand reproduces within two years exactly the mess it was meant to escape.

Migration then proceeds in waves, starting with low-risk workloads that validate the automation. Each wave has explicit exit criteria, and the first ones are executed together with the internal team so they become the template for the rest.

## Cost governance, from day one

Controlling spend is not a final optimisation phase, it is a property you build in from the start. If tagging is consistent from the first deployment, attributing cost to a team or a project is immediate; introduce it later and it becomes reconstruction across resources whose history is lost.

In practice that means budgets and alerts per environment, periodic sizing reviews, automatic shutdown of what is not needed outside working hours, and one simple rule: every resource must have an identifiable owner.

Frequently asked questions:

Q: Where does a cloud migration start?
A: With an honest inventory of what you already have. Before choosing a provider or an architecture you need to know which applications exist, how they are coupled, what data they handle and which regulatory constraints apply. Only then does it make sense to decide what moves as-is, what gets reworked, and what is better left where it is.

Q: Is it always worth migrating everything to the cloud?
A: No, and saying so is part of the job. Some workloads have a steady, predictable usage profile that simply costs more in public cloud. Others are tied to hardware or licences that make migration disproportionate to the benefit. A credible plan also states what stays put.

Q: Which cloud providers do you work with?
A: AWS, Microsoft Azure and Google Cloud, along with hybrid and on-premise scenarios built on Kubernetes. The approach is to keep automation as portable as possible using Terraform and CNCF tooling, and to make every provider-specific dependency explicit.

Q: How do you keep cloud costs from running away?
A: By making them visible before they become a problem. That means a tagging convention applied from day one, budgets and alerts per environment, resource sizing reviewed periodically, and automatic shutdown of non-production environments. Most of the waste I encounter does not come from bad choices but from resources nobody can attribute to an owner any more.

Q: How long does a cloud migration take?
A: The first waves of non-critical workloads typically complete within weeks once the landing zone is ready. A large application portfolio takes several months. Working in waves exists precisely to deliver value continuously instead of waiting for one large project to end.

### Platform Engineering Consulting (English)

- URL: https://lucabertelli.consulting/en/services/platform-engineering-consulting
- Language: en
- Summary: Platform Engineering consulting across Italy and the EU: Internal Developer Platform design, golden paths, self-service on Kubernetes, and measuring real adoption by product teams.
- Topics: platform engineering consulting, platform engineering consultant, platform engineering, internal developer platform, IDP, golden path, developer experience, developer platform consulting

Internal Developer Platforms designed to reduce developer cognitive load instead of moving it somewhere else.

Outcomes:
- A new developer reaches production in days rather than weeks
- Standard paths that are the easiest route, so they get chosen willingly
- The platform team stops being a ticket desk and goes back to building
- Security and compliance standards applied by construction, not by review

Deliverables:
- Internal user research: where time is actually lost in the development cycle
- Platform design and definition of the golden paths
- Self-service templates for creating services, environments and pipelines
- Developer portal and service catalogue
- Adoption metrics and a feedback loop with consuming teams

## The problem I usually find

Once an organisation passes three or four development teams, the promise that "every team owns its stack" starts to crack. Each team configured Kubernetes its own way, wrote its own pipelines, picked its own approach to secrets. None of those choices is wrong in isolation; the aggregate is unmanageable.

At that point one of two things happens. Either the infrastructure group becomes a ticket desk, buried under repetitive requests that consume it entirely, or developers work around it and the risk surface grows quietly. In both cases the time needed to get a new service into production is measured in weeks, and nobody can explain precisely why.

## How I work

The first phase is not technical. I talk to the developers who will use the platform and reconstruct what they actually do in a working week: which steps they repeat, where they wait on someone else, which configurations they copy between projects without fully understanding them. A platform built on assumptions rather than observation ends up automating the wrong problems.

From there we define the golden paths: standard routes for recurring tasks, from creating a new service to promoting between environments. What makes them effective is not enforcement, it is being the easiest option. If the standard path is also the most convenient one, it gets chosen without any policy.

It has to remain possible to step off it, though. Platforms that fail are almost always the ones that removed the developers' ability to do something unforeseen: the first legitimate case the model does not cover turns them from accelerator into obstacle.

## Building incrementally

I almost never recommend starting with a portal. The portal comes last, once there is something worth exposing. You start from the use case that wastes the most time for the most people, make it genuinely self-service, and ship it. Then the next one.

That approach has a useful side effect: it forces you to verify adoption at every step, instead of discovering after a year of work that the platform does not solve the problems teams actually have.

Frequently asked questions:

Q: What is Platform Engineering?
A: It is the discipline of treating internal infrastructure as a product whose real users are the company's own developers. Instead of asking every team to assemble Kubernetes, pipelines, secrets and observability by themselves, an internal platform offers ready and safe paths for recurring tasks, while keeping an escape hatch open when something unusual is needed.

Q: How is Platform Engineering different from DevOps?
A: DevOps describes a set of practices and a culture of collaboration between development and operations. Platform Engineering is an organisational answer to a problem DevOps created at scale: expecting every team to master the entire stack does not scale beyond a certain number of teams. The platform encapsulates that complexity behind stable interfaces.

Q: Does my company actually need an Internal Developer Platform?
A: Below three or four development teams, almost never: the cost of building and maintaining one outweighs the benefit. It starts to make sense when the same configuration is recreated slightly differently by several teams, when onboarding a service takes weeks, or when the infrastructure group spends most of its time answering repetitive requests.

Q: Do you use Backstage or similar tools?
A: Backstage is a reasonable choice for the catalogue and the portal, but it is only the visible part. The substance is in what the portal triggers: scaffolding templates, environment provisioning, policies applied automatically. I have also worked with Krateo PlatformOps, which I co-founded, and the tool choice always comes after the golden paths are defined.

Q: How do you measure whether the platform is working?
A: Through voluntary adoption, which is the only honest indicator: if teams use the standard paths without being forced to, the platform is solving a real problem. Alongside that I track the time from first commit to first production deployment for a new service, and the share of platform-team requests that have become self-service.

### Kubernetes Consulting (English)

- URL: https://lucabertelli.consulting/en/services/kubernetes-consulting
- Language: en
- Summary: Kubernetes consulting from a CKA certified consultant: cluster architecture, multi-tenancy, GitOps with Argo CD, security hardening and day-2 operations.
- Topics: Kubernetes consultant, Kubernetes consulting, Kubernetes Italy, CKA certified consultant, GitOps Argo CD, Kubernetes multi-tenancy

Design, hardening and operation of production Kubernetes clusters, by a Certified Kubernetes Administrator.

Outcomes:
- Clusters designed for production rather than prototypes grown by inertia
- Real isolation between teams and environments, with quotas and network policies enforced
- Declarative GitOps deployments, with drift detected instead of endured
- Documented day-2 operations: upgrades, backup, restore

Deliverables:
- Review of existing cluster architecture, with findings ordered by severity
- Cluster provisioning in Terraform, reproducible across environments
- Multi-tenancy model: namespaces, RBAC, quotas, network policies
- GitOps continuous delivery with Argo CD and Helm or Kustomize
- Security hardening and observability with Prometheus and Grafana

## The problem I usually find

Kubernetes almost always gets adopted in two stages. First someone builds a cluster for a pilot project, using configuration lifted from the docs and a few reasonable shortcuts to move fast. Then the pilot goes to production, other teams start relying on it, and those shortcuts become foundations.

The symptoms look remarkably similar from one client to the next. Nobody can say with confidence whether what runs in the cluster matches what is in the repository. A misbehaving workload degrades applications that have nothing to do with it. Version upgrades get postponed because nobody feels comfortable running them, and the cluster falls behind until upgrading becomes a project of its own.

## How I work

If the cluster already exists, we start with a structured review: architecture, configuration, security, observability and operational practice. The output is a list of findings ordered by severity and effort, not a generic best-practices document. The first three items usually account for most of the real risk.

On isolation, the work consists of making real what namespaces only imply. Namespaces, least-privilege RBAC, resource quotas, limit ranges and default-deny network policies: without these, multi-tenancy is a naming convention rather than a separation.

Delivery moves to GitOps with Argo CD. The benefit that matters is not automation as such, it is that desired state becomes readable in Git and every deviation is detected rather than discovered during an incident. From there we build day-2 operations: an upgrade strategy, backup and restore actually tested, and alerts that signal real problems instead of generating noise.

## Fleets and ephemeral environments

Once there is more than one cluster, the problems change shape. The question is no longer whether a cluster is well configured, but whether clusters are aligned with each other and how far behind they are on current image and chart versions. It is a topic I work on regularly and have written about publicly, alongside the use of ephemeral virtual clusters to give every pull request an isolated test environment without multiplying the infrastructure you have to maintain.

Frequently asked questions:

Q: Are you Kubernetes certified?
A: Yes. I have been a Certified Kubernetes Administrator (CKA) since 2020 and a Certified Argo Project Associate (CAPA), as well as VMware Certified Master Specialist in Cloud Native. The credentials are verifiable through their public Credly badges, linked from the certifications section of this site.

Q: What are the most common mistakes in production Kubernetes clusters?
A: Three come up almost every time: missing resource requests and limits, which makes scheduling unpredictable and lets unrelated workloads contend for resources; no network policies, so every pod can talk to every other pod; and configuration applied by hand on the cluster, which makes it impossible to know whether the environment matches what the repository describes.

Q: Managed Kubernetes or self-managed?
A: In the large majority of cases, managed: EKS, AKS or GKE. Running your own control plane only makes sense with specific data sovereignty constraints, on-premise requirements or customisation needs that managed services do not cover. The value you build almost always sits above the control plane, not inside it.

Q: Can you work on clusters that are already in production?
A: Yes, and it is the most common scenario. We start from a review of the existing architecture and configuration, with findings ordered by severity, and work in verifiable steps without halting operations. Rewriting a working environment from scratch is rarely the right call.

Q: How do you handle test environments on Kubernetes?
A: With ephemeral virtual clusters created per pull request and destroyed on close. I have documented that approach in detail in a blog article based on vCluster and Argo Workflows: it gives every developer an isolated, realistic environment without multiplying the real clusters you have to maintain.

### SecDevOps and CI/CD Consulting (English)

- URL: https://lucabertelli.consulting/en/services/secdevops-cicd-consulting
- Language: en
- Summary: SecDevOps and CI/CD consulting across Italy and the EU: toolchain selection, secure pipelines, HashiCorp Vault secrets management, software supply chain security and NIS2 evidence.
- Topics: SecDevOps consulting, DevSecOps consulting, CI/CD consulting, secure CI/CD pipelines, software supply chain security, HashiCorp Vault, DevSecOps, SecDevOps

Toolchains and pipelines that build security into the development flow instead of turning it into a bottleneck.

Outcomes:
- Vulnerabilities caught in the pipeline, while fixing them is still cheap
- Centralised, rotating secrets kept out of repositories and environment variables
- Traceable artifacts: you know what each release contains and where it came from
- Compliance evidence produced by the process, not reconstructed before an audit

Deliverables:
- Assessment of the existing toolchain and a reasoned choice of what is missing
- Security checks embedded in the pipeline: SAST, SCA, image scanning, IaC analysis
- Secrets management with HashiCorp Vault and removal of static credentials
- Automated dependency management with Renovate
- Artifact signing, SBOM generation and VEX/VDR statements

## The problem I usually find

Application security almost always arrives late in the lifecycle, and that determines its cost. An annual penetration test produces a report with thirty findings against code written six months earlier, by people who have since moved on to something else. Fixing them means stopping current work, and the discussion that follows is about which findings can be accepted rather than how to avoid them next time.

The second recurring theme is secrets. In most organisations I start working with, credentials live in pipeline configuration variables, in unversioned files on servers, occasionally in an old commit nobody purged from history. They are static, shared, and effectively unrotatable: changing them would require knowing who uses them, which is information nobody holds.

## How I work

The first step is mapping the existing toolchain before proposing any addition. Often the checks are already there but run at a point in the process where nobody reads the output, or they produce so many findings that they have been muted. Recovering what exists is almost always faster than introducing another tool.

Checks are then distributed along the pipeline according to their cost. Static analysis and dependency checks on every commit, because they are fast and the context is fresh. Container image scanning when the artifact is built. Infrastructure as Code analysis before apply. Slower verification stays off the blocking path.

The rule that makes the whole thing sustainable is the initial threshold: block only on severe vulnerabilities that have a fix available. A pipeline that halts on any finding gets routed around within a fortnight, and at that point you have made things worse rather than better.

## Secrets and supply chain

On secrets, the goal is moving from static credentials to short-lived ones generated on demand. Vault issues database access when the service needs it, valid for hours, and revokes it afterwards. This is not only about rotation: a credential that does not exist in permanent form cannot end up in a log or a repository.

On the supply chain the work is about traceability of what you ship. Artifact signing, SBOM generation on every build, automated dependency updates with Renovate. That last point has the most immediate return: most vulnerabilities found in production concern dependencies whose fix has existed for months and simply was not applied.

When the product falls under the Cyber Resilience Act, this same chain becomes a regulatory requirement rather than good practice, and it has to keep running for the whole support period. The [CRA compliance page](https://lucabertelli.consulting/en/services/cyber-resilience-act-compliance/) covers what changes: VEX and VDR on top of the SBOM, continuous monitoring of supported releases, and the evidence for the reporting deadlines.

Frequently asked questions:

Q: What is the difference between DevSecOps and SecDevOps?
A: In practice they describe the same goal: integrating security into the development cycle rather than applying it at the end. I use SecDevOps because the word order better reflects the idea that security is a starting requirement, not a check added after the thing is built.

Q: Do security checks slow the pipeline down?
A: If they are all made blocking at the same point, yes, and that is exactly how teams learn to bypass them. The setup that works spreads the checks out: fast ones run on every commit and block, slow ones run asynchronously or nightly and raise findings. And you start by blocking only on severe vulnerabilities that have a fix available, otherwise the noise makes the signal unusable.

Q: How do you manage secrets in pipelines?
A: With HashiCorp Vault, where I hold the Operations Professional and Implementation Partner certifications. The goal is to eliminate static credentials in favour of short-lived dynamic secrets, generated on demand and individually revocable. Credentials that do not exist permanently cannot be exfiltrated from a repository or a log.

Q: What does NIS2 compliance mean technically?
A: On the delivery side it mostly means traceability: knowing what was released, who approved it, which third-party components it contains and how known vulnerabilities are handled. A pipeline that produces an SBOM, signs artifacts and retains approval logs generates that evidence as a normal by-product of running, instead of requiring a manual collection exercise before every audit.

Q: Which CI/CD tools do you work with?
A: Mainly GitLab CI and GitHub Actions, with Argo Workflows and Argo CD for orchestration and deployment on Kubernetes. On the security side I integrate SAST and SCA scanners, container image scanning and static analysis of Infrastructure as Code, chosen according to what the client already owns.

### Cyber Resilience Act Compliance Consulting (English)

- URL: https://lucabertelli.consulting/en/services/cyber-resilience-act-compliance
- Language: en
- Summary: Cyber Resilience Act consulting in Italy and the EU: Annex I gap assessment, vulnerability handling, SBOM, secure updates, documentation, reporting readiness.
- Topics: Cyber Resilience Act consulting, Cyber Resilience Act compliance, CRA compliance, CRA gap assessment, vulnerability handling process, SBOM generation, VEX, VDR, coordinated vulnerability disclosure, CRA technical documentation, software supply chain security

The engineering side of the CRA: secure-by-design evidence, a vulnerability handling process that runs for the whole support period, technical documentation generated by your pipeline, and a team able to meet the 24-hour reporting clock.

Outcomes:
- A clear map of which products are in scope, in which class, and what each one is missing against Annex I
- A vulnerability handling process that works: intake, triage, fix, advisory and update, on every supported release
- SBOM, signed artifacts and VEX/VDR generated by the build, so the technical documentation describes what you actually ship
- Security updates that reach users through a verifiable channel, separate from feature releases
- A team that knows what to do in the first 24 hours after becoming aware of an actively exploited vulnerability
- Annex VII technical documentation kept current by the release process rather than rebuilt before an assessment

Deliverables:
- Product inventory and gap assessment: scope, classification (default, important class I or II, critical), current state against Annex I Parts I and II
- Engineering input to the cybersecurity risk assessment: attack surface, secure-by-default configuration, logging, data deletion, exploit mitigations, mapped to Part I requirements
- Vulnerability handling process: single point of contact, coordinated vulnerability disclosure policy, intake, triage with VEX, remediation targets, upstream reporting for third-party components
- SBOM generation in the pipeline (CycloneDX or SPDX), per artifact and per release, with VDR published alongside each supported version
- Artifact signing and provenance attestations, plus a secure update channel: security updates separate from functionality updates, advisories in machine-readable form, updates retained for the required period
- Continuous monitoring of every release inside its support period, with alerts routed to the owning team
- Reporting readiness: awareness criteria, 24-hour / 72-hour / 14-day runbook, Single Reporting Platform registration, user notification templates, and a tabletop exercise
- Annex VII technical documentation assembled from pipeline outputs: versions, architecture, processes, SBOM, test reports, support period rationale
- Release classification so the team can tell a maintenance update from a substantial modification before shipping it
- Handover: the internal team runs and extends everything without me

## The problem I usually find

Most teams I meet on this topic have already read the regulation, or a summary of it, and have often concluded that the hard part is the paperwork. It is not. The hard part is that the CRA describes a process that runs for the entire support period of every product, and the current delivery process was never designed to produce that kind of evidence continuously.

As a result, nobody is likely to have a complete list of which products, versions and embedded components are actually in scope. An SBOM was generated once, by hand, for a customer questionnaire, and nobody knows which build it describes. The vulnerability scanner reports two hundred findings per release, most of them in code the product never executes, so the team has stopped reading it. Security fixes ship inside feature releases, so a customer who cannot take the feature does not get the fix either. There is no published address to report a vulnerability to, and if a researcher wrote to the sales mailbox tomorrow it would take days to reach an engineer. And since 11 September 2026 the reporting clock is already running for products that were sold years ago.

## How I work

I start from what the product and the pipeline already do, not from the text of the regulation. Annex I lists thirteen properties the product must have and eight things the manufacturer must be able to do with vulnerabilities. Each maps to a design choice, a build step or a process still to be defined, and the gap to check is exactly that mapping together with the classification that decides whether a notified body is involved.

The work is then sequenced by what is already enforceable and by return. First the vulnerability handling process and reporting readiness, because Article 14 applies today and covers products already on the market. Then the supply chain evidence, SBOM, signing, secure updates, because everything downstream depends on knowing what is in each release. Then the Part I product requirements, which are mostly design work with the product team and feed the risk assessment. Technical documentation is not a phase of its own: it is assembled from the outputs of the previous three, so that it describes what ships and stays current on every release.

The tooling comes from what is already in use. GitLab CI and GitHub Actions, for example, both have adequate options for generating SBOMs, signing artifacts and publishing advisories; the differences between them matter far less than whether the output is reviewed, kept and reachable when an authority asks for it.

## What the engineering work covers

**Scope and classification.** An inventory of products with digital elements, including firmware, on-premise software, agents and edge components of SaaS products, and the third-party components that are integrated. Each product gets a class (default, important class I or II, critical) using the technical descriptions in Implementing Regulation 2025/2392, because that decides the conformity assessment route and therefore the calendar.

**Vulnerability handling (Annex I, Part II).** A single point of contact that every user can find, a vulnerability disclosure policy, and a notification that reaches the dedicated team. Triage recorded as VEX statements so that the same question is not investigated twice. Remediation targets ordered by severity. Reporting upstream when the vulnerability is in a third-party component, as Article 13(6) requires. Security updates built and shipped separately from feature updates where technically feasible, with advisories in a machine-readable format.

**Supply chain evidence.** SBOM generated at build time, per artifact, in CycloneDX or SPDX, stored next to the artifact it describes, with the signature covering both. Provenance attestations that link the artifact to the commit and the pipeline run that produced it. A VDR per supported release, generated from the VEX history. Signing keys kept out of the pipeline and used through short-lived credentials, the same work I do on the [SecDevOps side](https://lucabertelli.consulting/en/services/secdevops-cicd-consulting/).

**Secure update distribution.** A channel through which users can verify that an update comes from a recognised and verified source, security updates disseminated without delay and free of charge, and a retention plan so that each update stays available for the ten years the regulation requires.

**Continuous monitoring.** The SBOMs of every release still inside its support period are checked continuously against new vulnerability data. Matches go to the team that owns the component, with the VEX history attached, and feed the awareness assessment that may start the reporting clock.

**Reporting readiness.** Registration on the Single Reporting Platform, a written criterion for what "becoming aware" means in your organisation and where that moment is recorded, a runbook for the 24-hour early warning, the 72-hour notification and the final report, templates for informing impacted users, and a tabletop exercise.

**Technical documentation (Annex VII).** Versions affecting compliance, architecture, the vulnerability handling process with its SBOM and disclosure policy, the risk assessment, the support period rationale, test reports and the declaration of conformity, assembled from pipeline outputs on every release rather than written once before the assessment.

## Typical situations

- A manufacturer of connected devices whose firmware is built by a supplier, and who has to answer for the SBOM, the update channel and the support period without owning the build.
- An independent software vendor shipping on-premise software to customers who are themselves in scope and are already asking for SBOMs and disclosure policies in procurement.
- A SaaS company that thought it was out of scope until it counted its edge agents, mobile apps and on-premise connectors.
- A product built on Kubernetes that ships a container runtime. A public sector supplier whose tender responses now include CRA questions.

In each case the regulation is the same; what changes is where the evidence has to come from.

## What I do not do

I do not classify your product, nor do I stand in for any legal counsel on the conformity assessment route and the drafting of its declaration. What I make sure of is that when those decisions are taken, the product, the process and the documentation they depend on actually exist, are produced by your pipeline and describe what you ship.

Frequently asked questions:

Q: Who does the Cyber Resilience Act apply to?
A: Manufacturers placing products with digital elements on the EU market: software and hardware that can connect to a network, directly or indirectly, and the components embedded in them, regardless of where the manufacturer is established. Importers and distributors have their own duties. Software offered purely as a service is out of scope, since NIS2 covers it, unless it is remote data processing without which the product cannot perform its functions. Free and open source software developed outside a commercial activity is not covered; organisations that sustain such projects may be 'open source stewards' with a lighter regime. The Commission guidance of 27 July 2026 (C(2026) 5252) walks through these boundaries with worked examples. Whether your product is in scope and in which class is a question for your legal advisor; my work starts once the answer is yes.

Q: What are the Cyber Resilience Act deadlines?
A: Regulation (EU) 2024/2847 entered into force on 10 December 2024. Chapter IV, on notified bodies, applies since 11 June 2026. The reporting obligations of Article 14 apply since 11 September 2026, and they cover every in-scope product already on the market, not only new ones. Everything else, essential requirements, conformity assessment, CE marking and technical documentation, applies from 11 December 2027 to products placed on the market from that date, and to older products only if they are substantially modified. The Digital Omnibus package has not changed these dates.

Q: What does the CRA actually require beyond an SBOM?
A: Two sets of essential requirements in Annex I. Part I concerns the product: no known exploitable vulnerabilities at release, secure-by-default configuration, security updates that can be installed automatically, access control, encryption of data at rest and in transit, integrity protection, data minimisation, availability under denial of service, limited attack surface, exploit mitigations, security logging and secure data deletion, each applied on the basis of a documented risk assessment. Part II concerns the manufacturer's processes: identify and document vulnerabilities and components (this is where the SBOM lives), fix them without delay, test regularly, disclose fixed vulnerabilities publicly, run a coordinated vulnerability disclosure policy, provide a contact for vulnerability reports, distribute updates securely, and ship security updates free of charge with an advisory. The SBOM is one point out of twenty-one.

Q: Which class is my product in, and does it change the conformity assessment route?
A: Most products are in the default category and can be self-assessed. Annex III lists 'important' products in two classes, with technical descriptions in Implementing Regulation (EU) 2025/2392: class I includes operating systems, browsers, password managers, VPNs, network management systems, SIEMs, routers and switches, smart home security devices; class II includes hypervisors and container runtimes, firewalls and intrusion detection systems, tamper-resistant microprocessors. Annex IV lists 'critical' products such as hardware security modules and smart meter gateways. Class II and critical products need a notified body or a European certification scheme. Class I can be self-assessed only by applying a harmonised standard, and no CRA harmonised standard has been cited in the Official Journal yet, so for now class I in practice also means a notified body. This is the decision that most affects timing and budget, and it should be taken early.

Q: Is there a mandated SBOM format?
A: No. The regulation asks for a commonly used, machine-readable format covering at least the top-level dependencies, and gives the Commission the power to specify format and elements by implementing act, which has not been exercised. In practice this means CycloneDX or SPDX. The most concrete reference for content today is the German BSI Technical Guideline TR-03183-2, which market surveillance authorities are likely to lean on; building to that bar avoids rework when a standard is cited. The SBOM is not required to be public: it goes into the technical documentation and is handed to a market surveillance authority on reasoned request.

Q: What is the difference between SBOM, VEX and VDR, and why do I need all three?
A: The SBOM is the inventory of components in a specific version of the product. A VEX statement is a judgement about one vulnerability in one of those components: affected, not affected, fixed or under investigation, with the reasoning. The VDR is the report assembled from those judgements, listing which known vulnerabilities concern a release and what has been done about them. The SBOM alone produces a long list of matches, most of them not exploitable in your product; the Commission guidance itself notes that a vulnerable component whose code is not reachable does not make the product's vulnerability 'actively exploited'. VEX is how you record that judgement once instead of re-investigating every week, and the VDR is what you hand to a customer or an authority.

Q: What starts the 24-hour reporting clock?
A: Becoming aware of an actively exploited vulnerability in your product, or of a severe incident affecting its security. The Commission guidance reads 'aware' as having reached a reasonable degree of certainty after an initial assessment, and the Single Reporting Platform does not record that moment for you, so you need your own evidence of when the assessment concluded. From there: early warning within 24 hours, notification within 72 hours, final report within 14 days of a corrective measure being available (one month for incidents), all through ENISA's platform, with the CSIRT coordinator of your main establishment as the recipient. Separately, impacted users must be informed. Vulnerabilities you already knew were exploited before 11 September 2026 do not have to be reported retroactively.

Q: How long do the obligations last?
A: For the support period, which the manufacturer sets according to the expected time of use and which must be at least five years unless the product is expected to be used for less. During that period vulnerabilities must be handled and security updates provided; each security update must then remain available for at least ten years or the rest of the support period, whichever is longer. The end date of support has to be printed in the user information. A vulnerability handling process that only covers the latest release does not meet this.

Q: What is a substantial modification, and why does it matter for software that ships continuously?
A: A change after placing on the market that affects compliance with the Part I requirements or changes the intended purpose the product was assessed for. When that happens the modified product counts as newly placed on the market and must go through conformity assessment again. Security updates and maintenance releases are not substantial modifications; a release that adds control over connected machines to a monitoring dashboard is, to take one of the Commission's own examples. Teams that release weekly need a way to classify each release against this test before it ships, not after.

Q: What are the penalties, and who enforces the CRA in Italy?
A: Up to EUR 15 million or 2.5% of worldwide annual turnover for breaching the essential requirements or the manufacturer obligations in Articles 13 and 14; lower ceilings for other breaches and for supplying misleading information to authorities. Enforcement is national. In Italy, Law 36/2026 designates the Agenzia per la Cybersicurezza Nazionale (ACN) both as notifying authority for conformity assessment bodies and as market surveillance authority, and CSIRT Italia, run by ACN, is the CSIRT coordinator that receives Article 14 notifications. The implementing legislative decree that fixes the national penalty scale is still pending.

Q: Do you provide legal advice on the Cyber Resilience Act?
A: No. Product classification, the conformity assessment route, the support period decision and the contents of the EU declaration of conformity are decisions you take with legal counsel and, where the class requires it, a notified body. I cover the engineering side: making sure the product, the pipeline and the team produce the evidence those decisions rely on, and keep producing it after the assessment.

### DevOps and Cloud Native Training (English)

- URL: https://lucabertelli.consulting/en/services/devops-cloud-native-training
- Language: en
- Summary: Corporate training on Kubernetes, DevOps, SecDevOps and Terraform: tailored programmes in English and Italian, with hands-on labs based on your own real tooling.
- Topics: corporate Kubernetes training, DevOps training, Kubernetes course, Terraform training, cloud native training, SecDevOps training

Corporate training on Kubernetes, DevOps and SecDevOps, built around your stack rather than a demo environment.

Outcomes:
- The team works on its own real repositories, not on a demo application
- Knowledge spread across the group instead of concentrated in the usual two people
- A programme calibrated to the participants' actual level, verified before we start
- Material that stays with the company and can be reused for new hires

Deliverables:
- Preliminary level check and goal setting with the technical leads
- Tailored curriculum, in English or Italian
- Hands-on labs on environments aligned with your stack
- Course material and recordings handed over to the company
- Follow-up session a few weeks later, on the problems that surfaced in between

## Why catalogue training often is not enough

A standard Kubernetes course teaches Kubernetes. That is useful, and it is also why certifications exist. But the following week participants go back to a cluster configured in its own particular way, with corporate constraints, inherited decisions and a pipeline that looks nothing like the one in the exercise. The gap between the example and reality is where most of the learning evaporates.

There is also a question of level. In nearly every group I train the internal spread is wide: two or three people already have experience, the rest are starting from zero. A single programme bores the former and loses the latter.

## How I build a programme

Before defining the curriculum I talk to the technical leads and check the participants' actual level, usually with a short questionnaire. It tells me how much time to spend on fundamentals and which topics can be assumed. It costs very little and noticeably changes how much the days deliver.

The programme alternates explanation and practice in short blocks. The lab part uses an environment aligned with yours: if you work with GitLab CI the lab is on GitLab CI, if your cluster runs on AKS the exercises run on AKS. That removes the mental translation step that usually prevents people from applying what they learned.

Sessions are spread over time where possible, rather than compressed into one intensive week. Between sessions participants try what they saw on real work, and the next session starts from the difficulties that surfaced. That is when the programme produces the most value.

## What remains afterwards

Course material and recordings stay with the company and can be reused for future hires. A few weeks later I schedule a follow-up session dedicated to the problems the team ran into in the meantime: it is short, but it is the part that really consolidates adoption.

The experience behind these programmes is operational before it is didactic. I worked on the same problems as a DevOps Engineer, as a Cloud Native Engineering Manager and as a consultant, and the examples I use in the room come from there.

Frequently asked questions:

Q: Which topics do you teach?
A: Kubernetes from fundamentals to production operations, Docker and containerisation, Terraform and Infrastructure as Code, CI/CD pipelines with GitLab CI and GitHub Actions, GitOps with Argo CD, secrets management with HashiCorp Vault, SecDevOps practices and Platform Engineering foundations. Tracks can be combined according to your goals.

Q: Are courses delivered in English or Italian?
A: Both. For teams spread across countries I run sessions in English, with material in the same language.

Q: How is this different from an off-the-shelf course?
A: The labs. A catalogue course uses a demo application that looks nothing like what participants manage every day, and the gap between the example and reality is where most of the learning is lost. The programmes I build start from your repositories and your tooling, so the work done in the room is directly reusable.

Q: How long does a training programme take?
A: An introductory module on a single topic takes one or two days. A full Kubernetes track, from fundamentals to operations, typically runs across four or five days spread over time, so participants can apply what they saw between sessions.

Q: Are courses delivered remotely or on site?
A: Both. Remote works well with groups of up to about ten people; on site is preferable when the programme includes working sessions on the team's concrete problems.

### AI Agent Governance and Adoption (English)

- URL: https://lucabertelli.consulting/en/services/ai-agent-governance
- Language: en
- Summary: Consulting on AI agent governance and adoption across Italy and the EU: usage policy, security hardening, Model Context Protocol integration and inference cost control.
- Topics: AI agent governance, AI agent adoption, AI agent consulting, enterprise AI governance, AI agent security, AI engineering, Model Context Protocol, AI inference cost

Adopting AI agents in the enterprise with clear rules, controlled risk and predictable spend.

Outcomes:
- Agents in production with a defined and auditable scope of action
- Inference spend attributed per team and use case, with enforced limits
- Agent access managed as an identity rather than a shared key
- Explicit criteria for deciding where AI genuinely helps and where it does not

Deliverables:
- Use case assessment, ordered by expected value and risk
- Usage policy: permitted data, allowed actions, human approval points
- Integration architecture, including MCP servers and internal system access
- Hardening: execution isolation, secrets management, action auditing
- Budget model and token consumption monitoring

## The problem I usually find

AI agents enter companies from the bottom up. A developer tries an assistant, a team automates a support flow, someone wires a model to an internal system for a prototype. Within a few months there are several integrations nobody has inventoried, with shared API keys and no clear picture of which data is crossing which service.

The second problem is financial and follows shortly after. Inference spend does not have the predictable profile of a virtual machine: it depends on how much the agent is used and how much context it drags along on each call. Without attribution per use case, the monthly invoice becomes a single number nobody can decompose and therefore nobody can reduce.

## How I work

We start with use case selection, which is mostly an exercise in exclusion. Many tasks proposed for AI automation are cheaper and more reliable solved with ordinary code. The criterion I use is error tolerance: where an approximate answer is cheap and verification is quick, an agent adds value; where deterministic exactness is required, almost never.

For the tasks that pass the filter, we define the operating scope. Which data the agent may read, which actions it may take on its own, which require human approval. It looks like a formality and is instead the part that determines whether the system stays manageable: without explicit limits you discover the real scope only when something goes wrong.

## Security and integration

Technically an agent should be treated as a service with its own identity, not as a tool inheriting the credentials of whoever invokes it. That means minimal and specific permissions, secrets managed through Vault rather than static keys, isolated execution for any generated code, and a complete record of the actions taken.

Indirect prompt injection deserves particular attention because it has no direct equivalent in traditional security models: an agent processing externally sourced content can be induced to perform actions no user requested. The practical mitigation is the same one that applies to any untrusted component, namely reducing what it is able to do rather than hoping it interprets correctly what it reads.

On integration, when several agents need access to the same internal systems it is worth exposing an MCP server instead of multiplying bespoke integrations. It centralises access, permissions and auditing in one place, which is also the only realistic way to keep them consistent over time.

MCP still needs something true to query. If the inventory of how systems actually work lives in thousands of files and a few people's heads, agents fill the gaps with guesses. That is a [knowledge graph](https://lucabertelli.consulting/en/services/knowledge-graph-consulting/) problem, not a model problem.

Frequently asked questions:

Q: What does AI Engineering consulting cover?
A: The lifecycle of AI agents in an enterprise context: selecting the use cases that justify the investment, governance and usage policy, integration architecture with internal systems, security hardening and cost control. It is not model consulting, it is consulting on the infrastructure and the rules that make an agent usable in production.

Q: What security risks are specific to AI agents?
A: The two I treat as priorities are indirect prompt injection, where an agent reading external content can be induced to take unintended actions, and excessive permission scope, because agents are routinely granted credentials far broader than their task requires. Both are addressed with the same least-privilege principle applied to services, plus complete auditing of the actions taken.

Q: What is the Model Context Protocol and when is it worth using?
A: MCP is an open standard for exposing data and tools to AI agents through a uniform interface. It pays off when several agents or clients need access to the same internal systems: instead of writing a dedicated integration for each, you expose an MCP server that centralises access, permissions and auditing. I have published an article on a concrete application of it to Kubernetes fleet monitoring.

Q: How do you keep inference costs under control?
A: By attributing them before they grow. Every use case has a budget, token consumption is tracked per team and per feature, and limits are enforced automatically. The cost that most often escapes notice is not the occasional expensive prompt, it is an agent stuck in a retry loop that nobody capped.

Q: Do we need a self-hosted model or is a managed service enough?
A: In most cases a managed service is adequate. Self-hosting makes sense with genuine data confidentiality constraints or sovereignty requirements, and should be assessed including the operational cost it carries. The decision follows the actual constraints, not the impression that running things in-house is automatically safer.

Q: When does AI agent governance consulting make sense?
A: When agents are already entering the company without a shared perimeter, or when you want to adopt them deliberately before they proliferate. Typical signals are shared API keys, no inventory of use cases, no spend limits, and the question 'who authorised this agent to read that data?' with no clear answer.

### Temporal Knowledge Graph Consulting (English)

- URL: https://lucabertelli.consulting/en/services/knowledge-graph-consulting
- Language: en
- Summary: Knowledge graph and temporal knowledge graph consulting in Italy and the EU: operational facts, time-aware memory for AI agents, and MCP access.
- Topics: knowledge graph consulting, temporal knowledge graph, temporal knowledge graph consulting, operational knowledge graph, knowledge graph for AI agents, AI agent memory, MCP knowledge graph, CI/CD platform migration

Small, deterministic graphs of how your systems actually work, and temporal graphs of how they change, so people and agents query facts, including facts about the past, instead of trying to deduce them.

Outcomes:
- A queryable inventory of how systems actually work, not a slide of how they should
- Humans and AI agents reading the same facts, instead of grepping and guessing
- Coverage and gaps visible before a large platform migration starts
- Facts with a timeline: what was true, when it changed, and what an agent can safely recall
- A graph the internal team can rebuild, not a one-off consultancy artefact

Deliverables:
- Scope: which sources matter, which questions the graph must answer, what stays out
- Typed schema: node and relationship kinds small enough to keep honest
- Extractors from the catalogues, inventories and APIs you already run
- Curated mapping layer so primitives join on capabilities, not on names
- Temporal check where history may have changed: validity intervals, point-in-time queries, incremental updates
- Query surface for people (explorer) and for agents (MCP), plus a repeatable refresh

## The problem I usually find

The map of how a platform actually works lives in the wrong places: a few people's heads, an outdated wiki, and thousands of files nobody wants to review again. When a team asks "what do we run, what is already covered, what would block a move", the honest answer is days of manual reconstruction and three conflicting opinions.

AI agents make the gap louder. Given a repository they reconstruct by intuition a picture of what exists that reads well and is wrong in the places that matter. More context in the prompt does not fix that. They need facts they can query, with types and relationships that do not change meaning between calls.

## How I work

We start from the questions the graph must answer, not from a vocabulary of the business. Which sources already exist (catalogues, inventories, APIs, repositories). Which node and relationship kinds are enough. What we refuse to model, because a graph that pretends to cover everything becomes a second wiki.

Then extractors, not people filling forms. Facts come from artefacts the organisation already maintains. A curated mapping layer joins those primitives on capabilities: the same intent under different names becomes comparable. The store stays small and rebuildable. If you cannot regenerate the graph from sources, you do not have a graph; you have a snapshot.

People get an explorer. Agents get the same facts over MCP. One source of truth, two interfaces. Refresh is a pipeline you re-run, not a committee that tends an ontology.

## When the graph needs a clock

Some questions are not about what is true but about what was true, and when it stopped being. Which team owned this service when the incident happened. What the platform looked like before the last reorganisation. What an agent already learned about a customer in previous sessions. A snapshot graph, however honest, cannot answer them: every rebuild throws the past away.

A temporal knowledge graph keeps it. Each fact carries its validity intervals: when it became true, when it ceased to be, and separately when the system learned it. New observations arrive incrementally as episodes; when they contradict an existing fact, they invalidate it instead of deleting it. The result is a graph you can query at a point in time, and a memory AI agents can actually use: recall what held, see how it changed, and stop re-deriving the world from scratch in every session.

I add this layer only where the domain needs it. Inventories and coverage maps stay rebuildable snapshots; the additional temporal layer is for conversations, ownership, incidents and anything where history carries decisive weight. Same discipline as the rest: a typed schema, explicit relationships, and no product lock-in dictating the model.

## When it stops being optional

A large migration of a legacy CI/CD platform is the case I keep seeing. The target is not the problem; the unknown surface is. Without a graph of work units, coverage and gaps, the project is either frozen or rewritten from zero, which is how you spend a year moving and still cannot say what is left.

With the graph, coverage is a query. Gaps are ranked. Similar pipelines become templates instead of folklore. Efficiency, security and calendar time stop being slogans because you can point at what is ready, what is blocked, and what would be unsafe to invent. I do not claim every migration needs this. I do claim that past a certain size, many of them are unthinkable without it.

## A pragmatic scope

Pragmatic means no enterprise knowledge-graph suite, no RDF programme, and no six-month ontology workshop. The result is a typed schema you can hold in your head, extractors you can read, a mapping file you can disagree with in a review, and a refresh that finishes before the sources have moved again.

Frequently asked questions:

Q: What is a pragmatic knowledge graph?
A: A small, typed graph of operational facts extracted from systems you already have: catalogues, inventories, repositories, APIs. Nodes and directed relationships are explicit, the mapping layer is curated, and a rebuild produces the same result. It is not an enterprise ontology, not a graph-database product, and not a project that starts by modelling the whole company.

Q: How is this different from a graph database or a data-catalogue knowledge graph?
A: Those approaches assume you already know what to put in the graph and that the hard part is storage, search or governance at scale. Here the hard part is choosing a schema small enough to stay true, wiring extractors to sources that already exist, and exposing the same facts to people and to agents. The store is an implementation detail; an embeddable database is usually enough.

Q: When is a knowledge graph worth building?
A: When the answers you need live in thousands of files, several tools, and a few people's heads, and when guessing is expensive. Typical signals: a platform migration nobody can size, AI agents that sketch the inventory without certainty, or the same question answered differently depending on who you ask.

Q: What is a temporal knowledge graph?
A: A knowledge graph where facts carry their own temporal data: when they became true, when they stopped being true, and when the system learned them. New information does not overwrite; it invalidates the fact it contradicts. Questions can then be answered at a precise instant in time: what did the platform look like in March, what changed since the last audit, which owner was responsible when the incident happened.

Q: How does a temporal knowledge graph give AI agents memory?
A: Agents keep re-deriving the state of the world in every session because nothing persists between calls. With a temporal graph, new observations are ingested incrementally as episodes, contradictions invalidate old facts instead of deleting them, and an agent can retrieve what is true now, what was true at a given moment, and how it evolved. Memory becomes a set of queryable facts with provenance, not a transcript injected into the prompt.

Q: How do AI agents use the graph?
A: Through MCP, so any compatible IDE, CLI or assistant queries the same facts the explorer shows. Agents stop grepping repositories and stop filling gaps with plausible fiction. The graph remains read-oriented for them: they look up coverage, blockers and similar work units; changes to source catalogues still go through the team's normal review.

Q: Why do large CI/CD platform migrations stall so often without one?
A: Because the work is not writing the pipelines. It is knowing what already exists, what the target platform already covers, what is missing, and which work units look alike. Without that, teams either freeze or rewrite everything from scratch. Migrations that looked impossible on a file count alone become a sequenced plan once coverage and gaps are queryable. In those cases, a knowledge graph stops being optional.

Q: What do we keep after the engagement?
A: The schema, the extractors, the mapping, the query surface and the refresh path. The internal team should be able to rebuild the graph from sources without further consulting. If the graph only exists while we are collaborating, the engagement failed.

### Consulente DevOps (Italian)

- URL: https://lucabertelli.consulting/it/servizi/consulenza-devops
- Language: it
- Summary: Consulente DevOps freelance in Italia: automazione della delivery, pipeline CI/CD, Infrastructure as Code e pratiche operative per team Fintech, Insurtech e industriali.
- Topics: consulente DevOps, consulenza DevOps, DevOps freelance, consulente DevOps Italia, consulente DevOps freelance, automazione CI/CD, Infrastructure as Code, consulenza CI/CD

Consulenza DevOps freelance per team che vogliono rilasciare più spesso, con meno incidenti e senza dipendere da una sola persona.

Outcomes:
- Rilasci frequenti e ripetibili, senza finestre notturne e senza passaggi manuali
- Tempi di build e di deploy ridotti, con feedback agli sviluppatori in minuti anziché ore
- Infrastruttura descritta in codice, versionata e ricostruibile da zero
- Conoscenza operativa distribuita nel team, non concentrata in una sola persona

Deliverables:
- Assessment dello stato attuale di delivery e operations, con priorità di intervento motivate
- Pipeline CI/CD implementate sul vostro stack (GitLab CI, GitHub Actions, Argo)
- Moduli Terraform riutilizzabili e struttura degli ambienti
- Runbook operativi e documentazione delle scelte architetturali
- Affiancamento al team interno durante l'adozione

## Il problema che di solito trovo

Quasi sempre la richiesta arriva nello stesso modo: i rilasci fanno paura. Si accumulano per settimane, richiedono una finestra concordata, coinvolgono una persona sola che "sa come si fa" e ogni tanto qualcosa si rompe in produzione senza che sia chiaro perché.

Sotto quella superficie trovo quasi sempre le stesse cause. Gli ambienti di test non somigliano alla produzione, quindi i problemi emergono tardi. L'infrastruttura è stata creata a mano nel tempo e nessuno sa ricostruirla. Le pipeline esistono ma sono lente, non affidabili, e il team ha imparato a rilanciarle finché non passano. I segreti sono sparsi tra variabili d'ambiente e file di configurazione.

Nessuno di questi è un problema di strumenti. Sono problemi di processo, che gli strumenti da soli non risolvono.

## Come intervengo

Parto sempre da un assessment, perché installare tooling prima di capire come lavora il team è il modo più veloce per aggiungere complessità inutile. Guardo il flusso reale che porta una modifica dal commit alla produzione, misuro dove si perde tempo e dove nascono gli incidenti, e ne ricavo una lista di interventi ordinata per rapporto tra impatto e sforzo.

Da lì si lavora in modo incrementale. Prima si stabilizza la continuous integration, perché una pipeline di cui il team non si fida rende inutile tutto il resto. Poi si porta l'infrastruttura sotto controllo con Terraform, in modo che gli ambienti siano ricostruibili e confrontabili. Infine si automatizza la delivery, tipicamente con un approccio GitOps in cui lo stato desiderato del sistema vive in Git e la riconciliazione è continua.

L'ultima fase è quella che conta di più a distanza di un anno: il trasferimento di competenze. Documentazione delle scelte, runbook per le operazioni ricorrenti, sessioni di lavoro con il team. Una consulenza DevOps riuscita è quella dopo la quale il cliente non ha più bisogno del consulente.

## L'esperienza da cui arrivo

Ho lavorato su questi problemi dal 2018, prima come DevOps Engineer, poi come Cloud Native Engineering Manager e oggi come consulente indipendente. I settori in cui ho maturato più esperienza sono Fintech, Insurtech e industriale: contesti in cui il vincolo non è solo tecnico, ma anche di conformità, auditabilità e continuità del servizio.

Questa origine spiega l'approccio. In un ambiente regolamentato non basta che il deploy funzioni: deve essere tracciabile, ripetibile e spiegabile a chi lo verifica.

Frequently asked questions:

Q: Che cosa fa concretamente un consulente DevOps?
A: Un consulente DevOps interviene sul modo in cui il software passa dal repository alla produzione: automazione delle pipeline CI/CD, gestione dell'infrastruttura come codice, standardizzazione degli ambienti, osservabilità e pratiche operative. L'obiettivo non è introdurre strumenti, ma ridurre il tempo e il rischio di ogni rilascio, lasciando al team interno la capacità di mantenere ciò che è stato costruito.

Q: Lavori come freelance o tramite società di consulenza?
A: Lavoro come consulente freelance indipendente con partita IVA italiana. Questo significa un interlocutore tecnico unico, che partecipa direttamente all'implementazione invece di limitarsi alla supervisione.

Q: Quanto dura un intervento di consulenza DevOps?
A: Dipende dal perimetro. Un assessment mirato si esaurisce in poche giornate e produce una lista di priorità. Un percorso di adozione completo, con implementazione delle pipeline e affiancamento del team, si articola su più mesi con obiettivi verificabili a ogni tappa. In entrambi i casi il perimetro viene definito prima di iniziare.

Q: Lavori da remoto o in sede?
A: Prevalentemente da remoto, con la possibilità di giornate in sede quando servono workshop, sessioni di design o formazione al team. Opero principalmente con clienti in Italia e nell'Unione Europea.

Q: Su quali tecnologie DevOps sei specializzato?
A: Kubernetes e l'ecosistema CNCF, Terraform per l'Infrastructure as Code, GitLab CI e GitHub Actions per la continuous integration, Argo CD e Argo Workflows per GitOps e automazione, HashiCorp Vault per la gestione dei segreti, Prometheus e Grafana per l'osservabilità.

Q: Quanto costa un consulente DevOps e come viene prezzato il lavoro?
A: Due modelli. Un prezzo fisso per interventi con un risultato definito, come un assessment o una migrazione con perimetro chiaro, e una tariffa giornaliera per collaborazioni più lunghe in cui il perimetro evolve insieme al team. In entrambi i casi ricevete una proposta scritta con deliverable, stima dell'impegno ed esclusioni prima di iniziare, così la cifra è confrontabile con altri preventivi e non una sorpresa alla prima fattura.

Q: Conviene assumere un DevOps engineer o rivolgersi a un consulente?
A: Assumere quando il lavoro è continuativo e specifico del vostro prodotto: qualcuno deve presidiare la piattaforma giorno dopo giorno. Rivolgersi a un consulente quando il problema è una transizione che ha una fine, come impostare la pipeline di delivery, migrare a Kubernetes o prepararsi a una normativa, oppure quando serve un secondo parere su scelte già fatte. Spesso le due cose si combinano: imposto la pratica e le pipeline, poi le consegno alla persona che assumete, che eredita documentazione e un sistema funzionante invece di una pagina bianca.

### Consulenza Cloud e migrazione (Italian)

- URL: https://lucabertelli.consulting/it/servizi/consulenza-cloud-migrazione
- Language: it
- Summary: Consulenza cloud in Italia: strategia di adozione, migrazione di applicazioni e infrastruttura verso AWS, Azure e Google Cloud, governance e controllo dei costi.
- Topics: consulente cloud, consulenza cloud, migrazione cloud, cloud adoption, consulente cloud Italia, governance costi cloud

Adozione del cloud e migrazione di applicazioni e infrastruttura, con costi sotto controllo e senza riscrivere tutto dal primo giorno.

Outcomes:
- Una strategia di migrazione ordinata per rischio e valore, non un big bang
- Ambienti cloud coerenti tra loro e ricostruibili da codice
- Spesa cloud prevedibile, attribuita ai team e ai progetti che la generano
- Nessun lock-in involontario: le scelte vincolanti sono esplicite e motivate

Deliverables:
- Assessment del portafoglio applicativo e classificazione dei carichi di lavoro
- Piano di migrazione per ondate, con criteri di uscita per ciascuna
- Landing zone e struttura degli account/subscription in Terraform
- Modello di governance: naming, tagging, budget e allarmi di spesa
- Migrazione assistita dei primi carichi, come riferimento per i successivi

## Il problema che di solito trovo

Il cloud raramente arriva per decisione unitaria. Nella maggior parte delle organizzazioni con cui lavoro è entrato in modo frammentario: un team che ha aperto un account per un prototipo, un fornitore che ha portato con sé la propria infrastruttura, una migrazione parziale interrotta a metà. Il risultato è un ambiente ibrido non progettato, con account che nessuno governa e una spesa che cresce senza che sia chiaro chi la produca.

La seconda variante che incontro spesso è opposta: il "lift and shift" completato ma mai finito davvero. Le macchine virtuali sono state spostate, l'architettura è rimasta quella di prima, e adesso si pagano le stesse risorse di prima con in più il margine del provider. Il cloud viene percepito come un fallimento quando in realtà non è mai stato adottato, solo affittato.

## Come intervengo

Il punto di partenza è la classificazione dei carichi di lavoro. Ogni applicazione viene valutata su quanto è accoppiata all'infrastruttura sottostante, quali dati tratta, quali vincoli normativi la riguardano e quanto è variabile il suo profilo di utilizzo. Da questa griglia emerge in modo abbastanza naturale che cosa vada spostato così com'è, che cosa vada rivisto durante la migrazione e che cosa convenga lasciare dov'è.

Prima di spostare qualsiasi cosa si prepara la landing zone: struttura degli account, rete, identità e permessi, gestione dei segreti, convenzioni di naming e tagging. Tutto descritto in Terraform, perché un ambiente cloud costruito a mano riproduce nel giro di due anni esattamente il disordine da cui si voleva uscire.

La migrazione procede poi per ondate, partendo da carichi a basso rischio che servono a validare gli automatismi. Ogni ondata ha criteri di uscita espliciti, e le prime vengono eseguite insieme al team interno perché diventino il modello per quelle successive.

## La governance dei costi, dal primo giorno

Il controllo della spesa non è una fase finale di ottimizzazione, è una proprietà da costruire fin dall'inizio. Se il tagging è coerente dal primo deploy, attribuire i costi a un team o a un progetto è immediato; se lo si introduce dopo, diventa un lavoro di ricostruzione su risorse di cui si è persa la traccia.

In pratica significa budget e allarmi per ambiente, revisione periodica del dimensionamento, spegnimento automatico di ciò che non serve fuori orario, e una regola semplice: ogni risorsa deve avere un proprietario identificabile.

Frequently asked questions:

Q: Da dove si comincia una migrazione in cloud?
A: Da un inventario onesto di ciò che si ha. Prima di scegliere un provider o un'architettura serve capire quali applicazioni esistono, come sono accoppiate tra loro, quali dati trattano e quali vincoli normativi le riguardano. Solo a quel punto ha senso decidere che cosa spostare così com'è, che cosa rivedere e che cosa conviene lasciare dov'è.

Q: Conviene sempre migrare tutto in cloud?
A: No, e dirlo fa parte del lavoro. Alcuni carichi hanno un profilo di utilizzo costante e prevedibile per cui il cloud pubblico è semplicemente più caro. Altri sono legati a hardware o licenze che rendono la migrazione sproporzionata rispetto al beneficio. Un piano credibile include anche ciò che resta dov'è.

Q: Con quali cloud provider lavori?
A: AWS, Microsoft Azure e Google Cloud, oltre a scenari ibridi e on-premise basati su Kubernetes. L'approccio è di mantenere gli automatismi il più possibile portabili con Terraform e strumenti CNCF, e di rendere esplicita ogni dipendenza specifica dal provider.

Q: Come si evita che i costi cloud sfuggano di mano?
A: Rendendoli visibili prima che diventino un problema. Significa una convenzione di tagging applicata dal primo giorno, budget e allarmi per ambiente, dimensionamento delle risorse rivisto periodicamente e spegnimento automatico degli ambienti non produttivi. La maggior parte degli sprechi che incontro non deriva da scelte sbagliate, ma da risorse che nessuno sa più a chi appartengano.

Q: Quanto dura una migrazione cloud?
A: Le prime ondate di carichi non critici si completano tipicamente in poche settimane dopo la preparazione della landing zone. Un portafoglio applicativo esteso richiede più mesi. Lavorare per ondate serve proprio a rendere disponibile valore in modo continuo, invece di attendere la fine di un progetto unico.

### Consulenza Platform Engineering (Italian)

- URL: https://lucabertelli.consulting/it/servizi/consulenza-platform-engineering
- Language: it
- Summary: Consulenza Platform Engineering in Italia: progettazione di Internal Developer Platform, golden path, self-service su Kubernetes e misurazione dell'adozione da parte dei team.
- Topics: consulenza platform engineering, consulente platform engineering, platform engineering, internal developer platform, IDP, golden path, developer experience, piattaforma interna sviluppatori

Progettazione di Internal Developer Platform che riducono il carico cognitivo degli sviluppatori invece di spostarlo altrove.

Outcomes:
- Uno sviluppatore nuovo arriva in produzione in giorni, non in settimane
- Percorsi standard che sono la strada più semplice, quindi vengono scelti spontaneamente
- Il team di piattaforma smette di essere un ticket desk e torna a costruire
- Standard di sicurezza e conformità applicati per costruzione, non per revisione

Deliverables:
- Ricerca sugli utenti interni: dove si perde davvero tempo nel ciclo di sviluppo
- Disegno della piattaforma e definizione dei golden path
- Template self-service per creazione servizi, ambienti e pipeline
- Portale per sviluppatori e catalogo dei servizi
- Metriche di adozione e ciclo di feedback con i team consumatori

## Il problema che di solito trovo

Quando un'organizzazione supera i tre o quattro team di sviluppo, la promessa "ogni team è autonomo sul proprio stack" comincia a incrinarsi. Ogni team ha configurato Kubernetes a modo suo, ha scritto le proprie pipeline, ha scelto il proprio modo di gestire i segreti. Nessuna di queste scelte è sbagliata presa singolarmente; l'insieme è ingestibile.

A quel punto succede una di due cose. O il gruppo infrastrutturale diventa un ticket desk, sommerso da richieste ripetitive che lo consumano interamente, oppure gli sviluppatori si arrangiano e la superficie di rischio cresce in silenzio. In entrambi i casi il tempo che serve a portare un servizio nuovo in produzione si misura in settimane, e nessuno sa spiegare con precisione perché.

## Come intervengo

La prima fase non è tecnica. Parlo con gli sviluppatori che dovranno usare la piattaforma e ricostruisco che cosa fanno davvero in una settimana di lavoro: quali passaggi ripetono, dove aspettano qualcun altro, quali configurazioni copiano da un progetto all'altro senza capirle fino in fondo. Una piattaforma costruita su ipotesi invece che su osservazione finisce per automatizzare i problemi sbagliati.

Da lì si definiscono i golden path: i percorsi standard per le attività ricorrenti, dalla creazione di un servizio nuovo alla promozione tra ambienti. La caratteristica che li rende efficaci non è l'imposizione, è il fatto di essere la strada più semplice. Se il percorso standard è anche il più comodo, viene scelto senza bisogno di policy.

Serve però che sia sempre possibile uscirne. Le piattaforme che falliscono sono quasi sempre quelle che hanno tolto agli sviluppatori la possibilità di fare qualcosa di non previsto: il primo caso legittimo che il modello non copre le trasforma da acceleratore a ostacolo.

## Costruire per gradi

Non consiglio quasi mai di partire da un portale. Il portale è l'ultima cosa, quando c'è già qualcosa da esporre. Si parte dal caso d'uso che fa perdere più tempo a più persone, lo si rende self-service davvero, e lo si mette a disposizione. Poi il successivo.

Questo approccio ha un effetto collaterale utile: obbliga a verificare l'adozione a ogni passo, invece di scoprire dopo un anno di lavoro che la piattaforma non risolve i problemi che i team hanno veramente.

Frequently asked questions:

Q: Che cos'è il Platform Engineering?
A: È la disciplina che tratta l'infrastruttura interna come un prodotto, con utenti reali che sono gli sviluppatori dell'azienda. Invece di chiedere a ogni team di comporre da sé Kubernetes, pipeline, segreti e osservabilità, una piattaforma interna offre percorsi già pronti e sicuri per le attività ricorrenti, lasciando aperta la possibilità di uscirne quando serve.

Q: Che differenza c'è tra Platform Engineering e DevOps?
A: DevOps descrive un insieme di pratiche e una cultura di collaborazione tra sviluppo e operations. Il Platform Engineering è una risposta organizzativa a un problema che il DevOps ha generato su larga scala: chiedere a ogni team di padroneggiare l'intero stack non scala oltre un certo numero di team. La piattaforma incapsula quella complessità dietro interfacce stabili.

Q: Serve davvero una Internal Developer Platform alla mia azienda?
A: Sotto i tre o quattro team di sviluppo, quasi mai: il costo di costruirla e mantenerla supera il beneficio. Diventa sensata quando la stessa configurazione viene ricreata da più team in modo leggermente diverso ogni volta, quando l'onboarding di un servizio richiede settimane, o quando il gruppo infrastrutturale passa la maggior parte del tempo a rispondere a richieste ripetitive.

Q: Usate Backstage o strumenti simili?
A: Backstage è una scelta valida per il catalogo e il portale, ma è solo la parte visibile. La sostanza sta in ciò che il portale attiva: template di scaffolding, provisioning degli ambienti, policy applicate automaticamente. Ho lavorato anche con Krateo PlatformOps, di cui sono stato co-fondatore, e la scelta dello strumento viene sempre dopo la definizione dei golden path.

Q: Come si misura se la piattaforma sta funzionando?
A: Con l'adozione volontaria, che è l'unico indicatore onesto: se i team usano i percorsi standard senza che sia imposto, la piattaforma sta risolvendo un problema reale. Accanto a quello guardo il tempo dal primo commit al primo deploy in produzione per un servizio nuovo, e la quota di richieste al team di piattaforma che sono diventate self-service.

### Consulenza Kubernetes (Italian)

- URL: https://lucabertelli.consulting/it/servizi/consulenza-kubernetes
- Language: it
- Summary: Consulenza Kubernetes in Italia da consulente certificato CKA: architettura dei cluster, multi-tenancy, GitOps con Argo CD, hardening di sicurezza e operatività day-2.
- Topics: consulente Kubernetes, consulenza Kubernetes, Kubernetes Italia, consulente CKA certificato, GitOps Argo CD, multi-tenancy Kubernetes

Progettazione, messa in sicurezza e gestione di cluster Kubernetes in produzione, da parte di un Certified Kubernetes Administrator.

Outcomes:
- Cluster progettati per la produzione, non prototipi cresciuti per inerzia
- Isolamento reale tra team e ambienti, con quote e policy di rete applicate
- Deploy dichiarativi in GitOps, con drift rilevato invece che subito
- Operatività day-2 documentata: aggiornamenti, backup, ripristino

Deliverables:
- Revisione dell'architettura dei cluster esistenti, con criticità ordinate per gravità
- Provisioning dei cluster in Terraform, riproducibile tra gli ambienti
- Modello di multi-tenancy: namespace, RBAC, quote, network policy
- Continuous delivery in GitOps con Argo CD e Helm o Kustomize
- Hardening di sicurezza e osservabilità con Prometheus e Grafana

## Il problema che di solito trovo

Kubernetes viene quasi sempre adottato in due tempi. Prima qualcuno costruisce un cluster per un progetto pilota, con configurazioni prese dalla documentazione e qualche scorciatoia ragionevole per andare in fretta. Poi il pilota va in produzione, altri team ci si appoggiano, e quelle scorciatoie diventano fondamenta.

I sintomi si assomigliano molto tra un cliente e l'altro. Nessuno sa dire con certezza se ciò che gira nel cluster corrisponde a quanto c'è nel repository. Un carico di lavoro che si comporta male degrada le prestazioni di applicazioni che non c'entrano nulla. Gli aggiornamenti di versione vengono rimandati perché nessuno se la sente, e il cluster resta indietro finché l'aggiornamento diventa un progetto a sé.

## Come intervengo

Se il cluster esiste già, si comincia da una revisione strutturata: architettura, configurazione, sicurezza, osservabilità e prassi operative. Il risultato è un elenco di criticità ordinate per gravità e sforzo, non un documento generico di buone pratiche. Quasi sempre le prime tre voci coprono la maggior parte del rischio reale.

Sul piano dell'isolamento, il lavoro consiste nel rendere effettivo ciò che i namespace suggeriscono soltanto. Namespace, RBAC con privilegi minimi, resource quota, limit range e network policy in negazione predefinita: senza queste, la multi-tenancy è una convenzione di denominazione, non una separazione.

La delivery passa a GitOps con Argo CD. Il vantaggio che conta non è l'automazione in sé, è che lo stato desiderato diventa leggibile in Git e ogni scostamento viene rilevato invece che scoperto durante un incidente. Da lì si costruisce l'operatività day-2: strategia di aggiornamento, backup e ripristino provato davvero, allarmi che segnalano problemi reali invece di generare rumore.

## Fleet e ambienti effimeri

Quando i cluster diventano più d'uno, i problemi cambiano natura. La domanda non è più se un cluster è configurato bene, ma se i cluster sono allineati tra loro e quanto sono indietro rispetto alle versioni correnti di immagini e chart. È un tema su cui lavoro spesso e su cui ho scritto pubblicamente, insieme all'uso di cluster virtuali effimeri per dare a ogni pull request un ambiente di test isolato senza moltiplicare l'infrastruttura da mantenere.

Frequently asked questions:

Q: Sei certificato su Kubernetes?
A: Sì. Sono Certified Kubernetes Administrator (CKA) dal 2020 e Certified Argo Project Associate (CAPA), oltre a VMware Certified Master Specialist in Cloud Native. Le credenziali sono verificabili sui rispettivi badge pubblici Credly, collegati nella sezione certificazioni del sito.

Q: Quali sono gli errori più frequenti nei cluster Kubernetes in produzione?
A: I tre che incontro quasi sempre: assenza di resource request e limit, che rende lo scheduling imprevedibile e provoca contese di risorse tra carichi non correlati; nessuna network policy, per cui ogni pod può parlare con ogni altro pod; e configurazioni applicate a mano sul cluster, che rendono impossibile sapere se l'ambiente corrisponde a quanto descritto nel repository.

Q: Meglio Kubernetes gestito o self-managed?
A: Nella grande maggioranza dei casi, gestito: EKS, AKS o GKE. Gestire il control plane in proprio ha senso solo con vincoli specifici di sovranità del dato, requisiti on-premise o esigenze di personalizzazione che i servizi gestiti non coprono. Il valore che si costruisce sta quasi sempre sopra il control plane, non dentro.

Q: Puoi intervenire su cluster già in produzione?
A: Sì, ed è lo scenario più comune. Si parte da una revisione dell'architettura e della configurazione esistente, con le criticità ordinate per gravità, e si interviene per passi verificabili senza fermare l'attività. Riscrivere da zero un ambiente che funziona è raramente la scelta giusta.

Q: Come gestisci ambienti di test su Kubernetes?
A: Con cluster virtuali effimeri creati per ogni pull request e distrutti alla chiusura. È un approccio che ho documentato in dettaglio in un articolo del blog basato su vCluster e Argo Workflows: dà a ogni sviluppatore un ambiente isolato e realistico senza moltiplicare i cluster reali da mantenere.

### Consulenza SecDevOps e CI/CD (Italian)

- URL: https://lucabertelli.consulting/it/servizi/consulenza-secdevops-cicd
- Language: it
- Summary: Consulenza SecDevOps e CI/CD in Italia: toolchain, pipeline sicure, gestione dei segreti con HashiCorp Vault, supply chain del software e conformità NIS2.
- Topics: consulenza SecDevOps, consulenza DevSecOps, consulenza CI/CD, pipeline CI/CD sicure, DevSecOps Italia, supply chain sicurezza software, HashiCorp Vault, SecDevOps

Toolchain e pipeline che integrano la sicurezza nel flusso di sviluppo, senza trasformarla in un collo di bottiglia.

Outcomes:
- Vulnerabilità intercettate in pipeline, quando correggerle costa poco
- Segreti centralizzati e a rotazione, fuori da repository e variabili d'ambiente
- Artefatti tracciabili: si sa che cosa contiene ogni rilascio e da dove proviene
- Evidenze di conformità prodotte dal processo, non ricostruite prima di un audit

Deliverables:
- Valutazione della toolchain esistente e scelta motivata degli strumenti mancanti
- Controlli di sicurezza integrati in pipeline: SAST, SCA, scansione delle immagini, IaC
- Gestione dei segreti con HashiCorp Vault e rimozione delle credenziali statiche
- Gestione delle dipendenze automatizzata con Renovate
- Firma degli artefatti, generazione della SBOM e dichiarazioni VEX/VDR

## Il problema che di solito trovo

La sicurezza applicativa arriva quasi sempre in ritardo nel ciclo di vita, e questo ne determina il costo. Un penetration test annuale produce un rapporto con trenta rilievi su codice scritto sei mesi prima, da persone che nel frattempo lavorano ad altro. Correggerli significa fermare le attività in corso, e la discussione che ne segue riguarda quali rilievi si possano accettare invece di come evitarli in futuro.

Il secondo tema ricorrente sono i segreti. Nella maggior parte delle organizzazioni con cui inizio a lavorare le credenziali vivono in variabili di configurazione della pipeline, in file non versionati sui server, occasionalmente in un commit vecchio che nessuno ha rimosso dalla cronologia. Sono statiche, condivise, e in pratica non ruotabili: cambiarle richiederebbe di sapere chi le usa, informazione che nessuno possiede.

## Come intervengo

Il primo passo è mappare la toolchain esistente prima di proporre qualsiasi aggiunta. Spesso i controlli ci sono già ma girano in un punto del processo in cui nessuno guarda i risultati, oppure producono così tante segnalazioni da essere stati silenziati. Recuperare ciò che c'è è quasi sempre più rapido che introdurre uno strumento nuovo.

I controlli vengono poi distribuiti lungo la pipeline secondo il loro costo. Analisi statica e verifica delle dipendenze a ogni commit, perché sono veloci e il contesto è fresco. Scansione delle immagini container alla costruzione dell'artefatto. Analisi dell'Infrastructure as Code prima dell'applicazione. Le verifiche più lente restano fuori dal percorso bloccante.

La regola che rende sostenibile l'insieme è la soglia iniziale: si blocca solo su vulnerabilità gravi con una correzione disponibile. Una pipeline che si ferma su qualsiasi rilievo viene aggirata nel giro di due settimane, e a quel punto si è peggiorata la situazione invece di migliorarla.

## Segreti e supply chain

Sulla gestione dei segreti l'obiettivo è passare da credenziali statiche a credenziali generate al momento con scadenza breve. Vault emette l'accesso al database quando il servizio ne ha bisogno, con una validità di ore, e lo revoca dopo. Non è solo una questione di rotazione: una credenziale che non esiste in forma permanente non può finire in un log o in un repository.

Sulla supply chain il lavoro riguarda la tracciabilità di ciò che si rilascia. Firma degli artefatti, generazione della SBOM a ogni build, aggiornamento automatico delle dipendenze con Renovate. Quest'ultimo punto è quello con il ritorno più immediato: la maggior parte delle vulnerabilità che si trovano in produzione riguarda dipendenze per cui la correzione esiste da mesi e semplicemente non è stata applicata.

Quando il prodotto rientra nel Cyber Resilience Act, questa stessa catena passa da buona pratica a requisito normativo, e deve restare in funzione per tutto il periodo di supporto. La pagina sulla [conformità al CRA](https://lucabertelli.consulting/it/servizi/consulenza-cyber-resilience-act/) descrive che cosa cambia: VEX e VDR sopra la SBOM, monitoraggio continuo dei rilasci supportati ed evidenze per le scadenze di notifica.

Frequently asked questions:

Q: Che differenza c'è tra DevSecOps e SecDevOps?
A: Nella pratica indicano lo stesso obiettivo: integrare la sicurezza nel ciclo di sviluppo invece di applicarla alla fine. Uso SecDevOps perché l'ordine delle parole riflette meglio l'idea che la sicurezza sia un requisito di partenza e non un controllo aggiunto dopo la costruzione.

Q: Aggiungere controlli di sicurezza rallenta la pipeline?
A: Se vengono messi tutti in modo bloccante nello stesso punto, sì, e infatti è così che i team imparano a bypassarli. L'impostazione che funziona distribuisce i controlli: quelli rapidi girano a ogni commit e bloccano, quelli lenti girano in modo asincrono o notturno e generano segnalazioni. E si parte bloccando solo le vulnerabilità gravi con una correzione disponibile, altrimenti il rumore rende il segnale inutilizzabile.

Q: Come gestite i segreti nelle pipeline?
A: Con HashiCorp Vault, su cui sono certificato Operations Professional e Implementation Partner. L'obiettivo è eliminare le credenziali statiche a favore di segreti dinamici a scadenza breve, generati al momento della necessità e revocabili singolarmente. Le credenziali che non esistono in modo permanente non possono essere esfiltrate da un repository o da un log.

Q: Cosa comporta la conformità NIS2 sul piano tecnico?
A: Sul piano della delivery comporta soprattutto tracciabilità: sapere che cosa è stato rilasciato, da chi è stato approvato, quali componenti di terze parti contiene e come vengono gestite le vulnerabilità note. Una pipeline che produce SBOM, firma gli artefatti e conserva i log di approvazione genera queste evidenze come effetto normale del proprio funzionamento, invece di richiedere una raccolta manuale prima di ogni verifica.

Q: Con quali strumenti CI/CD lavori?
A: Principalmente GitLab CI e GitHub Actions, con Argo Workflows e Argo CD per l'orchestrazione e il deploy su Kubernetes. Sulla parte di sicurezza integro scanner SAST e SCA, scansione delle immagini container e analisi statica dell'Infrastructure as Code, scegliendoli in base a ciò che il cliente già possiede.

### Consulenza Cyber Resilience Act (CRA) (Italian)

- URL: https://lucabertelli.consulting/it/servizi/consulenza-cyber-resilience-act
- Language: it
- Summary: Consulenza Cyber Resilience Act in Italia: gap assessment sull'Allegato I, gestione delle vulnerabilità, SBOM, aggiornamenti sicuri, documentazione e notifiche.
- Topics: consulenza Cyber Resilience Act, conformità Cyber Resilience Act, adeguamento CRA, conformità CRA, gap assessment CRA, gestione delle vulnerabilità, generazione SBOM, VEX, VDR, coordinated vulnerability disclosure, documentazione tecnica CRA, supply chain sicurezza software

La parte ingegneristica del CRA: evidenze di security by design, un processo di gestione delle vulnerabilità che dura tutto il periodo di supporto, documentazione tecnica generata dalla pipeline e un team in grado di rispettare le 24 ore di notifica.

Outcomes:
- Una mappa chiara di quali prodotti rientrano nel perimetro, in quale classe, e che cosa manca a ciascuno rispetto all'Allegato I
- Un processo di gestione delle vulnerabilità che funziona: ricezione, triage, correzione, avviso e aggiornamento, su ogni rilascio supportato
- SBOM, artefatti firmati e VEX/VDR generati dalla build, così la documentazione tecnica descrive ciò che rilasciate davvero
- Aggiornamenti di sicurezza che arrivano agli utenti attraverso un canale verificabile, separati dai rilasci funzionali
- Un team che sa cosa fare nelle prime 24 ore dopo essere venuto a conoscenza di una vulnerabilità attivamente sfruttata
- Documentazione tecnica dell'Allegato VII tenuta aggiornata dal processo di rilascio, non ricostruita prima di una valutazione

Deliverables:
- Inventario dei prodotti e gap assessment: perimetro, classificazione (predefinita, importante di classe I o II, critica), stato attuale rispetto all'Allegato I, Parti I e II
- Contributo ingegneristico alla valutazione del rischio di cibersicurezza: superficie di attacco, configurazione sicura per impostazione predefinita, logging, cancellazione dei dati, mitigazioni degli exploit, mappati sui requisiti della Parte I
- Processo di gestione delle vulnerabilità: punto di contatto unico, policy di coordinated vulnerability disclosure, ricezione, triage con VEX, obiettivi di correzione, segnalazione a monte per i componenti di terze parti
- Generazione della SBOM in pipeline (CycloneDX o SPDX), per artefatto e per rilascio, con VDR pubblicato accanto a ogni versione supportata
- Firma degli artefatti e attestazioni di provenance, più un canale di aggiornamento sicuro: aggiornamenti di sicurezza separati da quelli funzionali, avvisi in formato leggibile da macchina, aggiornamenti conservati per il periodo richiesto
- Monitoraggio continuo di ogni rilascio ancora nel periodo di supporto, con avvisi indirizzati al team responsabile
- Preparazione alle notifiche: criteri di consapevolezza, runbook a 24 ore / 72 ore / 14 giorni, registrazione sulla piattaforma unica di segnalazione, modelli per informare gli utenti e un'esercitazione tabletop
- Documentazione tecnica dell'Allegato VII assemblata dagli output della pipeline: versioni, architettura, processi, SBOM, rapporti di test, motivazione del periodo di supporto
- Classificazione dei rilasci, così il team distingue un aggiornamento di manutenzione da una modifica sostanziale prima di pubblicarlo
- Passaggio di consegne: il team interno gestisce ed estende tutto senza di me

## Il problema che di solito trovo

La maggior parte dei team che incontro su questo tema ha già letto il regolamento, o una sua sintesi, e spesso ha concluso che la parte difficile sia la documentazione. Non lo è. La parte difficile è che il CRA descrive un processo che dura per tutto il periodo di supporto di ogni prodotto, e il processo di rilascio attuale non è mai stato pensato per produrre quel tipo di evidenze in modo continuo.

Di conseguenza probabilmente nessuno ha un elenco completo di quali prodotti, versioni e componenti integrati siano davvero in perimetro. Una SBOM è stata generata una volta, a mano, per il questionario di un cliente, e nessuno sa a quale build si riferisca. Lo scanner delle vulnerabilità segnala duecento rilievi per rilascio, per lo più in codice che il prodotto non esegue mai, e il team ha smesso di leggerli. Le correzioni di sicurezza viaggiano dentro i rilasci funzionali, quindi il cliente che non può prendere la funzionalità non riceve nemmeno la correzione. Non esiste un indirizzo pubblicato a cui segnalare una vulnerabilità, e se un ricercatore scrivesse domani alla casella commerciale ci vorrebbero giorni perché arrivasse a un ingegnere. E dall'11 settembre 2026 il cronometro delle notifiche corre già per prodotti venduti anni fa.

## Come intervengo

Parto da ciò che il prodotto e la pipeline fanno già, non dal testo del regolamento. L'Allegato I elenca tredici proprietà che il prodotto deve avere e otto cose che il fabbricante deve saper fare con le vulnerabilità. Ciascuna corrisponde a una scelta di progetto, ad uno step di build o ad un processo ancora da definire, e il gap da verificare è proprio quella mappatura insieme alla sua classificazione che decide se entra in gioco un organismo notificato.

Il lavoro viene poi ordinato per ciò che è già applicabile e per ritorno. Prima il processo di gestione delle vulnerabilità e la preparazione alle notifiche, perché l'articolo 14 si applica oggi e copre i prodotti già sul mercato. Poi le evidenze di supply chain, SBOM, firma, aggiornamenti sicuri, perché tutto ciò che segue dipende dal sapere che cosa c'è in ogni rilascio. Poi i requisiti di prodotto della Parte I, che sono soprattutto lavoro di progettazione con il team di prodotto e alimentano la valutazione del rischio. La documentazione tecnica non è una fase a sé: viene assemblata dagli output delle tre precedenti, così descrive ciò che si rilascia e resta aggiornata a ogni versione.

Gli strumenti arrivano da ciò che si usa già. GitLab CI e GitHub Actions, ad esempio, offrono entrambi opzioni adeguate per generare SBOM, firmare artefatti e pubblicare avvisi; le differenze tra loro contano molto meno del fatto che l'output venga rivisto, conservato e sia raggiungibile quando un'autorità lo chiede.

## Che cosa copre il lavoro ingegneristico

**Perimetro e classificazione.** Un inventario dei prodotti con elementi digitali, compresi firmware, software on-premise, agent e componenti edge dei prodotti SaaS, e i componenti di terze parti che vengono integrati. Ogni prodotto riceve una classe (predefinita, importante di classe I o II, critica) usando le descrizioni tecniche del Regolamento di esecuzione 2025/2392, perché è quella a decidere il percorso di valutazione della conformità e quindi il calendario.

**Gestione delle vulnerabilità (Allegato I, Parte II).** Un punto di contatto unico che tutti gli utenti riescono a trovare, una policy di vulnerability disclosure e una notifica che arriva al team dedicato. Triage registrato come dichiarazioni VEX, così la stessa domanda non viene indagata due volte. Obiettivi di correzione ordinati in base alla gravità. Segnalazione a monte quando la vulnerabilità è in un componente di terze parti, come richiede l'articolo 13(6). Aggiornamenti di sicurezza costruiti e distribuiti separatamente da quelli funzionali dove tecnicamente possibile, con avvisi in formato leggibile da macchina.

**Evidenze di supply chain.** SBOM generata in fase di build, per artefatto, in CycloneDX o SPDX, conservata accanto all'artefatto che descrive, con la firma che copre entrambi. Attestazioni di provenance che legano l'artefatto al commit e all'esecuzione di pipeline che lo hanno prodotto. Un VDR per ogni rilascio supportato, generato dalla storia dei VEX. Chiavi di firma tenute fuori dalla pipeline e usate tramite credenziali a scadenza breve, lo stesso lavoro che faccio sul fronte [SecDevOps](https://lucabertelli.consulting/it/servizi/consulenza-secdevops-cicd/).

**Distribuzione sicura degli aggiornamenti.** Un canale attraverso cui gli utenti possono verificare che un aggiornamento arrivi da una fonte riconosciuta e verificata, aggiornamenti di sicurezza diffusi senza ritardo e gratuitamente, e un piano di conservazione perché ogni aggiornamento resti disponibile per i dieci anni richiesti dal regolamento.

**Monitoraggio continuo.** Le SBOM di ogni rilascio ancora nel periodo di supporto vengono confrontate in continuo con i nuovi dati sulle vulnerabilità. Le corrispondenze arrivano al team responsabile del componente, con la storia dei VEX allegata, e alimentano la valutazione di consapevolezza che può far partire il cronometro delle notifiche.

**Preparazione alle notifiche.** Registrazione sulla piattaforma unica di segnalazione, un criterio scritto per che cosa significa "venire a conoscenza" nella vostra organizzazione e dove quel momento viene registrato, un runbook per il preallarme a 24 ore, la notifica a 72 ore e il rapporto finale, modelli per informare gli utenti coinvolti e un'esercitazione tabletop.

**Documentazione tecnica (Allegato VII).** Versioni rilevanti per la conformità, architettura, il processo di gestione delle vulnerabilità con la sua SBOM e la policy di divulgazione, la valutazione del rischio, la motivazione del periodo di supporto, i rapporti di test e la dichiarazione di conformità, assemblati dagli output della pipeline a ogni rilascio invece di essere scritti una volta prima della valutazione.

## Situazioni tipiche

- Un fabbricante di dispositivi connessi il cui firmware è costruito da un fornitore, e che deve rispondere della SBOM, del canale di aggiornamento e del periodo di supporto senza possedere la build. 
- Un produttore di software indipendente che consegna software on-premise a clienti a loro volta in perimetro, che già chiedono SBOM e policy di divulgazione nei capitolati. 
- Un'azienda SaaS convinta di essere fuori perimetro finché non ha contato agent edge, app mobili e connettori on-premise. 
- Un prodotto costruito su Kubernetes che distribuisce un container runtime. Un fornitore della pubblica amministrazione le cui risposte alle gare ora includono domande sul CRA. 

In ogni caso il regolamento è lo stesso; cambia da dove devono arrivare le evidenze.

## Che cosa non faccio

Non classifico il vostro prodotto ne mi sostituisco a nessun consulente legale per il percorso di valutazione della conformità e la stesura della sua dichiarazione. Quello di cui mi assicuro è che, quando quelle decisioni vengono prese, il prodotto, il processo e la documentazione su cui si basano esistano davvero, siano prodotti dalla vostra pipeline e descrivano ciò che rilasciate.

Frequently asked questions:

Q: A chi si applica il Cyber Resilience Act?
A: Ai fabbricanti che immettono sul mercato UE prodotti con elementi digitali: software e hardware in grado di connettersi a una rete, direttamente o indirettamente, e i componenti che li compongono, indipendentemente da dove il fabbricante sia stabilito. Importatori e distributori hanno obblighi propri. Il software offerto solo come servizio è fuori dal perimetro, coperto dalla NIS2, a meno che non sia un'elaborazione remota senza cui il prodotto non può svolgere le proprie funzioni. Il software libero e open source sviluppato al di fuori di un'attività commerciale non è coperto; le organizzazioni che sostengono questi progetti possono essere 'open source steward', con un regime alleggerito. Le linee guida della Commissione del 27 luglio 2026 (C(2026) 5252) percorrono questi confini con esempi concreti. Stabilire se il vostro prodotto rientra e in quale classe è una domanda per il vostro consulente legale; il mio lavoro comincia quando la risposta è sì.

Q: Quali sono le scadenze del Cyber Resilience Act?
A: Il Regolamento (UE) 2024/2847 è entrato in vigore il 10 dicembre 2024. Il Capo IV, sugli organismi notificati, si applica dall'11 giugno 2026. Gli obblighi di notifica dell'articolo 14 si applicano dall'11 settembre 2026 e riguardano ogni prodotto in perimetro già sul mercato, non solo quelli nuovi. Tutto il resto, requisiti essenziali, valutazione della conformità, marcatura CE e documentazione tecnica, si applica dall'11 dicembre 2027 ai prodotti immessi sul mercato da quella data, e ai prodotti precedenti solo se subiscono una modifica sostanziale. Il pacchetto Digital Omnibus non ha cambiato queste date.

Q: Che cosa richiede davvero il CRA oltre alla SBOM?
A: Due gruppi di requisiti essenziali nell'Allegato I. La Parte I riguarda il prodotto: nessuna vulnerabilità sfruttabile nota al rilascio, configurazione sicura per impostazione predefinita, aggiornamenti di sicurezza installabili automaticamente, controllo degli accessi, cifratura dei dati a riposo e in transito, protezione dell'integrità, minimizzazione dei dati, disponibilità sotto attacco di tipo denial of service, superficie di attacco ridotta, mitigazioni degli exploit, registrazione degli eventi di sicurezza e cancellazione sicura dei dati, ciascuno applicato sulla base di una valutazione del rischio documentata. La Parte II riguarda i processi del fabbricante: identificare e documentare vulnerabilità e componenti (è qui che vive la SBOM), correggerle senza ritardo, testare regolarmente, divulgare pubblicamente le vulnerabilità corrette, adottare una policy di coordinated vulnerability disclosure, fornire un contatto per le segnalazioni, distribuire gli aggiornamenti in modo sicuro e rilasciare gli aggiornamenti di sicurezza gratuitamente con un avviso. La SBOM è un punto su ventuno.

Q: In quale classe rientra il mio prodotto, e cambia il percorso di valutazione della conformità?
A: La maggior parte dei prodotti rientra nella categoria predefinita e può essere autovalutata. L'Allegato III elenca i prodotti 'importanti' in due classi, con le descrizioni tecniche nel Regolamento di esecuzione (UE) 2025/2392: la classe I comprende sistemi operativi, browser, password manager, VPN, sistemi di gestione della rete, SIEM, router e switch, dispositivi di sicurezza per la casa intelligente; la classe II comprende hypervisor e container runtime, firewall e sistemi di rilevamento delle intrusioni, microprocessori resistenti alle manomissioni. L'Allegato IV elenca i prodotti 'critici', come i moduli di sicurezza hardware e i gateway per contatori intelligenti. Classe II e prodotti critici richiedono un organismo notificato o uno schema europeo di certificazione. La classe I può essere autovalutata solo applicando una norma armonizzata, e nessuna norma armonizzata CRA è ancora stata citata nella Gazzetta ufficiale, quindi per ora anche la classe I significa in pratica organismo notificato. È la decisione che incide di più su tempi e budget, e va presa presto.

Q: Esiste un formato obbligatorio per la SBOM?
A: No. Il regolamento chiede un formato di uso comune e leggibile da macchina che copra almeno le dipendenze di primo livello, e dà alla Commissione il potere di specificare formato ed elementi con un atto di esecuzione, non ancora esercitato. Nella pratica significa CycloneDX o SPDX. Il riferimento più concreto sui contenuti oggi è la linea guida tecnica tedesca BSI TR-03183-2, a cui le autorità di vigilanza tenderanno ad appoggiarsi; costruire su quella asticella evita rilavorazioni quando una norma verrà citata. La SBOM non deve essere pubblica: entra nella documentazione tecnica e viene consegnata all'autorità di vigilanza su richiesta motivata.

Q: Che differenza c'è tra SBOM, VEX e VDR, e perché servono tutti e tre?
A: La SBOM è l'inventario dei componenti presenti in una versione specifica del prodotto. Una dichiarazione VEX è un giudizio su una vulnerabilità in uno di quei componenti: affetto, non affetto, corretto o in analisi, con la motivazione. Il VDR è il rapporto costruito da quei giudizi, che elenca quali vulnerabilità note riguardano un rilascio e che cosa è stato fatto. La SBOM da sola produce un lungo elenco di corrispondenze, per lo più non sfruttabili nel vostro prodotto; le stesse linee guida della Commissione osservano che un componente vulnerabile il cui codice non è raggiungibile non rende la vulnerabilità del prodotto 'attivamente sfruttata'. Il VEX è il modo di registrare quel giudizio una volta sola invece di riaprirlo ogni settimana, e il VDR è ciò che si consegna a un cliente o a un'autorità.

Q: Che cosa fa partire le 24 ore per la notifica?
A: Venire a conoscenza di una vulnerabilità attivamente sfruttata nel proprio prodotto, o di un incidente grave che ne compromette la sicurezza. Le linee guida della Commissione leggono 'conoscenza' come aver raggiunto un ragionevole grado di certezza dopo una valutazione iniziale, e la piattaforma unica di segnalazione non registra quel momento per voi: servono evidenze proprie di quando la valutazione si è conclusa. Da lì: preallarme entro 24 ore, notifica entro 72 ore, rapporto finale entro 14 giorni dalla disponibilità di una misura correttiva (un mese per gli incidenti), tutto tramite la piattaforma ENISA, con il CSIRT coordinatore dello Stato del vostro stabilimento principale come destinatario. Separatamente vanno informati gli utenti coinvolti. Le vulnerabilità di cui già sapevate lo sfruttamento prima dell'11 settembre 2026 non vanno notificate retroattivamente.

Q: Quanto durano gli obblighi?
A: Per il periodo di supporto, che il fabbricante stabilisce in base al tempo d'uso previsto e che deve essere di almeno cinque anni, salvo che il prodotto sia destinato a un uso più breve. In quel periodo le vulnerabilità vanno gestite e gli aggiornamenti di sicurezza forniti; ogni aggiornamento di sicurezza deve poi restare disponibile per almeno dieci anni o per il resto del periodo di supporto, se più lungo. La data di fine supporto va indicata nelle informazioni per l'utente. Un processo di gestione delle vulnerabilità che copre solo l'ultimo rilascio non basta.

Q: Che cos'è una modifica sostanziale, e perché conta per il software che rilascia in continuo?
A: Una modifica successiva all'immissione sul mercato che incide sulla conformità ai requisiti della Parte I o cambia la finalità prevista per cui il prodotto è stato valutato. Quando accade, il prodotto modificato conta come nuovamente immesso sul mercato e deve ripetere la valutazione della conformità. Aggiornamenti di sicurezza e rilasci di manutenzione non sono modifiche sostanziali; un rilascio che aggiunge il controllo delle macchine connesse a un cruscotto di monitoraggio lo è, per citare uno degli esempi della Commissione. I team che rilasciano ogni settimana hanno bisogno di un modo per classificare ogni rilascio rispetto a questo criterio prima di pubblicarlo, non dopo.

Q: Quali sono le sanzioni, e chi vigila sul CRA in Italia?
A: Fino a 15 milioni di euro o al 2,5% del fatturato mondiale annuo per la violazione dei requisiti essenziali o degli obblighi dei fabbricanti negli articoli 13 e 14; massimali più bassi per le altre violazioni e per la fornitura di informazioni fuorvianti alle autorità. L'applicazione è nazionale. In Italia la Legge 36/2026 designa l'Agenzia per la Cybersicurezza Nazionale (ACN) sia come autorità di notifica per gli organismi di valutazione della conformità sia come autorità di vigilanza del mercato, e il CSIRT Italia, gestito da ACN, è il CSIRT coordinatore che riceve le notifiche dell'articolo 14. Il decreto legislativo attuativo che fissa la scala nazionale delle sanzioni è ancora atteso.

Q: Fornisci consulenza legale sul Cyber Resilience Act?
A: No. La classificazione del prodotto, il percorso di valutazione della conformità, la decisione sul periodo di supporto e il contenuto della dichiarazione di conformità UE sono decisioni che prendete con il vostro consulente legale e, quando la classe lo richiede, con un organismo notificato. Io copro la parte ingegneristica: fare in modo che prodotto, pipeline e team producano le evidenze su cui quelle decisioni si basano, e continuino a produrle dopo la valutazione.

### Formazione DevOps e Cloud Native (Italian)

- URL: https://lucabertelli.consulting/it/servizi/formazione-devops-cloud-native
- Language: it
- Summary: Formazione aziendale su Kubernetes, DevOps, SecDevOps e Terraform: percorsi su misura in italiano e inglese, con laboratori pratici basati sui vostri strumenti reali.
- Topics: corso Kubernetes aziendale, formazione DevOps, corso DevOps aziendale, formazione Kubernetes Italia, corso Terraform, training cloud native

Corsi di formazione aziendale su Kubernetes, DevOps e SecDevOps, costruiti sul vostro stack e non su un ambiente di esempio.

Outcomes:
- Il team lavora sui propri repository reali, non su un'applicazione dimostrativa
- Competenze distribuite, invece che concentrate nelle solite due persone
- Percorso calibrato sul livello effettivo dei partecipanti, verificato prima di iniziare
- Materiale che resta all'azienda e può essere riutilizzato per i nuovi assunti

Deliverables:
- Verifica preliminare del livello e definizione degli obiettivi con i responsabili
- Programma su misura, in italiano o in inglese
- Laboratori pratici su ambienti allineati al vostro stack
- Materiale didattico e registrazioni consegnate all'azienda
- Sessione di follow-up a distanza di alcune settimane, sui problemi emersi nel frattempo

## Perché la formazione a catalogo spesso non basta

Un corso standard su Kubernetes insegna Kubernetes. È utile, ed è anche il motivo per cui esistono le certificazioni. Ma nella settimana successiva i partecipanti tornano su un cluster configurato in modo particolare, con vincoli aziendali, scelte ereditate e una pipeline che non somiglia a quella dell'esercitazione. La distanza tra l'esempio e la realtà è il punto in cui si disperde gran parte dell'apprendimento.

C'è poi una questione di livello. In quasi tutti i gruppi che formo la variabilità interna è alta: due o tre persone hanno già esperienza, gli altri partono da zero. Un programma unico annoia i primi e perde i secondi.

## Come costruisco un percorso

Prima di definire il programma parlo con i responsabili tecnici e verifico il livello effettivo dei partecipanti, di solito con un questionario breve. Serve a capire quanto tempo dedicare ai fondamenti e quali argomenti si possono dare per acquisiti. È un passaggio che richiede poco e che cambia sensibilmente la resa delle giornate.

Il programma alterna spiegazione e pratica in blocchi brevi. La parte di laboratorio usa un ambiente allineato al vostro: se lavorate con GitLab CI il laboratorio è su GitLab CI, se il vostro cluster è su AKS le esercitazioni girano su AKS. Questo elimina il passaggio di traduzione mentale che di solito impedisce di applicare quanto imparato.

Le sessioni vengono distribuite nel tempo quando possibile, invece di concentrarsi in una settimana intensiva. Fra una sessione e l'altra i partecipanti provano a usare quanto visto sul lavoro reale, e la sessione successiva parte dalle difficoltà emerse. È il momento in cui il percorso produce più valore.

## Che cosa resta dopo

Il materiale didattico e le registrazioni restano all'azienda e possono essere riutilizzati per chi verrà assunto in seguito. A qualche settimana di distanza prevedo una sessione di follow-up dedicata ai problemi che il team ha incontrato nel frattempo: è breve, ma è quella che consolida davvero l'adozione.

L'esperienza da cui arrivano questi percorsi è operativa prima che didattica. Ho lavorato sugli stessi problemi come DevOps Engineer, come Cloud Native Engineering Manager e come consulente, e gli esempi che uso in aula vengono da lì.

Frequently asked questions:

Q: Su quali argomenti tieni corsi di formazione?
A: Kubernetes dalle basi all'operatività in produzione, Docker e containerizzazione, Terraform e Infrastructure as Code, pipeline CI/CD con GitLab CI e GitHub Actions, GitOps con Argo CD, gestione dei segreti con HashiCorp Vault, pratiche SecDevOps e fondamenti di Platform Engineering. I percorsi possono essere combinati in base agli obiettivi.

Q: I corsi sono in italiano o in inglese?
A: Entrambi. Per team distribuiti su più paesi tengo le sessioni in inglese, con materiale nella stessa lingua.

Q: In cosa si differenziano dai corsi standard di mercato?
A: Nei laboratori. Un corso a catalogo usa un'applicazione dimostrativa che non somiglia a ciò che i partecipanti gestiscono ogni giorno, e la distanza tra l'esempio e la realtà è dove si perde la maggior parte dell'apprendimento. I percorsi che costruisco partono dai vostri repository e dai vostri strumenti, così il lavoro fatto in aula è direttamente riutilizzabile.

Q: Quanto dura un percorso formativo?
A: Un modulo introduttivo su un singolo argomento occupa una o due giornate. Un percorso completo su Kubernetes, dai fondamenti all'operatività, si sviluppa tipicamente su quattro o cinque giornate distribuite nel tempo, in modo che tra una sessione e l'altra i partecipanti possano applicare quanto visto.

Q: I corsi si tengono da remoto o in sede?
A: In entrambe le modalità. Da remoto funzionano bene con gruppi fino a una decina di persone; in sede sono preferibili quando il percorso include sessioni di lavoro sui problemi concreti del team.

### Governance e adozione di agenti AI (Italian)

- URL: https://lucabertelli.consulting/it/servizi/consulenza-agenti-ai
- Language: it
- Summary: Consulenza su governance e adozione di agenti AI in Italia: policy di utilizzo, hardening della sicurezza, integrazione MCP e controllo dei costi di inferenza.
- Topics: governance agenti AI, adozione agenti AI, consulenza agenti AI, consulenza AI Italia, governance AI aziendale, sicurezza agenti AI, AI engineering, Model Context Protocol

Adozione di agenti AI in azienda con regole chiare, rischio controllato e spesa prevedibile.

Outcomes:
- Agenti in produzione con perimetro di azione definito e verificabile
- Spesa di inferenza attribuita per team e caso d'uso, con limiti applicati
- Accessi degli agenti gestiti come identità, non come chiavi condivise
- Criteri espliciti per decidere dove l'AI serve davvero e dove non conviene

Deliverables:
- Valutazione dei casi d'uso, ordinati per valore atteso e rischio
- Policy di utilizzo: dati ammessi, azioni consentite, punti di approvazione umana
- Architettura di integrazione, inclusi server MCP e connessione ai sistemi interni
- Hardening: isolamento dell'esecuzione, gestione dei segreti, tracciamento delle azioni
- Modello di budget e monitoraggio del consumo di token

## Il problema che di solito trovo

Gli agenti AI entrano in azienda dal basso. Uno sviluppatore prova un assistente, un team automatizza un flusso di supporto, qualcuno collega un modello a un sistema interno per un prototipo. Nel giro di pochi mesi esistono diverse integrazioni che nessuno ha censito, con chiavi API condivise e nessuna idea precisa di quali dati stiano attraversando quale servizio.

Il secondo problema è economico e arriva poco dopo. La spesa di inferenza non ha un profilo prevedibile come quello di una macchina virtuale: dipende da quanto viene usato l'agente e da quanto contesto trascina a ogni chiamata. Senza attribuzione per caso d'uso, la fattura mensile diventa un numero unico che nessuno sa scomporre e quindi nessuno sa ridurre.

## Come intervengo

Si parte dalla selezione dei casi d'uso, che è soprattutto un lavoro di esclusione. Molte attività proposte per l'automazione con AI sono più economiche e più affidabili se risolte con codice ordinario. Il criterio che uso è la tolleranza all'errore: dove una risposta approssimativa ha un costo basso e la verifica è rapida, un agente porta valore; dove serve esattezza deterministica, quasi mai.

Sulle attività che superano il filtro si definisce il perimetro operativo. Quali dati l'agente può leggere, quali azioni può eseguire da solo, quali richiedono approvazione umana. Sembra un adempimento formale ed è invece la parte che determina se il sistema sarà gestibile: senza limiti espliciti si scopre il perimetro reale solo quando qualcosa va storto.

## Sicurezza e integrazione

Sul piano tecnico un agente va trattato come un servizio con un'identità propria, non come uno strumento che eredita le credenziali di chi lo invoca. Questo significa permessi minimi e specifici, segreti gestiti tramite Vault invece che chiavi statiche, esecuzione isolata per qualsiasi codice generato, e un registro completo delle azioni compiute.

La prompt injection indiretta merita attenzione particolare perché non ha un equivalente diretto nei modelli di sicurezza tradizionali: un agente che elabora contenuti provenienti dall'esterno può essere indotto a compiere azioni che nessun utente ha richiesto. La mitigazione pratica è la stessa che vale per ogni componente non affidabile, cioè ridurre ciò che può fare, non sperare che interpreti correttamente ciò che legge.

Sull'integrazione, quando più agenti devono accedere agli stessi sistemi interni conviene esporre un server MCP invece di moltiplicare integrazioni dedicate. Centralizza accesso, permessi e tracciamento in un punto solo, che è anche l'unico modo realistico per mantenerli coerenti nel tempo.

MCP ha comunque bisogno di qualcosa di vero da interrogare. Se l'inventario di come funzionano davvero i sistemi sta in migliaia di file e nella testa di poche persone, gli agenti riempiono i buchi con congetture. È un problema di [knowledge graph](https://lucabertelli.consulting/it/servizi/consulenza-knowledge-graph/), non di modello.

Frequently asked questions:

Q: Che cosa comprende una consulenza di AI Engineering?
A: Il ciclo di vita degli agenti AI in un contesto aziendale: selezione dei casi d'uso che giustificano l'investimento, governance e policy di utilizzo, architettura di integrazione con i sistemi interni, hardening di sicurezza e controllo dei costi. Non è consulenza sui modelli, è consulenza sull'infrastruttura e sulle regole che rendono un agente utilizzabile in produzione.

Q: Quali sono i rischi di sicurezza specifici degli agenti AI?
A: I due che considero prioritari sono la prompt injection indiretta, per cui un agente che legge contenuti esterni può essere indotto a compiere azioni non previste, e l'ampiezza eccessiva dei permessi, perché a un agente vengono spesso concesse credenziali molto più estese di quanto il suo compito richieda. Si affrontano con lo stesso principio del privilegio minimo che si applica ai servizi, più un tracciamento completo delle azioni compiute.

Q: Che cos'è il Model Context Protocol e quando conviene usarlo?
A: MCP è uno standard aperto per esporre dati e strumenti agli agenti AI attraverso un'interfaccia uniforme. Conviene quando più agenti o più client devono accedere agli stessi sistemi interni: invece di scrivere un'integrazione dedicata per ciascuno, si espone un server MCP che centralizza accesso, permessi e tracciamento. Ho pubblicato un articolo su una sua applicazione concreta al monitoraggio di una fleet Kubernetes.

Q: Come si tengono sotto controllo i costi di inferenza?
A: Attribuendoli prima che crescano. Ogni caso d'uso ha un budget, il consumo di token viene tracciato per team e funzionalità, e sono previsti limiti applicati automaticamente. La voce di spesa che sfugge più spesso non è il singolo prompt costoso, ma un agente in ciclo di ripetizione che nessuno ha limitato.

Q: Serve un modello proprietario o si può usare un servizio gestito?
A: Nella maggior parte dei casi un servizio gestito è adeguato. L'esecuzione in locale ha senso con vincoli reali di riservatezza dei dati o requisiti di sovranità, e va valutata considerando il costo operativo che comporta. La scelta si fa sui vincoli effettivi, non sull'impressione che eseguire in casa sia automaticamente più sicuro.

Q: Quando ha senso una consulenza di governance sugli agenti AI?
A: Quando gli agenti stanno già entrando in azienda senza un perimetro condiviso, oppure quando volete adottarli in modo deliberato prima che proliferino. I segnali tipici sono chiavi API condivise, nessun inventario dei casi d'uso, assenza di limiti di spesa e la domanda 'chi ha autorizzato questo agente a leggere quei dati?' senza una risposta chiara.

### Consulenza temporal knowledge graph (Italian)

- URL: https://lucabertelli.consulting/it/servizi/consulenza-knowledge-graph
- Language: it
- Summary: Consulenza temporal knowledge graph in Italia: conoscenza operativa, memoria per agenti AI, accesso MCP e migrazioni CI/CD di grande scala.
- Topics: consulenza knowledge graph, knowledge graph temporale, temporal knowledge graph, knowledge graph operativo, memoria agenti AI, MCP knowledge graph, migrazione CI/CD, agenti AI knowledge graph

Grafi piccoli e deterministici su come funzionano davvero i vostri sistemi, e grafi temporali su come cambiano, così persone e agenti interrogano fatti, anche sul passato, invece di provare a dedurre.

Outcomes:
- Un inventario interrogabile di come i sistemi funzionano davvero, non una slide di come dovrebbero
- Persone e agenti AI che leggono gli stessi fatti, invece di fare grep e indovinare
- Copertura e lacune visibili prima di partire con una grande migrazione di piattaforma
- Fatti con una linea temporale: che cosa era vero, quando è cambiato, che cosa un agente può richiamare con certezza
- Un grafo che il team interno sa ricostruire, non un artefatto che vive solo in consulenza

Deliverables:
- Perimetro: quali sorgenti contano, quali domande il grafo deve rispondere, cosa resta fuori
- Schema tipizzato: tipi di nodo e di relazione abbastanza pochi da restare onesti
- Estrattori dai cataloghi, inventari e API che usate già
- Livello di mapping curato, così i primitivi si incontrano sulle capability, non sui nomi
- Check temporale dove la storia potrebbe essere cambiata: intervalli di validità, query a un istante nel tempo, aggiornamenti incrementali
- Superficie di interrogazione per le persone (explorer) e per gli agenti (MCP), più un refresh ripetibile

## Il problema che di solito si trova

La mappa di come funziona davvero una piattaforma sta nei posti sbagliati: nella testa di poche persone, in un wiki non aggiornato, e in migliaia di file che nessuno ha voglia di riesaminare. Quando un team chiede "che cosa giriamo, che cosa è già coperto, che cosa bloccherebbe uno spostamento", la risposta onesta è giorni di ricostruzione manuale e tre opinioni in conflitto.

Gli agenti AI rendono il vuoto più rumoroso. Davanti a un repository ricostruiscono a intuito un quadro dell'esistente che si legge bene ed è sbagliato nei punti che contano. Più contesto nel prompt non lo risolve. Servono fatti interrogabili, con tipi e relazioni che non cambiano significato tra una chiamata e l'altra.

## Come intervengo

Si parte dalle domande che il grafo deve rispondere, non da un vocabolario dell'azienda. Quali sorgenti esistono già (cataloghi, inventari, API, repository). Quali tipi di nodo e di relazione bastano. Che cosa rifiutiamo di modellare, perché un grafo che finge di coprire tutto diventa un secondo wiki.

Poi estrattori, non persone che compilano moduli. I fatti arrivano da artefatti che l'organizzazione mantiene già. Un livello di mapping curato unisce quei primitivi sulle capability: lo stesso intento sotto nomi diversi diventa confrontabile. Lo store resta piccolo e ricostruibile. Se non potete rigenerare il grafo dalle sorgenti, non avete un grafo; avete uno snapshot.

Le persone hanno un explorer. Gli agenti hanno gli stessi fatti via MCP. Una sola fonte di verità, due interfacce. Il refresh è una pipeline che si rilancia, non un comitato che coltiva un'ontologia.

## Quando al grafo serve un orologio

Alcune domande non riguardano che cosa è vero, ma che cosa era vero, e quando ha smesso di esserlo. Quale team possedeva questo servizio quando è successo l'incidente. Com'era la piattaforma prima dell'ultima riorganizzazione. Che cosa un agente ha già appreso su un cliente nelle sessioni precedenti. Un grafo a snapshot, per quanto onesto, non può rispondere: ogni ricostruzione butta via il passato.

Un knowledge graph temporale lo conserva. Ogni fatto porta con sé i relativi intervalli di validità: quando è diventato vero, quando ha smesso di esserlo e, separatamente, quando il sistema lo ha appreso. Le nuove osservazioni entrano in modo incrementale come episodi; quando contraddicono un fatto esistente lo invalidano invece di cancellarlo. Il risultato è un grafo interrogabile a un istante nel tempo, e una memoria che gli agenti AI possono usare davvero: richiamare ciò che valeva, vedere come è cambiato, e smettere di ricostruire il mondo da zero a ogni sessione.

Aggiungo questo livello solo dove il dominio lo richiede. Inventari e mappe di copertura restano snapshot ricostruibili; il livello temporale aggiuntivo serve invece per conversazioni, ownership, incidenti e tutto ciò in cui la storia ha un peso determinante. Stessa disciplina del resto: schema tipizzato, relazioni esplicite, e nessun prodotto che detta il modello.

## Quando smette di essere opzionale

Una grande migrazione di una piattaforma CI/CD legacy è il caso che continuo a vedere. Il bersaglio non è il problema; la superficie sconosciuta sì. Senza un grafo di unità di lavoro, copertura e lacune, il progetto o si congela o si riscrive da zero, che è il modo in cui si spende un anno a spostare senza saper dire che cosa resta.

Con il grafo, la copertura è una query. Le lacune sono ordinate. Le pipeline simili diventano modelli invece che folklore. Efficienza, sicurezza e tempo di calendario smettono di essere slogan perché potete indicare che cosa è pronto, che cosa è bloccato, e che cosa sarebbe insicuro inventare. Non pretendo che ogni migrazione ne abbia bisogno. Pretendo che, oltre una certa scala, molte restino impensabili senza.

## Un perimetro pragmatico

Pragmatico significa niente suite enterprise di knowledge graph, niente programma RDF e niente workshop di ontologia da sei mesi. Il risultato è uno schema tipizzato che sta in testa, estrattori che si possono leggere, un file di mapping su cui si può dissentire in review e un refresh che finisce prima che le sorgenti si siano già mosse.

Frequently asked questions:

Q: Che cos'è un knowledge graph pragmatico?
A: Un grafo piccolo e tipizzato di fatti operativi estratti da sistemi che avete già: cataloghi, inventari, repository, API. Nodi e relazioni dirette sono espliciti, il mapping è curato, e una ricostruzione produce lo stesso risultato. Non è un'ontologia aziendale, non è un prodotto di graph database, e non è un progetto che parte modellando tutta l'azienda.

Q: In che cosa differisce da un graph database o da un knowledge graph da data catalogue?
A: Questi approcci danno per scontato che sappiate già che cosa mettere nel grafo e che la parte difficile sia lo storage, la ricerca o la governance a scala. Qui la parte difficile è scegliere uno schema abbastanza piccolo da restare vero, collegare estrattori a sorgenti che esistono già, ed esporre gli stessi fatti a persone e ad agenti. Lo store è un dettaglio di implementazione; di solito basta un database incorporabile.

Q: Quando vale la pena costruire un knowledge graph?
A: Quando le risposte che vi servono stanno in migliaia di file, in diversi strumenti e nella testa di poche persone, e quando indovinare costa caro. Segnali tipici: una migrazione di piattaforma che nessuno sa dimensionare, agenti AI che definiscono l'inventario senza certezza, o la stessa domanda con tre risposte diverse a seconda di chi la fai.

Q: Che cos'è un temporal knowledge graph?
A: Un knowledge graph in cui i fatti portano con sé dati legati alla loro temporalità: quando sono diventati veri, quando hanno smesso di esserlo, e quando il sistema li ha appresi. Le informazioni nuove non sovrascrivono; invalidano il fatto che contraddicono. Quindi le domande trovano una risposta in un istante preciso nel tempo: com'era la piattaforma a marzo, che cosa è cambiato dall'ultimo audit, chi era responsabile quando è successo l'incidente.

Q: In che modo un temporal knowledge graph dà memoria agli agenti AI?
A: Gli agenti ricostruiscono lo stato del mondo a ogni sessione perché tra una chiamata e l'altra non persiste nulla. Con un grafo temporale le nuove osservazioni entrano in modo incrementale come episodi, le contraddizioni invalidano i fatti vecchi invece di cancellarli, e un agente può recuperare che cosa è vero adesso, che cosa era vero in un dato momento e come è evoluto. La memoria diventa un insieme di fatti interrogabili con provenienza, non un transcript iniettato nel prompt.

Q: Come usano il grafo gli agenti AI?
A: Tramite MCP, così qualsiasi IDE, CLI o assistente compatibile interroga gli stessi fatti che mostra l'explorer. Gli agenti smettono di fare grep sui repository e di riempire i buchi con finzioni plausibili. Per loro il grafo resta in lettura: cercano copertura, blocchi e unità di lavoro simili; le modifiche ai cataloghi sorgente passano dalla review normale del team.

Q: Perché senza un grafo le grandi migrazioni CI/CD si arenano molto spesso?
A: Perché il lavoro non è scrivere le pipeline. È sapere che cosa esiste già, che cosa la piattaforma di destinazione copre già, che cosa manca, e quali unità di lavoro si assomigliano. Senza questo, i team o si bloccano o riscrivono tutto da zero. Migrazioni che al solo conteggio dei file sembravano impossibili diventano un piano sequenziato una volta che copertura e lacune sono interrogabili. In questi casi, un knowledge graph smette di essere opzionale.

Q: Che cosa resta dopo l'intervento?
A: Lo schema, gli estrattori, il mapping, la superficie di interrogazione e il percorso di refresh. Il team interno deve poter ricostruire il grafo dalle sorgenti senza ulteriori consulenze. Se il grafo esiste solo mentre si sta collaborando, l'intervento è fallito.


## Field guides (insights)

### Cyber Resilience Act: where things stand and what to do first (English)

- URL: https://lucabertelli.consulting/en/insights/cyber-resilience-act
- Language: en
- Published: 2026-09-28
- Summary: Reporting is live, harmonised standards are not, and December 2027 is closer than the release calendar suggests
- Related services: https://lucabertelli.consulting/en/services/cyber-resilience-act-compliance, https://lucabertelli.consulting/en/services/secdevops-cicd-consulting, https://lucabertelli.consulting/en/services/devops-consulting, https://lucabertelli.consulting/en/services/kubernetes-consulting

## Where things stand, September 2026

The Cyber Resilience Act, Regulation (EU) 2024/2847, has been in force since 10 December 2024, and the first obligation with teeth arrived on **11 September 2026**: Article 14 reporting. Since that date a manufacturer that becomes aware of an actively exploited vulnerability in one of its products, or of a severe incident affecting its security, must send an early warning within 24 hours, a notification within 72 hours and a final report, through the **Single Reporting Platform** that ENISA opened the same day. The duty covers every in-scope product already on the market, not only the ones placed after 2027 (Article 69(3)). What it does not cover is exploitation you already knew about before 11 September; the clock starts on fresh awareness.

Around that date a few pieces fell into place:

- **Commission guidance** (C(2026) 5252, 27 July 2026): 84 pages and 67 worked examples on scope, remote data processing, open source, substantial modification, support periods and reporting. Non-binding, but it is what market surveillance authorities will read. It says nothing about SBOM format.
- **Implementing Regulation (EU) 2025/2392** (28 November 2025): the technical descriptions of the important (class I and II) and critical product categories. It is the document that tells you whether your product needs a notified body.
- **Delegated Regulation (EU) 2026/881**: when a CSIRT may delay passing your notification on to others. It does not move your deadlines.
- In Italy, **Law 36/2026** designates the Agenzia per la Cybersicurezza Nazionale as both notifying and market surveillance authority, with CSIRT Italia as the coordinator that receives notifications. The legislative decree that sets the national penalty scale is still pending.

Two things have not fallen into place. **No harmonised standard has been cited in the Official Journal.** The horizontal EN 40000 series (vocabulary, principles, vulnerability handling, generic security requirements) is partly under approval and partly still being drafted, the Commission has proposed pushing the standardisation deadlines back, and first citations are not expected before 2027. Until then there is no presumption of conformity for anyone, and class I products cannot use the self-assessment route. And the **Digital Omnibus**, which proposes a single entry point for incident reporting across NIS2, CRA, GDPR and DORA built on top of ENISA's platform, is still in the Council. It does not change any CRA date.

## What the regulation asks, briefly

Annex I has two parts. **Part I** is about the product: thirteen properties, from "no known exploitable vulnerabilities at release" and secure-by-default configuration to encryption, integrity, data minimisation, attack surface reduction, security logging and secure deletion, each applied according to a documented risk assessment. **Part II** is about the manufacturer's process: eight duties, including the SBOM, fixing vulnerabilities without delay, regular testing, public disclosure of fixed vulnerabilities, a coordinated vulnerability disclosure policy, a contact address for reports, secure update distribution and free security updates with an advisory.

Around them: user information (Annex II, including the support end date and where to report vulnerabilities), technical documentation (Annex VII, including the SBOM and the reasoning behind the support period), a support period of at least five years, and security updates that must stay available for ten years after release. Penalties go up to EUR 15 million or 2.5% of worldwide turnover.

## Three misunderstandings I keep meeting

**"We are SaaS, so we are out."** The service itself is NIS2 territory, but the edge agent, the mobile app, the on-premise connector and the firmware in the gateway are products with digital elements. Remote data processing without which the product cannot work is also in scope. Most SaaS companies I talk to have three or four in-scope products they had not counted.

**"The SBOM is the deliverable."** It is one point out of twenty-one, and on its own it produces a long list of vulnerabilities in code the product never executes. The Commission guidance is explicit that a vulnerable component whose code is not reachable does not make the product's vulnerability actively exploited. What turns the list into evidence is the judgement recorded per finding (VEX) and the report assembled from those judgements (VDR), together with a process that keeps producing them for every supported release.

**"We will deal with it in 2027."** Article 14 applies today. The class decision determines whether you need a notified body, and there are very few of them so far; Article 35 asks Member States to ensure enough capacity by 11 December 2026, which tells you how tight the queue will be. And the support period is at least five years from the day you ship, so the process that handles vulnerabilities on that release has to exist on that day.

## How to sequence the work

There is no single right order, but this one has held up in regulated environments and it follows what is already enforceable:

1. **Inventory and classification.** Every product with digital elements, including firmware, agents, connectors and embedded third-party components, mapped to default, important class I or II, or critical. This decides the calendar.
2. **Reporting readiness.** A single point of contact users can find, a coordinated vulnerability disclosure policy, registration on the Single Reporting Platform, a written criterion for what "becoming aware" means and where it is recorded, a runbook for the 24-hour, 72-hour and 14-day steps, and one rehearsal.
3. **Supply chain evidence.** SBOM per artifact from the build, signed artifacts with provenance, VEX and VDR per supported release, continuous monitoring against new vulnerability data. This is the [SecDevOps](https://lucabertelli.consulting/en/services/secdevops-cicd-consulting/) work with the CRA's retention and disclosure duties added.
4. **Product requirements.** The Part I properties that are design decisions, worked through with the product team and recorded in the risk assessment. Security updates shipped separately from features where feasible.
5. **Technical documentation and conformity route.** Annex VII assembled from the outputs above, then the self-assessment or notified body decision taken with legal counsel.

The [Cyber Resilience Act compliance](https://lucabertelli.consulting/en/services/cyber-resilience-act-compliance/) page describes what each of these steps produces and what I do and do not cover.

## What to ask a consultant or a vendor

1. Which release does this SBOM describe, and how do you prove it?
2. If a researcher emails a vulnerability tonight, where does it land and who reads it?
3. What happens in your organisation in the first 24 hours after you learn a vulnerability is being exploited?
4. Which of your releases in the last twelve months would have counted as a substantial modification?
5. After the engagement, who on the internal team keeps this running for the next five years?

If the answers are vague, you are buying a document, not compliance. If you want a concrete view on where your product stands, [email info@lucabertelli.consulting](mailto:info@lucabertelli.consulting). The product, the current pipeline and the customer base are enough to start.

### When a knowledge graph makes a platform migration possible (English)

- URL: https://lucabertelli.consulting/en/insights/light-knowledge-graphs
- Language: en
- Published: 2026-08-14
- Summary: People and AI agents need queryable facts. Without them, large CI/CD migrations stay tribal and stall.
- Related services: https://lucabertelli.consulting/en/services/knowledge-graph-consulting, https://lucabertelli.consulting/en/services/ai-agent-governance, https://lucabertelli.consulting/en/services/platform-engineering-consulting, https://lucabertelli.consulting/en/services/devops-consulting

## The migration that never starts

Migrating a legacy CI/CD platform almost always starts uphill, when it does not fail outright, if nobody can answer four questions without hours or days of work:

1. Which use cases do we actually cover, and with which technologies?
2. What does the target CI/CD platform and library already cover?
3. What is missing, and how often does it show up?
4. Which work units look alike enough to map onto a reusable model?

Even trying to migrate with an AI agent alone, without a base of queryable facts, the project tends to become inefficient and too expensive: you still need a reliable map, and without it both people and agents waste time on guesses and retries, which makes real planning and progress hard to estimate.

That is the point at which [knowledge graph consulting](https://lucabertelli.consulting/en/services/knowledge-graph-consulting/) stops being a research exercise and becomes the condition that makes the migration sustainable.

## Facts, not more context

You often start from hundreds, if not thousands, of files whose code has not been verified or maintained over time. In that setting AI agents hit a basic limit: prior knowledge is not in the prompt; it is spread across catalogues, inventories, repositories and the memory of a few people (often no longer around). Simply adding more files to the context does not increase coverage; it only produces more confident guesses.

A purpose-built knowledge graph flips the approach. Typed facts are extracted from the sources through a deterministic, repeatable process, without involving AI agents. You get a clear schema of nodes, directed relationships and a carefully maintained mapping, so two elements with different names can be recognised as the same intent or purpose. That puts people and AI agents in a position to navigate them, including through dedicated MCP servers.

The graph does not migrate anything. It tells you what is ready, what is blocked, and what would be unsafe to invent. Humans still decide. Agents stop filling holes with fiction.

## A pragmatic scope

This is not an enterprise knowledge-graph programme. It is not a graph-database technology choice. It is not RDF (Resource Description Framework), where data is subject-predicate-object triples typical of the Semantic Web and formal ontologies. It is a pragmatic, purpose-built approach, not a semantic framework. It is not a second wiki people are asked to keep in sync by hand either. Nodes, properties and relationships are defined ad hoc, fitted to the client's context and use cases.

In practice:

- the schema fits in a review;
- extractors read artefacts the organisation already owns;
- mapping is a file you can disagree with, not a model that infers meaning;
- refresh stays cheap in resources and does not need the heavy refresh cycles typical of RAG or graphRAG.

## The CI/CD case, without the folklore

Take a legacy CI/CD platform with years of pipelines, shared steps, credentials and one-off scripts. The destination has reusable pieces. On paper the move is obvious. In practice you cannot size it, because "what we have" and "what they cover" do not share a join key.

A capability mapping is that join. Primitives on the source side (a step, a task, a CLI) and providers on the target side (a reusable workflow, a template) meet on the same intent. Then coverage becomes a simple query. Gaps rank by how much work they block. Similar pipelines become models you can reduce to covered capabilities and use cases.

Without that, teams either freeze or, more often, rewrite everything from scratch. The rewrite feels like progress for a quarter, then you fall back into not knowing what is missing and how many cases were actually covered. Security follows the same cut. You cannot claim a safer target if you cannot list which credentials, which privileged commands and which unmapped paths would be copied blindly.

## What you need to start

[DevOps consulting](https://lucabertelli.consulting/en/services/devops-consulting/) helps you get solid delivery practice: pipelines that work, ownership that is not a single person. [Platform Engineering](https://lucabertelli.consulting/en/services/platform-engineering-consulting/) can arrive only once golden paths can be defined, after the routes worth extracting are identified. [AI agent governance](https://lucabertelli.consulting/en/services/ai-agent-governance/), when the move toward agents has happened or is underway, is essential to define and maintain policy, identity and cost.

The graph is the layer underneath when AI agents, mapping of what exists and migrations need the same operational truth. MCP without facts is another integration. A platform programme without an inventory risks becoming a portal that exists for its own sake.

## When it makes sense

If you can already answer the four questions above, you probably do not need this. If answering them means asking one specific colleague, a chain of greps and a meeting where three maps disagree, [email me](mailto:info@lucabertelli.consulting) so we can look together at the use case you want to analyse (how many work units, which catalogues exist, who or what holds the map today). The service page spells out scope, outcomes and FAQ: [knowledge graph consulting](https://lucabertelli.consulting/en/services/knowledge-graph-consulting/).

### DevOps consulting for Fintech, Insurtech and industrial teams (English)

- URL: https://lucabertelli.consulting/en/insights/regulated-industries
- Language: en
- Published: 2025-10-26
- Updated: 2026-09-28
- Summary: What changes when releases, audits and change windows are business constraints rather than operational details
- Related services: https://lucabertelli.consulting/en/services/devops-consulting, https://lucabertelli.consulting/en/services/secdevops-cicd-consulting, https://lucabertelli.consulting/en/services/cyber-resilience-act-compliance, https://lucabertelli.consulting/en/services/kubernetes-consulting, https://lucabertelli.consulting/en/services/cloud-migration-consulting, https://lucabertelli.consulting/en/services/platform-engineering-consulting

## Same Kubernetes, different constraints

A pipeline that "works" for a consumer digital product can be unacceptable in a bank, an insurer or a plant. Not because the tools change names: because **traceability, change windows and accountability** become part of the requirement, not an appendix.

I have built experience in these contexts first as a cloud-native engineer, then as a manager, today as a freelance [DevOps consultant](https://lucabertelli.consulting/en/services/devops-consulting/). What follows is not a catalogue of regulations: it is the practical difference I have lived when bringing a cloud-native approach into regulated organisations.

## Fintech: speed under evidence

In Fintech the typical conflict is between time-to-market and demonstrability. The product team needs to ship often; risk and compliance want to know *who* approved *what*, with which third-party components, and how a known vulnerability is handled.

What works technically:

- **CI/CD with explicit approvals** and retained logs, not screenshots rebuilt before the audit.
- **SBOMs and artifact signing** as a normal pipeline by-product, not a side project.
- **Dynamic secrets** managed by a secrets-management solution instead of static keys in repositories.
- **Comparable environments**: if staging lies about production, every non-regression test will never have concrete value.

Here [SecDevOps and CI/CD consulting](https://lucabertelli.consulting/en/services/secdevops-cicd-consulting/) is not "adding a scanner": it is making evidence emerge from the release process itself.

## Insurtech: slow change, long-lived systems

In Insurtech systems live for a long time, vendors are mixed, and change windows are tight. The risk is not only a production bug: it is being unable to explain, months later, why a configuration was applied.

Recurring patterns:

- inherited clusters or cloud accounts with blurred ownership;
- batch integrations beside services that want to be cloud-native;
- security policies written for datacenters and poorly applied to containers.

The approach to take in these cases should be incremental: stabilise delivery on new services, isolate legacy, make boundaries observable. A [cloud migration](https://lucabertelli.consulting/en/services/cloud-migration-consulting/) "big bang" in this sector is rarely the advisable first step.

## Industrial: service continuity before elegance

In industrial contexts (and OT-adjacent environments more broadly) continuity comes first. A nightly "agile" release that stops a line or a plant is not an acceptable trade-off.

The design changes:

- test environments that **replicate real constraints**, not only the code;
- verified rollback, not theoretical rollback;
- clear separation of networks and identities where IT and plant systems meet;
- observability built for operators, not only for developers;
- **SBOMs, signed firmware and a vulnerability handling process** if the product falls under the [Cyber Resilience Act](https://lucabertelli.consulting/en/services/cyber-resilience-act-compliance/): connected devices and on-machine software are the typical case.

Kubernetes remains useful, but only if day-2 and isolation are solid. Otherwise you add a control plane without reducing operational risk. On this point [Kubernetes consulting](https://lucabertelli.consulting/en/services/kubernetes-consulting/) and SecDevOps practices inevitably intertwine.

## What to ask a consultant

Regardless of sector, these questions separate a useful engagement from a slide deck:

1. How do we produce release evidence **without manual work** before the audit?
2. Who can promote to production, and where does the approval trail live?
3. What happens if we must restore the state from three months ago?
4. Which security checks block the pipeline and which only signal?
5. After the engagement, **who on the internal team** can maintain what was built?

If the answers are vague, you do not have consulting: you have a dependency.

## How I sequence the work

There is no magic recipe for every kind of sector. In regulated environments this sequence is advisable:

1. Honest assessment of delivery state and compliance constraints.
2. Stabilise CI/CD and secrets - see [DevOps](https://lucabertelli.consulting/en/services/devops-consulting/) and [SecDevOps](https://lucabertelli.consulting/en/services/secdevops-cicd-consulting/).
3. Clear boundaries on cloud and Kubernetes.
4. Only afterwards, if many teams share the same pain, extract repeated paths into [Platform Engineering](https://lucabertelli.consulting/en/services/platform-engineering-consulting/).

If you operate in Fintech, Insurtech or an industrial context and want a concrete view on your main constraint (audit, change window, drift, supply chain), [email info@lucabertelli.consulting](mailto:info@lucabertelli.consulting). Three precise sentences beat a long presentation.

### Platform Engineering vs DevOps: the difference that matters in practice (English)

- URL: https://lucabertelli.consulting/en/insights/platform-vs-devops
- Language: en
- Published: 2024-07-13
- Updated: 2026-07-28
- Summary: Same delivery goals, different operating models. How to choose without buying a developer portal too early
- Related services: https://lucabertelli.consulting/en/services/devops-consulting, https://lucabertelli.consulting/en/services/platform-engineering-consulting, https://lucabertelli.consulting/en/services/kubernetes-consulting, https://lucabertelli.consulting/en/services/devops-cloud-native-training

## This is not a labelling war

"We are doing Platform Engineering" has become as convenient a sentence as "we are doing DevOps" was ten years ago. Often it only means someone installed a service catalogue, renamed the infrastructure team, and left the path to production unchanged.

The useful distinction is not vocabulary. It is the **operating model**: who carries complexity, who consumes it, and how you measure whether the system works.

## What DevOps solves (when it is done seriously)

[DevOps](https://lucabertelli.consulting/en/services/devops-consulting/), in the form that matters to teams that have to ship, is a set of practices and automations on the commit → production path: reliable CI, infrastructure as code, comparable environments, fast feedback, shared ownership of incidents.

It works very well while the number of teams stays small and each one can still master the stack. Cognitive load is high, but sustainable.

Collapse often arrives when every team recreates the same piece slightly differently: pipelines, Infrastructure as Code modules, network policy, observability, secrets management. No single choice is wrong on its own. The aggregate is unmanageable.

## What Platform Engineering solves

[Platform Engineering](https://lucabertelli.consulting/en/services/platform-engineering-consulting/) answers that collapse by treating internal infrastructure as a **product**, with real users: the company's developers.

Instead of asking every squad to assemble Kubernetes, CI, secrets and observability, the platform offers **golden paths**: ready, safe, measurable routes for recurring work, with an escape hatch when the case is genuinely special.

It is not "a portal". The portal is the shop window. The substance is what the portal triggers: templates, provisioning, policies applied by construction, self-service environments, adoption metrics.

## An honest comparison

| | DevOps / delivery | Platform Engineering |
| :--- | :--- | :--- |
| **Typical problem** | Slow, fragile releases tied to one person. | Too many teams reinventing the same stack. |
| **Primary user** | The team shipping a product. | The many teams consuming the platform. |
| **Key artefact** | Pipelines, IaC, operational practice. | Golden paths, self-service, internal product. |
| **Useful metric** | Lead time, failure rate, restore time. | Voluntary adoption of standard paths. |
| **Too early when…** | Almost never, if releases are not yet repeatable. | Below roughly 3–4 product teams. |

## Recurring mistakes that show up

### Buying the platform before delivery works

If releases still scare a single team, an Internal Developer Platform adds surface without removing friction in adopting the platform as a whole. That often causes the entire project or internal initiative to fail. In those cases the priority is to fix CI, environments and ownership first with [DevOps consulting](https://lucabertelli.consulting/en/services/devops-consulting/).

### Confusing the portal with the platform

Installing a portal or service catalogue without feasibility and compatibility checks against real use cases produces an inventory. Useful, not sufficient. The question to ask is: *which repetitive action needs a ticket today and should be self-service tomorrow?*

### Mandating golden paths

If teams use the standard path only because it is mandatory, you do not have a product: you have policy. Voluntary adoption is the only honest indicator.

### Separating Kubernetes from the platform

On cloud-native stacks the platform almost always rests on [Kubernetes](https://lucabertelli.consulting/en/services/kubernetes-consulting/), multi-tenancy and GitOps. If the cluster is unstable, self-service multiplies the damage and increases the sense that the platform is fragile.

## How to choose the next step

1. **One team, fragile delivery** → start with DevOps and CI/CD.
2. **Several teams, the same infrastructure tickets** → evaluate Platform Engineering.
3. **Inherited cluster, painful day-2** → fix Kubernetes before industrialising paths.
4. **You only need shared skills** → targeted [training](https://lucabertelli.consulting/en/services/devops-cloud-native-training/) on the real toolchain.

In my experience the right sequence is almost always: stabilise delivery, clarify boundaries on Kubernetes, then extract repeated paths into a platform. Reversing that order costs months (at least).

If you are debating whether to "do PE" or "strengthen DevOps", tell me in a few lines how many teams ship, which requests still need an infrastructure ticket, and [we can talk](mailto:info@lucabertelli.consulting). Detail pages stay here: [DevOps consulting](https://lucabertelli.consulting/en/services/devops-consulting/) and [Platform Engineering consulting](https://lucabertelli.consulting/en/services/platform-engineering-consulting/).

### When you need a Kubernetes consultant (English)

- URL: https://lucabertelli.consulting/en/insights/kubernetes-consultant
- Language: en
- Published: 2024-04-27
- Updated: 2026-07-28
- Summary: What changes between a focused engagement and another YAML sprint
- Related services: https://lucabertelli.consulting/en/services/kubernetes-consulting, https://lucabertelli.consulting/en/services/devops-cloud-native-training, https://lucabertelli.consulting/en/services/platform-engineering-consulting, https://lucabertelli.consulting/en/services/cloud-migration-consulting

## The question that usually arrives too late

People rarely call because they "want Kubernetes". They call because Kubernetes is already there, workloads are running, and every release or incident still costs more than the team can explain. Someone inherited a cluster stood up in a hurry; someone else has three environments that should match and do not; security asks for evidence that nobody can produce without a week of manual work.

The useful question is not "do we need Kubernetes?". It is **when a [Kubernetes consultant](https://lucabertelli.consulting/en/services/kubernetes-consulting/) makes sense**, instead of another internal sprint of patches and charts.

## When internal effort is no longer enough

Not every cluster needs a consultant. If you have a single environment, for example, or a handful of services and a team that knows the perimeter, time and discipline are often enough. External help becomes economical when one of these patterns shows up.

### 1. Day-2 is eating day-1

The cluster is "up", but upgrading nodes, certificates, CSI, ingress or a critical chart is a project every time. There is no repeatable path: there is the person who last time "did everything".

### 2. Multi-tenancy in practice, governance in name only

Shared namespaces, missing or decorative ResourceQuotas, patchy NetworkPolicies, test environments that can touch staging secrets. The cluster hosts several teams without an explicit isolation model. That is when trivial incidents become organisational incidents.

### 3. Half-finished GitOps

A GitOps tool is installed but half of the changes still go through `kubectl` commands and tickets. Desired state is not the source of truth: it is a hope. In those conditions every audit and every disaster recovery starts from scratch.

### 4. Drift nobody measures

Images and charts advance at different speeds across clusters and namespaces. You know you are behind; you do not know by how much, where, or what is deprecated. That is a fleet problem, not a single-deployment problem.

### 5. CI that builds environments "almost like" production

Tests pass on an improvised cluster or temporary namespace without the same policies, ingress rules and limits. Differences then appear in production that CI never saw. Here you usually need a model for ephemeral environments or virtual clusters, not another ancillary pipeline to paper over environment differences.

## What a Kubernetes consultant does (and does not)

A good engagement does not replace the team: it **shrinks the surface where the team has to improvise**.

In practice my engagements develop across four planes, also described on the [Kubernetes consulting](https://lucabertelli.consulting/en/services/kubernetes-consulting/) page:

1. **Architecture and boundaries**: cluster vs namespace vs virtual cluster, networking, identity, limits.
2. **Day-2 operations**: upgrades, verified backup/restore, observability that helps during incidents.
3. **Delivery**: coherent GitOps, test environments that resemble production, pipelines that do not lie.
4. **Handover**: runbooks and documented decisions, so the value remains after the engagement.

What I do not do is "install an operator and leave". If three months later only I know why that NetworkPolicy exists, the engagement failed.

## Consultant, training or Platform Engineering?

Three different levers, often mixed up:

- **Kubernetes consulting** when the problem is the cluster (or the fleet) and you need design or remediation.
- **[DevOps and cloud-native training](https://lucabertelli.consulting/en/services/devops-cloud-native-training/)** when the team already has a clear direction but lacks shared practice and language.
- **[Platform Engineering](https://lucabertelli.consulting/en/services/platform-engineering-consulting/)** when the problem is not one cluster, but the fact that *every team* reinvents the same one.

If you recognise two or more signals above and the internal cost of incidents exceeds a few weeks of focused external work, it is worth talking. If you are still deciding whether to adopt Kubernetes at all, start with a [cloud adoption and migration](https://lucabertelli.consulting/en/services/cloud-migration-consulting/) assessment before buying complexity.

## How a typical engagement runs

1. **Short assessment**: real path from commit to production, privileges, drift, failure points.
2. **Motivated priorities**: not a tool wishlist; an impact/effort sequence.
3. **Incremental implementation**: stability and observability first, then automation, then self-service.
4. **Close with internal ownership**: decision docs and pairing, not dependency.

I work as a freelance consultant, mostly remotely, with clients in Italy and across the EU. Details, FAQ and scope live on the dedicated page: [Kubernetes consulting](https://lucabertelli.consulting/en/services/kubernetes-consulting/).

If you want a second opinion on your case with no commitment, [email me](mailto:info@lucabertelli.consulting) in a few lines: managed or self-managed, how many teams share the cluster, and which incident or constraint made you open this page.

### Cyber Resilience Act: a che punto siamo e da dove cominciare (Italian)

- URL: https://lucabertelli.consulting/it/insights/cyber-resilience-act
- Language: it
- Published: 2026-09-28
- Summary: Le notifiche sono già obbligatorie, le norme armonizzate non ci sono ancora, e dicembre 2027 è più vicino di quanto suggerisca il calendario dei rilasci
- Related services: https://lucabertelli.consulting/it/servizi/consulenza-cyber-resilience-act, https://lucabertelli.consulting/it/servizi/consulenza-secdevops-cicd, https://lucabertelli.consulting/it/servizi/consulenza-devops, https://lucabertelli.consulting/it/servizi/consulenza-kubernetes

## A che punto siamo, settembre 2026

Il Cyber Resilience Act, Regolamento (UE) 2024/2847, è in vigore dal 10 dicembre 2024, e il primo obbligo con conseguenze concrete è arrivato l'**11 settembre 2026**: le notifiche dell'articolo 14. Da quella data un fabbricante che viene a conoscenza di una vulnerabilità attivamente sfruttata in uno dei suoi prodotti, o di un incidente grave che ne compromette la sicurezza, deve inviare un preallarme entro 24 ore, una notifica entro 72 ore e un rapporto finale, attraverso la **piattaforma unica di segnalazione** che ENISA ha aperto lo stesso giorno. L'obbligo copre ogni prodotto in perimetro già sul mercato, non solo quelli immessi dopo il 2027 (articolo 69(3)). Non copre invece lo sfruttamento di cui si era già a conoscenza prima dell'11 settembre: il cronometro parte dalla nuova consapevolezza.

Intorno a quella data alcuni pezzi sono andati a posto:

- **Linee guida della Commissione** (C(2026) 5252, 27 luglio 2026): 84 pagine e 67 esempi pratici su perimetro, elaborazione remota dei dati, open source, modifica sostanziale, periodi di supporto e notifiche. Non vincolanti, ma sono ciò che le autorità di vigilanza leggeranno. Non dicono nulla sul formato della SBOM.
- **Regolamento di esecuzione (UE) 2025/2392** (28 novembre 2025): le descrizioni tecniche delle categorie di prodotti importanti (classe I e II) e critici. È il documento che dice se il vostro prodotto ha bisogno di un organismo notificato.
- **Regolamento delegato (UE) 2026/881**: quando un CSIRT può ritardare la trasmissione della vostra notifica ad altri. Non sposta le vostre scadenze.
- In Italia la **Legge 36/2026** designa l'Agenzia per la Cybersicurezza Nazionale sia come autorità di notifica sia come autorità di vigilanza del mercato, con il CSIRT Italia come coordinatore che riceve le notifiche. Il decreto legislativo che fissa la scala nazionale delle sanzioni è ancora atteso.

Due cose non sono andate a posto. **Nessuna norma armonizzata è stata citata nella Gazzetta ufficiale.** La serie orizzontale EN 40000 (vocabolario, principi, gestione delle vulnerabilità, requisiti di sicurezza generici) è in parte in approvazione e in parte ancora in stesura, la Commissione ha proposto di spostare in avanti le scadenze di normazione, e le prime citazioni non sono attese prima del 2027. Fino ad allora non esiste presunzione di conformità per nessuno, e i prodotti di classe I non possono usare l'autovalutazione. E il **Digital Omnibus**, che propone un punto di ingresso unico per la segnalazione degli incidenti tra NIS2, CRA, GDPR e DORA costruito sopra la piattaforma ENISA, è ancora in Consiglio. Non cambia nessuna data del CRA.

## Che cosa chiede il regolamento, in breve

L'Allegato I ha due parti. La **Parte I** riguarda il prodotto: tredici proprietà, da "nessuna vulnerabilità sfruttabile nota al rilascio" e configurazione sicura per impostazione predefinita fino a cifratura, integrità, minimizzazione dei dati, riduzione della superficie di attacco, registrazione degli eventi di sicurezza e cancellazione sicura, ciascuna applicata secondo una valutazione del rischio documentata. La **Parte II** riguarda il processo del fabbricante: otto doveri, tra cui la SBOM, la correzione delle vulnerabilità senza ritardo, i test regolari, la divulgazione pubblica delle vulnerabilità corrette, una policy di coordinated vulnerability disclosure, un indirizzo di contatto per le segnalazioni, la distribuzione sicura degli aggiornamenti e aggiornamenti di sicurezza gratuiti con un avviso.

Intorno: le informazioni per l'utente (Allegato II, compresa la data di fine supporto e dove segnalare le vulnerabilità), la documentazione tecnica (Allegato VII, compresa la SBOM e la motivazione del periodo di supporto), un periodo di supporto di almeno cinque anni e aggiornamenti di sicurezza che devono restare disponibili per dieci anni dal rilascio. Le sanzioni arrivano a 15 milioni di euro o al 2,5% del fatturato mondiale.

## Tre fraintendimenti che incontro di continuo

**"Siamo SaaS, quindi siamo fuori."** Il servizio in sé è territorio NIS2, ma l'agent edge, l'app mobile, il connettore on-premise e il firmware nel gateway sono prodotti con elementi digitali. Anche l'elaborazione remota senza cui il prodotto non funziona è in perimetro. La maggior parte delle aziende SaaS con cui parlo ha tre o quattro prodotti in perimetro che non aveva contato.

**"La SBOM è il deliverable."** È un punto su ventuno, e da sola produce un lungo elenco di vulnerabilità in codice che il prodotto non esegue mai. Le linee guida della Commissione sono esplicite: un componente vulnerabile il cui codice non è raggiungibile non rende la vulnerabilità del prodotto attivamente sfruttata. Ciò che trasforma l'elenco in evidenza è il giudizio registrato per ogni rilievo (VEX) e il rapporto costruito da quei giudizi (VDR), insieme a un processo che continua a produrli per ogni rilascio supportato.

**"Ce ne occupiamo nel 2027."** L'articolo 14 si applica oggi. La decisione sulla classe determina se serve un organismo notificato, e finora ce ne sono pochissimi; l'articolo 35 chiede agli Stati membri di garantire capacità sufficiente entro l'11 dicembre 2026, il che dice quanto sarà stretta la coda. E il periodo di supporto è di almeno cinque anni dal giorno del rilascio, quindi il processo che gestisce le vulnerabilità su quel rilascio deve esistere quel giorno.

## Come ordinare il lavoro

Non esiste un unico ordine giusto, ma questo ha tenuto in contesti regolati e segue ciò che è già applicabile:

1. **Inventario e classificazione.** Ogni prodotto con elementi digitali, compresi firmware, agent, connettori e componenti di terze parti integrati, mappato su categoria predefinita, importante di classe I o II, o critica. Questo decide il calendario.
2. **Preparazione alle notifiche.** Un punto di contatto unico che gli utenti riescono a trovare, una policy di coordinated vulnerability disclosure, la registrazione sulla piattaforma unica di segnalazione, un criterio scritto per che cosa significa "venire a conoscenza" e dove viene registrato, un runbook per i passi a 24 ore, 72 ore e 14 giorni, e una prova generale.
3. **Evidenze di supply chain.** SBOM per artefatto dalla build, artefatti firmati con provenance, VEX e VDR per ogni rilascio supportato, monitoraggio continuo contro i nuovi dati sulle vulnerabilità. È il lavoro [SecDevOps](https://lucabertelli.consulting/it/servizi/consulenza-secdevops-cicd/) con in più i doveri di conservazione e divulgazione del CRA.
4. **Requisiti di prodotto.** Le proprietà della Parte I che sono decisioni di progetto, affrontate con il team di prodotto e registrate nella valutazione del rischio. Aggiornamenti di sicurezza distribuiti separatamente dalle funzionalità dove possibile.
5. **Documentazione tecnica e percorso di conformità.** L'Allegato VII assemblato dagli output precedenti, poi la decisione tra autovalutazione e organismo notificato presa con il consulente legale.

La pagina sulla [conformità al Cyber Resilience Act](https://lucabertelli.consulting/it/servizi/consulenza-cyber-resilience-act/) descrive che cosa produce ciascuno di questi passi e che cosa copro e non copro.

## Che cosa chiedere a un consulente o a un fornitore

1. Quale rilascio descrive questa SBOM, e come lo dimostrate?
2. Se un ricercatore segnala una vulnerabilità stanotte, dove arriva e chi la legge?
3. Che cosa succede nella vostra organizzazione nelle prime 24 ore dopo aver saputo che una vulnerabilità viene sfruttata?
4. Quali dei vostri rilasci degli ultimi dodici mesi sarebbero contati come modifica sostanziale?
5. Dopo l'intervento, chi nel team interno tiene in piedi tutto questo per i prossimi cinque anni?

Se le risposte sono vaghe, state comprando un documento, non la conformità. Se volete una lettura concreta di dove si trova il vostro prodotto, [scrivete a info@lucabertelli.consulting](mailto:info@lucabertelli.consulting). Il prodotto, la pipeline attuale e la base clienti bastano per cominciare.

### Quando un knowledge graph rende possibile una migrazione di piattaforma (Italian)

- URL: https://lucabertelli.consulting/it/insights/light-knowledge-graphs
- Language: it
- Published: 2026-08-14
- Summary: Persone e agenti AI servono fatti interrogabili. Senza, le grandi migrazioni CI/CD restano tribali e si arenano.
- Related services: https://lucabertelli.consulting/it/servizi/consulenza-knowledge-graph, https://lucabertelli.consulting/it/servizi/consulenza-agenti-ai, https://lucabertelli.consulting/it/servizi/consulenza-platform-engineering, https://lucabertelli.consulting/it/servizi/consulenza-devops

## La migrazione che non parte

La migrazione di una piattaforma CI/CD legacy quasi sempre parte in salita, se non fallisce, quando nessuno sa rispondere a quattro domande senza aver bisogno di ore o giorni per rispondere:

1. Quali use-case copriamo davvero e con quali tecnologie?
2. Cosa copre già la piattaforma e la libreria CI/CD di destinazione?
3. Che cosa manca, e quanto spesso compare?
4. Quali unità di lavoro si assomigliano abbastanza per poter ricondurle ad un modello riusabile?

Anche provando a migrare solo con un agente AI, senza una base di fatti interrogabili, il progetto rischia di diventare inefficiente e troppo costoso: serve comunque una mappa affidabile, e senza di questa sia le persone che gli agenti finiscono per perdere tempo tra congetture e tentativi, rendendo difficile pianificare e stimare davvero il lavoro e i relativi progressi.

È il punto in cui una [consulenza knowledge graph](https://lucabertelli.consulting/it/servizi/consulenza-knowledge-graph/) smette di essere un esercizio di ricerca e diventa la condizione che rende la migrazione sostenibile.

## Fatti, non più contesto

Spesso si parte con centinaia, se non migliaia, di file il cui codice non è stato verificato o mantenuto nel tempo. In questo scenario, gli agenti AI incontrano subito una difficoltà fondamentale: la conoscenza pregressa non è presente nel prompt ma è dispersa tra cataloghi, inventari, repository e nella memoria di poche persone (spesso non più presenti). Aggiungere semplicemente più file nel contesto non porta maggiore copertura, ma solo a congetture più sicure di sé.

Un knowledge graph costruito per uno scopo preciso capovolge l'approccio. I fatti tipizzati vengono estratti dalle sorgenti tramite un processo deterministico e ripetibile, senza coinvolgere agenti AI. Così si ottiene uno schema chiaro fatto di nodi, relazioni dirette e un mapping mantenuto con cura, che permette di riconoscere quando due elementi con nomi diversi rispondono allo stesso intento o scopo. Questo mette le persone e gli agenti AI in condizione di navigarli, anche tramite server MCP dedicati.

Il grafo non migra nulla. Ti dice che cosa è pronto, che cosa è bloccato, e che cosa sarebbe insicuro inventare. Decidono ancora le persone. Gli agenti smettono di riempire i buchi con finzioni.

## Un perimetro pragmatico

Non è un programma enterprise di knowledge graph. Non è una scelta di tecnologia graph database. Non è RDF (Resource Description Framework), dove i dati sono triplette soggetto-predicato-oggetto tipiche del Semantic Web e delle ontologie formali. È un approccio pragmatico e costruito per uno scopo preciso, non un framework semantico. Non è nemmeno un secondo wiki che le persone devono tenere allineato a mano. Nodi, proprietà e relazioni si definiscono ad hoc, calati sul contesto del cliente e sugli use-case.

In pratica:

- lo schema sta in una review;
- gli estrattori leggono artefatti che l'organizzazione possiede già;
- il mapping è un file su cui si può dissentire, non un modello che inferisce il significato;
- il refresh è gestibile con pochissime risorse e non necessita delle grosse moli tipiche del refresh di RAG o graphRAG.

## Il caso CI/CD, senza folklore

Prendi una piattaforma CI/CD legacy con anni di pipeline, step condivisi, credenziali e script fatti una volta sola. La destinazione ha pezzi riusabili. Sulla carta lo spostamento è ovvio. In pratica non lo sai dimensionare, perché "che cosa abbiamo" e "che cosa coprono" non condividono una chiave di join.

Un mapping per capability è quella join. I primitivi sul lato sorgente (uno step, un task, un CLI) e i provider sul lato destinazione (un workflow riusabile, un template) si incontrano sullo stesso intento. Allora la copertura diventa una semplice query. Le lacune si ordinano per quanto lavoro bloccano. Le pipeline simili diventano modelli riconducibili per capability e use-case coperti.

Senza quello, i team o si congelano o quasi sempre riscrivono tutto da zero. La riscrittura sembra progresso per un trimestre ma poi si ricade ancora nel problema di capire cosa manca e quanti casi sono stati realmente coperti. La sicurezza segue lo stesso taglio. Non puoi sostenere una destinazione più sicura se non sai elencare quali credenziali, quali comandi privilegiati e quali percorsi non mappati verrebbero copiati alla cieca.

## Cosa serve per partire

La [consulenza DevOps](https://lucabertelli.consulting/it/servizi/consulenza-devops/) aiuta a ottenere una buona pratica di delivery: pipeline che funzionano, ownership che non è una sola persona. Il [Platform Engineering](https://lucabertelli.consulting/it/servizi/consulenza-platform-engineering/) può arrivare solo quando è possibile definire dei golden path, una volta identificati i percorsi che vale la pena estrarre. La [governance degli agenti AI](https://lucabertelli.consulting/it/servizi/consulenza-agenti-ai/), quando l'evoluzione verso gli agenti è avvenuta o è in corso, è indispensabile per definire e mantenere policy, identità e costi.

Il grafo è lo strato sotto, quando agenti AI, mappatura dell'esistente e migrazioni servono la stessa verità operativa. MCP senza fatti è un'altra integrazione. Un programma di piattaforma senza inventario rischia di essere un portale fine a sé stesso.

## Quando ha senso

Se sapete rispondere alle quattro domande sopra, probabilmente non vi serve questo. Se rispondervi richiede interrogare uno specifico collega, una catena di grep e una riunione in cui tre mappe non coincidono, [contattatemi](mailto:info@lucabertelli.consulting) per capire insieme lo use-case che volete analizzare (quante unità di lavoro, quali cataloghi esistono, chi o cosa oggi possiede la mappa). La pagina di servizio precisa perimetro, risultati attesi e FAQ: [consulenza knowledge graph](https://lucabertelli.consulting/it/servizi/consulenza-knowledge-graph/).

### Consulenza DevOps in Fintech, Insurtech e industriale (Italian)

- URL: https://lucabertelli.consulting/it/insights/regulated-industries
- Language: it
- Published: 2025-10-26
- Updated: 2026-09-28
- Summary: Cosa cambia quando release, audit e finestre di change non sono un dettaglio operativo ma un vincolo di business
- Related services: https://lucabertelli.consulting/it/servizi/consulenza-devops, https://lucabertelli.consulting/it/servizi/consulenza-secdevops-cicd, https://lucabertelli.consulting/it/servizi/consulenza-cyber-resilience-act, https://lucabertelli.consulting/it/servizi/consulenza-kubernetes, https://lucabertelli.consulting/it/servizi/consulenza-cloud-migrazione, https://lucabertelli.consulting/it/servizi/consulenza-platform-engineering

## Stesso Kubernetes, vincoli diversi

Una pipeline che "funziona" in un prodotto digitale consumer può essere inaccettabile in una banca, in una compagnia assicurativa o in uno stabilimento produttivo. Non perché gli strumenti cambino nome: perché **tracciabilità, finestre di change e responsabilità** diventano parte del requisito, non un'appendice.

Ho maturato esperienza in questi contesti prima come cloud native engineer, poi come manager, oggi come [consulente DevOps](https://lucabertelli.consulting/it/servizi/consulenza-devops/) freelance. Quello che segue non è un elenco di normative: è la differenza pratica che ho vissuto quando si porta un approccio Cloud Native dentro organizzazioni regolate.

## Fintech: velocità sotto evidenza

Nel settore Fintech il conflitto tipico è tra il time-to-market e la dimostrabilità. Il team di prodotto ha necessità di rilasciare spesso; risk e compliance vogliono sapere *chi* ha approvato *cosa*, con quali componenti di terzi, e come si risponde a una vulnerabilità nota.

Quello che funziona sul piano tecnico:

- **CI/CD con approvazioni esplicite** e log conservati, non screenshot ricostruiti prima dell'audit.
- **SBOM e firma degli artefatti** come effetto normale della pipeline, non come progetto a parte.
- **Segreti dinamici** gestiti da una soluzione di secrets management al posto di chiavi statiche nei repository.
- **Ambienti confrontabili**: se staging mente sulla produzione, ogni test di non-regressione non avrà mai valore concreto.

Qui la [consulenza SecDevOps e CI/CD](https://lucabertelli.consulting/it/servizi/consulenza-secdevops-cicd/) non è "mettere uno scanner": è far sì che le evidenze nascano dal processo di rilascio.

## Insurtech: cambiamenti lenti, sistemi longevi

Nel settore Insurtech i sistemi vivono a lungo, i vendor sono misti, e le finestre di change sono strette. Il rischio non è solo il bug in produzione: è non poter spiegare, mesi dopo, perché una configurazione è stata applicata.

Pattern ricorrenti:

- cluster o cloud account ereditati con ownership sfumata;
- integrazioni batch accanto a servizi che vogliono essere cloud-native;
- policy di sicurezza scritte per datacenter e applicate male ai container.

L'approccio da tenere in questi casi dovrebbe essere incrementale: stabilizzare la delivery sui servizi nuovi, isolare il legacy, rendere osservabili i confini. Una [migrazione cloud](https://lucabertelli.consulting/it/servizi/consulenza-cloud-migrazione/) "big bang" in questo settore è raramente il primo passo consigliabile.

## Industriale: continuità del servizio prima dell'eleganza

Nel contesto industriale (e in generale OT-adjacent) la priorità è la continuità. Un rilascio notturno "agile" che ferma una linea o un impianto non è un trade-off accettabile.

Cambia il disegno:

- ambienti di test che **replicano i vincoli reali**, non solo il codice;
- rollback verificato, non teorico;
- separazione netta tra reti e identità quando IT e impianti si toccano;
- osservabilità pensata per operatori, non solo per sviluppatori;
- **SBOM, firmware firmato e un processo di gestione delle vulnerabilità** se il prodotto rientra nel [Cyber Resilience Act](https://lucabertelli.consulting/it/servizi/consulenza-cyber-resilience-act/): dispositivi connessi e software a bordo macchina sono il caso tipico.

Kubernetes resta utile, ma solo se day-2 e isolation risultano solidi. Altrimenti si aggiunge un piano di controllo senza ridurre il rischio operativo. Su questo la [consulenza Kubernetes](https://lucabertelli.consulting/it/servizi/consulenza-kubernetes/) e le pratiche SecDevOps si intrecciano per forza.

## Cosa chiedere a un consulente

Indipendentemente dal settore, queste domande separano un intervento utile da una slide deck:

1. Come produciamo evidenze di rilascio **senza lavoro manuale** prima dell'audit?
2. Chi può promuovere in produzione, e dove resta traccia dell'approvazione?
3. Cosa succede se dobbiamo ripristinare lo stato di tre mesi fa?
4. Quali controlli di sicurezza bloccano la pipeline e quali segnalano soltanto?
5. Dopo l'intervento, **chi nel team interno** sa mantenere ciò che è stato costruito?

Se le risposte sono vaghe, non avete una consulenza: avete una dipendenza.

## Come alloco il lavoro

Non esiste una ricetta magica per ogni tipologia di settore. In ambienti regolati è consigliabile la sequenza:

1. Assessment onesto dello stato di delivery e dei vincoli di conformità.
2. Stabilizzazione CI/CD e segreti - vedi [DevOps](https://lucabertelli.consulting/it/servizi/consulenza-devops/) e [SecDevOps](https://lucabertelli.consulting/it/servizi/consulenza-secdevops-cicd/).
3. Confini chiari su cloud e Kubernetes.
4. Solo dopo, se i team sono tanti, estrazione dei percorsi ripetuti in [Platform Engineering](https://lucabertelli.consulting/it/servizi/consulenza-platform-engineering/).

Se operate in Fintech, Insurtech o in un contesto industriale e volete un parere concreto sul vostro vincolo principale (audit, finestra di cambio, drift, supply chain), [scrivete a info@lucabertelli.consulting](mailto:info@lucabertelli.consulting). Meglio tre frasi precise di una presentazione lunga.

### Platform Engineering vs DevOps: la differenza che conta in pratica (Italian)

- URL: https://lucabertelli.consulting/it/insights/platform-vs-devops
- Language: it
- Published: 2024-07-13
- Updated: 2026-07-28
- Summary: Stessi obiettivi di delivery, modelli operativi diversi. Come scegliere senza comprare un portale per sviluppatori troppo presto
- Related services: https://lucabertelli.consulting/it/servizi/consulenza-devops, https://lucabertelli.consulting/it/servizi/consulenza-platform-engineering, https://lucabertelli.consulting/it/servizi/consulenza-kubernetes, https://lucabertelli.consulting/it/servizi/formazione-devops-cloud-native

## Non è una guerra di etichette

"Facciamo Platform Engineering" è diventata una frase comoda quanto "facciamo DevOps" dieci anni fa. Spesso significa soltanto che qualcuno ha installato un catalogo servizi, ha rinominato il team infrastrutturale e ha lasciato invariato il modo in cui i prodotti arrivano in produzione.

La distinzione utile non sta nel vocabolario. Sta nel **modello operativo**: chi porta la complessità, chi la consuma, e come si misura se il sistema funziona.

## Cosa risolve DevOps (quando è fatto sul serio)

[DevOps](https://lucabertelli.consulting/it/servizi/consulenza-devops/), nella forma che interessa ai team che devono rilasciare, è un insieme di pratiche e di automazioni sul percorso commit → produzione: CI affidabile, infrastructure as a code, ambienti confrontabili, feedback rapido, responsabilità condivisa sugli incidenti.

Funziona molto bene finché il numero di team resta piccolo e ognuno può ancora padroneggiare lo stack. Il costo cognitivo è alto, ma è sostenibile.

Il collasso arriva spesso quando ogni team ricrea leggermente diverso lo stesso pezzo: pipeline, moduli di Infrastructure as Code, policy di rete, osservabilità, gestione dei segreti. Nessuna scelta è sbagliata da sola. L'insieme è ingestibile.

## Cosa risolve Platform Engineering

Il [Platform Engineering](https://lucabertelli.consulting/it/servizi/consulenza-platform-engineering/) risponde a quel collasso trattando l'infrastruttura interna come un **prodotto**, con utenti reali: gli sviluppatori dell'azienda.

Invece di chiedere a ogni squadra di assemblare Kubernetes, CI, segreti e osservabilità, la piattaforma offre **golden path**: percorsi già pronti, sicuri e misurabili per le attività ricorrenti, con una via di uscita quando il caso è davvero speciale.

Non è "un portale". Il portale è la vetrina. La sostanza è ciò che il portale attiva: template, provisioning, policy applicate per costruzione, ambienti self-service, metriche di adozione.

## Una tabella onesta

| | DevOps / delivery | Platform Engineering |
| :--- | :--- | :--- |
| **Problema tipico** | Rilasci lenti, fragili, legati a una persona. | Troppi team che reinventano lo stesso stack. |
| **Utente principale** | Il team che consegna un prodotto. | I molti team che consumano la piattaforma. |
| **Artefatto chiave** | Pipeline, IaC, pratiche operative. | Golden path, self-service, prodotto interno. |
| **Metrica utile** | Lead time, failure rate, tempo di ripristino. | Adozione volontaria dei percorsi standard. |
| **Troppo presto quando…** | Quasi mai, se i rilasci non sono ancora ripetibili. | Sotto circa 3–4 team di sviluppo. |

## Errori ricorrenti che emergono

### Comprare la piattaforma prima della delivery

Se i rilasci fanno ancora paura a un solo team, una Internal Developer Platform aggiunge superficie senza togliere frizione nell'adozione dell'intera piattaforma. Questo spesso causa il fallimento dell'intero progetto o iniziativa interna. In questi casi la priorità è sistemare prima CI, ambienti e ownership con una [consulenza DevOps](https://lucabertelli.consulting/it/servizi/consulenza-devops/).

### Confondere il portale con la piattaforma

Installare un portale o un catalogo servizi senza verifiche di fattibilità e compatibilità con gli use-case reali produce un inventario. Utile, non sufficiente. La domanda da fare è: *quale azione ripetitiva oggi richiede un ticket e domani deve essere self-service?*

### Imporre i golden path

Se i team usano il percorso standard solo perché è obbligatorio, non avete prodotto: avete policy. L'adozione volontaria è l'unico indicatore onesto.

### Separare Kubernetes dalla piattaforma

Su stack cloud-native la piattaforma poggia quasi sempre su [Kubernetes](https://lucabertelli.consulting/it/servizi/consulenza-kubernetes/), multi-tenancy e GitOps. Se il cluster è instabile, il self-service moltiplica il danno e aumenta la sensazione di fragilità della piattaforma.

## Come scegliere il prossimo passo

1. **Un team, delivery fragile** → partire da DevOps e CI/CD.
2. **Più team, stessi ticket infrastrutturali** → valutare Platform Engineering.
3. **Cluster ereditato e day-2 doloroso** → sistemare Kubernetes prima di industrializzare i percorsi.
4. **Serve solo allineare competenze** → [formazione](https://lucabertelli.consulting/it/servizi/formazione-devops-cloud-native/) mirata sulla toolchain reale.

Nella mia esperienza la sequenza corretta è quasi sempre: stabilizzare la delivery, chiarire i confini su Kubernetes, poi estrarre i percorsi ripetuti in una piattaforma. Invertire l'ordine costa mesi (almeno).

Se state discutendo se "fare PE" o "rafforzare DevOps", descrivetemi in poche righe quanti team rilasciano, cosa oggi richiede un ticket al gruppo infrastrutturale, e [ne parliamo](mailto:info@lucabertelli.consulting). Le pagine di dettaglio restano qui: [Consulenza DevOps](https://lucabertelli.consulting/it/servizi/consulenza-devops/) e [Consulenza Platform Engineering](https://lucabertelli.consulting/it/servizi/consulenza-platform-engineering/).

### Quando serve un consulente Kubernetes (Italian)

- URL: https://lucabertelli.consulting/it/insights/kubernetes-consultant
- Language: it
- Published: 2024-04-27
- Updated: 2026-07-28
- Summary: Cosa cambia tra un intervento mirato e un'altra sprint di YAML
- Related services: https://lucabertelli.consulting/it/servizi/consulenza-kubernetes, https://lucabertelli.consulting/it/servizi/formazione-devops-cloud-native, https://lucabertelli.consulting/it/servizi/consulenza-platform-engineering, https://lucabertelli.consulting/it/servizi/consulenza-cloud-migrazione

## La domanda che arriva troppo tardi

Di solito non mi contattano perché "vogliono Kubernetes". Mi chiamano perché Kubernetes c'è già, i workload girano, eppure ogni rilascio o ogni incidente costa più di quanto il team riesca a spiegare. Qualcuno ha ereditato un cluster montato in fretta; qualcun altro ha tre ambienti che dovrebbero essere uguali e non lo sono; la security chiede evidenze che nessuno sa estrarre senza una settimana di lavoro manuale.

La domanda utile non è "serve Kubernetes?". È **quando ha senso un [consulente Kubernetes](https://lucabertelli.consulting/it/servizi/consulenza-kubernetes/)**, invece di un'altra sprint interna di patch e chart.

## Quando l'intervento interno non basta più

Non tutti i cluster hanno bisogno di un consulente. Se avete un solo ambiente, ad esempio, o pochi servizi e un team che conosce il perimetro, spesso basta tempo e disciplina. L'intervento esterno diventa conveniente quando compare uno di questi pattern.

### 1. Il day-2 mangia il day-1

Il cluster "è su", ma aggiornare nodi, certificati, CSI, ingress o un chart critico è un progetto ogni volta. Non esiste un percorso ripetibile: esiste la persona che l'ultima volta "ha fatto tutto".

### 2. Governance di nome ma multi-tenancy di fatto

Namespace condivisi, ResourceQuota assenti o decorative, NetworkPolicy a macchia di leopardo, ambienti di test che possono toccare segreti di staging. Il cluster ospita più team senza un modello di isolamento esplicito. È il punto in cui incidenti banali diventano incidenti organizzativi.

### 3. GitOps a metà

Uno strumento GitOps è installato ma metà dei cambiamenti passa ancora da comandi `kubectl` e da ticket. Lo stato desiderato non è la fonte di verità: è una speranza. In queste condizioni ogni audit e ogni disaster recovery riparte da zero.

### 4. Drift che nessuno misura

Immagini e chart avanzano a velocità diverse tra cluster e namespace. Sapete che siete indietro; non sapete di quanto, dove, e cosa è deprecato. È un problema di fleet, non di un singolo deployment.

### 5. CI che crea ambienti "quasi uguali" alla produzione

I test passano su un cluster improvvisato o su un namespace temporaneo senza le stesse policy, gli stessi ingress, gli stessi limiti. Poi in produzione emergono differenze che il CI non aveva visto. Qui spesso serve un modello di ambienti effimeri o di virtual cluster, non un'altra pipeline a corollario per colmare le differenze tra ambienti.

## Cosa fa (e non fa) un consulente Kubernetes

Un buon intervento non sostituisce il team: **riduce il perimetro in cui il team deve improvvisare**.

Nella pratica i miei interventi si sviluppano su quattro piani, descritti anche nella pagina di [consulenza Kubernetes](https://lucabertelli.consulting/it/servizi/consulenza-kubernetes/):

1. **Architettura e confini**: cluster vs namespace vs virtual cluster, rete, identity, limiti.
2. **Operatività day-2**: upgrade, backup/restore verificati, osservabilità utile agli incidenti.
3. **Consegna**: GitOps coerente, ambienti di test che assomigliano alla produzione, pipeline che non mentono.
4. **Trasferimento**: runbook e scelte documentate, così il vantaggio resta dopo la consulenza.

Quello che non faccio è "installare un operator e andarmene". Se dopo tre mesi solo io so perché quella NetworkPolicy esiste, l'intervento è fallito.

## Consulente, formazione o Platform Engineering?

Tre leve diverse, spesso confuse:

- **Consulenza Kubernetes** quando il problema è il cluster (o la fleet) e serve progettare o rimettere in ordine.
- **[Formazione DevOps e Cloud Native](https://lucabertelli.consulting/it/servizi/formazione-devops-cloud-native/)** quando il team ha già una direzione chiara ma gli mancano pratica e linguaggio comune.
- **[Platform Engineering](https://lucabertelli.consulting/it/servizi/consulenza-platform-engineering/)** quando il problema non è un cluster, ma il fatto che *ogni team* deve reinventare lo stesso cluster.

Se riconoscete due o più segnali della lista e il costo interno degli incident supera qualche settimana di focus esterno, ha senso parlare. Se invece state ancora scegliendo se adottare Kubernetes, partite da un assessment di [migrazione e adozione cloud](https://lucabertelli.consulting/it/servizi/consulenza-cloud-migrazione/) prima di comprare complessità.

## Come si svolge un intervento tipico

1. **Assessment breve**: flusso reale dal commit alla produzione, privilegi, drift, punti di fallimento.
2. **Priorità motivate**: non una wishlist di tool; una sequenza impatto/sforzo.
3. **Implementazione incrementale**: prima stabilità e osservabilità, poi automazione, poi self-service.
4. **Chiusura con ownership interno**: documentazione delle decisioni e affiancamento, non dipendenza.

Lavoro come consulente freelance, prevalentemente da remoto, con clienti in Italia e in Unione Europea. Dettagli, FAQ e perimetro sono sulla pagina dedicata: [Consulenza Kubernetes](https://lucabertelli.consulting/it/servizi/consulenza-kubernetes/).

Se volete un secondo parere sul vostro caso senza impegno, [scrivimi](mailto:info@lucabertelli.consulting) in poche righe: ambiente gestito o self-managed, quanti team sul cluster, e qual è l'incidente o il vincolo che vi ha fatto aprire questa pagina.


## Blog articles

### Digging up fossils in your K8s cluster fleet (English)

- URL: https://lucabertelli.consulting/en/blog/omastx
- Language: en
- Published: 2026-07-26
- Summary: How to use Omastx to sniff out obsolete images and Helm charts, plus MCP for AI agents
- Tags: kubernetes, helm, drift, observability, devsecops, fleet-management, mcp

## Why do we need it?

Running a single Kubernetes cluster already means managing container images and Helm releases. Running a *fleet* multiplies the problem: every namespace brings its own workloads and charts with their versions, and the "are we up to date?" doubt becomes a question you answer by opening dashboards, registry UIs, and running `helm list` one cluster at a time.

Platform teams feel this weight first. Security asks which clusters still run a deprecated Redis tag. Product asks whether the `prod-eu` and `prod-us` clusters are aligned. You know *something* is outdated, but there is no single place that answers: *How up to date / obsolete is my fleet?*

Commercial fleet tools exist, but they often pull write access, push agents into every cluster, or bury version gaps inside a broader ops product. Homegrown scripts scrape registries and dump CSVs that go stale by lunchtime.

**Bottom line:** no read-only view that continuously compares what is *running* against what is *latest* upstream, across images and Helm charts, with a navigable chart instead of a spreadsheet.

## Finding a solution: Omastx

[Omastx](https://github.com/banshee86vr/omastx) is an open-source web portal that scans your Kubernetes clusters, discovers container images and Helm releases, resolves the latest upstream versions, and shows the gap as drift classes you can navigate: Current, Patch, Minor, Major, Deprecated, and Unknown. It is read-only by design: even if you connect an admin kubeconfig, Omastx only issues read calls against the Kubernetes API (`get`/`list` on workloads and, for Helm releases, on secrets): never create, update, delete, or any other invasive command. Beside the UI, a scoped Bearer API and a thin [MCP](https://modelcontextprotocol.io/) server let scripts and AI agents (Cursor, Claude, and similar) query the fleet and trigger scans without cluster write access.

![Fleet overview: 50% of updated workloads, per-cluster drift bars, and status rail](https://lucabertelli.consulting/blog/omastx/fleet.webp)
*Fleet page: percentage of updated workloads in the headline, stacked drift bars per cluster, and a rail for failures, last scans, and connection status.*

## What does the dashboard give you?

The **Fleet** page opens with a single number: the share of workloads still on latest across every connected cluster. Under that, each cluster is a horizontal lane of stacked drift segments. Click a segment and you land in the artifact ledger already filtered to that cluster and drift class. The right rail surfaces what needs attention (degraded clusters, failed scans), recent scan history, and connection health.

Open a cluster and the same chart language zooms to **namespace lanes**. You see schedule, API server, last scan, a drift breakdown, a short trend, and the mix of images versus Helm charts. Recent scans are clickable: each "View artifacts" link opens the ledger scoped to that scan's cluster.

![Cluster detail for prod-eu: namespace drift lanes, breakdown, and recent scans](https://lucabertelli.consulting/blog/omastx/cluster_drift.webp)
*Cluster detail: namespace-level drift bars, analytics cards, and scan history with one-click jump into the ledger.*

Not every cluster grants the same RBAC. If secrets access is missing, Omastx stays useful in **images-only** mode: Helm discovery is skipped, the cluster is marked DEGRADED, and you get a clear banner explaining what permission to add. Unknown drift appears when a registry cannot be resolved (for example a private host without credentials).

![Degraded cluster prod-us: images-only mode with unknown drift](https://lucabertelli.consulting/blog/omastx/cluster_degraded.webp)
*Degraded cluster: Helm access missing, images still scanned, Unknown segment when a registry cannot be resolved.*

The **Artifacts** ledger is the global, filterable list of every discovered image and chart, sorted by how far it has drifted. Filter by cluster, kind (image or chart), drift class, and namespace; search by name. Each row shows installed → latest and a drift badge.

From the same table you can export the filtered result as CSV or PDF. Active filters apply to both formats: what you see in the table is what lands in the file.

![Artifact ledger across the fleet](https://lucabertelli.consulting/blog/omastx/artifacts.webp)
*Artifacts page: ledger with filters and Export CSV / Export PDF buttons.*

Click a row to open the **artifact detail** sheet: identity, registry or chart repo URL, match confidence for Helm, releases behind, history sparkline, and candidate versions when the tag channel allows a comparison.

![Filtered ledger and artifact detail for ingress-nginx major drift](https://lucabertelli.consulting/blog/omastx/artifact_detail.webp)
*Drill-down: filter to major drift in a namespace, then open the sheet for installed → latest, confidence, and metadata.*

![Ledger filtered to prod-eu / platform / major](https://lucabertelli.consulting/blog/omastx/artifacts_filtered.webp)
*Same ledger after narrowing to one cluster, one namespace, and major drift only.*

**Connect a cluster** is a guided flow to drop or paste a kubeconfig, pick contexts, then set a name and cron schedule for the scans.

![Connect cluster onboarding with kubeconfig drop zone](https://lucabertelli.consulting/blog/omastx/connect.webp)
*Connect flow: drop or paste a read-only kubeconfig; Omastx checks permissions before saving.*

Credentials for private registries can be attached, for example, when drift is classified as Unknown and the artifact points at a host that requires authentication.

## Machine API and MCP

Beside the UI, Omastx exposes a scoped Bearer API for scripts and AI agents. Admin actions (connect clusters, registry credentials) stay session-only. OpenAPI is at `/api/openapi.yaml` (also under `docs/openapi.yaml` in the repo).

### 1. Create an API token

1. Sign in and open **Settings → API tokens**.
2. Give the token a name, enable scopes `read` (fleet, artifacts, scans) and/or `scan` (start scans).
3. Click **Create token** and copy the value once (`omx_…`). It is never shown again.

Smoke-test the token with curl (Compose URL shown; use `http://localhost:5173` or `:8484` for native dev):

```bash
export OMASTX_URL=http://localhost:8080
export OMASTX_API_TOKEN=omx_…

curl -sS -H "Authorization: Bearer $OMASTX_API_TOKEN" \
  "$OMASTX_URL/api/fleet/summary" | jq .
```

### 2. Build the MCP server

The thin wrapper lives in `mcp/` and calls the same REST API (no duplicated business logic, no kubeconfigs or registry secrets):

```bash
cd mcp
npm install
npm run build
```

That produces `mcp/dist/index.js`. It needs Node 20+ and two env vars: `OMASTX_URL` (site root, without `/api`) and `OMASTX_API_TOKEN`.

### 3. Configure Cursor (or any MCP host)

Add an entry to your MCP config (Cursor: project or user `mcp.json`). Use the **absolute** path to `dist/index.js`:

```json
{
  "mcpServers": {
    "omastx": {
      "command": "node",
      "args": ["/absolute/path/to/omastx/mcp/dist/index.js"],
      "env": {
        "OMASTX_URL": "http://localhost:8080",
        "OMASTX_API_TOKEN": "omx_…"
      }
    }
  }
}
```

Reload MCP servers in the host. Tools available: `fleet_summary`, `list_clusters`, `get_cluster`, `list_artifacts`, `get_artifact`, `artifact_history`, `start_scan`, `list_scans`, `export_artifacts`.

### 4. Test the MCP layer

With Omastx running and at least one cluster connected, ask the agent (or call the tools) in this order:

1. **`fleet_summary`** then **`list_clusters`** - confirm your cluster appears and status looks right.
2. **`list_artifacts`** with that cluster's id - expect a page of images/charts with drift classes.
3. **`start_scan`** on the cluster id, then **`list_scans`** until status is `done` or `error` (agents poll; the UI can also follow SSE).
4. Optional: **`export_artifacts`** with `format=csv` for a text export of the filtered ledger.

Example prompts: "Summarize fleet drift", "List major-drift artifacts on cluster X", "Start a scan on cluster X and tell me when it finishes".

If a tool returns `401`, recreate the token. `403` / `insufficient_scope` means the token is missing `read` or `scan`. Admin routes are intentionally unavailable over MCP.

## Requirements

- Docker + Compose (quickest path), **or** Go 1.26+ and Node 20+ for native development
- PostgreSQL (bundled in Compose; external for typical Helm installs)
- A read-only kubeconfig per cluster (get/list on workloads; secrets for Helm release discovery)
- For production: a [GitHub OAuth App](https://github.com/settings/developers) and membership in the configured GitHub org (or your username for a solo install)

## Preparation steps

### 1. Clone the repository

```bash
git clone https://github.com/banshee86vr/omastx.git
cd omastx
```

### 2. Start locally with Docker Compose

```bash
make dev   # or: docker compose -f deploy/docker-compose.yml up --build
```

Open http://localhost:8080. In this mode you are signed in automatically (no credentials or `.env` file required).

### 3. (Optional) Native development with hot reload

For day-to-day coding, run Postgres in Docker and the API + Vite on the host:

```bash
make dev-local
```

Open http://localhost:5173. Vite proxies `/api` to the backend on `:8484` and signs you in automatically.

### 4. Connect a cluster and scan

In the UI, open **+ Connect cluster**, drop a read-only kubeconfig, select the contexts to import, confirm the permission check, and set a scan schedule. Click **Scan now** on the cluster page (or wait for the cron). When the scan finishes, the Fleet headline and drift lanes update; open **Artifacts** to walk the ledger.

### 5. (Optional) Seed demo data

To explore the UI without a real fleet, the repository includes a seed path used for the screenshots in this article (`make seed` / the article capture script under `docs/screenshots/article/`).

## Architecture (in short)

![Omastx architecture: React SPA and MCP/Bearer clients, Go API, PostgreSQL, read-only Kubernetes clusters, and upstream sources](https://lucabertelli.consulting/blog/omastx/architecture.webp)
*React SPA (session + CSRF) and AI agents/MCP (Bearer read/scan), Go backend with OpenAPI, scan orchestrator and pluggable providers/resolvers, PostgreSQL (including API tokens), read-only cluster discovery, and latest-version resolve from OCI registries, Helm repos, and Artifact Hub.*

## Docker Compose

The Compose stack under `deploy/docker-compose.yml` builds and runs Postgres, the Go API, and the nginx-fronted frontend. Images for releases are published to GitHub Container Registry: `ghcr.io/banshee86vr/omastx-backend` and `ghcr.io/banshee86vr/omastx-frontend`.

```bash
make dev          # build and start
# open http://localhost:8080
```

## Deploying to Kubernetes

Omastx ships a Helm chart in `deploy/chart/omastx`. Create a Secret with the master key, GitHub OAuth credentials, org gate, base URL, and database URL, then install with `existingSecret` (values never template secrets inline).

Register a GitHub OAuth App with callback `${OMASTX_BASE_URL}/api/auth/github/callback`. Only members of `OMASTX_GITHUB_ORG` can sign in.

```bash
kubectl create secret generic omastx \
  --from-literal=OMASTX_MASTER_KEY=$(openssl rand -hex 32) \
  --from-literal=OMASTX_GITHUB_CLIENT_ID=... \
  --from-literal=OMASTX_GITHUB_CLIENT_SECRET=... \
  --from-literal=OMASTX_GITHUB_ORG=your-org \
  --from-literal=OMASTX_BASE_URL=https://omastx.example.com \
  --from-literal=DATABASE_URL=postgres://user:pass@host:5432/omastx

helm install omastx deploy/chart/omastx --set existingSecret=omastx
```

For a throwaway test install with bundled Postgres:

```bash
helm install omastx deploy/chart/omastx \
  --set existingSecret=omastx --set postgres.internal.enabled=true
```

The chart runs non-root containers with hardened security contexts; the product itself never requests Kubernetes write permissions on the clusters it monitors.

## Bottom line

With `make dev` you get a portal that answers one question for your whole fleet: how many fossils will we find on our clusters? Connect read-only kubeconfigs, scan on a schedule, check the drift classes on the chart, and drill into every image and Helm chart in the ledger, or ask an AI agent over MCP for the same read/scan surface. Open-source and no write path into your clusters. For anyone running more than one Kubernetes environment, Omastx is the drift view that `kubectl` and `helm list` never aggregate for you.

### A self-hosted dashboard for Renovate Bot (English)

- URL: https://lucabertelli.consulting/en/blog/krabbx
- Language: en
- Published: 2025-05-01
- Summary: How to use Krabbx to track dependency freshness and open update PRs across your GitHub organization
- Tags: renovate, dependency-management, devsecops, kubernetes, observability

## Why do we need it?

Every modern project depends on dozens of libraries, and keeping them up to date is a security and stability concern. [Renovate Bot](https://docs.renovatebot.com/) automates this by opening PRs when new versions are available. GitHub offers its own Dependabot, but Renovate supports a wider range of package managers, allows grouping updates into a single PR, provides fine-grained automerge rules, and works identically on any Git platform, not just GitHub. Renovate also integrates naturally with AI-assisted workflows: its custom managers and post-upgrade commands let you plug in AI tools to auto-fix breaking changes or generate migration code, while Dependabot's Copilot Autofix is limited to security patches. Once you adopt Renovate across an entire GitHub organization, though, new questions arise: *Which repos actually run Renovate? How many update PRs are piling up? Which dependencies are the most outdated?*

GitHub provides no aggregated view of PRs activity. You have to open each repository, check if a config file exists, browse open PRs, and mentally piece together the state of all your dependencies. With 10 repos it's tedious; with 50+ it's not manageable.

**Bottom line:** no central dashboard for Renovate adoption, no cross-repo dependency view, no health score that tells you where your technical debt is accumulating.

## Finding a solution: Krabbx

[Krabbx](https://github.com/banshee86vr/krabbx) is an open-source, self-hosted dashboard that monitors Renovate Bot adoption and dependency update activity across GitHub organizations. It scans your repositories via the GitHub API, detects whether Renovate is configured (config files, workflow YAML, or PR evidence), parses open Renovate PRs to extract dependency data, and presents everything in a single interface with real-time updates.

![Main Krabbx dashboard: summary cards, health leaderboard, and achievement badges](https://lucabertelli.consulting/blog/krabbx/dashboard.webp)
*Main dashboard: total repositories, adoption rate, outdated dependencies, health leaderboard, and badges.*

## What does the dashboard give you?

The **Dashboard** page shows three summary cards at the top: total repositories, Renovate adoption rate, and total outdated dependencies with the count of open PRs. Below these, a **Health & achievements** section displays the organization-wide outdated trend over a 14-day window.

The **Health leaderboard** ranks repositories by a 0-100 health score based on three axes: freshness (ratio of outdated dependencies), major discipline (penalty for major-version drift), and PR remediation (bonus for having active Renovate PRs). **Badges** highlight milestones like "Zero Major Drift" for repos with no major-version outdated packages.

![Top outdated repositories and top outdated dependencies](https://lucabertelli.consulting/blog/krabbx/dashboard_cards.webp)
*Bottom cards: top outdated repos and top outdated dependencies with cross-repo usage*

Three additional cards show the **top outdated repositories** and the **top outdated dependencies** (with links to the Renovate PRs in every repo that uses them), and **recent activity**.

The **Repositories** page lists all synced repositories with their adoption status ("Adopted" or "Not adopted"), health score, open PRs count, dependency count, last scan time, and contributors.

![Repository list with adoption status, health score, and open PRs](https://lucabertelli.consulting/blog/krabbx/repositories.webp)
*Repository list: filter by adoption status, sort by health score, and jump into any repo's detail page.*

From here you can deep dive into a **Repository Detail** page. This view shows the dependency health score with a radar chart for the three scoring axes, a breakdown of how the score is calculated, the org rank, and a table of all open Renovate PRs with package name, current version, latest version, and update type (patch, minor, major).

![Repository detail: health score radar, scoring breakdown, and open Renovate PRs](https://lucabertelli.consulting/blog/krabbx/repository_details.webp)
*Repository detail: health score with transparent calculation, radar chart, and the list of open Renovate PRs.*

The **Dependencies** page is a global, filterable view of all tracked dependencies across the organization. You can filter by outdated-only, search by package name, and filter by update type. Each row shows the repository, package manager type, current and latest versions, and a direct link to the Renovate PR on GitHub.

![Global dependency view with search, filters, and PR links](https://lucabertelli.consulting/blog/krabbx/dependencies.webp)
*Dependencies page: search across all organization dependencies, filter by outdated status and update type.*

**Live scanning** runs in the background with real-time progress. A modal overlay shows the current scan status (e.g., "4 of 7 repositories") with a progress bar, so you always know where the scan stands.

![Live scanning modal with progress bar](https://lucabertelli.consulting/blog/krabbx/scanning.webp)

## Requirements

- Node.js 24+
- pnpm
- A GitHub Personal Access Token with `repo` scope ([create one here](https://github.com/settings/tokens))
- (Optional) PostgreSQL for persistent storage
- (Optional) Redis for session management and Socket.IO scaling

## Preparation steps

### 1. Clone the repository and install dependencies

```bash
git clone https://github.com/banshee86vr/krabbx.git
cd krabbx
pnpm install
```

### 2. Configure the environment

```bash
cp .env.example .env
```

Edit `.env` with your settings:

```env
# GitHub scanner
GITHUB_TOKEN=ghp_your_personal_access_token
GITHUB_TARGETS=your-org,your-username

# Auth (disable for local demo)
AUTH_ENABLED=false
ALLOW_INSECURE_NOAUTH=true

# Storage: memory for quick start, database for persistence
STORAGE_MODE=memory

# Session
SESSION_SECRET=your_random_32_character_secret_string
```

`GITHUB_TARGETS` accepts a comma-separated list of GitHub organization or user names. Every repository under those owners will be scanned.

### 3. Start the application

```bash
pnpm run dev
```

The frontend starts at `http://localhost:5173` and the backend API at `http://localhost:3001`. Click **Scan** in the top bar and the dashboard will begin scanning your repositories, detecting Renovate configurations, and parsing open PRs.

### 4. (Optional) Enable database mode for persistent storage

For data that survives restarts, spin up a PostgreSQL instance:

```bash
docker run --name krabbx-postgres \
  -e POSTGRES_DB=krabbx \
  -e POSTGRES_USER=postgres \
  -e POSTGRES_PASSWORD=postgres \
  -p 5432:5432 -d postgres:18
```

Update your `.env`:

```env
STORAGE_MODE=database
DATABASE_URL=postgresql://postgres:postgres@localhost:5432/krabbx?sslmode=disable
```

Run the Prisma migrations and restart:

```bash
pnpm run db:generate
pnpm run db:migrate
pnpm run dev
```

### 5. (Optional) Enable GitHub OAuth for multi-user access

For team environments, create a GitHub OAuth App at [GitHub Developer Settings](https://github.com/settings/developers):

- **Application name**: `Krabbx Dashboard`
- **Homepage URL**: `http://localhost:5173`
- **Authorization callback URL**: `http://localhost:3001/api/auth/callback`

Then update `.env`:

```env
AUTH_ENABLED=true
ALLOW_INSECURE_NOAUTH=false
GITHUB_AUTH_CLIENT_ID=your_oauth_client_id
GITHUB_AUTH_CLIENT_SECRET=your_oauth_client_secret
```

You can optionally restrict access to a specific GitHub team with `GITHUB_AUTH_TEAM_SLUG`.

## Architecture (in short)

Frontend: React 19 + TypeScript with Vite, Tailwind, TanStack Query, and Recharts. Backend: Node.js with Express 5 and TypeScript, Prisma ORM, and Socket.IO for real-time updates. Storage has two modes: `STORAGE_MODE=memory` for development (in-process Maps, zero setup), `STORAGE_MODE=database` for production with PostgreSQL. Sessions and Socket.IO can optionally scale via Redis.

The scanning engine uses the GitHub API (Octokit) to detect Renovate adoption through three options: config file presence (`renovate.json`, `.renovaterc`, etc.), workflow YAML markers (Renovate GitHub Action, Mend actions, Docker images), and PR evidence (open or recently closed PRs from the Renovate bot). Dependency data is extracted by parsing Renovate PR titles and bodies.

## Docker Compose

The quickest way to run the full stack in production mode:

```bash
cp .env.example .env
# edit .env with your GitHub token and targets
pnpm run docker:up
```

This starts PostgreSQL, Redis, the backend, a Prisma migration job, and an nginx-fronted frontend. Services are available at `http://localhost:5173` (frontend) and `http://localhost:3001` (API).

```bash
pnpm run docker:down  # stop the stack
```

## Deploying to Kubernetes

Krabbx ships with a Helm chart under `helm/renovate-dashboard/` that provisions separate backend and frontend deployments, optional PostgreSQL and Redis StatefulSets, Ingress with path-based routing (`/`, `/api`, `/socket.io`), a migration Job, and non-root security contexts. Production values include autoscaling, TLS with cert-manager, network policies, and PodDisruptionBudgets.

```bash
helm install krabbx ./helm/renovate-dashboard \
  --set backend.github.token=your_token \
  --set backend.github.targets="your-org" \
  --set backend.session.secret=your_session_secret
```

## Bottom line

With `pnpm run dev` you get a dashboard that scans your GitHub organization, detects Renovate adoption, tracks every outdated dependency, scores each repository on a 0-100 scale, and updates in real time. Start in memory mode to try it in minutes, then switch to PostgreSQL when you need persistence. For anyone running Renovate across multiple repositories, Krabbx is the centralized view that GitHub doesn't provide.

### A self-hosted CI/CD dashboard for GitHub Actions (English)

- URL: https://lucabertelli.consulting/en/blog/snorlx
- Language: en
- Published: 2025-03-08
- Summary: How to use Snorlx to get centralized visibility and real-time updates across all your repositories
- Tags: github-actions, cicd, devsecops, kubernetes, observability

## Why do we need it?

GitHub Actions is the standard for CI/CD. GitHub shows runs clearly *inside* a single repo, but when an organization has 50, 100 or more repos with dozens of workflows, there's no aggregated view: to see what failed you have to open repo after repo. Teams often resort to scripts or expensive SaaS.

**Bottom line:** no central dashboard, no cost breakdown per workflow/repo (GitHub bills by the minute but only shows monthly totals). Commercial options exist but add cost and vendor lock-in. Snorlx is the self-hosted, open-source answer.

## Finding a solution: Snorlx

[Snorlx](https://github.com/banshee86vr/snorlx) is an open-source, self-hosted CI/CD dashboard for GitHub Actions: it aggregates all runs in one interface, delivers real-time updates via WebSocket, tracks costs per workflow and per repository, and provides **repository scoring** (a per-repo grade on Security, Testing, CI/CD, Documentation, Code Quality, Maintenance, and Community, with gold/silver/bronze tiers).

![Main Snorlx dashboard view: summary cards, trends, and active pipelines](https://lucabertelli.consulting/blog/snorlx/dashboard.webp)
*Main dashboard: summary cards, success/failure trends, and running pipelines.*

## What does the dashboard give you?

The **Dashboard** page shows cards for repositories, workflows, and run stats (success rate, in-progress count, comparison to previous period), charts for the last 30 days, outcome distribution, a live section with running and queued pipelines, and the average repository score and how many repos have been graded.

![Scanning repositories in the GitHub Organization](https://lucabertelli.consulting/blog/snorlx/scanning.webp)

The **Repositories** page lists synced repositories; for each you can see the **repository score** (when computed): an overall percentage and a tier (gold, silver, bronze) based on seven categories: Security, Testing, CI/CD, Documentation, Code Quality, Maintenance and Community derived from GitHub data (branch protection, Dependabot, code scanning, README, config files, community profile, etc.). The score is computed during sync or on demand via "Refresh grade" from the repository detail page; in the detail view you get a radar chart for the seven dimensions and the list of checks (pass/fail).

![Snorlx repositories list](https://lucabertelli.consulting/blog/snorlx/repositories.webp)
![Repository scoring](https://lucabertelli.consulting/blog/snorlx/scoring.webp)

The **Runs** page is a filterable, paginated list of all workflow runs; **Run Detail** shows the full job hierarchy, step status, timelines, error annotations, workflow YAML viewer, and links to logs on GitHub. Data can be force-refreshed from GitHub with `?refresh=true`. Re-run and cancel actions call the GitHub API with proper error handling.

![Search across all organization workflows](https://lucabertelli.consulting/blog/snorlx/workflows.webp)
![List of runs with filters for status, branch, event](https://lucabertelli.consulting/blog/snorlx/runs.webp)
*Run list with filters and pagination; from here you drill into each run.*

![Details and logs for a specific run](https://lucabertelli.consulting/blog/snorlx/run_details.webp)

**Cost tracking** per workflow and per repository lets you spot the most expensive pipelines and model the impact of future pricing changes. Use `STORAGE_MODE=memory` to try everything with no database; switch to `STORAGE_MODE=database` and PostgreSQL with TimescaleDB for production.

## Requirements

- Go 1.21+
- Node.js 20+
- pnpm (recommended) or npm
- A GitHub OAuth App ([create one here](https://github.com/settings/developers))
- PostgreSQL 14+ with TimescaleDB (only for database mode)

## Preparation steps

### 1. Clone the repository and install dependencies

```bash
git clone https://github.com/banshee86vr/snorlx.git
cd snorlx
pnpm install
```

### 2. Create a GitHub OAuth App

Go to [GitHub Developer Settings](https://github.com/settings/developers), click **OAuth Apps** → **New OAuth App**, and fill in:

- **Application name**: `Snorlx Dashboard`
- **Homepage URL**: `http://localhost:5173`
- **Authorization callback URL**: `http://localhost:8080/api/auth/callback`

Copy the **Client ID** and generate a **Client Secret**.

### 3. Configure the environment

```bash
cp env.example .env
```

Edit `.env` with your credentials:

```env
# Development mode
DEV_MODE=true

# Storage Mode: memory for quick start, database for persistence
STORAGE_MODE=memory

# GitHub OAuth
GITHUB_CLIENT_ID=your_oauth_client_id
GITHUB_CLIENT_SECRET=your_oauth_client_secret

# Session Security (generate with: openssl rand -base64 32)
SESSION_SECRET=your_random_32_character_secret_string

# URLs
PORT=8080
FRONTEND_URL=http://localhost:5173
```

### 4. Start the application

```bash
# From project root: starts both frontend and backend concurrently
pnpm run dev
```

The application will start on two ports: the frontend at `http://localhost:5173` and the backend API at `http://localhost:8080`. Log in with GitHub, and the dashboard will begin syncing your repositories, workflows, and runs.

### 5. (Optional) Enable database mode for persistent storage

If you want data to survive restarts, spin up a TimescaleDB instance:

```bash
docker run --name snorlx-postgres \
  -e POSTGRES_DB=snorlx \
  -e POSTGRES_USER=postgres \
  -e POSTGRES_PASSWORD=postgres \
  -p 5432:5432 -d timescale/timescaledb:latest-pg16
```

Then update your `.env`:

```env
STORAGE_MODE=database
DATABASE_URL=postgresql://postgres:postgres@localhost:5432/snorlx?sslmode=disable
```

Restart the application: migrations run automatically on startup.

### 6. (Optional) Enable real-time webhooks

For instant updates without polling, configure a webhook in your GitHub repository or organization settings:

- **Payload URL**: `https://your-domain.com/api/webhooks/github`
- **Content type**: `application/json`
- **Secret**: Generate a secure secret and add it to `.env` as `GITHUB_WEBHOOK_SECRET`
- **Events**: Select `Workflow runs`, `Workflow jobs`, `Deployments`

## Architecture (in short)

Frontend: React 18 + TypeScript with TanStack Query and Recharts. Backend: Go (Chi router) with GitHub OAuth, webhooks, and WebSocket for real-time updates. PostgreSQL with TimescaleDB for time-series, hypertables, and continuous aggregates. Two modes: `STORAGE_MODE=memory` for development or quick start, `STORAGE_MODE=database` for production.

![Three-tier architecture: frontend, backend, database](https://lucabertelli.consulting/blog/snorlx/architecture.webp)
*Three-tier architecture: frontend, backend, database.*

## Deploying to Kubernetes

Snorlx ships with a Helm chart under `helm/snorlx/` that provisions separate backend and frontend deployments, an optional TimescaleDB StatefulSet, secrets, Ingress, and non-root security contexts.

```bash
helm install snorlx ./helm/snorlx \
  --set github.clientId=your_id \
  --set github.clientSecret=your_secret \
  --set session.secret=your_session_secret
```

## Bottom line

With `pnpm run dev` you get a dashboard that aggregates runs from all your repos, tracks costs, scores each repository (gold/silver/bronze), and updates in real time: self-hosted, open-source, under your control. Start in memory mode to try it in minutes, then switch to PostgreSQL when you need persistence. For anyone running GitHub Actions across many repositories, Snorlx is the central view GitHub doesn't provide.

### Ephemeral test environments for CI workflows (English)

- URL: https://lucabertelli.consulting/en/blog/vcluster
- Language: en
- Published: 2024-04-01
- Summary: How to use vCluster and Argo Workflow to manage ephemeral test environments
- Tags: vcluster, argo, cicd, devsecops, kubernetes, multi-tenancy

## Why do we need it?

Since the early 2000s, it was clear that monolithic applications needed to be more scalable to avoid hindering business growth. After a few years, in 2011, during a workshop of software architects near Venice, a new software architectural style was emerging: microservices. The micro-services architecture model can scale to meet business needs by running multiple copies of each service on as many servers as necessary; with separate teams working on each micro-service, productivity and ownership of the code increase, which can be challenging with a monolithic architecture. Therefore, it is essential to implement a micro-services architecture to enable scalability for the application and the team.
But All that glitters is not gold! Are there any drawbacks to adopting this kind of approach? And what happens if we try it in the cloud-native world using Kubernetes environments?
Everyone who has already followed this journey can witness the risk of building a nightmare called *dependency hell*. 

> Dependency hell is a colloquial term for the frustration of some software users who have installed software packages which have dependencies on specific versions of other software packages.
> The dependency issue arises when several packages have dependencies on the same shared packages or libraries, but they depend on different and incompatible versions of the shared packages. If the shared package or library can only be installed in a single version, the user may need to address the problem by obtaining newer or older versions of the dependent packages. This, in turn, may break other dependencies and push the problem to another set of packages.

During the software development lifecycle, one of the goals of every developer team is to develop and test their application using the correct version of dependencies like other application services or DBs.

How can I obtain a temporary environment to perform all these checks safely?

## So, what's the problem?

This kind of gap is a common scenario that usually requires many infrastructure resources to replicate all the dependencies in a separate environment. Preparing it locally on every developer device is typically impossible, and every team cannot quickly request a different Kubernetes cluster to proceed with all the required tests due to increased infrastructure costs. At the same time, performing all these tests on the primary test environment used by all the teams is not recommended to avoid invalidating other tests conducted at the exact moment.

## Finding a solution: vCluster + Argo Workflow

Deeping dive into this use case, one of the possible solutions is to use [vCluster powered by Loft](https://www.vcluster.com). Using this tool, the user can create a temporary Kubernetes cluster inside an existing one. The virtual cluster has separate control plane APIs that can be exposed differently. VCluster is a valid option when multiple tenants must be managed with a single Kubernetes Cluster, sharing the same infrastructure. It's easy to use and adopt by existing Kubernetes users, as it doesn't require installing anything on your existing clusters. New vCluster users need no training, as they can access a standard Kubernetes API Server endpoint. In this experiment, I enjoy integrating this technology with [Argo Workflow](https://argoproj.github.io/workflows), a popular workflow execution engine for Kubernetes. This engine provides a way to efficiently configure the orchestration of the deployment, testing, and teardown processes. The tool lets the final user define processes drawing DAGs (Directed acyclic graph). This feature also supports complex scenarios where there is a requirement to maximize parallelism when running tasks.
This combination offers a fast, cost-effective, and scalable solution, avoiding many of the day-2 activities required for creating and managing a new dedicated cluster every time.
It's typing time!!!

---

## Demo Project

URL: <https://github.com/banshee86vr/ephemeral-test-environment> \
Project structure:

```plaintext
.
├── argo-workflow
│   └── lang
└── hello-world-app
```

* `argo-workflow`: CI/CD pipeline templates folder
* `lang`: ArgoWorkflow Templates folder for supported languages
* `hello-world-app`: Go Hello world application that prints a beautiful octopus 🐙 in ASCII code

## Requirements

- Minikube
- `kubectl` command-line tool installed and configured to connect to your Kubernetes cluster.
- Helm version `3.x` installed.

## Preparation steps

### 1. Start Minikube and install Argo Workflows using Helm

```bash
minikube start
helm repo add argo https://argoproj.github.io/argo-helm
helm install argo-workflows argo/argo-workflows -n argo --create-namespace
```

This command installs Argo Workflows in the `argo` namespace of your Kubernetes cluster.

### 2. Verify the Installation

To check if the installation was successful, you can run:

```bash
kubectl get pods -n argo
```

You should see a list of pods running with names prefixed with `workflow-controller` and `argo-server`.

### 3. Patch argo-server authentication

As reported on the official documentation: <https://argo-workflows.readthedocs.io/en/latest/quick-start/#patch-argo-server-authentication>

The argo-server (and thus the UI) defaults to client authentication, which requires clients to provide their Kubernetes bearer token to authenticate. For more information, refer to the Argo Server Auth Mode documentation. We will switch the authentication mode to `server` so that we can bypass the UI login for now:

```bash
kubectl patch deployment \
  argo-server \
  --namespace argo \
  --type='json' \
  -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/args", "value": [
  "server",
  "--auth-mode=server"
]}]'
```

### 4. Access Argo Workflows UI (Optional)

Argo Workflows provides a web-based UI for managing and monitoring workflows. To access the UI, you need to expose it as a service:

```bash
kubectl port-forward svc/argo-server -n argo 2746:2746
```

Now, you can access the Argo Workflows UI by navigating to `http://localhost:2746` in your web browser.

### 5. Add privileges to Argo service accounts

> Add these privileges to the Argo service accounts are recommended only for demo purposes. **IT'S STRONGLY NOT RECOMMENDED TO REPLICATE THIS CONFIGURATION IN PRODUCTION ENVIRONMENTS.**

This command adds `cluster-admin` clusterrole to `argo:argo-server` and `argo:default`. In this way, Argo Workflow can manage every kind of resource in every namespace of the cluster.

```bash
kubectl create clusterrolebinding argo-admin-server --clusterrole=cluster-admin --serviceaccount=argo:argo-server -n argo
kubectl create clusterrolebinding argo-admin-default --clusterrole=cluster-admin --serviceaccount=argo:default -n argo
```

> In production environments, creating a dedicated role for these service accounts is strongly recommended, allowing only required verbs on the resources managed by the workflows.

### 6. Prepare secrets required by the pipelines

Just in case of a private Git repository, you can run this command to allow the clone command executed by the pipeline `ci.yaml`:

```bash
kubectl create secret generic github-token -n argo --from-literal=token=.........
```

This command creates the secret that contains the credentials to push the Docker image to the registry:

```bash
export DOCKER_USERNAME=******
export DOCKER_TOKEN=******
kubectl create secret generic docker-config --from-literal="config.json={\"auths\": {\"https://ghcr.io/\": {\"auth\": \"$(echo -n $DOCKER_USERNAME:$DOCKER_TOKEN|base64)\"}}}"
```

### 7. Add Argo WorkflowTemplate manifests

```bash
git clone https://github.com/banshee86vr/ephemeral-test-environment.git
cd argo/workflow

kubectl apply -f ci.yaml
kubectl apply -f lang/go.yaml
kubectl apply -f cd.yaml
```

## Execution steps

With all prerequisites met and Argo Workflows successfully deployed and configured, you dive into the execution steps to start creating and managing workflows.

### 8. Submit the CI pipeline

The CI pipeline performs these steps inside the [ci.yaml](https://github.com/banshee86vr/ephemeral-test-environment/blob/main/argo-workflow/ci.yaml) manifest:

1. **Cloning Repository**: Fetches the source code from the git repository.
2. **Building Application**: Utilizes the GoLang template [go.yaml](https://github.com/banshee86vr/ephemeral-test-environment/blob/main/argo-workflow/lang/go.yaml) to compile the Go application.
3. **Building and Pushing Docker Image**: Packages the application into a Docker image and pushes it to the registry.

![CI Argo Workflow Flowchart](https://lucabertelli.consulting/blog/vcluster/ci_flowchart.webp)

To submit the CI pipeline, you can use the [official APIs](https://argo-workflows.readthedocs.io/en/latest/rest-api/):

```plaintext
<ArgoWorkflow URL>/api/v1/workflows/{namespace}/submit
```

Alternatively, you can submit the workflow using the UI:

![Submit CI workflow via UI](https://lucabertelli.consulting/blog/vcluster/ci_submit.webp)

After the completion of all steps, you can check the correct status of every step and locate the updated Docker image in your registry:

![CI workflow graph](https://lucabertelli.consulting/blog/vcluster/ci_graph.webp)

### 9. Submit the CD pipeline

The CD pipeline performs these steps inside the [cd.yaml](https://github.com/banshee86vr/ephemeral-test-environment/blob/main/argo-workflow/cd.yaml) manifest:

1. **Preparing an ephemeral environment**: Prepares a temporary environment using vCluster where the user can test the application inside an isolated Kubernetes cluster.
2. **Deploy the application**: Deploy the application Helm chart on the vCluster just created.

![CD Argo Workflow Flowchart](https://lucabertelli.consulting/blog/vcluster/cd_flowchart.webp)

To submit the CD pipeline, you can use the [official APIs](https://argo-workflows.readthedocs.io/en/latest/rest-api/):

```plaintext
<ArgoWorkflow URL>/api/v1/workflows/{namespace}/submit
```

Alternatively, you can submit the workflow using the UI:

![Submit CD workflow via UI](https://lucabertelli.consulting/blog/vcluster/cd_submit.webp)

After the completion of all steps, you can check the correct status of every step:

![CD workflow graph](https://lucabertelli.consulting/blog/vcluster/cd_graph.webp)

### 10. Access to the application

To check how to access the application deployed on vCluster, you can run these commands to list all vCluster and to access it:

```bash
$ vcluster list
  
         NAME       | CLUSTER  |    NAMESPACE    | STATUS  | VERSION | CONNECTED |            CREATED            |   AGE   | DISTRO  
  ------------------+----------+-----------------+---------+---------+-----------+-------------------------------+---------+---------
    demo-pr-request | minikube | demo-pr-request | Running | 0.19.0  |           | xxxx-xx-xx xx:xx:xx +0100 CET | 1h8m49s | OSS

$ vcluster connect demo-pr-request --namespace demo-pr-request -- kubectl get pod -n demo-pr-request

NAME                                           READY   STATUS    RESTARTS   AGE
demo-pr-request-hello-world-7f6d78645f-bjmjc   1/1     Running   0          7s
```

As reported [here](https://www.vcluster.com/docs/using-vclusters/access), you can expose the ephemeral vCluster created differently.

- **Via Ingress**: An Ingress Controller with SSL passthrough support will provide the best user experience. Ensure your ingress controller is installed and healthy on the cluster hosting your virtual clusters. More details [here](https://www.vcluster.com/docs/using-vclusters/access#via-ingress)
- **Via LoadBalancer service**: The easiest way is to use the flag `--expose` in the vcluster create phase to tell vCluster to use a LoadBalancer service. It depends on the specific implementation of the host Kubernetes cluster.
- **Via NodePort service**: You can also expose the vCluster via a NodePort service. In this case, you must create a NodePort service and change the `values.yaml` file to use for the creation of the vCluster. More details [here](https://www.vcluster.com/docs/using-vclusters/access#via-nodeport-service)
- **From Host Cluster**: To access the virtual cluster from within the host cluster, you can directly connect to the vCluster service. Make sure you can access that service and then create a kube config in the following form:
  
  ```bash
  vcluster connect my-vcluster -n my-vcluster --server=my-vcluster.my-vcluster --insecure --update-current=false
  ```

## How have we filled the gap?

The demo project has demonstrated how easily it can be to integrate CI workflow using the Argo workflow engine by deploying an application in a temporary and isolated environment based on vCluster  that includes all the dependencies. Furthermore, it's essential to evaluate the possibility of customizing the initialization of the vCluster, applying `.yaml` manifests or helm charts. Typically, every microservice can have dependencies already packaged with another Helm chart or available with a `.yaml` manifest. With vCluster, the developer team can choose the chart version to init the vCluster to test the application.

## How can we manage the lifecycle of this ephemeral vCluster?

During the demo project, we saw how to create a dynamically dedicated cluster on demand. But now we have to think about its management:
* How can I optimize the resources utilized by the vCluster?
* When can I delete the vCluster automatically?
* Can I automate everything, avoiding any manual operations?
* How can I prevent the proliferation of vClusters?

Loft guys help us to satisfy all these tricky topics. The OSS version is not enough to cover all of it, but let's go step-by-step:
* *Quotas and limits* (available with OSS version): A Kubernetes standard `ResourceQuota` manifest applied in the namespace where the virtual cluster is running prevents the vCluster from consuming excessive resources in the host cluster.
* *Automated creation and deletion*: These operations can be triggered using Argo Events. This event-driven workflow automation framework allows linking an event to the webhooks provided by the SCM tool, for example, about the change of the state of a pull request.
* *Optimization of vCluster resources usage*: about this topic, Loft provides a feature to monitor and manage the inactivity and avoid any waste of resources. The enterprise version of the tool (vCluster.PRO) offers two valuable functionalities that can help minimize Kubernetes expenses. Firstly, the `Sleep Mode` feature enables virtual clusters to go to sleep mode when they are not being used, which means that all the pods are removed, but the resources are retained within the virtual clusters during the inactive period. Secondly, the `Auto-Delete` feature automatically deletes virtual clusters that have been idle for a specific period. Suppose it's not possible to adopt vCluster.PRO, there is a workaround using CronJob and the vCluster CLI Docker image scheduling the start and the sleep/resume of the cluster following the cron scheduling format.

## What do we bring at home?

By integrating Argo Workflow with vCluster, we have implemented a fast and scalable solution, enabling each development team to test their applications independently in a secure and isolated environment. The possibility to customize the initialization of the vCluster permits the addition of any dependency needed, elevating the test quality performed on the deployed application.

The same architecture can also be event-driven by adding ArgoEvents, linking events to webhooks of the SCM tools, and making it a cost-effective solution.

### A caccia di fossili nella tua fleet di cluster K8s (Italian)

- URL: https://lucabertelli.consulting/it/blog/omastx
- Language: it
- Published: 2026-07-26
- Summary: Come usare Omastx per scovare immagini e chart Helm obsoleti, e collegarlo agli agent AI via MCP
- Tags: kubernetes, helm, drift, observability, devsecops, fleet-management, mcp

## Perché mai dovremmo averne bisogno?

Gestire un singolo cluster Kubernetes significa già gestire immagini container e release Helm. Gestire una *fleet* moltiplica il problema: ogni namespace porta con sè i propri workload e le proprie chart con le relative versioni, e il dubbio "siamo aggiornati?" diventa una domanda a cui si risponde aprendo dashboard, UI dei registry ed eseguendo comandi `helm list` un cluster alla volta.

I team di platform questo peso lo sentono per primi. La security chiede quali cluster usano ancora un tag Redis deprecato. Il prodotto chiede se i cluster `prod-eu` e `prod-us` sono allineati. Sai che *qualcosa* è indietro, ma non esiste un unico posto che risponda: *Quanto è aggiornata/obsoleta la mia fleet?*

Esistono tool commerciali per la fleet, ma spesso richiedono permessi in scrittura, installano agent su ogni cluster, oppure nascondono i gap di versione dentro un prodotto ops più ampio. Gli script fatti in casa scansionano i registry e producono CSV già obsoleti a pranzo.

**In sintesi:** nessuna vista in sola lettura che confronti continuamente ciò che è *in esecuzione* con ciò che è *latest* upstream, tra immagini e chart Helm, con un grafico navigabile invece di un foglio di calcolo.

## Una possibile soluzione: Omastx

[Omastx](https://github.com/banshee86vr/omastx) è un portale web open-source che scansiona i cluster Kubernetes, scopre immagini container e release Helm, risolve le ultime versioni upstream e mostra il gap come classi di drift navigabili: Current, Patch, Minor, Major, Deprecated e Unknown. È in sola lettura by design: anche se colleghi un kubeconfig da amministratore, Omastx usa solo chiamate di lettura alle API Kubernetes (`get`/`list` su workload e, per le release Helm, sui secrets): mai create, update, delete o altri comandi invasivi. Accanto alla UI, una API Bearer con scope e un thin server [MCP](https://modelcontextprotocol.io/) permettono a script e agent AI (Cursor, Claude e simili) di interrogare la fleet e avviare scan senza accesso in scrittura ai cluster.

![Vista Fleet: 50% dei workload aggiornati, barre di drift per cluster e rail di stato](https://lucabertelli.consulting/blog/omastx/fleet.webp)
*Pagina Fleet: percentuale di workload aggiornati in evidenza, barre di drift aggregate per cluster e rail con failure, ultime scan e stato di connessione.*

## Cosa ci offre la dashboard?

La pagina **Fleet** si apre con un unico numero: la quota di workload aggiornati per tutti i cluster connessi. Sotto, ogni cluster è una lane orizzontale di segmenti che riportano tutti i drift. Un click su un segmento apre il ledger degli artifact già filtrato per quel cluster e quella classe di drift. Il rail di destra evidenzia cosa richiede attenzione (cluster degraded, scan fallite), lo storico recente delle scan e lo stato delle connessioni.

Aprendo un cluster viene proposto lo stesso tipo di grafico ma applicato alle **lane per namespace**. Si vedono schedule, API server, ultima scan, un breakdown del drift, un breve trend e il mix tra immagini e chart Helm. Le scan recenti sono cliccabili: ogni link "View artifacts" apre il ledger limitato a quel cluster.

![Dettaglio cluster prod-eu: lane di drift per namespace, breakdown e scan recenti](https://lucabertelli.consulting/blog/omastx/cluster_drift.webp)
*Dettaglio cluster: barre di drift a livello di namespace, card analitiche e storico scan con salto diretto al ledger.*

Non tutti i cluster concedono lo stesso RBAC. Se manca l'accesso ai secrets, Omastx resta utile in modalità **images-only**: in questo caso la discovery Helm viene saltata, il cluster è marcato DEGRADED e compare un banner chiaro sul permesso da aggiungere. Il drift Unknown, invece,  compare quando un registry non è risolvibile (ad esempio un host privato senza credenziali).

![Cluster degraded prod-us: modalità images-only con drift unknown](https://lucabertelli.consulting/blog/omastx/cluster_degraded.webp)
*Cluster degraded: accesso Helm assente, immagini comunque scansionate, segmento Unknown quando un registry non è risolvibile.*

Il ledger **Artifacts** è la lista globale e filtrabile di ogni immagine e chart scoperti, ordinata per quanto è driftata. Si filtra per cluster, kind (image o chart), classe di drift e namespace; si cerca per nome. Ogni riga mostra installed → latest e un badge di drift.

Dalla stessa tabella è possibile esportare il risultato filtrato in formato CSV oppure PDF. I filtri attivi valgono per entrambi i formati: ciò che vedi in tabella è ciò che esce nel file.

![Ledger degli artifact sulla fleet](https://lucabertelli.consulting/blog/omastx/artifacts.webp)
*Pagina Artifacts: ledger con filtri e pulsanti Export CSV / Export PDF.*

Un click sulla singola riga apre il **foglio di dettaglio** dell'artifact: identity, URL del registry o del chart repo, confidence del match Helm, release di ritardo, sparkline dello storico e versioni candidate quando il canale del tag consente il confronto.

![Ledger filtrato e dettaglio artifact per il major drift di ingress-nginx](https://lucabertelli.consulting/blog/omastx/artifact_detail.webp)
*Drill-down: filtro sul major drift in un namespace, poi apertura del foglio con installed → latest, confidence e metadati.*

![Ledger filtrato su prod-eu / platform / major](https://lucabertelli.consulting/blog/omastx/artifacts_filtered.webp)
*Lo stesso ledger dopo aver ristretto a un cluster, un namespace e solo major drift.*

**Connect a cluster** permette tramite un flusso guidato di trascinare o incollare un kubeconfig, scegliendo i context per poi impostare nome e schedule cron per pianificare le scansioni.

![Onboarding Connect cluster con drop zone del kubeconfig](https://lucabertelli.consulting/blog/omastx/connect.webp)
*Flusso Connect: drop o paste di un kubeconfig in sola lettura; Omastx verifica i permessi prima di salvare.*

Le credenziali per i registry privati si possono associare, ad esempio, quando il drift viene classificato come Unknown e l'artefatto punta ad un host che richiede autenticazione.

## API machine e MCP

Oltre alla UI, Omastx espone un'API Bearer con scope per script e agent AI. Le azioni admin (connessione cluster, credenziali registry) restano solo in sessione browser. L'OpenAPI è su `/api/openapi.yaml` (anche in `docs/openapi.yaml` nel repository).

### 1. Creare un API token

1. Accedere e aprire **Settings → API tokens**.
2. Dare un nome al token e abilitare gli scope `read` (fleet, artifact, scan) e/o `scan` (avvio scan).
3. Cliccare **Create token** e copiare subito il valore (`omx_…`): non viene più mostrato.

Smoke-test del token con curl (URL Compose; in native dev usare `http://localhost:5173` o `:8484`):

```bash
export OMASTX_URL=http://localhost:8080
export OMASTX_API_TOKEN=omx_…

curl -sS -H "Authorization: Bearer $OMASTX_API_TOKEN" \
  "$OMASTX_URL/api/fleet/summary" | jq .
```

### 2. Build del server MCP

Il thin wrapper è in `mcp/` e chiama la stessa API REST (niente logica duplicata, niente kubeconfig o secret di registry):

```bash
cd mcp
npm install
npm run build
```

Si ottiene `mcp/dist/index.js`. Serve Node 20+ e due variabili d'ambiente: `OMASTX_URL` (root del sito, senza `/api`) e `OMASTX_API_TOKEN`.

### 3. Configurare Cursor (o un altro host MCP)

Per integrare l'host MCP aggiungere una voce alla config MCP (Cursor: `mcp.json` di progetto o utente). Usare il path **assoluto** di `dist/index.js`:

```json
{
  "mcpServers": {
    "omastx": {
      "command": "node",
      "args": ["/absolute/path/to/omastx/mcp/dist/index.js"],
      "env": {
        "OMASTX_URL": "http://localhost:8080",
        "OMASTX_API_TOKEN": "omx_…"
      }
    }
  }
}
```

Ricaricare i server MCP nell'host. Tool disponibili: `fleet_summary`, `list_clusters`, `get_cluster`, `list_artifacts`, `get_artifact`, `artifact_history`, `start_scan`, `list_scans`, `export_artifacts`.

### 4. Testare il layer MCP

Con Omastx in esecuzione e almeno un cluster connesso, chiedere all'agent (o invocare i tool) in questo ordine:

1. **`fleet_summary`** poi **`list_clusters`** - verificare che il cluster compaia con lo stato atteso.
2. **`list_artifacts`** con l'id del cluster - attendersi una pagina di immagini/chart con classi di drift.
3. **`start_scan`** sull'id del cluster, poi **`list_scans`** fino a `done` o `error` (gli agent fanno poll; la UI può anche seguire l'SSE).
4. Opzionale: **`export_artifacts`** con `format=csv` per l'export testuale del ledger filtrato.

Esempi di prompt: "Riassumi il drift della fleet", "Elenca gli artifact in major drift sul cluster X", "Avvia una scan sul cluster X e dimmi quando finisce".

Se un tool risponde `401`, ricreare il token. `403` / `insufficient_scope` indica scope `read` o `scan` mancante. Le route admin non sono disponibili via MCP, di proposito.

## Requisiti

- Docker + Compose (via più rapida), **oppure** Go 1.26+ e Node 20+ per lo sviluppo nativo
- PostgreSQL (incluso in Compose; esterno nelle installazioni Helm tipiche)
- Un kubeconfig in sola lettura per cluster (get/list sui workload; secrets per la discovery delle release Helm)
- In produzione: una [GitHub OAuth App](https://github.com/settings/developers) e membership nella GitHub org configurata (o il proprio username per un'installazione personale)

## Step di preparazione

### 1. Clone del repository

```bash
git clone https://github.com/banshee86vr/omastx.git
cd omastx
```

### 2. Avvio locale con Docker Compose

```bash
make dev   # oppure: docker compose -f deploy/docker-compose.yml up --build
```

Aprire http://localhost:8080. In questa modalità si è autenticati automaticamente (nessuna credenziale o file `.env` richiesto).

### 3. (Opzionale) Sviluppo nativo con hot reload

Per il lavoro quotidiano, Postgres in Docker e API + Vite sull'host:

```bash
make dev-local
```

Aprire http://localhost:5173. Vite fa proxy di `/api` sul backend in `:8484` e autentica automaticamente.

### 4. Connettere un cluster ed eseguire una scan

Nella UI, aprire **+ Connect cluster**, trascinare un kubeconfig in sola lettura, selezionare i context da importare, confermare il check dei permessi e impostare lo schedule di scan. Cliccare **Scan now** sulla pagina del cluster (o attendere il cron). A scan terminata, headline e lane di drift sulla Fleet si aggiornano; aprire **Artifacts** per percorrere il ledger.

### 5. (Opzionale) Seed dei dati demo

Per esplorare la UI senza una fleet reale, il repository include un percorso di seed usato per gli screenshot di questo articolo (`make seed` / lo script di capture sotto `docs/screenshots/article/`).

## Architettura (in breve)

![Architettura Omastx: SPA React e client MCP/Bearer, API Go, PostgreSQL, cluster Kubernetes in sola lettura e sorgenti upstream](https://lucabertelli.consulting/blog/omastx/architecture.webp)
*SPA React (sessione + CSRF) e agent AI/MCP (Bearer read/scan), backend Go con OpenAPI, orchestratore di scan e provider/resolver pluggable, PostgreSQL (inclusi API token), discovery read-only sui cluster e resolve delle versioni da registry OCI, repo Helm e Artifact Hub.*

## Docker Compose

Lo stack Compose in `deploy/docker-compose.yml` esegue la fase di build e avvia Postgres, l'API Go e il frontend con nginx. Le immagini di release sono pubblicate su GitHub Container Registry: `ghcr.io/banshee86vr/omastx-backend` e `ghcr.io/banshee86vr/omastx-frontend`.

```bash
make dev          # build e avvio
# aprire http://localhost:8080
```

## Deploy su Kubernetes

Omastx include un Helm chart in `deploy/chart/omastx`. Si crea un Secret con master key, credenziali GitHub OAuth, gate dell'org, base URL e database URL, poi si installa con `existingSecret` (i values non templano mai i secret inline).

Registrare una GitHub OAuth App con callback `${OMASTX_BASE_URL}/api/auth/github/callback`. Solo i membri di `OMASTX_GITHUB_ORG` possono accedere.

```bash
kubectl create secret generic omastx \
  --from-literal=OMASTX_MASTER_KEY=$(openssl rand -hex 32) \
  --from-literal=OMASTX_GITHUB_CLIENT_ID=... \
  --from-literal=OMASTX_GITHUB_CLIENT_SECRET=... \
  --from-literal=OMASTX_GITHUB_ORG=your-org \
  --from-literal=OMASTX_BASE_URL=https://omastx.example.com \
  --from-literal=DATABASE_URL=postgres://user:pass@host:5432/omastx

helm install omastx deploy/chart/omastx --set existingSecret=omastx
```

Per un'installazione di prova con Postgres incluso:

```bash
helm install omastx deploy/chart/omastx \
  --set existingSecret=omastx --set postgres.internal.enabled=true
```

Il chart esegue container non-root con security context hardening; il prodotto non richiede mai permessi di scrittura Kubernetes sui cluster che monitora.

## In sintesi

Con `make dev` hai un portale che risponde a una sola domanda per l'intera fleet: quanti fossili troveremo sui nostri cluster? Colleghi kubeconfig in sola lettura, scansiona periodicamente, verifichi la tipologia di drift sul grafico e scendi nel dettaglio di ogni immagine e chart Helm nel ledger, oppure chiedi lo stesso a un agent AI via MCP. Open-source e nessun percorso di scrittura sui tuoi cluster. Per chi gestisce più di un ambiente Kubernetes, Omastx è la vista sul drift che `kubectl` e `helm list` non aggregano mai.

### Una dashboard self-hosted per Renovate Bot (Italian)

- URL: https://lucabertelli.consulting/it/blog/krabbx
- Language: it
- Published: 2025-05-01
- Summary: Come usare Krabbx per monitorare le versioni delle dipendenze e le PR di aggiornamento aperte nella tua organizzazione GitHub
- Tags: renovate, dependency-management, devsecops, kubernetes, observability

## Perché mai dovremmo averne bisogno?

Ogni progetto moderno dipende da decine di librerie, e tenerle aggiornate è una questione di sicurezza e stabilità. [Renovate Bot](https://docs.renovatebot.com/) automatizza questo processo aprendo PR quando sono disponibili nuove versioni. GitHub offre il proprio Dependabot, ma Renovate supporta una gamma più ampia di package manager, permette di raggruppare gli aggiornamenti in una singola PR, offre regole di automerge granulari e funziona in modo identico su qualsiasi piattaforma Git, non solo GitHub. Renovate si integra inoltre in modo naturale con i workflow assistiti da AI: i custom manager e i post-upgrade command permettono di collegare strumenti AI per correggere automaticamente le breaking change o generare codice di migrazione, mentre il Copilot Autofix di Dependabot è limitato alle patch di sicurezza. Una volta adottato Renovate su un'intera organizzazione, però, emergono nuove domande: *Quali repository usano davvero Renovate? Quante PR di aggiornamento si stanno accumulando? Quali sono le dipendenze più obsolete e trascurate?*

GitHub non offre alcuna vista aggregata dell'attività sulle PR. Bisogna aprire ogni repository, verificare se esiste un file di configurazione, scorrere le PR aperte e ricostruire mentalmente lo stato delle diverse dipendenze. Con 10 repo è tedioso; con 50+ è ingestibile.

**In sintesi:** nessuna dashboard centralizzata per l'adozione di Renovate, nessuna vista cross-repo sulle dipendenze, nessun punteggio di salute che indichi a colpo d'occhio dove si accumula il debito tecnico.

## Una possibile soluzione: Krabbx

[Krabbx](https://github.com/banshee86vr/krabbx) è una dashboard open-source e self-hosted che monitora l'adozione di Renovate Bot e l'attività di aggiornamento delle dipendenze nelle organizzazioni GitHub. Scansiona i repository tramite le API GitHub, rileva se Renovate è configurato (file di configurazione, workflow YAML o evidenze nelle PR), analizza le PR aperte di Renovate per estrarre i dati sulle dipendenze e presenta tutto in un'unica interfaccia con aggiornamenti in tempo reale.

![Vista principale della dashboard Krabbx: card riepilogative, classifica di salute e badge](https://lucabertelli.consulting/blog/krabbx/dashboard.webp)
*Vista principale della dashboard: repository totali, tasso di adozione, dipendenze obsolete, classifica di salute e badge.*

## Cosa ci offre la dashboard?

La pagina **Dashboard** mostra tre card riepilogative in alto: repository totali, tasso di adozione di Renovate e dipendenze obsolete totali con il numero di PR aperte. Sotto, una sezione **Health & achievements** visualizza il trend delle dipendenze obsolete dell'organizzazione in una finestra di 14 giorni.

La **Health leaderboard** classifica i repository con un punteggio di salute da 0 a 100 basato su tre assi: freshness (rapporto di dipendenze obsolete), major discipline (penalità per drift su versioni major) e PR remediation (bonus per PR Renovate attive). I **Badge** evidenziano traguardi come "Zero Major Drift" per i repo senza pacchetti obsoleti su versioni major.

![Repository più obsoleti e le dipendenze più obsolete](https://lucabertelli.consulting/blog/krabbx/dashboard_cards.webp)
*Card inferiori: repository più obsoleti e le dipendenze più obsolete con utilizzo cross-repo.*

Tre card aggiuntive mostrano i **repository più obsoleti** e le **dipendenze più obsolete** (con link alle PR di Renovate in ogni repo che le utilizza).

La pagina **Repositories** elenca tutti i repository sincronizzati con lo stato di adozione ("Adopted" o "Not adopted"), il punteggio di salute, il conteggio delle PR aperte, il numero di dipendenze, l'ultima scansione e i contributori.

![Lista repository con stato di adozione, punteggio di salute e PR aperte](https://lucabertelli.consulting/blog/krabbx/repositories.webp)
*Lista repository: filtra per stato di adozione, ordina per punteggio di salute e accedi al dettaglio di ogni repo.*

Da qui si può accedere alla pagina **Repository Detail**. Questa vista mostra il punteggio di salute delle dipendenze con un grafico radar per i tre assi di scoring, il dettaglio di come viene calcolato il punteggio, il ranking nell'organizzazione e una tabella di tutte le PR Renovate aperte con nome del pacchetto, versione corrente, ultima versione e tipo di aggiornamento (patch, minor, major).

![Dettaglio repository: radar del punteggio di salute, calcolo dello score e PR Renovate aperte](https://lucabertelli.consulting/blog/krabbx/repository_details.webp)
*Dettaglio repository: punteggio di salute con calcolo trasparente, grafico radar e lista delle PR Renovate aperte.*

La pagina **Dependencies** è una vista globale e filtrabile di tutte le dipendenze tracciate nell'organizzazione. Si può filtrare per sole dipendenze obsolete, cercare per nome del pacchetto e filtrare per tipo di aggiornamento. Ogni riga mostra il repository, il tipo di package manager, la versione corrente e l'ultima disponibile, e un link diretto alla PR Renovate su GitHub.

![Vista globale delle dipendenze con ricerca, filtri e link alle PR](https://lucabertelli.consulting/blog/krabbx/dependencies.webp)
*Pagina Dependencies: ricerca tra tutte le dipendenze dell'organizzazione, filtri per stato di obsolescenza e tipo di aggiornamento.*

La **scansione live** avviene in background con avanzamento in tempo reale. Un overlay modale mostra lo stato della scansione in corso (es. "4 of 7 repositories") con una barra di avanzamento, così si sa sempre a che punto è la scansione.

![Modale di scansione live con barra di avanzamento](https://lucabertelli.consulting/blog/krabbx/scanning.webp)

## Requisiti

- Node.js 24+
- pnpm
- Un GitHub Personal Access Token con scope `repo` ([creane uno qui](https://github.com/settings/tokens))
- (Opzionale) PostgreSQL per lo storage persistente
- (Opzionale) Redis per la gestione delle sessioni e lo scaling di Socket.IO

## Step di preparazione

### 1. Clone del repository e installazione delle dipendenze

```bash
git clone https://github.com/banshee86vr/krabbx.git
cd krabbx
pnpm install
```

### 2. Configurazione dell'ambiente

```bash
cp .env.example .env
```

Modificare il file `.env` con le proprie impostazioni:

```env
# Scanner GitHub
GITHUB_TOKEN=ghp_your_personal_access_token
GITHUB_TARGETS=your-org,your-username

# Auth (disabilitare per demo locale)
AUTH_ENABLED=false
ALLOW_INSECURE_NOAUTH=true

# Storage: memory per quick start, database per persistenza
STORAGE_MODE=memory

# Sessione
SESSION_SECRET=your_random_32_character_secret_string
```

`GITHUB_TARGETS` accetta una lista separata da virgole di nomi di organizzazioni o utenti GitHub. Tutti i repository sotto quei proprietari verranno scansionati.

### 3. Avvio dell'applicazione

```bash
pnpm run dev
```

Il frontend si avvia su `http://localhost:5173` e l'API backend su `http://localhost:3001`. Cliccare **Scan** nella barra superiore e la dashboard inizierà a scansionare i repository, rilevare le configurazioni Renovate e analizzare le PR aperte.

### 4. (Opzionale) Abilitare la modalità database per storage persistente

Per mantenere i dati tra un riavvio e l'altro, avviare un'istanza PostgreSQL:

```bash
docker run --name krabbx-postgres \
  -e POSTGRES_DB=krabbx \
  -e POSTGRES_USER=postgres \
  -e POSTGRES_PASSWORD=postgres \
  -p 5432:5432 -d postgres:18
```

Aggiornare il file `.env`:

```env
STORAGE_MODE=database
DATABASE_URL=postgresql://postgres:postgres@localhost:5432/krabbx?sslmode=disable
```

Eseguire le migrazioni Prisma e riavviare:

```bash
pnpm run db:generate
pnpm run db:migrate
pnpm run dev
```

### 5. (Opzionale) Abilitare GitHub OAuth per l'accesso multi-utente

Per ambienti team, creare una GitHub OAuth App nelle [GitHub Developer Settings](https://github.com/settings/developers):

- **Application name**: `Krabbx Dashboard`
- **Homepage URL**: `http://localhost:5173`
- **Authorization callback URL**: `http://localhost:3001/api/auth/callback`

Aggiornare il file `.env`:

```env
AUTH_ENABLED=true
ALLOW_INSECURE_NOAUTH=false
GITHUB_AUTH_CLIENT_ID=your_oauth_client_id
GITHUB_AUTH_CLIENT_SECRET=your_oauth_client_secret
```

Si può opzionalmente restringere l'accesso a uno specifico team GitHub con `GITHUB_AUTH_TEAM_SLUG`.

## Architettura (in breve)

Frontend React 19 + TypeScript con Vite, Tailwind, TanStack Query e Recharts; backend Node.js con Express 5 e TypeScript, Prisma ORM e Socket.IO per gli aggiornamenti in tempo reale. Lo storage ha due modalità: `STORAGE_MODE=memory` per lo sviluppo (Map in-process, zero configurazione), `STORAGE_MODE=database` per la produzione con PostgreSQL. Le sessioni e Socket.IO possono scalare opzionalmente via Redis.

Il motore di scansione utilizza le API GitHub (Octokit) per rilevare l'adozione di Renovate attraverso tre opzioni: presenza di file di configurazione (`renovate.json`, `.renovaterc`, ecc.), marker nei workflow YAML (Renovate GitHub Action, azioni Mend, immagini Docker), ed evidenze nelle PR (PR aperte o chiuse di recente dal bot Renovate). I dati sulle dipendenze vengono estratti analizzando titoli e body delle PR di Renovate.

## Docker Compose

Il modo più rapido per eseguire l'intero stack in modalità produzione:

```bash
cp .env.example .env
# modificare .env con il proprio token GitHub e i target
pnpm run docker:up
```

Questo avvia PostgreSQL, Redis, il backend, un job di migrazione Prisma e un frontend con nginx. I servizi sono disponibili su `http://localhost:5173` (frontend) e `http://localhost:3001` (API).

```bash
pnpm run docker:down  # fermare lo stack
```

## Deploy su Kubernetes

Krabbx include un Helm chart in `helm/renovate-dashboard/` che effettua il provisioning di deployment separati per backend e frontend, StatefulSet opzionali per PostgreSQL e Redis, Ingress con routing basato su path (`/`, `/api`, `/socket.io`), un Job di migrazione e security context non-root. I valori di produzione includono autoscaling, TLS con cert-manager, network policy e PodDisruptionBudget.

```bash
helm install krabbx ./helm/renovate-dashboard \
  --set backend.github.token=your_token \
  --set backend.github.targets="your-org" \
  --set backend.session.secret=your_session_secret
```

## In sintesi

Con `pnpm run dev` hai una dashboard che scansiona la tua organizzazione GitHub, rileva l'adozione di Renovate, traccia ogni dipendenza obsoleta, assegna a ogni repository un punteggio da 0 a 100 e aggiorna in tempo reale. Parti in modalità memory per provarla in pochi minuti, poi passi a PostgreSQL quando serve persistenza. Per chi usa Renovate su più repository, Krabbx è la vista centralizzata che GitHub non fornisce.

### Una dashboard self-hosted per le GitHub Actions (Italian)

- URL: https://lucabertelli.consulting/it/blog/snorlx
- Language: it
- Published: 2025-03-08
- Summary: Come usare Snorlx per ottenere visibilità centralizzata e aggiornamenti in tempo reale su tutti i repository
- Tags: github-actions, cicd, devsecops, kubernetes, observability

## Perché mai dovremmo averne bisogno?

Le GitHub Actions sono lo standard per l'automazione CI/CD. GitHub mostra bene le run *dentro* un singolo repository, ma quando un'organizzazione ha 50, 100 o più repo con decine di workflow, non c'è alcuna vista aggregata: per capire cosa è fallito bisogna aprire repo per repo. Di conseguenza i team spessono devono arrangiarsi con script custom o prodotti SaaS costosi.

**In sintesi:** nessuna vista centralizzata e nessuna ripartizione dei costi per workflow/repository (GitHub fattura al minuto ma mostra solo totali mensili). Le soluzioni commerciali esistono ma con costi non trascurabili e portano inveitabilmenet vendor lock-in. 

## Una possibile soluzione: Snorlx

[Snorlx](https://github.com/banshee86vr/snorlx) è una dashboard CI/CD open-source e self-hosted per le GitHub Actions: aggrega tutte le run in un'unica interfaccia, fornisce aggiornamenti in tempo reale via WebSocket, tracking costi per workflow e repository, e il **repository scoring** (punteggio per repo su Security, Testing, CI/CD, Documentation, Code Quality, Maintenance, Community con tier gold/silver/bronze).

![Vista principale della dashboard Snorlx: card riepilogative, trend e pipeline attive](https://lucabertelli.consulting/blog/snorlx/dashboard.webp)
*Vista principale della dashboard: card riepilogative, trend successo/fallimento e pipeline in esecuzione.*

## Cosa ci offre la dashboard?

La pagina **Dashboard** mostra card per repository, workflow e statistiche run (tasso di successo, run in corso, confronti con il periodo precedente), grafici per i trend degli ultimi 30 giorni, distribuzione risultati, una sezione live con pipeline in esecuzione e in coda, e la media del punteggio dei repository e il numero di repo "graded".

![Scanning dei reposity all'interno della GitHub Organization](https://lucabertelli.consulting/blog/snorlx/scanning.webp)

La pagina **Repositories** elenca i repository sincronizzati; per ognuno puoi vedere il **repository score** (se calcolato): un punteggio complessivo in percentuale e un tier (gold, silver, bronze) basato su sette categorie: Security, Testing, CI/CD, Documentation, Code Quality, Maintenance e Community ricavate dai dati GitHub (branch protection, Dependabot, code scanning, README, file di config, community profile, ecc.). Lo score viene calcolato durante la sync o on-demand con "Refresh grade" dalla pagina di dettaglio del repository; nel dettaglio trovi il grafico a radar per le sette dimensioni e l'elenco dei check pass/fail.

![Sonrlx dashboard](https://lucabertelli.consulting/blog/snorlx/repositories.webp)

![Scoring dei repository](https://lucabertelli.consulting/blog/snorlx/scoring.webp)

La pagina **Runs** è un elenco filtrabile e paginato di tutti i workflow run; la **Run Detail** mostra la gerarchia dei job, stato degli step, timeline, annotazioni errori, YAML del workflow e link ai log su GitHub. I dati si possono aggiornare da GitHub con `?refresh=true`.

![Ricerca tra tutti i workflow della organization](https://lucabertelli.consulting/blog/snorlx/workflows.webp)

![Elenco delle run con filtri per stato, branch, evento](https://lucabertelli.consulting/blog/snorlx/runs.webp)
*Elenco run con filtri e paginazione; da qui si accede al dettaglio di ogni run.*

![Dettagli e log della run specifica](https://lucabertelli.consulting/blog/snorlx/run_details.webp)

Il **tracking dei costi** per workflow e per repository permette di identificare le pipeline più costose e modellare l'impatto di eventuali cambi di pricing. Con `STORAGE_MODE=memory` si può provare tutto senza database; per la produzione si passa a `STORAGE_MODE=database` e PostgreSQL con TimescaleDB.

## Requisiti

- Go 1.21+
- Node.js 20+
- pnpm (consigliato) o npm
- Una GitHub OAuth App ([creane una qui](https://github.com/settings/developers))
- PostgreSQL 14+ con TimescaleDB (solo per la modalità database)

## Step di preparazione

### 1. Clone del repository e installazione delle dipendenze

```bash
git clone https://github.com/banshee86vr/snorlx.git
cd snorlx
pnpm install
```

### 2. Creazione di una GitHub OAuth App

Accedere alle [GitHub Developer Settings](https://github.com/settings/developers), cliccare **OAuth Apps** → **New OAuth App** e compilare:

- **Application name**: `Snorlx Dashboard`
- **Homepage URL**: `http://localhost:5173`
- **Authorization callback URL**: `http://localhost:8080/api/auth/callback`

Copiare il **Client ID** e generare un **Client Secret**.

### 3. Configurazione dell'ambiente

```bash
cp env.example .env
```

Modificare il file `.env` con le proprie credenziali:

```env
# Modalità sviluppo
DEV_MODE=true

# Modalità storage: memory per quick start, database per persistenza
STORAGE_MODE=memory

# GitHub OAuth
GITHUB_CLIENT_ID=your_oauth_client_id
GITHUB_CLIENT_SECRET=your_oauth_client_secret

# Sicurezza sessione (generare con: openssl rand -base64 32)
SESSION_SECRET=your_random_32_character_secret_string

# URL
PORT=8080
FRONTEND_URL=http://localhost:5173
```

### 4. Avvio dell'applicazione

```bash
# Dalla root del progetto: avvia contemporaneamente frontend e backend
pnpm run dev
```

L'applicazione si avvierà su due porte: il frontend su `http://localhost:5173` e l'API backend su `http://localhost:8080`. Effettuare il login con GitHub e la dashboard inizierà a sincronizzare i repository, i workflow e i run.

### 5. (Opzionale) Abilitare la modalità database per storage persistente

Per mantenere i dati tra un riavvio e l'altro, avviare un'istanza TimescaleDB:

```bash
docker run --name snorlx-postgres \
  -e POSTGRES_DB=snorlx \
  -e POSTGRES_USER=postgres \
  -e POSTGRES_PASSWORD=postgres \
  -p 5432:5432 -d timescale/timescaledb:latest-pg16
```

Aggiornare il file `.env`:

```env
STORAGE_MODE=database
DATABASE_URL=postgresql://postgres:postgres@localhost:5432/snorlx?sslmode=disable
```

Riavviare l'applicazione: le migrazioni vengono eseguite automaticamente all'avvio.

## Architettura (in breve)

Frontend React 18 + TypeScript con TanStack Query e Recharts; backend Go (Chi router) con OAuth GitHub, webhook e WebSocket per gli aggiornamenti in tempo reale; PostgreSQL con TimescaleDB per le serie temporali, hypertable e aggregati continui. Due modalità: `STORAGE_MODE=memory` per sviluppo/quick start, `STORAGE_MODE=database` per produzione.

![Schema dell'architettura a tre livelli: frontend, backend, database](https://lucabertelli.consulting/blog/snorlx/architecture.webp)
*Architettura a tre livelli: frontend, backend, database.*

## Deploy su Kubernetes

Snorlx include un Helm chart in `helm/snorlx/` che effettua il provisioning di deployment separati per backend e frontend, StatefulSet TimescaleDB opzionale, secrets, Ingress e security context non-root.

## In sintesi

Con `pnpm run dev` hai una dashboard che aggrega le run di tutti i repo, traccia i costi, assegna uno score a ogni repository (gold/silver/bronze) e aggiorna in tempo reale: self-hosted, open-source, sotto il tuo controllo. Parti in modalità memory per provarla in pochi minuti, poi passi a PostgreSQL quando serve persistenza. Per chi usa GitHub Actions su molti repository, Snorlx è la vista centrale che GitHub non fornisce.

### Ambienti di test effimeri per flussi di CI (Italian)

- URL: https://lucabertelli.consulting/it/blog/vcluster
- Language: it
- Published: 2024-04-01
- Summary: Come usare i vCluster e Argo Workflow per gestire ambienti di test effimeri
- Tags: vcluster, argo, cicd, devsecops, kubernetes, multi-tenancy

## Perchè mai dovremmo avere questa esigenza?

A partire dai primmi anni 2000 iniziò ad essere evidente che le applicazioni monolitiche necessitavano di essere più scalabili per evitare di bloccare la crescita del business e la sua scalabilità. Dopo qualche anno, nel 2011, durante un workshop di software architect organizzato vicino a Venezia, un nuovo modello architetturale dei software stava compiendo i primi passi: i microservizi. Il modello a microservizi è in grado di scalare per soddisfare quei requisiti di business che richiedono l'esecuzione di più istanze dello stesso servizio su diversi server. In questo scenario diversi team di sviluppo lavorano su diversi microservizi aumentando la produttività e la competenza sul codice prodotto, cosa che con le applicazioni monolitiche era difficile da ottenere. Di conseguenza, fu sempre più evidente come il modello a microservizi permettesse questa scalabilità delle applicazioni e dei team di lavoro.

Molti lettori ormai avranno già pensato: ok, ma non è tutto oro quello che luccica! Siamo sicuri che l'adozione di questo approccio non porti con se anche degli effetti collaterali? Cosa succede se proviamo ad adottare questo modello nell'ecosistema cloud-native usando degli ambienti basati su Kubernetes?

Chiunque abbia già valutato o vissuto in prima persona questo percorso di dozione può testimoniare come si presenti in maniera concreta il rischio di assemblare un mostro chiamato *dependecy hell*.

> Dependency hell is a colloquial term for the frustration of some software users who have installed software packages which have dependencies on specific versions of other software packages.
> The dependency issue arises when several packages have dependencies on the same shared packages or libraries, but they depend on different and incompatible versions of the shared packages. If the shared package or library can only be installed in a single version, the user may need to address the problem by obtaining newer or older versions of the dependent packages. This, in turn, may break other dependencies and push the problem to another set of packages.

Durante il ciclo di rilascio di ogni pacchetto software uno degli obiettivi più importanti di ogni gruppo di sviluppo è quello di poter implementare e testare il codice prodotto essendo sicuri di utilizzare la versione corretta di ogni dipendenza, come altri microservizi o database.

Come si può ottenere un ambiente temporaneo su richiesta dove poter effettuare tutti i miei test in sicurezza?

## Quindi? Qual'è il problema?

Questo tipo di richiesta si presenta molto spesso e usualmente richiede più risorse infrastrutturali per poter replicare tutte le dipendenze in un ambiente completamente isolato. Normalmente non è possibile preparare agevolmente un ambiente di questo tipo sul dispositivo a disposizione dello sviluppatore, e in ogni caso ogni gruppo di sviluppo non riesce a richiedere in tempi brevi un nuovo ambiente kubernetes per poter procedere con i test a causa anche dei costi legati alle risorse infrastrutturali. Allo stesso tempo si evita di eseguire questo tipo di verifiche nell'ambiente di sviluppo condiviso con gli altri gruppi per evitare che i test vengano invalidati da altri rilasci effettuati nella stessa finestra temporale.

## Una possibile soluzione: vCluster + Argo Workflow

Analizzando i requisiti dello use case, una possibile soluzione è quella di sfruttare [vCluster di Loft](https://www.vcluster.com). Utilizzando questo strumento l'utente può creare un cluster Kubernetes temporaneo all'interno di uno già esistente. Il virtual cluster espone in diversi modi le API di un control plane completamente separato. I vCluster sono una valida opzione quando all'interno di un cluster Kubernetes si presenta il requisito di gestire la multi tenancy utilizzando l'infrastruttura già messa a disposizione. L'adozione e il suo utilizzo non risultano eccessivamente complessi, e non è necessario installare altre dipendenze sul cluster. Un altro aspetto interessante è che non servono particolari percorsi formativi per iniziare ad utilizzare i vCluster in quanto dopo la loro creazione viene fornito semplicemente un Kubernetes API Server endpoint standard per poter iniziare eseguire comandi tramite `kubectl`.

In questo esperimento mi sono divertito provando ad integrare questa tecnologia con [Argo Workflow](https://argoproj.github.io/workflows), un workflow execution engine specifico per Kubernetes. Questo engine fornisce un modo efficiente per configurare l'orchestrazione di rilasci, del loro test e della loro eventuale dismissione. Lo strumento abilita l'utente finale a disegnare ed implementare dei DAG (Directed acyclic graph), riuscendo quindi supportare anche lo sviluppo di scenari complessi dove persiste il requisito di alto parallelismo dei task eseguiti.

Questa combinazione quindi offre una soluzione veloce, conveniente e scalabile facendo risparmiare molte attività di manutenzione richieste per creare e gestire un nuovo cluster Kubernetes ogni volta che questo sia richiesto.

---

## Demo Project

URL: <https://github.com/banshee86vr/ephemeral-test-environment> \
Struttura del progetto:

```plaintext
.
├── argo-workflow
│   └── lang
└── hello-world-app
```

* `argo-workflow`: cartella contenente i template delle pipeline di CI/CD
* `lang`: cartella contenente i diversi ArgoWorkflow Templates per i linguaggi di programmazione supportati
* `hello-world-app`: Applicazione Hello World implementata in Go che effettua una print di fantastico un 🐙 in ASCII code

## Requisiti

* Minikube
* `kubectl` command-line installata e configurata per connettersi al cluster Kubernetes esistente
* Helm versione `3.x` installato

## Step di preparazione

### 1. Start Minikube e installazione Argo Workflows usando Helm

```bash
minikube start
helm repo add argo https://argoproj.github.io/argo-helm
helm install argo-workflows argo/argo-workflows -n argo --create-namespace
```

Questo comando installa Argo Workflows nel namespace `argo` sul cluster Kubernetes.

### 2. Verifica dell'installazione

Per verificare che l'installazione sia avvenuta con successo eseguire:

```bash
kubectl get pods -n argo
```

Nella lista risultante dei pod in stato Running dovrebbero esserci dei pod con prefisso `workflow-controller` e `argo-server`.

### 3. Patch della configurazione di autenticazione per argo-server

Come riportato dalla documentazione ufficiale: <https://argo-workflows.readthedocs.io/en/latest/quick-start/#patch-argo-server-authentication>

> The argo-server (and thus the UI) defaults to client authentication, which requires clients to provide their Kubernetes bearer token to authenticate. For more information, refer to the Argo Server Auth Mode documentation. We will switch the authentication mode to `server` so that we can bypass the UI login for now:

```bash
kubectl patch deployment \
  argo-server \
  --namespace argo \
  --type='json' \
  -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/args", "value": [
  "server",
  "--auth-mode=server"
]}]'
```

### 4. Accesso alla UI di Argo Workflows UI (Opzionale)

Argo Workflows fornisce un'interfaccia utente web per gestire e monitorare i workflows. Per accedere alla UI è necessario esporre il relativo service Kubernetes:

```bash
kubectl port-forward svc/argo-server -n argo 2746:2746
```

A questo punto è possibile accedere tramite browser alla UI di Argo Workflows all'indirizzo `http://localhost:2746`.

### 5. Aggiungere permessi al service account di Argo

> Vengono aggiunti questi livelli di permessi solamente a scopo dimostrativo. **È FORTEMENTE SCONSIGLIATO REPLICARE QUESTO TIPO DI CONFIGURAZIONE IN AMBIENTI DI PRODUZIONE**

Questo commando associa il clusterrole `cluster-admin` ai service account `argo:argo-server` e `argo:default`. In questo modo Argo Workflow potrà gestire qualsiasi tipo di risorsa in ogni namespace del cluster.

```bash
kubectl create clusterrolebinding argo-admin-server --clusterrole=cluster-admin --serviceaccount=argo:argo-server -n argo
kubectl create clusterrolebinding argo-admin-default --clusterrole=cluster-admin --serviceaccount=argo:default -n argo
```

> Negli ambienti produttivi è consigliabile creare dei ruoli dedicati in modo tale da permettere solamente l'associazione dei verbs necessari sulle risorse gestite dai workflow.

### 6. Preparare i secrets richiesti dalle pipeline

In caso di utilizzo di repository Git privati eseguire questo comando per permettere l'esecuzione del comando clone eseguito dalla pipeline `ci.yaml`:

```bash
kubectl create secret generic github-token -n argo --from-literal=token=.........
```

Questo comando crea un secret che contiene le credenziali per eseguire il push delle immagini Docker sul registry:

```bash
export DOCKER_USERNAME=******
export DOCKER_TOKEN=******
kubectl create secret generic docker-config --from-literal="config.json={\"auths\": {\"https://ghcr.io/\": {\"auth\": \"$(echo -n $DOCKER_USERNAME:$DOCKER_TOKEN|base64)\"}}}"
```

### 7. Applicare i manifest Argo WorkflowTemplate

```bash
git clone https://github.com/banshee86vr/ephemeral-test-environment.git
cd argo/workflow

kubectl apply -f ci.yaml
kubectl apply -f lang/go.yaml
kubectl apply -f cd.yaml
```

## Step esecutivi

Dopo aver completato tutti i passi preparatori ed avere installato e configurato Argo Workflow si può procedere creando ed eseguendo i workflow.

### 8. Submit della pipeline di Continuous Integration

La pipeline di Continuous Integration esegue gli step previsti all'interno del manifest [ci.yaml](https://github.com/banshee86vr/ephemeral-test-environment/blob/main/argo-workflow/ci.yaml):

1. **Clone del Repository**: Prepara in locale il codice sorgente prelevato dal repository Git.
2. **Esegue il build dell'applicazione**: Compila l'applicazione Hello World in Go utilizzando il template GoLang [go.yaml](https://github.com/banshee86vr/ephemeral-test-environment/blob/main/argo-workflow/lang/go.yaml).
3. **Build e Push dell'immagine Docker**: Produce l'immagine Docker ed esegue la push sul registry.

![CI Argo Workflow Flowchart](https://lucabertelli.consulting/blog/vcluster/ci_flowchart.webp)

Per eseguire la pipeline di CI è possibile usare l'API ufficiale [official APIs](https://argo-workflows.readthedocs.io/en/latest/rest-api/):

```plaintext
<ArgoWorkflow URL>/api/v1/workflows/{namespace}/submit
```

In alternativa è possibile utilizzare l'interfaccia utente:

![Submit CI workflow via UI](https://lucabertelli.consulting/blog/vcluster/ci_submit.webp)

Dopo il completamento di tutti gli step, controllare il corretto stato di ogni task e verificare la presenza dell'immagine Docker nel registry:

![CI workflow graph](https://lucabertelli.consulting/blog/vcluster/ci_graph.webp)

### 9. Submit della pipeline di Continuous Delivery

La pipeline di Continuous Delivery esegue gli step previsti nel manifest [cd.yaml](https://github.com/banshee86vr/ephemeral-test-environment/blob/main/argo-workflow/cd.yaml):

1. **Preparazione dell'ambiente effimero**: Preparazione dell'ambiente temporaneo usando vCluster dove l'utente potrà testare la sua applicazione in un ambiente isolato.
2. **Deploy dell'applicazione**: Deploy dell'applicazione tramite Helm chart sul vCluster appena creato.

![CD Argo Workflow Flowchart](https://lucabertelli.consulting/blog/vcluster/cd_flowchart.webp)

Per eseguire la pipeline di CI è possibile usare l'API ufficiale [official APIs](https://argo-workflows.readthedocs.io/en/latest/rest-api/):

```plaintext
<ArgoWorkflow URL>/api/v1/workflows/{namespace}/submit
```

In alternativa è possibile utilizzare l'interfaccia utente:

![Submit CD workflow via UI](https://lucabertelli.consulting/blog/vcluster/cd_submit.webp)

Dopo il completamento di tutti gli step, controllare il corretto stato di ogni task:

![CD workflow graph](https://lucabertelli.consulting/blog/vcluster/cd_graph.webp)

### 10. Accesso all'applicazione

Per verificare come accedere all'applicazione è possibile esegure questi comandi per elencare tutti i vCluster ed accedere a quello interessato:

```bash
$ vcluster list
  
         NAME       | CLUSTER  |    NAMESPACE    | STATUS  | VERSION | CONNECTED |            CREATED            |   AGE   | DISTRO  
  ------------------+----------+-----------------+---------+---------+-----------+-------------------------------+---------+---------
    demo-pr-request | minikube | demo-pr-request | Running | 0.19.0  |           | xxxx-xx-xx xx:xx:xx +0100 CET | 1h8m49s | OSS

$ vcluster connect demo-pr-request --namespace demo-pr-request -- kubectl get pod -n demo-pr-request

NAME                                           READY   STATUS    RESTARTS   AGE
demo-pr-request-hello-world-7f6d78645f-bjmjc   1/1     Running   0          7s
```

Come riportato [qui](https://www.vcluster.com/docs/using-vclusters/access), è possibile esporre in diversi modi i vCluster:

* **Via Ingress**: Un Ingress Controller con una configurazione SSL passthrough dovrebbe fornire l'esperienza utente migliore. Per fare ciò verificare che l'ingress controller sia installato e funzionante sul cluster che ospita il vCluster. Per maggiori dettagli fare riferimento [qui](https://www.vcluster.com/docs/using-vclusters/access#via-ingress)
* **Via LoadBalancer service**: Il modo più semplice, utilizzando l'opzione `--expose` durante la fase di creazione del vCluster verrà creato anche un service di tipo LoadBalancer. Il risultato dipende dalla specifica implementazione del cluster Kubernetes che ospita il vCluster.
* **Via NodePort service**: È possibile esporre il vCluster anche tramite un servizio NodePortYou. In questo caso è necessario creare il servizio NodePort e modificare il file `values.yaml` usato per la creazione del vCluster. Per maggiori dettagli fare riferimento [qui](https://www.vcluster.com/docs/using-vclusters/access#via-nodeport-service)
* **From Host Cluster**: Per accedere al vCluster direttamente dal cluster che lo ospita è possibile connettersi direttamente al vCluster service creato. Verificare in questo caso la raggiungibilità del service e creare un kubeconfig dedicato tramite questo comando:
  
  ```bash
  vcluster connect my-vcluster -n my-vcluster --server=my-vcluster.my-vcluster --insecure --update-current=false
  ```

## Abbiamo veramente risolto il nostro problema?

Con il progetto demo è stato dimostrato quanto sia facile integrare un flusso di CI usando l'engine di Argo Workflow per effettuare il rilascio di un'applicazione in un ambiente temporaneo ed isolato creato tramite vCluster che contiene tutte le eventuali dipendendenze. Per questo è importante considerare che ogni vCluster può essere inizializzato e personalizzato tramite manifest `.yaml` o Helm charts. Tipicamente ogni microservizio può contenere già le proprie dipendenze in altri Helm charts o in manifest `.yaml`. Quindi con i vCluster il gruppo di sviluppo può decidere quale versione del chart utilizzare per inizializzare il vCluster per testare la relativa applicazione.

## Come possiamo governare il ciclo di vita di questi vCluster effimeri?

Durante il progetto demo abbiamo visto come creare cluster dinamicamente. Ma ora dovremmo preoccuparci della loro gestione:

* Come possiamo ottimizzare le risorse utilizzare del vCluster?
* Possiamo eliminare il vCluster automaticamente?
* In quale modo posso automatizzare qualsiasi operatività manuale?
* Come posso prevenire la proliferazione di questi ambienti effimeri?

Il team di Loft ci aiuta per poter soddisfare tutti queste tematiche. La versione open source non è sufficiente a coprire nativamente tutti i requisiti, ma:

* *Quotas e limits* (già disponibile con la versione open source): un manifest standard Kubernetes `ResourceQuota` può essere applicato per poter prevenire l'eccessivo utilizzo di risorse da parte del vCluster
* *Creazione ed eliminazione automatica*: Queste operazioni possono essere scatenate utilizzando Argo Events. Questo framwork event-driven permette di agganciare eventi e workflow a webhook forniti dai tool di gestione centralizzata del codice; ad esempio, il cambio di stato di una pull request.
* *Ottimizzazione delle risorse usate dai vCluster*: a riguardo Lof fornisce una funzionalità di monitoraggio per gestire i periodi di inattività del vcluster ed evitare sprechi di risorse. La versione Enterprise del tool (vCluster.PRO) offre due funzionalità che ci possono tornare utili in tal senso. La prima si chiama `Sleep Mode` e permette di impostare il vCluster in una modalità dormiente quando non viene utilizzato, eliminando tutti i pod ma mantenendo tutte le risorse all'interno del vCluster. La seconda si chiama `Auto-delete` e permette di eliminare l'intero vCluster dopo un certo periodo di inattività. Per questo, nel caso non sia possibile adottare vCluster.PRO, è possibile implementare un workaround utilizzando i CronJob l'immagine Docker contenente la CLI di vCluster per poter schedulare lo start e lo sleep/resume del vCluster seguendo il formato standard di schedulazione di cron.

## Quindi cosa ci portiamo a casa?

Integrando Argo Workflows con vCluster abbiamo implementato una soluzione veloce e scalabile, permettendo ad ogni gruppo di sviluppo di poter testare la propria applicazione in maniera indipendente in un ambiente sicuro ed isolato. La possibilità di personalizzare l'inizializzazione del vCLuster permette di aggiungere qualsiasi dipendendenza necessaria, alzando il livello di qualità dei test effettuati sull'applicazione.

La stessa architettura, integrando anche Argo Events, può divenire event-driven, collegando eventi ai webhook forniti dagli strumenti di gestione centralizzata del codice, rendendola una soluzione molto conveniente in termini economici.