What is the security model?

[haf]

Is your request:

• [ ] A feature request: The feature you want currently does not exist. If implemented, will provide additional value to you.
• [ ] A technical issue: You are unable to use Shippable's service per your expectation & need help to resolve the issue.
• [x] A question: A technical question such as not billing.

Simply put; what's Shippable's security model?

• OAuth for authentication?
• Do you ensure the right owner is accessing the links with hexadecimals in them? (/project etc)
• How do you protect containers from interfering with each other?
• Who can access the physical machines and in what country are they?
• How do I ensure a developer of mine who has left the bitbucket org no longer has access? Do you check on every request?
• How do you store the private keys I give you?
• How can you ensure noone but my build can access the private keys?
• Are the private keys AES (or similar)-encrypted in storage?
• Do all of your servers have encrypted connections in between?
• How do you secure your CA that generates certificates for communication between your infrastructure servers?
• Have you performed an pentest to test your defenses?
• Are you OK with me performing a pentest?

Thanks, Henrik

[rageshkrishna]

Hi @haf! We definitely would like to address any concerns you have with the security of our service. Can you please email me (ragesh@shippable.com) or Manisha (manisha@shippable.com) to talk about this in more detail? Thanks!

[manishas]

Closing this issue since this will be followed up over email.

[rvrignaud]

Hi @rageshkrishna ,

Is there any particular reason that your security model is not publicly described ? I think there is a lot of people interested like @haf is.

[haf]

I agree that it should be public. I just wanted to give some metadata at this point. I did ask the same questions over e-mail which had answers that prompted more questions. I sent these questions the 6th May and am yet to receive a response.

[avinci]

Let me try and take a stab at the questions

1. We use Oauth wherever its possible. In some of our integrations, oAuth is not a possibility, we use basic Auth. Mostly to do with Docker Hub.
2. I am not sure what you mean by right owner? Our model is that we internally sync with source control providers every 4 hrs. This means if a user is removed from the source control, it might take up to 4 hours to remove them from our system. The users Shippable API token is mapped to these permissions and hence every single call, our API token is validated against the current permissions allowed by the source control system (can be a 4 hr lag worst case). Since every single call to our API is validated, we are alway ensuring the right level of authorization is taking place
3. Each container is running on a separate VM. VMs are on a subnet where no internal traffic is allowed. Hence there is no way one container can talk to another container running on a different machine. Within the same machine, i.e. if you use docker compose or something, we are not aware of those containers.
4. We use AWS, us-east-1 DC. They are in USA and in Virginia, the policies that AWS enforces is what we rely on
5. Do we check on every request. Yes, we do. There is a 4hr lag between our sync's and hence if you remove a user, it might take up to 4 hrs to sync
6. Private keys are stored in an encrypted fashion on a DB which is running on a completely separate private subnet. No system can access this subnet , other than the API system. They are decrypted when needed. The key for description is at each subscription level and we don't have any master key to decrypt them. We have put in a lot of effort to make sure there is no master key for shippable. Everything is happening at a customer's subscription level. Our entire VPC is accessible only through 1 jump box which is secured and only approved people (this is a very few list of background checked folks and have been with the company for atleast 2 years) at Shippable have access to jump box.
7. As i mentioned, there is no way to decrypt your key other than with your subscriptions's encryption key. Only the build system has the ability to decrypt it
8. We encrypt the keys at rest. I am not sure of AES, but will check on it
9. Servers cannot talk to each other. We use a message bus to manage all traffic and that traffic is encrypted. The only traffic thats not encrypted is the communication between API and DB, but since data at rest is encrypted, and no one else cannot connect to that subnet, we should be fine on that traffic
10. CA certs are done only by 2 people in the company and its kept on a system that no-one has access to. Our production infra is setup by automation and only the folks who have access to prod system can access the automation infra. Key setup is done manually
11. We have done a pentest before our latest release. We are going to scheduling 1 soon and will be happy to share the results.
12. Lets get our pen test done and if you still feel that you want do another one, lets schedule a time once we are done with our tests and we are happy to accommodate it. We need a bit more information about you etc. before we can let you do that :-)

Let me know if you need any more info around this. Some of the core team worked on Xbox live infra and we have used the same grade that we used at XBOX live as the way to design the system. Of course we rely on AWS and can do as much as they can in terms of DC. But I am sure AWS is 50x more worried about this and hence its a fair bet to use AWS.

[avinci]

i am closing this. Please re-open if you need further info

[haf]

Thank you for the well written replies.