Edition 2: "Questions a good inventory should answer"

Software inventories are hard to build and even harder to maintain. If they don't serve a specific purpose, it is not worth all the effort. It's useful to define exactly what you are looking for.

In the first post of this newsletter, I penned down thoughts on getting started with software inventories. If you are now convinced (or if you always were) to build one, it’s important to clearly define why you need one. In addition to helping you keep focus, a clearly defined goal also helps you sell the idea to other stakeholders in your company.

Simply put, the goal of an inventory is to help you make security decisions with data, instead of just instinct. For e.g.: You (or someone on your team) may instinctively know what are the riskiest apps on your portfolio. While this approach may get you all the low hanging fruit quickly, it’s hard to scale intuition. It also makes decisions hard to audit (“why did we decide to pen test this app in 2019?”) in the future.

Here are some questions a well-designed inventory can answer with more precision than intuition:

1. What are the riskiest apps in our portfolio?

2. What apps have known high risk security defects?

3. What apps hold PII data (replaced PII with financial information, business critical information or whatever else makes sense for your business)

4. What apps runs on infra component C (this could be a sub domain, K8S cluster etc.)

5. What apps use Data source D (D could be an S3 buckets, a database, filesystem and so on. Make it more pointed by asking “what apps write to Data source D”)

6. Who owns app A? (quite possibly the hardest piece of data to keep current. Especially in large-ish organizations.)

7. What apps on our portfolio uses software component S (useful when new CVEs are published)

8. What apps are internet facing?

Each of these questions can be further drilled down into other questions. Sometimes “counts” are more interesting than lists (e.g.: How many High risk apps do we have in our portfolio), it makes sense to add those too.

Answers to the above questions can help you make AppSec decisions in an informed manner. For example:

1. Which apps should go through a penetration test this year?

2. Who should we contact if we get a report of an attack on app A?

3. Which department needs most assistance/attention from the Security team?

The exact questions can/will evolve over time, but having a framework helps immensely.

That’s it for today! If you have a tip that has worked, drop me a line on twitter, LinkedIn or email. If you find this newsletter useful, do share it with a friend, colleague or on your social media feed.