Page 190 - Hands-On Bug Hunting for Penetration Testers

Other Tools Chapter 11

Yes. Moving to an all-cloud workflow takes away a lot of the say you have over your
environment. Because your data is all in cloud storage (from a technical perspective), you
have no control over it. In addition, none of your workflows can be ported over to another
system, considering all your integrations, the interaction of all your tools, and so on, occurs
on opaque layers of the stack you can't rely on accessing.
In the case of a paid tool, does it integrate with an outside workflow (incoming and
outgoing webhooks, either client libraries in several languages or a RESTful interface)? Or
does it lock you into its system?

This is a similar, related question to the general one about vendor lock. The previous
question is more about the compatibility of your overall design, and whether that general
workflow (and architecture) is portable. This question is more about integrating around the
edges. Can parts of your existing workflow be incorporated? If the new tools works great
for everything but X, could you still incorporate that in some way? Through a common
data format (JSON, YAML, or XML) or a programmatic API interface, could you extend the
service's functionality?
The answer for SecApps seems to be sort of. There are some basic CLI options for the more
CI/CD solutions, such as their Cohesion app, which is essentially a source code analysis
tool DevOps engineers can drop into their build chain. But there's no documentation about
using an API to interact with the same backend services the browser-based tooling connects
to.

There is a native application wrapper called pown apps, created by Pown.js, but the
documentation is pretty spartan and CLI options are limited (see Does it have a mature
CLI?), and when we navigate to the Pown.js repository, we don't see much to inspire
confidence. Many repositories are new, none have a large contribution graph, and
issue/community support seems haphazard (see also If it's open source, how old is the
project? When was the last commit and what's the general frequency of commits? Are there
a lot of outstanding issues? Are issues addressed?).
That doesn't work for us. As great as the promise of the service is, it's too opinionated about
what our pentesting regimen should look like. Contrary to the Unix philosophy of small,
single-serving components with specialized concerns and the shared Lingua Franca of plain
unicode, SecApps makes us install and use large, complex apps (either through the web or
natively via the pown apps bridge) that we don't have visibility into and can't control.
Other users with different processes around pentesting engagements will naturally have
their own opinions about these and other tools, but hopefully us analyzing these tools
within the context of this book's workflow will illustrate the key decision points and
general process.

[ 175 ]