OWASP Jupiter

= Main = 

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
 * style="border-right: 1px dotted gray;padding-right:25px;" valign="top" |

OWASP Jupiter - Application Inventory Management System
= Defining Application = What is an application? Asking that question to five different people will probably yield five different answers. In terms of what the Jupiter Application Inventory Management System considers an application, it can be thought of as a singular module or code project unit that is built and deployed independently (aside from data or operating environment dependencies).

Taking another step, an application has certain attributes. It has a name. It has a codebase and thus a code repository. Where is that repository? It might have a team that supports it and somebody who is ultimately responsible for it. Who owns it? These are the types of questions Jupiter helps to solve.

Data collected includes:
 * Common Name: The most widely known or current name of the application
 * Aliases: Other names the application might have or have had previously
 * Description: A brief synopsis of the application’s purpose for existing
 * Code Repository URL: The location where the application’s code is stored and versioned
 * Binary Repository URL: The location where build artifacts are stored and versioned
 * Primary Language: The most prominent programming language used in the application’s codebase
 * Secondary Languages: Additional programming languages used in the application’s codebase
 * Type: Applications might have a particular role inside of an application ecosystem, such as a microservice, user interface, batch job, etc.
 * Primary Owner: A person who has ultimate responsibility for the direction or well-being of the application
 * Secondary Owners: Other people who may be delegates of the Primary Owner
 * Business Unit: Particularly important in large organizations, this is the specific group within the organization to which the application belongs
 * Exposure: Applications have varying ways they can be exposed – internal to the organization, publicly available on the internet, or to a select group of users
 * Number of Users: The number of users (or an estimate) of the application
 * Data Classification: Many organizations have a data risk classification hierarchy and applications may fall into one of the categories
 * Deployment Environment: Because the Collector captures information at the build and deployment stages, the specific environment to which the build is destined can be recorded (e.g. QA, UAT, Production, etc.)
 * Deployment Environment URL: Correlating to the Deployment Environment, this is a URL for the application if it is a web application or service
 * Risk Level: Many organizations have formal risk levels that determine prioritization of resources aside from data categorization (can be a factor of data classification and exposure)
 * Regulations: Applicable regulations such as PCI, SOX, HIPPA, etc. can be listed
 * Chat Channel: Many application development and support teams have a way to communicate with each other and to collaborate within their organization such as Slack or Glip
 * Agile Scrum Board URL: Development teams often keep a list of their in-flight work and backlog in a project tracking system such as Jira or Redmine
 * Build Server URL: The CI server from which the recorded build or deployment originated
 * Age: Applications can have a long life and understanding a given application’s age can help determine risk and gauge other implications
 * Lifecycle Stage: Similar to age, an application can be New, in a Maintenance steady-state, or in Retirement
 * Last Deployment Date: The last date on which the application was deployed

High Level Design

 * style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" valign="top" |

Project Resources
Source Code

Project Leader
Matt Stanchek

Classifications

 * }

= Roadmap =

Jupiter Application Inventory Management System Roadmap

 * 1) Collector Service
 * 2) Authentication
 * 3) * Utilize Auth Service for JWT validation
 * 4) Authorization
 * 5) * Based on JWT payload, enforce restrictions on CRUD operations
 * 6) Database Connectivity
 * 7) *Update Mongo connection code to update deprecated connection method
 * 8) Input Validation
 * 9) *Input length checks
 * 10) *Input type checks
 * 11) Data Fields
 * 12) *Enable data fields beyond Common Name and Primary Owner
 * 13) Containerization
 * 14) *Prepare Dockerfile
 * 15) *Build Docker container
 * 16) *Deploy and test Docker container
 * 17) Curated Inventory Service
 * 18) Authentication
 * 19) *Utilize Auth Service for JWT validation
 * 20) Authorization
 * 21) *Based on JWT payload, enforce restrictions on CRUD operations
 * 22) Input Validation
 * 23) *Input length checks
 * 24) *Input type checks
 * 25) Data Fields
 * 26) *Enable Application-specific data fields beyond Common Name and Primary Owner
 * 27) *Enable capture of Collector Service instance ID
 * 28) Data Integrity
 * 29) *Restrict Common Name to unique values
 * 30) Containerization
 * 31) *Prepare Dockerfile
 * 32) *Build Docker container
 * 33) *Deploy and test Docker container
 * 34) Auth Service
 * 35) Authentication
 * 36) Enable LDAP authentication
 * 37) *Build LDAP integration capabilities
 * 38) *Based on successful username/password LDAP authentication, provide time-limited JSON Web Token for subsequent requests
 * 39) *Enable facility to validate expiration of tokens and deny access to expired tokens
 * 40) Authentication
 * 41) *Define user roles (administrator, reader, creator/updater)
 * 42) *Enable issuance of tokens that restrict access based on user role
 * 43) Management Console
 * 44) Base Architecture
 * 45) Add Local SQLite Database
 * 46) *Enable saving of configuration and preferences
 * 47) Authentication
 * 48) Collector Services
 * 49) *Build an interface to allow configuration of Collector Services
 * 50) Curated Inventory Service
 * 51) *Build an interface to allow configuration of Curated Inventory Service
 * 52) Data Fields
 * 53) *Enable Application-specific data fields beyond Common Name and Primary Owner
 * 54) External Integrations
 * Consistent naming across multiple external Application Security tools will allow for greater future automation and reporting as well as utilization.
 * 1) *Enable set up of Application in Fortify Software Security Center
 * 2) *Enable set up of Application in OWASP Dependency-Track
 * 3) *Enable set up of Application in OWASP Defect Dojo
 * 4) *Enable set up of Application in OWASP SecurityRAT
 * 5) User Experience
 * 6) Antecessors
 * 7) *Aggregate all Collectors’ data in available Antecessors list when there is more than one Collector Service defined
 * 8) Jenkins Collector Plugin
 * 9) Input Validation
 * 10) *Input length checks
 * 11) *Input type checks
 * 12) Connectivity Validation
 * 13) *Add a “Test Connection…” button to the Global config screen to test the Collector URL and token
 * 14) Data Fields
 * 15) *Enable Application-specific data fields beyond Common Name and Primary Owner under “Advanced”

= About Jupiter =

FAQ
Q: Why is this project named "Jupiter"?

A: In 2001: A Space Odyssey, the Discovery One embarked on a mission to investigate the signal sent from the monolith on the Moon to Jupiter. In 2010: The Year We Make Contact, the crews of the Discovery and Leonov witness countless monoliths emerge from Jupiter before it is converted into a star. Aside from the cool sci-fi reference, there is an analog to what this project is for -- to start with a small amount of information about software applications in an organization's portfolio and build upon that knowledge to find more.