[trustable-software] Git auditing tool

[trustable at panic.fluff.org]

>
>> 	Given we have to authenticate to GIT that authentication access
>> control is usually based on some role or group membership don't we
>> have this already through the act of authentication ?
>
> I take it that one concern here is to ensure that the process of 
> authenticating doesn't itself get compromised?
>

   So the same is entirely true about signing code. There is no reason why 
groups won't share signing keys and process any more than shared password 
and username situations. This has to be watched for. Code signing gives us 
no more protection than an unmanaged delivery of 
authentication/authorisation as seen in many git servers and gitano 
particularly.

> The reasons  for this in my experience so far have been:
>
> - friction/delay on establishing access for new/changed user
> - skill/knowledge gap, where a subset of engineers know how to do the work, 
> so they end up committing the work of those who don't
> - general policy where subcontractor organisation gets one 'id' for 
> submission into a system
>

I agree that the above are massive problems, but for many enterprises the 
ability to work and delivery solutions return revenue to the business has 
value. The inability to track work and authorisation become legal problems 
for them so this is something which quickly gains CISO/CEO visibililty and 
they'll fund fixes to the enterprise SO long as you don't invent yet 
another system for authorisation.

Anything which dis-intermediates between the business  and its actors 
raises massive problems for the business as has happend recently 
with business discovering they are in the cloud with customer data which 
is not known about to the rest of the business... People go to jail for 
this, and share holders asking direct questions of the board !


>> 	This requires us to be able to go back in time through the repository
>> and not just who the person was, but also what role they had when they
>> performed the action..
>
> Yes, this is a crucial point. In addition to policing and enforcing roles on 
> an ongoing basis, we need to be able to trace the historic states of the 
> project rules/roles/responsibilities at any time, which I think is a further 
> reason to consider that the metadata describing these project factors should 
> itself be held in VCS, rather than database storage.

I believe strongly that enhancing the meta data associated with the 
actions performed against the repositry and enforming them as actions 
which occur. I hope that this can be done in the meta data of the 
repository as it feels to me that code and meta data about the code should 
be together. [This is why I believe gerrit is useless as it has to have a 
seperate DB meaning the information linkage is lost]

         The issue which is missing the meta data assocaited with the roles 
assocaited with tasks. For example, it might be possible to say the 
following.

  * The act of creating a branch immediately puts you in the role of
    'subject matter expert' or 'designer'
    as this is a new feature tobe added, and requires the presence of
    some BDD test outline.

   * The act of pushing that branch to review means you are the
     "developer".

   * The act of merging that branch puts you in the role of
      "reviewer"

   * The act of Tagging a branch puts you in the role of
      "product owner"
    as the act of giving it a tag make is releasble.


But it is enforcing these roles and building the dashboard that report it 
a standard manner which is crucial to the trustable efforts



> The gitano server provides a good working implementation of this
> for git.

     It is my view that gitano has major issue as it invents yet another 
repository of identity and role information which causes problems with 
audit for any organisation I've worked with. In the same manner as people 
just signing code with some random pgp key they invent.

 	In all the enterprises I've worked with the issue is to make use 
of the existing Identiy and Access Management (IAM) platform and 
associated management tools. This typically is then implemented in access 
controls which exist within the Active Directory/LDAP environments. 
Placing this information in yet another text file which has be be managed 
by some random administrator without audit seems not to help with this 
delivery of trustable..



-- 
========================================================================
Edmund J. Sutcliffe                     Thoughtful Solutions; Creatively
<edmunds at panic.fluff.org>               Implemented and Communicated
<http://panic.fluff.org>                +44 (0) 7976 938841