[B! リスク] hiroaki256のブックマーク

GitHub Copilot のセキュリティ・ライセンスに関する懸念の調査メモ

GitHub Copilot を業務で利用するとなると、以下の 2 つの懸念がある。自社のプライベートなコードが GitHub Copilot に送信され、学習モデルとして使われ、外部に流出してしまわないか自動生成されたコードが学習モデルとなった public なコードのライセンスを侵害してしまわないか 1 については、コードの一部なら大きな問題にはならないと思われるが、もし一時的にエディタに貼っていたクレデンシャルが送信されて外部流出してしまう可能性があるのであればリスクが低いとは言いづらい。 2 については、ライセンスを侵害すること自体がリスクである。それに加えて、GitHub Copilot がよそのライセンスを侵害する可能性があることがあとから発覚した場合、それまでに GitHub Copilot を使って書かれたコードすべてを精査しなくてはいけなくなる可能性があるのもリスクと

hiroaki256 2023/02/18

リンク

リスクの洗い出しと判断のコツ - やしお

会社で係長的なポジションになって3年近くが経った。先日、副係長というか職長的なポジションが新たに設けられ、30歳前後のメンバーが就いた。折を見て彼らに伝える機会があるかもしれないし、3年やってみた知見を自分の中で一度整理しておきたいと思った。（大手メーカーの製造側に近い部門で働いている、という前提がある。）自分が苦しくならないようにする究極的には本人が自分でスタイルを確立するしかない。「こうした方がより良い」と思って行動変容しても、それで自分が苦しくなるなら続けられない。どうせ正解の型が一意に決まるわけではないし、仮に正解の型があっても自分を完全にはめ込むこともできない。「自分がやれるようにやるだけ」くらいに思っている方が精神衛生に良い。それで不適格ならしょうがない。一方で「より良い方法」に寄せる努力も必要で、その間のバランスが必要になる。例えば自分自身は、人付き合いがすごく

hiroaki256 2021/12/22

リンク

半導体不足は「ジャストインタイム」が生んだ弊害、TSMCが急所を握る自動運転車

新型コロナウイルス感染症（COVID-19／以下、コロナ）の感染が世界に拡大する直前の2020年2月11日にお亡くなりになった野村克也氏は、プロ野球の監督時代に、「勝ちに不思議の勝ちあり、負けに不思議の負けなし」という名言を残している（『負けに不思議の負けなし』（朝日文庫）という著書もある）。これは、「勝負は時の運と言うが、偶然勝つことはあっても、偶然負けることは無い」という意味だ。つまり、負けた場合、そこには必ずそれなりの理由があるということである。 2021年に入ってから現在に至るまで、車載半導体の供給不足のためにクルマがつくれないというニュースが連日報道されている。2月初旬に米テキサス州を襲った寒波でドイツのInfineon　Techno logiesとオランダのNXP Semiconductorsの半導体工場が停止し、3月19日にルネサス那珂工場で火災が発生した。さらに4月14日、

hiroaki256 2021/04/22

リンク

一括請負契約はソフトウェア開発にやっぱり向いていない - プログラマの思索

一括請負契約はソフトウェア開発にやっぱり向いていない、と改めて感じた。理由は2つある。【参考】 ERPの落とし穴part4～システム移行という名のデスマーチ: プログラマの思索システムのリプレース案件が最も危険な理由: プログラマの思索請負契約がソフトウェア開発者を苦しめている: プログラマの思索【1】1つは、発注者は外部ベンダーにリスク転嫁しているつもりでも、リスク転嫁できていない。結局、発注者に全てリスクで跳ね返ってくる。発注者は、要件定義でガチガチに仕様を固めて、その仕様通りにリリースできたとしても、もし本番障害があれば、瑕疵担保責任でベンダーに追求できる。民法の請負契約では、受託側は成果物の完成責任があるからだ。しかし、その契約スタイルはソフトウェア開発になじまない。たとえば、発注者が要件定義や外部設計をまとめて、ベンダーに開発工程を一括請負で委託したら、それが

hiroaki256 2021/03/13

リンク

「リスクゼロ以外、許容できない」という人たちに遭遇するけど、多分それは、みんな不幸になる考え方。

今日書きたいことは、「世の中にはリスク管理の考え方が苦手な人が結構な数いて割と困る」という話です。よろしくお願いします。「リスクアセスメント」って皆さん聞いたことありますか？なんかアセスメントっていうと小難しい感じの言葉になりますが、要はある物事についてのリスクの評価をする為の手順っていうかやり方みたいなもんでして、ざっくりと「どんなリスクがあるかを考える」「そのリスクの大きさや発生確率について考える」「そのリスクに対してどう対応するか、あるいはしないかを考える」というようなプロセスで進めるものなんです。私が知っている限りだと、情報セキュリティマネジメントの一分野としてまとめられているものが一番分かりやすいです。 IPA(情報処理推進機構)のページで読めます。色々面白いです。 https://www.ipa.go.jp/security/manager/protect/pdc