As you are likely well aware, Forge introduces a new way of building apps for Atlassian cloud products where Atlassian hosts and runs apps on behalf of developers. This approach to hosting apps shifts many of the operational and maintenance responsibilities onto Atlassian.
In the context of security, one question that frequently comes up with this shared approach to running apps is “What are app developers responsible for?” vs “What is Atlassian responsible for?” Up until now, answering this would involve scouring the Forge documentation to deduce answers. To help clarify these questions, we’ve built the Forge Shared Responsibility Model (SRM).
The Forge SRM is a living document that expands on the Cloud Shared Responsibility Model to help clarify the division of responsibilities between app developers and Atlassian in the context of Forge apps. This is similar in concept to SRMs you may have seen from cloud providers like AWS or Microsoft Azure. Our goal in publishing the SRM externally is to create clarity around what Forge seeks to ensure from a security perspective, and what you as an app developer should be considering when building and operating your app.
Additionally, we’ve also set out to document the Forge Security Principles to define what Forge apps can vs cannot do by design. We use both the Forge SRM and these Forge Security Principles to guide security design and discussions internally.
Please familiarise yourself with the Forge SRM, as it will continue to evolve with your feedback and the Forge platform. If you have any questions or feedback, please reply to this thread or reach out to us on the Ecosystem Security Service Desk.
A few questions came to my mind when reading the SRM documentation:
Consider establishing a bug bounty program that has your application in scope.
Does that mean that vendors will still have to participate in the Bugcrowd program to get a –badge in their forge-marketplace-listing as we already know it from Connect/Server apps?
Disaster recovery - Atlassian's responsibilities: Ensure data stored by Atlassian on behalf of your app (in Forge data storage) is backed up, and can be restored in an incident.
How does Atlassian achieve this? Given a worst case scenario: an update of a an Forge app causes data loss. How can vendors or developers access (and restore) the data from the backups Atlassian creates? Is there an Api for it? How long will these backups be accessible, what do they contain? – Does Atlassian backup data stored via the Storage Api?
This page is intended to help you understand your responsibilities when building and supporting a Forge app, and what responsibilities Atlassian takes care of.
How does the Shared Responsibility Model play together with the Security Self-Assessment Program in Atlassian marketplace? Will it be sufficient for a Forge app to refer to the SRM to get the according badge? Most of the questions mentioned here are probably answered the same for every Forge app (“how do you create backups, etc.”).
@JulianWolf . Great questions. Will answer the ones that I can and loop in other folks to get the rest responded to.
Does that mean that vendors will still have to participate in the Bugcrowd program to get a –badge in their forge-marketplace-listing as we already know it from Connect/Server apps?
Yes. We are treating Forge apps the same way as other apps for the Bugbounty program.
How does the Shared Responsibility Model play together with the Security Self-Assessment Program in Atlassian marketplace? Will it be sufficient for a Forge app to refer to the SRM to get the according badge? Most of the questions mentioned here are probably answered the same for every Forge app (“how to you create backups, etc.”).
That is correct. If your apps does not use any infrastructure outside of Forge, referring to current documentation is sufficient for the self-assessment purposes.
Thanks for the feedback and great questions @JulianWolf.
Disaster recovery - Atlassian’s responsibilities: Ensure data stored by Atlassian on behalf of your app (in Forge data storage) is backed up, and can be restored in an incident.
How does Atlassian achieve this? Given a worst case scenario: an update of a an Forge app causes data loss. How can vendors or developers access (and restore) the data from the backups Atlassian creates? Is there an Api for it? How long will these backups be accessible, what do they contain? – Does Atlassian backup data stored via the Storage Api?
Good question! At the moment there’s no way to self-service an app storage restore - this is something that may be added in future. In order to kick-off a restore, vendors would need to raise a request with Atlassian. The backup will contain everything stored in app storage for at least 30 days.
thanks a lot for all this clarity 
–badge in their forge-marketplace-listing as we already know it from Connect/Server apps?