Has anyone using Bugzilla dealt with auditors?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Has anyone using Bugzilla dealt with auditors?

Trent Ohannessian
Hello,

We're using Bugzilla to track our bugs.  Works wonderfully.  Now, we are
going through the process of being audited for company-wide security.
Our auditors want bug entry to be limited to a handful of people or a
group.  They don't want the developer to introduce unethical code.  If a
set of approvals and checkoffs are not in place, bad code could get out
there.  Sure, I'll buy that.  So they say that any new code or change in
code must originate from an official business request or a legitimate
problem ticket.  In their ideal world the problem tickets would be
generated by a group of people.  In our world, that doesn't work so
well.  Has anyone else run into this situation?  How was it handled?  Do
I stifle productivity and create a 'Create bugs' permission switch?

Thanks for any input,
Trent
_______________________________________________
mozilla-webtools mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-webtools
Reply | Threaded
Open this post in threaded view
|

Re: Has anyone using Bugzilla dealt with auditors?

Max Kanat-Alexander
On Mon, 2005-06-13 at 15:45 -0500, Trent Ohannessian wrote:
> They don't want the developer to introduce unethical code.

        ...To be honest, my answer to this is "then they should fire unethical
developers." 97.5% of the people I've ever known in development are just
trying to do their job and contribute something creative. It sounds like
they're trying to create a blanket solution to deal with an incredibly
small minority of people.

> If a set of approvals and checkoffs are not in place, bad code could get out
> there.

        You can use flags for that; that's what we do. You just enforce it as
part of the process. Bugzilla is just a process tool. I mean,
theoretically, somebody could introduce "unethical code" (*scoff*) by
just directly checking it in to CVS without any bug being filed at all!

> Sure, I'll buy that.  So they say that any new code or change in
> code must originate from an official business request or a legitimate
> problem ticket.

        You could add a free-text field to Bugzilla called "source of bug" or
something like that.

        I think it's possible that your auditors don't fully understand the
needs of your development process? Security is certainly important--
you're protecting the company from destruction. But that doesn't mean
that security itself should destroy the company. :-)

        -Max
--
http://www.everythingsolved.com/
Everything Solved: Experts at Bugzilla... and everything else, too.

_______________________________________________
mozilla-webtools mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-webtools
Reply | Threaded
Open this post in threaded view
|

RE: Has anyone using Bugzilla dealt with auditors?

Benton, Kevin
In reply to this post by Trent Ohannessian
> We're using Bugzilla to track our bugs.  Works wonderfully.  Now, we
are
> going through the process of being audited for company-wide security.
> Our auditors want bug entry to be limited to a handful of people or a
> group.  They don't want the developer to introduce unethical code.  If
a

Actually, it seems to me that having something in Bugzilla or not isn't
going to stop developers from introducing "unethical code."  If they
really want to do damage, they're going to do it behind everyone's back.
Bugzilla isn't a cop and was never intended to reach that potential.
What I would be more concerned about is potentially allowing Bugzilla to
be a gateway for releasing trade secrets or other confidential
information to unauthorized parties.

Frankly, I think it's appropriate to ask the auditors what they are
really after - what are they trying to accomplish.  Bugzilla isn't
designed to police development, merely provide a method for
communicating about development.

> set of approvals and checkoffs are not in place, bad code could get
out

As Max suggested, implement and start using flags or better yet - use
the QA process like it's supposed to be - if the QA people are the ones
giving the nod for a release, and without that nod, nothing goes out.
If most of your users don't have 'editbugs' privileges, they shouldn't
(if memory serves me correctly) be able to change the QA contact.
Regardless, if someone slips code in, how is Bugzilla going to be able
to point that out?

> there.  Sure, I'll buy that.  So they say that any new code or change
in
> code must originate from an official business request or a legitimate

Turn off editbugs for most of your users and make the new bug status
default UNCONFIRMED rather than NEW.

> problem ticket.  In their ideal world the problem tickets would be
> generated by a group of people.  In our world, that doesn't work so

If you use UNCONFIRMED as the initial status, only an authorized list of
people would be able to change the status from UNCONFIRMED to
ASSIGNED/RESOLVED.

> well.  Has anyone else run into this situation?  How was it handled?
Do
> I stifle productivity and create a 'Create bugs' permission switch?
I guess my question would be - what are the auditors really after?

Your auditors should know that "social engineering of development" from
a software perspective is nearly impossible.  How does software decide
what's ethical or not?  How does it allow for creativity and still quash
what management doesn't want?  Users who want to get around the system
are going to get around it.  Those who try to follow guidelines will do
their best, but often times, they're the ones who accidentally mess
things up.  Your auditors should be talking about things like "Change
Control Process" and "Quality Assurance" or "Validation" before release.

There is no way a company can operate efficiently if it can not at least
marginally trust its employees to do their jobs.  Granted, there are
always dangers of malevolent people (employees or otherwise) wanting to
"get back at the company", but that's what source control and backups
are for.  Bugzilla is not a source control manager and is not intended
to be one at this point.

---
Kevin Benton
Perl/Bugzilla Developer
Advanced Micro Devices
 
The opinions stated in this communication do not necessarily reflect the
view of Advanced Micro Devices and have not been reviewed by management.
This communication may contain sensitive and/or confidential and/or
proprietary information.  Distribution of such information is strictly
prohibited without prior consent of Advanced Micro Devices.  This
communication is for the intended recipient(s) only.  If you have
received this communication in error, please notify the sender, then
destroy any remaining copies of this communication.


_______________________________________________
mozilla-webtools mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-webtools
Reply | Threaded
Open this post in threaded view
|

Re: Has anyone using Bugzilla dealt with auditors?

Trent Ohannessian
In reply to this post by Trent Ohannessian
Hey Max.  Thanks for the reply.  Your last statement really hits home.
The security measures should help the process, not hinder it.  We kind
of pride ourselves in being quick to react with code fixes and whatnot,
but if we add more steps in the process the quickness is greatly
diminished.  And I have no doubt we'd fire an unethical developer, I
think the auditors just want to put more checks in place to possibly
reduce the chance of malicious code getting out there.  Or at least make
the unethical developer think twice before doing anything stupid.  Try
to stop it before it even happens.  Honestly though, if there was a
worker who was really T.O.'ed, he or she would get some bad code out
there.  They'd find a way around the checks.

I haven't worked that closely with the auditors, so I don't know the
level of their knowledge about our process.  My gut feeling is that
they're seeing our process right now from a very high level, and right
now we have very few checks and balances in place.

The flags idea is a good suggestion.  I'll check into that.

Max Kanat-Alexander wrote:

> On Mon, 2005-06-13 at 15:45 -0500, Trent Ohannessian wrote:
>
>>They don't want the developer to introduce unethical code.
>
>
> ...To be honest, my answer to this is "then they should fire unethical
> developers." 97.5% of the people I've ever known in development are just
> trying to do their job and contribute something creative. It sounds like
> they're trying to create a blanket solution to deal with an incredibly
> small minority of people.
>
>
>>If a set of approvals and checkoffs are not in place, bad code could get out
>>there.
>
>
> You can use flags for that; that's what we do. You just enforce it as
> part of the process. Bugzilla is just a process tool. I mean,
> theoretically, somebody could introduce "unethical code" (*scoff*) by
> just directly checking it in to CVS without any bug being filed at all!
>
>
>>Sure, I'll buy that.  So they say that any new code or change in
>>code must originate from an official business request or a legitimate
>>problem ticket.
>
>
> You could add a free-text field to Bugzilla called "source of bug" or
> something like that.
>
> I think it's possible that your auditors don't fully understand the
> needs of your development process? Security is certainly important--
> you're protecting the company from destruction. But that doesn't mean
> that security itself should destroy the company. :-)
>
> -Max
_______________________________________________
mozilla-webtools mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-webtools
Reply | Threaded
Open this post in threaded view
|

Re: Has anyone using Bugzilla dealt with auditors?

Trent Ohannessian
In reply to this post by Trent Ohannessian
Hey Kevin.  Thank you for your detailed reply.  You're right, Bugzilla
will not stop someone from introducing unethical code.  That's not it's
function.  I think the auditors want it (or something similar) to
provide checks and balances in our process.  They want people at
different levels (developer, qa, managers, etc) to sign off on all code
changes, and they want that to be well-documented.

I will most definitely check into the flags more.  I also like the idea
of having bugs start off in an UNCONFIRMED status, and only certain
people can move them from that status.

Our QA department currently gives the go or no go for things that move
into production, but right now that happens verbally.  We have a series
of meetings leading up to a release and if something shouldn't go they
say so and it is held up.  The auditors seem to want that more
formalized and documented.  I don't expect Bugzilla to point out code
that was slipped in.  If it did, some people could be making a ton of
money off of that technology. :)

Thanks again for your reply.  I'll take snippets of your and Max's
replies and send them to my manager.  Ultimately, it's his decision to
make.  I just give him as many options and perspectives as I can and let
him do the rest. :)

Trent

Benton, Kevin wrote:

>>We're using Bugzilla to track our bugs.  Works wonderfully.  Now, we
>
> are
>
>>going through the process of being audited for company-wide security.
>>Our auditors want bug entry to be limited to a handful of people or a
>>group.  They don't want the developer to introduce unethical code.  If
>
> a
>
> Actually, it seems to me that having something in Bugzilla or not isn't
> going to stop developers from introducing "unethical code."  If they
> really want to do damage, they're going to do it behind everyone's back.
> Bugzilla isn't a cop and was never intended to reach that potential.
> What I would be more concerned about is potentially allowing Bugzilla to
> be a gateway for releasing trade secrets or other confidential
> information to unauthorized parties.
>
> Frankly, I think it's appropriate to ask the auditors what they are
> really after - what are they trying to accomplish.  Bugzilla isn't
> designed to police development, merely provide a method for
> communicating about development.
>
>
>>set of approvals and checkoffs are not in place, bad code could get
>
> out
>
> As Max suggested, implement and start using flags or better yet - use
> the QA process like it's supposed to be - if the QA people are the ones
> giving the nod for a release, and without that nod, nothing goes out.
> If most of your users don't have 'editbugs' privileges, they shouldn't
> (if memory serves me correctly) be able to change the QA contact.
> Regardless, if someone slips code in, how is Bugzilla going to be able
> to point that out?
>
>
>>there.  Sure, I'll buy that.  So they say that any new code or change
>
> in
>
>>code must originate from an official business request or a legitimate
>
>
> Turn off editbugs for most of your users and make the new bug status
> default UNCONFIRMED rather than NEW.
>
>
>>problem ticket.  In their ideal world the problem tickets would be
>>generated by a group of people.  In our world, that doesn't work so
>
>
> If you use UNCONFIRMED as the initial status, only an authorized list of
> people would be able to change the status from UNCONFIRMED to
> ASSIGNED/RESOLVED.
>
>
>>well.  Has anyone else run into this situation?  How was it handled?
>
> Do
>
>>I stifle productivity and create a 'Create bugs' permission switch?
>
> I guess my question would be - what are the auditors really after?
>
> Your auditors should know that "social engineering of development" from
> a software perspective is nearly impossible.  How does software decide
> what's ethical or not?  How does it allow for creativity and still quash
> what management doesn't want?  Users who want to get around the system
> are going to get around it.  Those who try to follow guidelines will do
> their best, but often times, they're the ones who accidentally mess
> things up.  Your auditors should be talking about things like "Change
> Control Process" and "Quality Assurance" or "Validation" before release.
>
> There is no way a company can operate efficiently if it can not at least
> marginally trust its employees to do their jobs.  Granted, there are
> always dangers of malevolent people (employees or otherwise) wanting to
> "get back at the company", but that's what source control and backups
> are for.  Bugzilla is not a source control manager and is not intended
> to be one at this point.
>
> ---
> Kevin Benton
> Perl/Bugzilla Developer
> Advanced Micro Devices
>  
> The opinions stated in this communication do not necessarily reflect the
> view of Advanced Micro Devices and have not been reviewed by management.
> This communication may contain sensitive and/or confidential and/or
> proprietary information.  Distribution of such information is strictly
> prohibited without prior consent of Advanced Micro Devices.  This
> communication is for the intended recipient(s) only.  If you have
> received this communication in error, please notify the sender, then
> destroy any remaining copies of this communication.
>
>
_______________________________________________
mozilla-webtools mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-webtools
Reply | Threaded
Open this post in threaded view
|

Re: Has anyone using Bugzilla dealt with auditors?

Peter Kay
Trent Ohannessian wrote:
> Our QA department currently gives the go or no go for things that move
> into production, but right now that happens verbally.  We have a series
> of meetings leading up to a release and if something shouldn't go they
> say so and it is held up.  The auditors seem to want that more
> formalized and documented.  I don't expect Bugzilla to point out code
> that was slipped in.  If it did, some people could be making a ton of
> money off of that technology. :)

You're using QA contacts on the bugs, right?

--Peter
_______________________________________________
mozilla-webtools mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-webtools
Reply | Threaded
Open this post in threaded view
|

Re: Has anyone using Bugzilla dealt with auditors?

Trent Ohannessian
We weren't using the QA Contact previously, but we sure are in the new
release.  This was decided before our friendly auditors came to town.

Peter Kay wrote:

> Trent Ohannessian wrote:
>
>> Our QA department currently gives the go or no go for things that move
>> into production, but right now that happens verbally.  We have a
>> series of meetings leading up to a release and if something shouldn't
>> go they say so and it is held up.  The auditors seem to want that more
>> formalized and documented.  I don't expect Bugzilla to point out code
>> that was slipped in.  If it did, some people could be making a ton of
>> money off of that technology. :)
>
>
> You're using QA contacts on the bugs, right?
>
> --Peter
_______________________________________________
mozilla-webtools mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-webtools