The first step in creating your programme brief, which you should undertake if you’ve decided that you and your business are willing to invest the necessary time and resources to administer a bug bounty programme, is setting the programme scope. Defining your programme scope involves choosing what needs to be tested, specifics of your software and many more important factors. Since all of this is essential, a good basis for your defining your scope becomes necessary.
Setting the programme scope is the first stage in developing your programme brief, which you should do if you've decided that you and your company are prepared to devote the required time and resources to operate a bug bounty programme.
It is crucial first to decide what you want to be tested. Since this varies greatly depending on the business or necessity, we assume you already know what you want to have tested.
The needs and objectives of your software are clearly communicated to hackers by having well-defined scopes. This gives hackers a better understanding of what you want them to concentrate on and how to prioritise their time.
Here are some valuable pointers to aid in defining and establishing your scope:
· Give specificity: There is less potential for misunderstanding the more clearly each asset is identified. Do not use a wildcard to combine many domains into a single asset. Keep your blog.yourprogram.com separate from secure.yourprogram.com, for instance.
· List Assets that are out of scope: Having elements that are outside the scope is quite acceptable, common, and even encouraged. Do you have an "associated site" that is entirely separate and is run by a different person? Write "out of scope" next to it. The hacker who spent hours hacking it won't be surprised when you identify assets as out of scope, and you won't be surprised when you try to explain, "We do not own that property" after the fact.
· Know and understand your attack surface: Knowing and comprehending your attack surface will enable you to more clearly communicate to researchers what is and isn't in scope, guaranteeing that you receive the desired programme outcomes. You run the risk of either (a) researchers testing too little of the app or (b) researchers testing outside of what you had expected as the desired scope if the attack surface isn't completely understood.
· Clarify bug bounties for the assets: Offering bug bounties just for certain assets and gradually expanding that list over time is considered to be the standard best practice. By expressly whitelisting the assets that are subject to bounties, you may create realistic expectations for hackers. Please include any pertinent details in the directions field. Oversharing aids in avoiding future conflicts.
· Set the Environmental Score for the Asset: The asset's level of vulnerability is determined by the environmental score. These three measures can have an environmental score set:
1. Confidentiality: Determine if the data being gathered is truly confidential to their firm, i.e., determine whether there is a danger to the business if the data is released.
2. Integrity: The danger to the business if the data is altered.
3. Availability: The risk to the business depends on whether the component is online or not.
Always assess your scope objectively; a good rule of thumb is to write your scope such that it cannot possibly be misconstrued rather than merely so that it may be comprehended.
Different targets have different needs. It's vital to keep in mind that, like any other force of nature, researchers will choose the route that has the fewest obstacles because such applications naturally experience less activity than those that present more obstacles. Consider your program's objectives as well as your security priorities when developing your program scope.
