Custom post type is defined with special parameter ‘capability type’:
(string or array) (optional) The string to use to build the read, edit, and delete capabilities. May be passed as an array to allow for alternative plurals when using this argument as a base to construct the capabilities, e.g. array(‘story’, ‘stories’) the first array element will be used for the singular capabilities and the second array element for the plural capabilities, this is instead of the auto generated version if no array is given which would be “storys”. The ‘capability_type’ parameter is used as a base to construct capabilities unless they are explicitly set with the ‘capabilities’ parameter. It seems that `map_meta_cap` needs to be set to false or null, to make this work (see note 2 below).
Read this article for more details.
If custom post type uses the same capability type as the WordPress built-in ‘post’ does, that is ‘post’, then this custom post type is protected by the same capabilities set: edit_posts, ‘delete_posts’, ‘publish_posts’, etc.
Any capability, like ‘edit_posts’ is granted to a role, not to a custom post type, or WordPress built-in type post. Capabilities groups to the left in a User Role Editor just shows a kind of permissions required for access to the functionality related to a group. Thus if few post types uses the same capability type you change access to all of them at once when you revoke ‘edit_post’ from a role. It does not matter which group (custom post type) you use to find ‘edit_posts’ and turn OFF its checkbox.
If you need to manage access to all custom post types separately there is a special option (Pro version only) at “Settings->User Role Editor->Additional Modules”: “Activate force custom post types use their own capabilities”.
You have to aware that, if you turn this option ON, then you need to check roles if they have needed capabilities, e.g. ‘edit_attachments’, etc., as every post type will get its own capability type: post type ‘video’ – ‘edit_videos’, ‘project’: ‘edit_projects’, etc.