<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Matt, <br>
The intent of the application to security software was meant to address
cyber security. What I was going for was for the SW assurance to
complement, but not supersede cyber security. What other software
security did you have in mind?<br>
<br>
Kelly<br>
<br>
Matt Bickley wrote:
<blockquote cite="mid:4A71FCBF.90206@jlab.org" type="cite">
<pre wrap="">Kelly Mahoney wrote:
<snipped>
</pre>
<blockquote type="cite">
<pre wrap="">This procedure only applies to security software configuration items
insofar as the impact ineffective security software controls may
materially affect operations and safety.
</pre>
</blockquote>
<pre wrap=""><!---->
Kelly,
Did you mean the paragraph above to refer to cybersecurity in
particular, or do you really want to include all security
software in the scope?
Graham Heyes wrote:
</pre>
<blockquote type="cite">
<pre wrap="">As far as FPGAs are concerned they should be exempt in everything except safety interlocks and systems controlling hardware that would cause damage or injury if the FPGA misbehaved.
</pre>
</blockquote>
<pre wrap=""><!---->
I don't agree with Graham. A QA process doesn't just try
to protect us from misbehaving software, it also ensures
that we can maintain and support our software products. If we
have an FPGA critical to data acquisition and programmed with code
that lives on some person's PC (and not backed up), and that person
leaves the lab, what does the lab do if it needs to be modified?
Who knows where the code is, or what it does? A good QA process will
ensure we have the documentation and data to continue to provide
support. Without the QA process the lab would have to start over.
</pre>
</blockquote>
</body>
</html>