App Meta Security Information

When we implement security programs, we often advise clients to build an inventory of their applications. There are a lot of
things we can do when we know what our inventory is. We can do this right in the available tools developers are already using.
This post covers one way to do this.

App Inventory

When we know what applications we have, we can effectively plan what work needs to be done for each one.

If we have 10 apps with secrets hard coded in the repos, we can track that until all 10 are remediated.

If we have 1,000 apps that need to have dependencies updated, we can start to put a plan in place that
allows us to do that over time.

Most of the time, most companies we know, don’t do a great job of tracking information about applications,
automating the collection of and making that data accessible or visible.

Use What You Already Have

Most projects we see these days are using some git variant—BitBucket, GitLab, GitHub, ProjectLocker, etc.
Since developers are already using these platforms to store code, what if we just put the meta information
in the repo with the code?

So the imagine if we add a new file in every repo: /appmeta.json.

Now we can write a program to list all of the repos for an org and pull out their security state. Well,
as you will see the security state also includes more general information, which is why we called it
appmeta instead of security.json. But of course, you could adapt this practice and do all of this
yourself with just the properties you care about in the scope you want.

Application Meta Information

What meta information do we care about?

At a high level:

  • Overview
  • Support
  • Ops
  • Continuity
  • Security

Security is just part of it.

Consider the following example, which we will go through section by section:

  "name": "",
  "description": "A platform for implementing security programs.",
  "stage": "live",
  "team": "SPIO",
    "slack": "securityprogramio",
    "github": "",
    "plan": "",
    "adr": "docs/adr/"
  "support": {
    "slack": "securityprogramchat",
    "email": "",
    "github": "",
    "documentation": ""
  "ops": {
    "email": "",
    "github": "",
    "documentation": ""
  "continuity": {
    "tier": 2,
    "comment": "Important for SPIO business but not business critical for clients.",
    "email": "",
    "plan": "link"
  "security": {
    "tier": 1,
    "summary": "Contains security information about clients.  Very sensitive.",
    "email": "",
    "github": "",
    "threatmodel": "",
    "soxdata": false,
    "pcidata": false,
    "hippadata": false,
    "piidata": true,
    "codereview": "3/24/2020",
    "training": "1/20/2020",
    "linting": "3/24/2020",
    "securityrequirements": "3/24/2020",
    "securityunittests": "",
    "dependencies": "3/24/2020",
    "staticanalysis": "",
    "dynamicanalysis": "",
    "pentest": "planned",
    "signal": "",
    "audit": ""

Top Level

NameThe name of the project
DescriptionA description
StageWhat lifecycle stage is the system in?
TeamTeam responsible for the project.


Then we have a section about the development of the app. This includes:

SlackThe Development Slack Channel
GitHubThe URL of the project in GitHub
PlanThe location of the development plan
ADRArchitecture decision records

The idea is to make it easy for this information to be collected and distributed beyond
the development team, who undoubtedly already has access to these things and hopefully
knows about them.


SlackThe slack channel for support
EmailHow to reach the support team via email
GithubURL for issues or other project info
DocumentationWhere to get support documentation

If you are using intercom or zendesk or other support tools, you can include those
URL’s here so that it is easy for everyone to find support.


In some cases, we may have an ops team that works in a different set of tools. We
can capture them here for a given project. In the example in this post, it is
basically the same as Dev and Support.


TierThe tier of app. Typically 1 is most critical. (Numeric)
CommentText around the tier.
EmailEmail to use to contact BCP related team.
PlanLink to the response plan.


TierNumeric tier of app. (Programmable)
SummaryText around the tier and app
EmailWho to email about security for the app.
GithubWhere code lives
ThreatModelLink to the threat model (eg. ThreatDragon)
soxdataDoes the app have Sarbanes Oxley related data? (Y/N)
pcidataDoes the app have credit card data (Y/N)
phidataDoes the app have personal health data (Y/N)
piidataDoes the app have personally identifiable information (PII) (Y/N)
codereviewWhen was the last code review? (Date)
trainingWhen was the team last trained on security (OWASP TOP 10) (Date)
lintingWhen was linting last run? (Date)
securityrequirementsSecurity requirements are incorporated up to what date? (Date)
securityunittestsSecurity unit tests are running up to what date? (Date)
dependenciesAutomated dependency checking was run what date? (Date)
staticanalysisWhen was static analysis last run? (Date)
dynamicanalysisWhen was dynamic analysis last run? (Date)
pentestWhen was the last pentest? (Date)
signalSignal function up to date as of? (Date)
auditAudit function up to date as of? (Date)

As you can see there is a lot here. You could remove attributes you don’t care to track.
You could add new ones that you want to track.

Next Steps

We are considering building some automation (think a tool written in Golang or JS) that
you could point at a GitHub Organization and it would iterate through the repositories,
pull this file and compile data - maybe even a semi static web view that would look
like a rich inventory… if you’re interested, let us know. Maybe we can give you
early access to help test.

Share this article with colleagues

Matt Konda

Founder and CEO of Jemurai

Popular Posts

Ready to get started?

Build a comprehensive security program using our proven model.
© 2012-2024 Jemurai. All rights reserved.
linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram