DEV Community

Cover image for Bulwark Advisory: From Hands-On Security Work to a Focused Product Security Practice
Ivan Piskunov for Bulwark Advisory

Posted on

Bulwark Advisory: From Hands-On Security Work to a Focused Product Security Practice

Introduction

For years, I had already been doing many of the things people associate with running a consulting practice. I wrote technical and commercial proposals, scoped projects, discussed pricing, negotiated contracts, performed security assessments, worked directly with customers, and sometimes delivered the actual work behind another company's brand.

I just did not have a company name for all of it. Around 2017, I was already experimenting with promoting my own cybersecurity services through professional communities and social platforms in Russia. Later, I worked independently, registered as self-employed in Moscow, performed contract work for other companies, and helped build and sell cybersecurity services inside established businesses.

So when I eventually created Bulwark Advisory, I did not wake up one morning and suddenly decide to become a cybersecurity entrepreneur. By that point, most of the underlying work had already happened. The company came last.

A Business Built After the Experience, Not Before It

I have already written about the longer version of my career story, from my first years in cybersecurity to hands-on engineering, offensive security, leadership, research, consulting, and entrepreneurship.

Bulwark Advisory is not a break from those stories. It is one of the consequences of them. For a long time, my professional identity was simply my name: Ivan Piskunov. My articles, research, GitHub projects, conference work, consulting, teaching, security reviews, and public materials all existed under that name. That worked well for years.

But over time, the work itself became broader than a personal profile page could explain in a few lines. There was a clear pattern in what I was doing, the kind of problems I was best at solving, and the kind of clients I wanted to help. At some point, I needed a professional home for that work.

I Had Already Been Learning the Commercial Side for Years

One thing I learned fairly early is that technical expertise alone does not create a consulting business.

You can be excellent technically and still be terrible at turning that expertise into a service another company can understand, buy, and use. Over the years, I had to learn the other side of professional work too.

I prepared proposals. I discussed budgets. I estimated effort. I negotiated contracts. I had to explain what the client was paying for and what result they should expect. I had to define scope clearly enough that both sides understood where the project started and where it ended. I also learned how different selling a security service is from actually delivering it.

A proposal can sound impressive and still lead to a useless project. A report can contain hundreds of findings and still fail to help the people responsible for the product. A consultant can be technically correct and still create more confusion than value.

  • That changed how I think about consulting.
  • The client does not need the longest report.
  • The client does not need the largest number of findings.
  • The client does not need more security theater.
  • The client needs a useful outcome.

Sometimes that means a clear architecture decision. Sometimes it means a prioritized remediation plan. Sometimes it means putting security controls into CI/CD. Sometimes it means helping leadership understand which risks actually matter. Sometimes it means telling a company that something does not need to become an urgent security project at all. That kind of judgment only comes from combining technical depth with experience, context, and business understanding.

Product Security as the Focus

I have worked across different areas of cybersecurity during my career. I came through technical work. I spent time in offensive security. I worked with systems, application security, DevSecOps, cloud environments, architecture, security engineering, leadership, and program development.

All of those areas influenced the way I work today. But I do not believe that having experience in many parts of cybersecurity means I should sell every cybersecurity service that exists. I do not want Bulwark Advisory to become another company that claims to do everything from penetration testing and forensics to SOC operations, awareness training, compliance, incident response, cloud security, and twenty other unrelated services.

That is not the kind of company I want to build. My strongest focus today is Product Security. To me, Product Security is the place where security, software engineering, architecture, cloud, DevSecOps, automation, and business risk meet.

It is not simply application scanning. It is not just penetration testing. It is not a checklist before release. It is the broader question of how software is designed, built, tested, released, and operated in a way that reduces risk without making engineering slower than it needs to be.

That philosophy is very close to how I think about Product Security. My offensive background still matters. It helps me look at architecture, trust boundaries, attack paths, and assumptions differently. But the purpose of my work today is not to prove that something can be broken. The purpose is to help companies build products that are harder to break in the first place.

From Personal Expertise to a Company Structure

Bulwark Advisory is intentionally founder-led. I stay involved in discovery, technical analysis, architecture, prioritization, workshops, delivery, and recommendations. I did not create the company so that my name could disappear from the work. I created it so that the work could have a clearer structure.

That distinction matters to me. The company gives clients one place where they can understand what I do, what I do not do, what kind of problems I work on, and how I think about security. But the responsibility is still personal. If I put my name behind an assessment, a recommendation, or a security program, I need to be comfortable defending it technically and professionally.

The Kind of Consulting Business I Want to Build

My principles are simpler.

  • Be clear about the scope.
  • Be transparent about the commercial terms.
  • Keep bureaucracy as low as possible.
  • Do not invent urgency.
  • Do not sell work that is not necessary.
  • Stay technically serious.
  • Communicate directly.
  • Finish the job.

And if the client needs help again later, be there. I value long-term professional relationships, but I do not believe long-term relationships should be created through dependency. They should be created through trust. If a client comes back six months later because the previous engagement was useful, that is the kind of repeat business I want.

The Commercial Part Is Not Something I Hide

I also do not want to create a romantic story in which money somehow does not matter. Bulwark Advisory is a commercial business.

I want it to make money. I have never believed that useful professional work becomes less honorable because someone pays for it.

Expertise has value. Time has value. Good judgment has value. Years spent learning from failures, projects, mistakes, incidents, architecture decisions, audits, research, and leadership have value too.

The important question is not whether a business makes money. The important question is how it makes money.

I do not want growth to depend on selling unnecessary tools, creating fear, inflating project scope, or convincing every client that they need every cybersecurity service imaginable. I would rather solve real problems and charge fairly for solving them. That is a much simpler business model. It is also the one I can respect.

Proof in Public

Publishing what I learn has been part of my professional life for years. I did it before Bulwark existed, and I intend to keep doing it.

Over time, I have written articles, shared technical notes, published research, created guides, built repositories, and documented practical security work because I believe useful knowledge becomes more valuable when other people can learn from it.

One of the clearest examples is my Product Security Knowledge Base.

It contains material on Product Security programs, Secure SDLC, threat modeling, application security, DevSecOps, cloud, Kubernetes, software supply chain security, security automation, metrics, leadership, and other areas I work with regularly. The same principle now applies to Bulwark Advisory on GitHub, where I publish practical material around Product Security engineering and program development. There is also Bulwark Advisory on DEV Community, where I continue publishing technical and professional material under the company brand.

If I say that I know how to build a Product Security program, people should be able to see how I think about one. If I talk about DevSecOps, CI/CD security, cloud security, or engineering practices, there should be something more substantial behind those words than a service description. A potential client should be able to read the material, review the repositories, look at the methodology, and decide whether the way I think makes sense for their organization. That is a much better starting point for a professional relationship than a generic sales pitch.

The Next Chapter

I spent a large part of my career learning how security works. Then I had to learn how engineering works, how organizations work, how clients make decisions, how services are sold, how contracts are negotiated, how risk is explained, and how professional reputation is built over time.

Bulwark Advisory is where those experiences finally meet.

I do not know exactly what size the practice will become or what it will look like ten years from now. That is part of the journey. What I do know is what I want it to stand for: technically serious work, honest communication, clear commercial terms, useful results, and security that helps good products become better products.

  • I want to continue working directly with technology.
  • I want to continue publishing what I learn.
  • I want to help engineering teams build security into products without turning security into unnecessary bureaucracy.
  • I want clients to understand exactly what they are paying for.
  • And yes, I want to build a healthy commercial business around expertise I spent many years developing.

After more than fifteen years in cybersecurity, this does not feel like starting another career. It feels like finally putting my own name on the door.

Links

Top comments (0)