Provide mechanism to execute electronic signatures on approval

[jorgecarleitao]

Select Topic Area

Product Feedback

Body

Hi!

I would like to propose that repository administrators of github Enterprise are allowed to "tick a box" whereby certain pull request approvals require 2FA/password typing as part of the approval process.

Background

There are several industries where certain approvals require what is known as an electronic signature. For example, in medical / pharma, one of such requirements comes from FDA's Part 11.

In summary, the requirement is that, under certain conditions, the approval must not only be done by an authenticated user via an action (press a button), but it must also include a step that can be technically equivalent to an electronic signature (e.g. write username and password, type username + 2FA, mileage vary).

This flow is very similar to github's own model where certain actions on github require the user to type their password or 2FA as a security control.

Why it matters

Currently, regulated industries manage content resulting from software development, particularly documentation and configuration lists, in a myriad of places such as Word documents, excel sheets and PDFs. This content usually has the same lifecycle as source code (think of: 1.2.3 of the software has a risk assessment associated with its release).

Due to the nature of the content (technical specifications, formal requirements, risk assessment conducted by multiple people), it must be controlled. This implies a strong process over who is authorized to make changes, a record of all changes, who, when and what was changed, a change log. You know, what github already offers via git, PR, code owners, etc.

Likewise, due to the software's critically, merges to main that result in a release to production must be approved.

Many development teams in regulated industries have started using git to manage documentation (look for "documentation as code"), just like they manage documentation and release notes in open source (see here for more context within in pharma).

The problem

A critical limitation of this approach is that none of existing git management systems (github, gitlab, ADO, etc.) support a form of "approval beyond pressing a button". This implies that organizations cannot map a PR approval to an electronic signature. Consequently, the approval process cannot be established in the git management system, like we all love.

Instead, during deployment, e.g. a markdown needs to be converted to PDF, uploaded somewhere, a bunch of emails be sent to ping people, the approval needs to happen, and then the document needs to be linked back in the repository to "establish that the approval is in place".

I do not have exact numbers, but knowing the industry, this process has massive negative impact to productivity. It also has negative implications to software quality, developer experience, and patient safety. It also makes github less useful for DevOps, as it is severely hampered by this "side approval flow".

This process is largely outdated and needs to be changed industry-wide. Narrowing to its core, there is currently a technical limitation forbidding the process from being done on Github - we cannot state "this PR was approved on this date by this person via electronic signature".

Proposal

The proposal is to allow admins or some other role to be able to configure the repository so that, when people approve a PR, they are prompt with the type of prompt that they prompted when they try to make a major modification to their account on github. Something along the lines of "you are about to approve PR X, please type your password / 2FA to confirm".

This may sound completely ridiculous for someone that is not in these industries that approves multiple PRs per day. I urge you to interview Github customers in Pharma, Banking and medical devices to understand their devops experience (not only development).

There is a bureaucratic step of arguing that whatever github implements is an electronic signature, but FDA is adamant that it must be more than a pressing a button. In most systems I know, the signature is executed by typing username + password (part 11 is explicit about what is required, but again, mileage vary by industry).

With this feature, in my opinion (we should reach e.g. FDA and EMA) would enable organizations to interpret this action as the execution of an electronic signature, thereby allowing the full lifecycle and approval process to happen within Github.

My anecdotal evidence is that the pain is currently so high that many would prefer "all PRs require password/2FA" over "the current process of signatures somewhere". This can be further improved to allow more control over what needs password/2FA.

In my opinion, allowing a full devops story within github for Pharma and medical devices will ultimately result in better medical outcomes of existing products and shorter time to market of new ones.

[Ika1009]

Hi @username (Note: replace 'username' with the user's actual GitHub handle),

Thank you for taking the time to provide such a comprehensive and detailed suggestion related to the enhancement of pull request approvals in Github Enterprise. We genuinely appreciate the effort you've put into articulating the background, the current problems faced by specific industries, and your proposed solution.

The Concern:
You've clearly highlighted the unique needs of regulated industries where specific approvals go beyond just 'clicking a button'. Electronic signatures, especially for sectors like medical/pharma, have very stringent requirements set by bodies like the FDA. The concept of "electronic signature" is one that ensures greater accountability and security over processes, and your proposal to integrate this into Github's PR approval process would indeed be a groundbreaking advancement.

Potential Benefits:
Introducing this feature could revolutionize the way certain industries use GitHub. By allowing PR approvals to function as electronic signatures, we could potentially see:

1. Enhanced productivity by reducing the dependency on side processes like document conversions, emailing, and external approvals.
2. Improved software quality and patient safety.
3. A streamlined DevOps experience for these sectors.

Next Steps:
Your idea of integrating an electronic signature-like process, via password/2FA confirmations for PR approvals, certainly holds merit. As you rightly pointed out, while this might seem cumbersome for daily PRs in some industries, the benefits it offers to regulated sectors are massive. We will definitely consider the implications, both technical and regulatory, and evaluate the feasibility of such an implementation.

In the interim, we might also explore engaging with representatives from industries like Pharma, Banking, and Medical Devices, as you've suggested, to gain deeper insights into their DevOps experience.

Once again, thank you for bringing this to our attention. Ideas like these push the boundaries of what's possible and inspire continuous improvement.

Warm Regards

[rwhalley]

Hi there, I'm a former tech founder of a medical device company. Adding an option within an organization to enable Part 11 digital signatures with the small change @jorgecarleitao mentioned, would add a huge amount of value to the industry, and is something I'm very interested in. Even as we speak, I'm starting a new medical project and having trouble deciding how to do exactly this: digital signatures. In my experience, this one requirement led us to spending tens of thousands of dollars a year in money (which is standard), whether it was for coding a custom solution, running validations, or signing up for eDMS services that gave us the right amount of flexibility for our record keeping. Companies like DocuSign have recently implemented a Part 11 service for PDFs and I think are gaining decent traction. Opening up the possibility of digital signatures with plaintext/Markdown/CSV data would be amazing due to its minimal size and portability, even though there are some drawbacks there in terms of training personnel and integration of tables/headers. Even if this isn't the perfect solution, yet, it's a step towards something that could make documentation more accessible, efficient, and compliant and support the development of safer, more compliant, medical devices. Please keep me posted!

[andybrown-naitive]

Hi, I would also like to support @jorgecarleitao 's request here, which he has articulated the issue extremely well. Approvals of the code, particularly in regards to merging to main for release builds in medical devices needs this level of signatory approval, and as a very small company with mainly Devs and DevOps, keeping this all in the tool we are already using would be a significant boon to our approvals process flow. I would be very keen to hear if there have been any updates since Dec 2023 on this. Cheers Andy

[Thilaknath]

Hello @Ika1009 Its been more than a year. Was there some improvements at your end for this feature implementation ?

[Thilaknath]

Select Topic Area

Product Feedback

Body

Hi!

I would like to propose that repository administrators of github Enterprise are allowed to "tick a box" whereby certain pull request approvals require 2FA/password typing as part of the approval process.

Background

There are several industries where certain approvals require what is known as an electronic signature. For example, in medical / pharma, one of such requirements comes from FDA's Part 11.

In summary, the requirement is that, under certain conditions, the approval must not only be done by an authenticated user via an action (press a button), but it must also include a step that can be technically equivalent to an electronic signature (e.g. write username and password, type username + 2FA, mileage vary).

This flow is very similar to github's own model where certain actions on github require the user to type their password or 2FA as a security control.

Why it matters

Currently, regulated industries manage content resulting from software development, particularly documentation and configuration lists, in a myriad of places such as Word documents, excel sheets and PDFs. This content usually has the same lifecycle as source code (think of: 1.2.3 of the software has a risk assessment associated with its release).

Due to the nature of the content (technical specifications, formal requirements, risk assessment conducted by multiple people), it must be controlled. This implies a strong process over who is authorized to make changes, a record of all changes, who, when and what was changed, a change log. You know, what github already offers via git, PR, code owners, etc.

Likewise, due to the software's critically, merges to main that result in a release to production must be approved.

Many development teams in regulated industries have started using git to manage documentation (look for "documentation as code"), just like they manage documentation and release notes in open source (see here for more context within in pharma).

The problem

A critical limitation of this approach is that none of existing git management systems (github, gitlab, ADO, etc.) support a form of "approval beyond pressing a button". This implies that organizations cannot map a PR approval to an electronic signature. Consequently, the approval process cannot be established in the git management system, like we all love.

Instead, during deployment, e.g. a markdown needs to be converted to PDF, uploaded somewhere, a bunch of emails be sent to ping people, the approval needs to happen, and then the document needs to be linked back in the repository to "establish that the approval is in place".

I do not have exact numbers, but knowing the industry, this process has massive negative impact to productivity. It also has negative implications to software quality, developer experience, and patient safety. It also makes github less useful for DevOps, as it is severely hampered by this "side approval flow".

This process is largely outdated and needs to be changed industry-wide. Narrowing to its core, there is currently a technical limitation forbidding the process from being done on Github - we cannot state "this PR was approved on this date by this person via electronic signature".

Proposal

The proposal is to allow admins or some other role to be able to configure the repository so that, when people approve a PR, they are prompt with the type of prompt that they prompted when they try to make a major modification to their account on github. Something along the lines of "you are about to approve PR X, please type your password / 2FA to confirm".

This may sound completely ridiculous for someone that is not in these industries that approves multiple PRs per day. I urge you to interview Github customers in Pharma, Banking and medical devices to understand their devops experience (not only development).

There is a bureaucratic step of arguing that whatever github implements is an electronic signature, but FDA is adamant that it must be more than a pressing a button. In most systems I know, the signature is executed by typing username + password (part 11 is explicit about what is required, but again, mileage vary by industry).

With this feature, in my opinion (we should reach e.g. FDA and EMA) would enable organizations to interpret this action as the execution of an electronic signature, thereby allowing the full lifecycle and approval process to happen within Github.

My anecdotal evidence is that the pain is currently so high that many would prefer "all PRs require password/2FA" over "the current process of signatures somewhere". This can be further improved to allow more control over what needs password/2FA.

In my opinion, allowing a full devops story within github for Pharma and medical devices will ultimately result in better medical outcomes of existing products and shorter time to market of new ones.

This is a very valid request. We are in the same boat. I have gone as far as maintaining SOP's in github, Enforcing verified commits for the repository, Have Codeowners, Custom workflows to review the incoming changes. The only missing requirement is the e signature implementation.

[arobinson-consynsys]

@Thilaknath @rwhalley @andybrown-naitive - any progress that you are aware of on this front? I have the opportunity to "start from scratch" with respect to document management at a very small scale so I have the ability to experiment with various workflows. Curious if you have seen anything that might move this effort forward.