[{"content":"","date":"July 5, 2026","externalUrl":null,"permalink":"/posts/","section":"Posts","summary":"","title":"Posts","type":"posts"},{"content":"","date":"July 5, 2026","externalUrl":null,"permalink":"/tags/ai/","section":"Tags","summary":"","title":"Ai","type":"tags"},{"content":"","date":"July 5, 2026","externalUrl":null,"permalink":"/tags/devsecops/","section":"Tags","summary":"","title":"Devsecops","type":"tags"},{"content":"","date":"July 5, 2026","externalUrl":null,"permalink":"/","section":"Dimitar Georgievski","summary":"","title":"Dimitar Georgievski","type":"page"},{"content":"","date":"July 5, 2026","externalUrl":null,"permalink":"/tags/security/","section":"Tags","summary":"","title":"Security","type":"tags"},{"content":"","date":"July 5, 2026","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"DevSecOps was created because security could no longer sit at the end of the software delivery process like a disappointed auditor with a clipboard. Software started moving faster, infrastructure became code, cloud environments multiplied, containers appeared everywhere, and suddenly “we’ll review security before production” became a phrase people said right before production caught fire.\nThe idea was right: security needed to shift left, integrate with engineering, and become part of daily delivery. But somewhere along the way, the DevSecOps engineer quietly became responsible for everything.\nReview the code. Secure the pipeline. Check the Terraform. Explain the Kubernetes misconfiguration. Triage the vulnerability scanner. Find the secret someone committed “just temporarily.” Update the policy. Interpret the compliance control. Investigate the alert. Explain the alert. Re-explain the alert, but this time in executive language. Then do it all again tomorrow, preferably before coffee.\nThis is why AI agentic assistance is no longer just a nice productivity booster. It is becoming a practical necessity.\nThe traditional DevSecOps toolchain is excellent at producing signals. Sometimes too excellent. SAST, SCA, DAST, container scanners, cloud security tools, SIEM platforms, CSPM systems, and pipeline checks can all generate findings with impressive confidence and occasionally the emotional sensitivity of a smoke alarm in a toaster factory.\nThe problem is not that we lack security data. The problem is that we are drowning in it.\nA scanner can tell you that a package has a critical vulnerability. What it usually cannot tell you, at least not without help, is whether that package is actually used, whether the vulnerable function is reachable, whether the affected service is internet-facing, whether an exploit exists, who owns the code, whether a fix will break production, and whether this is truly more urgent than the other 412 “critical” issues currently blinking in the dashboard like a Christmas tree designed by a risk committee.\nThis is where AI agents can help.\nAn AI agent can correlate findings across tools, repositories, runtime data, ownership metadata, business context, and threat intelligence. Instead of handing the DevSecOps engineer another pile of alerts, it can produce a prioritized explanation: what matters, why it matters, who should fix it, what the likely remediation path is, and what evidence supports that recommendation.\nThat does not replace the engineer. It gives the engineer a fighting chance.\nThe same applies to remediation. Finding security issues is only half the battle. The other half is turning those findings into something developers can act on without needing a three-hour meeting, a threat modeling workshop, and a ritual sacrifice to the CI/CD gods.\nAI agents can draft remediation tickets, suggest code changes, open pull requests, explain failed pipeline checks, generate safer infrastructure-as-code patterns, and prepare audit evidence. They can handle the repetitive translation layer between “security tool says no” and “developer understands what to fix.”\nThis matters because DevSecOps is not supposed to be a human copy-paste API between scanners and Jira.\nThe real value of a DevSecOps engineer is judgment: deciding which risks matter, designing guardrails, improving delivery systems, guiding engineering teams, responding to incidents, and building security into the way software is actually made. But too often, that judgment gets buried under alert triage, dashboard archaeology, YAML spelunking, and the eternal question: “Why did this build fail?”\nAI agentic assistance changes the operating model. It moves DevSecOps from manual tool operation toward security workflow orchestration. The engineer remains accountable, but the agent does the heavy lifting: collecting context, connecting signals, drafting actions, validating fixes, and escalating decisions that require human approval.\nIn other words, the future of DevSecOps is not replacing engineers with robots. It is giving engineers better assistants so they can stop doing robot work.\nAnd frankly, many of us became DevSecOps engineers because we like solving hard problems, not because we dreamed of spending our best years explaining why public S3 buckets are still bad.\nThe next phase of DevSecOps productivity will not come from adding yet another dashboard to stare at during lunch. It will come from AI agents that help teams understand risk faster, fix issues sooner, reduce toil, and keep humans focused on the decisions where human judgment actually matters.\nBecause DevSecOps does not need more noise.\nIt needs leverage.\n","date":"July 5, 2026","externalUrl":null,"permalink":"/posts/why-devsecops-needs-ai-agentic-assistance-in-daily-work/","section":"Posts","summary":"DevSecOps was created because security could no longer sit at the end of the software delivery process like a disappointed auditor with a clipboard. Software started moving faster, infrastructure became code, cloud environments multiplied, containers appeared everywhere, and suddenly “we’ll review security before production” became a phrase people said right before production caught fire.\n","title":"Why DevSecOps Needs AI Agentic Assistance in Daily Work","type":"posts"},{"content":"","date":"February 20, 2022","externalUrl":null,"permalink":"/tags/do-it/","section":"Tags","summary":"","title":"Do-It","type":"tags"},{"content":"","date":"February 20, 2022","externalUrl":null,"permalink":"/tags/experience/","section":"Tags","summary":"","title":"Experience","type":"tags"},{"content":"Initially, I wanted to name this blog \u0026ldquo;Uneducated DevOps\u0026rdquo; in homage to the Uneducated Economist, street level thoughts, opinions, analysis and perspectives from a working-class point of view, but my better half thought I could do better with my choice of adjectives.\nUnlike Paul Krugman, the intellectually bankrupt, orthodox Keynesian hiding behind meaningless charts and sophistry to distort simple economic truths, the Uneducated Economists breaks complex topics to a level that everyone could understand them using his experience and observing the ebb and flow of commodities like lumber.\nBrake it until you make it # Uneducated in DevOps emphasizes a personal experience above everything else. I know it sounds a bit provocative and giving maybe wrong ideas to impressionable young engineers, but a good education is not a continuous absorption of facts and accumulation of certificates.\nIn my current role, I’ve met talented engineers who in absence of practical ideas on how to start their DevOps journey, were exchanging lists with must-read books for serious DevOps professionals. I usually help them by first listening to their work, challenges and future plans. Intersections with Infra-as-code automation or Kubernetes are easy to spot.\nI help them by asking them to try new ideas on a real project while I watch over their shoulder. It takes a session or two to get them going in the right direction. Before long people start innovating and collaborating. More often than not I learn too something from my disciples. The most important point, that I never get tired of repeating is to embrace failures and learn from them. How could you discriminate among many options unless you are able to apply previous experience to new situations?\nBreaking until you make it is especially important to boost confidence in large corporate environments that are rife with restrictions and gatekeepers. A fear of a failure forces people to make wrong decisions – subnets with laughably small CIDR ranges, a VPC with only two subnets, under provisioned capacity for workloads, etc.\nPersonal experience becomes even more important as systems under management grow in number, size and complexity, which they always do 😊.\nExperienced engineers always find the best solution for their end-users. They could always put themselves in the shoes of their clients. Inexperienced ones take the deceptive path of the least resistance and provide sub-optimal solutions. Their insecurities augmented by fear of failure force them to stick to what they know which is to say repeat the same solution as frequent as possible.\nExperienced engineers create opportunities and are a driving force behind new projects. Inexperienced just wait to be told.\nAnd when I say experienced, I don’t mean old, but simply having the attitude and patience to try new solutions in a fail-fast fashion until the optimal or good enough solution is found. From experience we learn that the only constant in our work is change. What worked yesterday, might not be applicable today.\nPanta Rei, everything flows. You cannot descend twice in the same river. Or, in the words of the famous ferryman from Herman Hesse’s Sidharta book - Much can be learned from a river.\nSo, what is a DevOps? # Learn you some Git and software engineering, don’t be shy of talking to strangers and afraid of breaking things. Everything else comes with the experience.\n","date":"February 20, 2022","externalUrl":null,"permalink":"/posts/whats-devops/","section":"Posts","summary":"Initially, I wanted to name this blog “Uneducated DevOps” in homage to the Uneducated Economist, street level thoughts, opinions, analysis and perspectives from a working-class point of view, but my better half thought I could do better with my choice of adjectives.\n","title":"What's a DevOps?","type":"posts"},{"content":"This blog started as a demo for static content generators on IPFS as a great alternative to clunky, expensive, insecure, hard to manage and scale CMS platforms like WordPress.\nI thought HA, no back-end infra to manage, applications rich in features, and easy to automate deployments would impress my audience, but although they liked the demo, they failed to see how WordPress could be de-throned.\nMy blog will live to fight that argument another day. In the meantime, I’d be happy to use it as a vent for articulating all the internal discussions taking place in the back of my consciousness about projects I’ve done, plan to do or playing with for various reasons.\nOn the importance of writing # I love reading Nathan Martz’s blog since discovering Clojure first and then his project Apache Storm, a real time stream processing engine. Those were the days when I was immersed in BigData technologies and projects. He is a great writer and simply suggests writing makes you a better reader and smarter.\nWe become more receptive to other people’s ideas and learn how to structure our train of thoughts to be better understood. Instead of wasting energy on unproductive counter claims, for the sake of an argument, we are more likely to engage in meaningful discussions by focusing on the important parts.\nWe are all indebted to great writers to become what we are. Without any expectations on readership of my personal musings I will find a great pleasure in sharing my experience and work with no one in particular.\nTo be alive # More literally inclined minds would note that we write to be alive, make art of everyday DevOps moments.\nI cannot recall if I felt adventurous in the search for a new life perspective when I started writing. As the time passed, I for sure felt more alive and connected to others. Writing has been the best medium for reaching to various audiences at work. People who would find my writings interesting would invite me for talks within their communities which would give me opportunities to get familiar with their work, and this in turn would provide me more material for future writings, talks and demo. I’d become a regular, and sometimes start a project, with them based on these exchanges.\nOn those occasions when I ventured outside the corporate walls to present my work or ideas, I was always met by curious minds which just increased my enthusiasm for writing and giving public talks. Exchanging ideas with the outside world is especially important to mitigate the risks created by cognitive biases. The longer you work with the same group of people the higher the risks. If you deny this maybe it is time to go out and give a talk in front of total strangers 😊.\nChronology of ideas # I wished I started writing earlier if for nothing else to document some ideas or projects. I’d be happy to read my writings with some time distance between us, trying to understand my motivations and reasoning behind my ideas. Would I recognize myself in my writing? Does it mean I have evolved as a writer if my old writing feels unpolished, imprecise or unfocused?\nIt’s an interesting thought worth exploring. I will know more soon.\n","date":"February 13, 2022","externalUrl":null,"permalink":"/posts/why-write/","section":"Posts","summary":"This blog started as a demo for static content generators on IPFS as a great alternative to clunky, expensive, insecure, hard to manage and scale CMS platforms like WordPress.\n","title":"Why write, really?","type":"posts"},{"content":"","date":"February 13, 2022","externalUrl":null,"permalink":"/tags/write/","section":"Tags","summary":"","title":"Write","type":"tags"},{"content":"My DevOps blog has been long overdue. I just couldn’t find the time or the right platform to host it. WordPress or Drupal would not cut it. I helped friends to use them but was never attracted to them. What to say of bloated, badly engineered, and hard to manage apps that forces its users to become MySQL experts?\nThe turning point came when I got exposed to IPFS and was eager to show case it in combination with static Web site generators like Hugo or GatsbyJS as a modern, lightweight, and cost-effective alternative to traditional CMS mastodonts.\nThe revolution didn’t happen …yet, but once that point was reached, there was no turning back. IPFS was just a stepping stone to the world of decentralized technologies that is blockchains, decentralized apps and identities combined with economic incentives to minimize waste and maximize certain outcomes.\nWe are witnessing history. Traditional banks, that are still using fax machines for the simplest wire transfer of money, are going the way of the dodo while at the same time decentralized technologies are reshaping the Internet and democratizing access to cloud services.\nIt would be interesting to see how these developments will affect Kubernetes and DevOps. There might be little if any infra to automate, dApps don’t need orchestration and execute in users browsers, downtime as a concept might cease to exist, identities are decentralized and bound to users’ blockchain wallets, cryptography is foundational block of blockchains which makes them inherently more secure and a great platform for trustless computations.\nWhile thinking of the future I am helping my employer to automate the cloud and manage everything as code. The biggest challenge has always been how to do that effectively as an organization with ever growing infra and teams managing or using it while the proverbial tech ground beneath your feet is continuously shifting.\nIf nothing else, I’ll try to document this journey and share my experiences with the world. I know it’s a cliché, but I am standing on the shoulders of others who have influenced my views and helped me become what I am today. Sharing is the least I could do to maybe help someone embrace Kubernetes in the cloud amidst mind numbing plethora of choices.\nWhether I’d go back in time and mention things when Apache Ant was all the rage for automation would depend on my mood for the search of lost time.\n","date":"July 1, 2021","externalUrl":null,"permalink":"/about/","section":"Dimitar Georgievski","summary":"My DevOps blog has been long overdue. I just couldn’t find the time or the right platform to host it. WordPress or Drupal would not cut it. I helped friends to use them but was never attracted to them. What to say of bloated, badly engineered, and hard to manage apps that forces its users to become MySQL experts?\n","title":"About","type":"page"},{"content":"I’d argue if your users are not contributing to automation of the infrastructure and cloud services, they care the most than you are a sys admin in disguise.\nI’ve been frequently in a situation when a developer or data engineer would approach me and ask me for help with the automation of some complex workflow with cloud services I’ve never used before. After looking at the diagram I usually give them a deal – I teach them how to automate their solution in the cloud, but they’d have to do it over a GitHub repository following our best DevOps practices while I and other DevOps engineers are involved in the PR reviews of their code.\nI haven’t met a single person that has refused this offer. Without ceremony we jump next on ensuring their working environment supports Infra-as-code (IaC) tools and services. Sadly, MS Windows is still a bit of a challenge for some of them, but things are rapidly improving on this front with the introduction of WSL2.\nEngaging users works well in start-ups where it is an absolute necessity, you might be the single DevOps supporting ever growing cloud infra, but this approach is also applicable in large organizations like John Wiley \u0026amp; Sons, my current employer with infra spread globally across different cloud providers.\nSo, how do you recruit DevOps from the ranks of your users? It usually follows this pattern:\nTalk to everyone, anytime and anywhere. I’ve stopped counting the number of projects I’ve started just by talking to people by the coffee machine or while going together for a casual jog during a lunch break. Teach them git and explain them that Git is all you need to know Find a real project – or risk forgetting everything you’ve learned. Rinse and repeat Talk to everyone, anytime and anywhere # Besides being a good listener, after all we are trying to solve real problems, be ready to explain complex concepts on the back of a napkin on a small notice.\nI’ve done countless presentations about Kubernetes to groups and individuals who’d contact me because someone I knew sent them my way. Sometimes that meant I dropped other things I was working on to give them the info they needed to understand if Kubernetes would be a good fit for their use case. I find those interactions very rewarding even on a personal level regardless of the outcome. I get in touch with great individuals with whom I might collaborate in the future if not immediately.\nGit is all you need to know # Depending on the users’ experience with Git we spend some time on Git workflows and what that means in terms of collaboration and releasing changes to different environments. If there is one message newbies should take home is the importance of using Git and branching strategies when collaborating with others over the Internet. Everything else follows out of this and it is easy to automate once it is managed in some source code repository.\nSome of the users have been so good at this I’ve told them if they ever plan to change career tracks, they should consider joining some of our DevOps team. The education goes both ways. Users learn something about DevOps best practices, and at the same time DevOps learn first-hand about the intricacies of the infra and services they are expected to support in the future.\nOthers needed more time to absorb the differences between GitHub and Git, but once that chasm was bridged, they were off to the races and started contributing and innovating.\nThere are no stupid questions and show empathy for the awkward first steps of your users. Learn by failing and don’t be afraid to fail.\nFind a real project # Working on a real project is one of the skin-in-the-game factors that increases the chances of success of engagement tremendously. I’ve seen too often people forget everything they’ve learned in some online course for the simple reason they never apply the newly acquired knowledge to their projects.\nMore importantly no training covers challenges encountered in real-life projects. These challenges prompt discussions whose outcome is always the refinement of the architecture of the infrastructure to the satisfaction of all involved.\nMy role here is to really educate and guide users, answer their questions, and address their concerns. I look over their shoulder and perform PR reviews. They do all of the work.\nInitially the biggest obstacles to engaging others as DevOps come from the security team. All those unknown users are potential security threats to them. The answer to their concern is developing a trust in the process by providing total transparency, granting least privileged access to resources, performing reviews, auditing users’ actions, separating code from secrets, scanning code for vulnerabilities, and good monitoring and alerting.\nThe Sec team realizes fast, ok maybe not so fast , that it’s in their best interest to educate users in best security practices instead of managing Sec Groups manually over protracted periods of time. Users always find a way to get what they want but that might create sec holes in order to circumvent the block standing in their way. Not to mention they’ll consider you an annoyance that needs to be avoided at any cost.\nRinse and repeat # Once empowered users usually come back with new projects, start contributing with new modules, or fix your issues you never had time to fix yourself \nAn example of a successful DevOps transformation # A seasoned DBA engineer, yes DBA is still a thing but we are converting them fast to DevOps, had no previous knowledge of Git but he understood the importance of automation in the cloud. In the first month we’ve covered a Git, collaboration over GitHub and using Terraform for IaC automation.\nIn the second month this person has identified and applied alone an Open Source Terraform project for provisioning Couchbase clusters in AWS, which he contributed to the common DevOps infra GitHub repository.\nThis success inspired him so much that he is now working on managing databases in Kubernetes with Operators, which is our next chapter in conquering Kubernetes.\n","date":"July 1, 2021","externalUrl":null,"permalink":"/posts/everyone-is-devops/","section":"Posts","summary":"I’d argue if your users are not contributing to automation of the infrastructure and cloud services, they care the most than you are a sys admin in disguise.\n","title":"Everyone Is A Devops Now","type":"posts"},{"content":"","date":"July 1, 2021","externalUrl":null,"permalink":"/tags/git/","section":"Tags","summary":"","title":"Git","type":"tags"},{"content":"","externalUrl":null,"permalink":"/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"}]