Interviewed by: Mehadi Hasan
Developer: Arif KURNAZ
Role: Founder of Attestkeep (Ecavist Technologies)
Location: Çanakkale, Türkiye
Website: attestkeep.com
Featured Projects: Attestkeep and Portiger
Software infrastructure has become increasingly sophisticated, but the security challenges surrounding it have not disappeared. Container images can pass through CI/CD pipelines without anyone noticing newly discovered vulnerabilities. Security reports can remain buried in DevOps channels while developers continue deploying affected images. And when auditors eventually ask why a particular image was allowed into production, teams often struggle to provide reliable evidence.
For Arif Kurnaz, these were not hypothetical problems. They were practical challenges he encountered while working with development teams in Kubernetes environments.
After years of professional software development, including extensive experience with Java, Quarkus, Keycloak, Kafka, and Kubernetes, Arif decided to address these gaps himself. In March 2026, he started building Attestkeep, a Kubernetes admission controller designed to scan container images, verify signatures, enforce security policies, and maintain independently verifiable evidence of admission decisions.
Alongside Attestkeep, he is also developing Portiger, a different approach to application infrastructure that brings many familiar Kubernetes capabilities to developers running applications on ordinary Docker servers.
His journey offers an interesting perspective on infrastructure engineering, product development, software security, and why understanding real-world problems matters more than simply mastering programming languages.
From Economics to Nearly Two Decades in Software Development
Arif's journey into software development did not begin with a traditional computer science education. He studied economics, but his curiosity about computers eventually led him toward programming.
He started learning software development in 2005 and began working professionally in 2008. His first major step into the industry was through PHP, during a period when web development looked very different from what developers experience today.
Websites were built using HTML tables, even relatively simple interface elements required considerable effort, and finding technical information often meant spending hours researching solutions.
Outside professional work, he experimented with different programming languages, including Delphi 7, Visual Basic, C, and C++. He also developed custom applications for clients, covering B2B and B2C platforms, CRM systems, accounting software, and web-integrated business applications.
He remembers the Stack Overflow era as an important part of his development journey. Debugging sometimes meant spending hours or even days investigating unusual errors, learning from other developers, and gradually understanding how software systems worked internally.
One particularly important lesson was understanding object-oriented programming. It took him time to fully internalise OOP concepts, but that experience eventually changed how he approached different programming languages.
As he explains:
The language changes, the fundamentals do not.
His professional experience later expanded into Java development, particularly in identity and access management systems. At Keymate.io, he worked with reactive microservices using Quarkus and SmallRye, Keycloak extensions, Kafka pipelines, Kubernetes deployments, Helm, OpenTelemetry, JUnit 5, Testcontainers, and K6.
Working in that environment also gave him practical exposure to Kubernetes at professional scale. Combined with his existing Docker knowledge, this experience helped him recognise infrastructure problems that could become the foundation for his own products.
Recognising the Security Gaps That Inspired Attestkeep
Attestkeep emerged from three interconnected problems Arif observed while working with Kubernetes development teams.
The first involved container image vulnerabilities.
Developers frequently select a base image when building an application, but they do not always verify whether that image contains known vulnerabilities. A CI/CD pipeline may complete successfully, displaying a green status, even though the underlying container image has security issues.
The second problem was communication between development and DevOps teams.
Even when DevOps engineers performed vulnerability scans, the results often remained in separate channels, screenshots, or tickets. Developers responsible for the affected images might not receive the information until weeks later.
By that time, the same vulnerable base image could already have been incorporated into multiple services.
The third challenge involved compliance.
DevOps teams frequently had to collect security evidence manually when preparing for frameworks such as SOC 2. Screenshots, tickets, and email conversations created additional work and made it difficult to demonstrate exactly what happened at a particular point in time.
Arif recognised that all three problems shared a common cause: security information was not reaching the right person at the right moment.
Developers needed information during development, DevOps engineers needed reliable decisions during deployment, and auditors needed trustworthy evidence afterward.
Rather than treating these as separate problems, he decided to build a system connecting all three stages.
That decision led to Attestkeep.
Attestkeep: Moving Container Security Beyond CI/CD Scanning
Traditional container security approaches often focus on scanning images during the CI/CD process.
However, Arif identified three limitations in relying exclusively on build-time scanning.
Timing: Vulnerability databases change regularly. An image that was considered clean during its initial scan may contain a critical vulnerability several weeks later.
Enforcement: A scan report does not automatically prevent an image from entering a Kubernetes cluster. Without a connection to the deployment decision, vulnerable images may still be admitted.
Evidence: When auditors ask why an image was accepted, teams may have only screenshots or tickets rather than an independently verifiable record.
Attestkeep addresses these gaps by connecting image security checks with Kubernetes admission decisions and a signed evidence ledger.
Its vulnerability database refreshes every six hours, while running images are rescanned daily by default.
Every admission decision is recorded alongside the exact policy content that produced it.
An important design principle is that customer data stays inside the customer's cluster. According to Arif, Attestkeep does not collect telemetry, analytics, or crash reports. The only external communication is the three values used in its daily licence check.
Inside Attestkeep's Kubernetes Architecture
One of the most interesting aspects of Attestkeep is how it handles security decisions without introducing unnecessary delays into Kubernetes deployments.
When a Deployment is applied, the Kubernetes API server contacts Attestkeep's validating admission webhook before creating the pod.
The webhook does not modify the deployment manifest. Its first responsibility is to resolve the image tag into a digest.
This distinction matters because image tags can change, whereas a digest identifies a specific image version. Attestkeep therefore makes security decisions against image digests rather than relying on potentially movable tags.
It then checks the latest available scanning and signature results stored in PostgreSQL.
A particularly important architectural decision was keeping scanning out of the admission path. A cold Trivy scan can take minutes, while Kubernetes admission has a limited time budget.
Instead of scanning synchronously, Attestkeep uses cached results to target admission decisions in under 100 milliseconds.
For previously unseen images, two behaviours are available:
- allowAndScan: The image is admitted and its scan is queued.
- DenyUntilScanned: The image is rejected until scanning has completed.
Both modes are available across every edition.
Security decisions are evaluated against an ImageSecurityPolicy custom resource definition (CRD). Policies can specify signature requirements, trusted identities, minimum SLSA provenance levels, SBOM requirements, rejected CVE severities, VEX handling, and deny-list rules.
Policies also support two operating modes:
- Enforce: Security decisions can block deployments.
- Audit: The system records what would have been denied without blocking the deployment.
This allows teams to observe potential problems before introducing stricter enforcement.
Another important architectural component is the admissions ledger.
Each decision is stored in PostgreSQL together with the hash of the applied policy. Individual records are hashed using SHA-256, while Merkle roots and Ed25519-signed checkpoints provide additional integrity verification.
The signing key is stored separately in a Kubernetes Secret rather than inside the database.
The evidence package is generated from this ledger.
The application itself is distributed as a single binary containing the webhook, REST API, controllers, kubectl plugin, and embedded Vue 3 console.
Attestkeep also separates enforcement state from product data. Kubernetes CRDs in etcd preserve enforcement state, allowing admission decisions to continue even if PostgreSQL becomes unreachable.
Making Compliance Evidence Independently Verifiable
For Arif, recording security decisions was only part of the problem. Those records also needed to be useful to auditors without requiring them to trust the vendor.
Attestkeep currently maps its evidence to 13 compliance frameworks, covering 293 individual items.
These include SOC 2, ISO/IEC 27001:2022, PCI DSS v4.0.1, NIST SP 800-190, NIST 800-53, EU CRA, NIS2, DORA, GDPR Article 32, MAS TRM, ASD Essential Eight, ISMAP, and ISMS-P.
The evidence package follows the auditor's structure and uses OSCAL vocabulary. Each item identifies how it was verified rather than relying on marketing descriptions or unsupported statements.
The package includes several components:
report.json containing the evidence report.attestation.json containing a DSSE-signed in-toto Statement v1.certificate.jwt containing the installation certificate.- A PDF report.
- A README file.
The verification process uses a chain of trust connecting Attestkeep's published root key, the installation's own signing key, and the signed attestation.
Auditors can independently examine the package using a small Python verifier or a browser-based verification page. Both rely on the published root key rather than requiring direct trust in the vendor.
The package also reports the integrity of the ledger, including hash-chain consistency, checkpoint relationships, and the length of any unsealed record tail.
One particularly thoughtful decision is that hypothetical policy evaluation results are never included as actual evidence. Attestkeep's what-if functionality can replay historical decisions under a proposed policy, but those results remain unsigned and unsealed.
This distinction prevents simulated outcomes from being mistaken for real security decisions.
Engineering Challenges: Reliability Comes Before Convenience
Building software that sits directly in the Kubernetes admission process introduces responsibilities beyond those of an ordinary application.
A failure can affect the deployment process itself.
Arif describes several engineering challenges that required particular attention.
Keeping admission fast
Scanning and other expensive operations cannot run synchronously during admission. Attestkeep therefore relies on cached results and keeps the decision process lightweight.
Managing webhook availability
The webhook operates with two replicas, a PodDisruptionBudget, anti-affinity, and controlled draining during upgrades.
The default failure policy is Ignore. This means the cluster is not prevented from deploying applications if Attestkeep becomes unavailable.
However, this also creates a period during which the security control is not actively enforcing admission decisions. Attestkeep records that availability gap in its evidence package, and an hourly reconciliation process checks pods admitted during that period.
Handling silent tool failures
Some security tools can return ambiguous errors. Arif describes an issue where cosign verification was being interpreted as an unsigned image when the actual problem was a read-only root filesystem preventing successful verification.
The lesson was that a tool returning an exit code does not necessarily mean the intended security check actually happened.
Testing against real environments
For Arif, unit tests alone are not sufficient evidence that infrastructure software works correctly.
He relies on end-to-end testing against real Kubernetes clusters and real container images, including broken and malicious data.
His philosophy is straightforward:
A green unit test is a signal, not proof.
This approach reflects the responsibilities involved in building software that can directly influence production infrastructure.
Shipping Attestkeep: From Evidence Collection to Active Security
Attestkeep's development moved quickly after its initial release.
The first release arrived on 30 August 2026, followed by version 1.0.0 on 6 September. Subsequent releases introduced additional capabilities, including runtime security integration, more advanced enforcement, deny lists, SIEM export, and binary inventory.
One of the biggest changes was the transition from a system primarily focused on recording security decisions to a product capable of actively intervening.
Arif points out that this transition significantly changes the engineering responsibilities.
A mistake in an evidence-collection tool can produce an inaccurate report. A mistake in software that actively intervenes can interrupt production workloads.
Every new capability therefore introduces additional permissions, failure scenarios, and questions about how the system should respond to false positives.
Several decisions helped shape the product:
- Keeping scanning outside the admission path.
- Establishing the CRD group and naming conventions before the first release.
- Making security capabilities consistent across editions rather than limiting important protection features to paid customers.
- Keeping the default failure policy visible and documenting periods when protection was unavailable.
- Replacing the earlier Falco bearer-token connection with mutual TLS authentication.
His approach to product editions is particularly notable. Paid plans primarily differ in cluster and node capacity, SSO, and support rather than restricting essential security capabilities.
For infrastructure security software, he believes customers should not receive weaker protection simply because they choose a cheaper edition.
Extending Security Beyond Admission with Falco
Admission control determines whether a container image can enter a Kubernetes cluster. But it does not explain everything that happens after deployment.
That is where Falco becomes relevant.
Attestkeep's Falco integration connects runtime events with the same security ledger and evidence package used for admission decisions.
Attestkeep does not install or manage Falco itself. Customers retain control of their existing Falco configuration and rules.
Events can be received directly through Falco's HTTP output using mutual TLS or through Falcosidekick.
The integration can associate events with admission verdicts, signatures, namespaces, and image information. Depending on the configured rules, actions can include recording, notifying, opening an issue, or stopping a pod through eviction.
One technical challenge is identifying the exact image associated with a runtime event. Falco events do not always provide the image digest.
Attestkeep uses the same image-normalisation logic as admission. If a digest is unavailable, it uses the last admitted digest for the corresponding image name and tag when possible. Otherwise, it leaves the digest field empty rather than inventing one.
The system also distinguishes between a period with no runtime events and a period when the event feed was unavailable.
This matters because the absence of reported security incidents does not necessarily mean that monitoring was active.
Building Portiger: Kubernetes Capabilities Without Kubernetes
While Attestkeep addresses Kubernetes security, Arif is also developing a second product called Portiger.
The idea behind Portiger came from a different infrastructure problem.
Kubernetes provides powerful capabilities, but operating a complete environment can introduce significant resource and operational costs for smaller teams and independent developers.
A typical setup may involve separate systems for secrets management, gateways, CI/CD, and monitoring. Each additional component requires resources and maintenance.
For many applications, one or a few Docker servers would be sufficient. The challenge is reproducing the convenience of a more sophisticated infrastructure environment without manually managing everything.
Portiger is designed to address that gap.
It installs as a single binary on an existing server and provides a management interface through an embedded web panel.
Developers can connect GitHub, GitLab, or Gitea, build images using their own runners, and deploy applications from Compose files.
The platform also brings together:
- Git-based deployments.
- Automatic TLS certificate management.
- Scheduled jobs.
- Encrypted secrets and configuration management.
- Backups.
- Metrics and change history.
- Notifications.
- Host security scanning.
Its Sentinel component checks server security, including SSH configuration, Docker exposure, listening ports, pending updates, and other system conditions. It also performs a Trivy scan of the server itself.
Portiger uses Go for its backend and embedded SQLite for application state, avoiding the need for a separate database server.
Arif describes its goal as bringing together the ease of cPanel and many of the capabilities developers appreciate in Kubernetes.
The project is currently undergoing beta testing.
The Engineering Philosophy Behind Both Products
Although Attestkeep and Portiger address different infrastructure environments, they share an important design principle.
Both products aim to make security a continuous part of infrastructure management rather than something handled only during initial deployment.
Attestkeep concentrates on Kubernetes admission decisions and signed evidence. Portiger focuses on continuous checks of both the server and the images running on it.
The underlying questions remain similar:
Who checked the image? What is running on the server? Who can access it?
The implementation changes depending on the environment, but the security objectives remain connected.
Arif's development workflow also reflects this focus on reliability.
He considers OpenTelemetry, K6, unit testing, and Testcontainers particularly valuable. Among these, he places special importance on Testcontainers because it allows developers to test how systems behave in environments that more closely resemble actual deployments.
K6 is useful for performance and load testing, while OpenTelemetry provides visibility into system behaviour.
For infrastructure-level products, however, his strongest requirement is testing against the real environment where the software will operate.
Attestkeep releases are exercised end to end on real Kubernetes clusters with real images. The team examines database decisions, tests invalid inputs, and checks potential side effects.
For him, writing code is only one part of software development. Understanding what that code actually does when it runs is equally important.
Why Understanding Problems Matters More Than Learning Languages
After nearly two decades in software development, Arif's advice to other developers is centred on problem-solving rather than programming syntax.
He believes developers should focus on understanding the problem, analysing it correctly, and identifying the most effective solution.
The programming language is simply the tool used to implement that solution.
This perspective has become particularly relevant as AI tools increasingly generate code.
Rather than competing with AI at writing syntax, he believes developers should develop stronger skills in software architecture, problem definition, system boundaries, and verification.
He also offers an interesting perspective on building independent products.
Product ideas do not necessarily need to begin with extensive market analysis. Sometimes they emerge from problems developers repeatedly encounter in their everyday professional work.
Attestkeep is an example of that approach.
Arif observed security blind spots in real Kubernetes environments, recognised that existing workflows did not connect the necessary information, and decided to build a solution.
His experience suggests that some of the most useful software products begin with a simple question: why does this problem still exist when developers encounter it every day?
Conclusion
Arif Kurnaz's journey from PHP development to enterprise Java systems and independent infrastructure products demonstrates how years of practical engineering experience can shape product ideas.
Attestkeep grew out of security and compliance challenges he observed in Kubernetes environments. Its architecture connects admission-time decisions, continuous vulnerability scanning, signature verification, runtime events, and independently verifiable evidence.
Portiger approaches a different challenge by simplifying application deployment and infrastructure management for developers who do not need the operational overhead of Kubernetes.
Despite their different goals, both projects reflect the same philosophy: infrastructure should make developers' work easier without compromising security or reliability.
Perhaps the most important lesson from Arif's experience is that building useful software starts with understanding what actually needs to be solved.
As he puts it:
A product idea does not come from a market analysis but from the blind spot you see every day at work that nobody touches.
For developers considering building their own products, that is a practical place to start: pay attention to the problems existing systems leave unresolved, understand why they persist, and build something that addresses them properly.
About Arif Kurnaz
Arif Kurnaz is a software developer and founder of Attestkeep at Ecavist Technologies, based in Çanakkale, Türkiye. He began his software development journey in 2005 and has worked professionally since 2008, with experience spanning PHP, Java, Go, backend systems, identity and access management, distributed architectures, and cloud-native infrastructure.
He is currently developing Attestkeep, a Kubernetes container image security and compliance evidence platform, alongside Portiger, a self-hosted application deployment and infrastructure management platform designed for Docker servers.
Connect with Arif and explore his work:
Developer Stories is a CoderLegion interview series highlighting the people, ideas, projects, and engineering decisions behind software development.