As I move away from Twitter/X, Reblog is my attempt at recreating the way which I would share blogposts and add my own commentary to them. Any likeness in naming to my prior life as a Tumblr kid is completely incidental.

This week, Ross Haleliuk wrote a guest blog post for tl;dr sec on the similarities between the evolution of pentesting and quality assurance. While this article can stand alone, it’s heavily intertwined with a linked article on the rise of security engineering. I recommend reading both of these, and the thoughts here represent ideas on both of these articles.

First off, these articles specifically target the process of enterprise/corporate cybersecurity. While I agree that security engineering will almost certainly be the future of pentesting & product security in general, for some people, pentesting is a fun hobby. If that’s you, then keep pentesting the way that makes you happy; I know that I’ll continue to decomplie things in Ghidra long after Angr or whatever comes out of the AIxCC competition makes that pointless, because messing with those things makes me happy. Your hobby/fun activity doesn’t need to be maximally efficient (something that I often like to remind myself). That being said, lets put on our “product security engineer”/”part of the infosec machine” hat.

Anyone who has tried to retrofit the traditional internal pentest process onto an Agile or Agile-like development structure knows that it’s the equivalent of trying to catch an eel in a stream with your bare hands. Traditional penetration testing methodologies focus on a holistic analysis of a specific product or service, and for good reason, as often the integration points of changes are where the largest assumptions, and thus the largest security holes, can be. However, even finding an environment (that isn’t production) upon which you can do a kind of stable testing can often be challenging in Agile/Agile-like companies.

One solution I’ve seen companies take in the past is that of a “Agile psuedo-pentest”, where a “light pentest” is conducted at the end of each Agile cycle. In order to avoid scope creep, these pentests are scoped to only the feature being changed. While this keeps with the spirit of Agile, it does not keep with the spirit of pentesting, and often findings will come up that are not directly associated with this feature, but with the integrations around it, or with something else in the service that has no connection to the feature. This can lead to tense situations with developers, who acknowledge they have a problem in the system, but don’t have the cycles to fix things outside the scope of that feature.

Instead, the method I advocate for is to keep the pentest as a regular, fully scoped event, and focus on a more Agile-like method for the intermittent testing of security properties between pentests. This is also what the pentesting article calls “continuous testing”, though what that actually entails is hand-waved at. While the article proposes this as the “evolution” of penetration testing, I would instead push for it as a new kind of security testing, which can compliment the penetration testing process.