Kurt Boberg - Staff Security Researcher at r2c

Kurt Boberg: personal site, Twitter, Mastodon, LinkedIn

Tell us a little about your current role: where do you work, your title and generally the sort of work you and your team do.

I am a Staff Security Researcher at r2c. My team wears many hats - open-source vulnerability research, static analysis rule-writing, internal tooling development, and secure source code review, to name a few. My job is a little bit different from the “standard” Staff Engineer role - I spend most of my time on research, design and advocacy.

How do you spend your time day-to-day?

Right now, I spend most of my time working on the R&D side of a new product we are launching this fall. I split my time between exploring customer needs and doing R&D on proof-of-concept technical solutions in the problem space. I am a staff engineer at a startup and we prioritize agility and velocity, which leads to some interesting trade-offs when making tooling and design decisions. Right now I am more of a Solver/Fixer as we learn more about customer pain points and product-market fit. As the product matures, I will spend more time on Architect tasks - designing for scalability, making thoughtful technology choices, and automating as much of R&D’s repeatable work as possible.

I will spend ~5 hours a week in design meetings, checking in with product/engineering stakeholders and other “social” work. The remainder of my time is spent on developing process and automation to allow rule-writing to scale effectively, writing rules, and occasionally building back-office tools to support team objectives. As a smaller organization, I probably spend slightly more hands-on-keyboard time compared to Staff+ at larger, established companies.

You first got the Staff engineer title when you joined r2c. Can you talk a little about the process for finding that role?

I was hired into the Staff title at r2c. On the advice of my longtime mentor John Heasman, I consistently selected my career moves to support an advanced IC role.

My current role was the result of “right place, right time” rather than a dedicated search for a Staff position. Having a leadership title (“Lead Application Security Engineer”) and the experience to back it up made negotiating the title pretty straightforward - if you’ve already effectively done the job, the title is mostly paperwork.

What two or three factors were most important in you reaching Staff? How have the companies you joined, your location, or your education impacted your path?

In-order: Network, planning, education.

1. Peer network. Hands down the most important contributor to achieving a Staff title was my network and peer/mentor group. I chose my first job on the strength of the hiring manager (I was offered a position on several teams at the same company). From there, I met my longtime AppSec mentor and several other “superconnector” peers in the industry. These connections lead to job opportunities, access to mentors in diverse skill sets, and a reasonably good “whisper network” for communicating critical events in the industry.

2. Planning. Within six months of starting my career, I had a five-year plan to be a “professional hacker.” At the time, titles were not a huge part of my plan - I did not have the experience to know what titles mean or how they matter. I did, however, understand that I needed to make some strong connections with people ~5 years ahead of me on their own career paths, headed in the direction I wanted (see item #1).

3. Education. I have a masters degree in computational science (applied computer science) and an undergraduate degree in mathematics. My background did an excellent job preparing me for complex critical thinking tasks, as well as the ability to separate the tool from the problem you are solving. I found my pure-adjacent degree to be a good conditioner for the systems engineering mindset you need to succeed at Staff and beyond.

A huge part of my successful path to the Staff title was my mentor group and their willingness to help me level up. I was particularly impressed with John’s ability to quickly audit large, unfamiliar codebases and that was the first skill I prioritized acquiring. In pursuit of this goal, I learned a valuable meta-lesson about mentoring: communication is lossy and mentees often ask the wrong question. I had to very quickly learn to accept advice that didn’t immediately make sense to me and mechanically follow it without understanding, trusting that “experience would bring enlightenment.” Turns out, there’s no substitute for elbow grease.

In addition to technical prowess, I rapidly discovered (from watching the success of my mentors) that technical skill is table stakes, what makes high-level individual contributors effective is their ability to drive change across a large group - this takes people skills! This was the hardest part of the journey for me: I am an introvert and building the “corporate politics” skill took many years of observation and focused practice.

Some of Kurt’s Public Work

• Building An AppSec Program - People To Know

• Fun With Semgrep

Where do you feel most impactful as a Staff-plus Engineer? A specific story would be grand.

Design and technology choices feel most impactful to me, with a side of “culture of documentation.” Choices I’ve made on my current project are being back-propagated into our existing codebase and many of our emerging standards are based on opinions of mine. I am also a champion of documentation within our organization, which has significantly improved onboarding for new team members since I joined early in 2022.

Can you think of anything you’ve done as a Staff-plus engineer that you weren’t able to or wouldn’t have done before reaching that title?

I have a lot of cultural influence with my current title that I struggled with even with my previous relatively-prestigious “Lead” title. Also, expectations around hands-on-keyboard work are a little different - short bursts of high impact work in between research, outreach, and education are normalized or even preferred over focused “deep work” output.

What Staff Engineer archetype do you consider yourself? Why?

I am most closely aligned with Solver/Architect, though I have been all 4 at some point in my career. I enjoy “the chase” of solving difficult problems and the breadth of knowledge and experience that comes from “firefighting”, as well as building in “fire resistance” to new projects so I can spend more time elsewhere.

Did you ever consider engineering management, and if so how did you decide to pursue the staff engineer path?

I briefly tried engineering management. I enjoy mentoring but I do not find the active, consistent work of managing engaging and frankly, I was not a very good people manager.

How have you sponsored other engineers? Is sponsoring other engineers an important aspect of your role? We’d love to hear a story.

Any sponsorship of engineers I have done has been via shedding impactful work to other engineers and using my relative position of authority to ensure leadership is aware of their contributions to said work. Leveling up the people around you is the highest-leverage work you can do.

What are some resources (books, blogs, people, etc) you’ve learned from? Who are your role models in the field?

Schneier’s Applied Cryptography, Anderson’s Security Engineering, and ye olde RFCs/NIST publications. Standards are incredibly useful for finding weird joints between systems/protocols/implementations. Some of my role models in the field (in no particular order):

• John Heasman, CISO @ Chegg, formerly DocuSign, NCC Group, NGS

• Silvia Botros, former Principal Engineer @ Box

• David Wong, Senior Cryptography Engineer @ O(1) Labs, formerly Facebook, NCC Group

• Ian Coldwater, Director of Offensive Security @ Twilio

• Clint Gibler, Head of Research @ r2c (and a big part of why I took the job I have now)

What about advice for someone who has just started as a Staff-plus engineer?

Delegation is hard, especially if you are a talented engineer. You have probably gotten where you are in no small part due to a surplus of competence in one or more technical disciplines. You need to remember that sometimes, simple tasks for you are excellent learning opportunities for those around you, for an insignificant time penalty relative to other inevitable scheduling delays and other side-effects of bureaucracy. If you don’t need to personally handle a task, it is often worth delegating to someone else.

Do you spend time advocating for technology, practice, process or architectural change? Can you share a story of influencing your organization?

Yes, I have spent time advocating for pretty much all of the above. My biggest success story was actually at a previous job - Staff-in-all-but-name. I got a ~400 person engineering organization to adopt a “batteries included” authorization scheme for GraphQL as part of a major initiative to migrate all legacy API behavior from RESTful services to a more modern technology stack. Authorization is not part of the original specification and missing or broken access control is a recurring problem with many early adopters of GraphQL. I strongly advocated for authorization considerations early in the design process which lead to a launch with basically zero authorization issues in a collection of services notorious for broken access control.